本文主要记录在看小林coding 时的一些体会，会记录一些我认为重要的知识点以及感受

网络基础篇

osi 七层协议
tcp/ip 四层协议 应用层 传输层 网络层 网络接口层

实际场景：

• 输出网址 到 网页显示 过程
• url 解析（协议+web 服务器 + 数据源路径）
• 生成 http 请求消息
• 服务器地址查询（dns）获取ip 地址
  先访问本地dns查重是否存在缓存 若不存在可以使用递归查询或者迭代查询 将最终查询结果缓存在本地dns
• 调用协议栈
  协议栈包括上下两部分 上部分 为tcp/udp 下部分 为ip 进行网络包传送以及确定路由
• tcp 发送 添加tcp 头部 三次握手建立连接 数据分割等操作 生成tcp 报文
• ip 发送 添加ip头部 利用路由表确定网卡（源ip）
• mac 头部 若arp 缓存中包含接收方的mac 地址，取出使用； 若不包括需要arp 进行广播，获取接收方mac 地址
• 网卡 ，增加报头和起始分帧符，校验序列
• 交换机（mac地址），路由器 根据路由表寻找下一跳地址
• 服务器收到客户端请求，进行拆包，将需要信息封装后再发送到客户端

linux收发网络包流程

• 接收数据
  首先会以DMA的方式把网卡上收到的帧写到指定内存（ring buffer）里。再向CPU发起一个中断，以通知CPU有数据到达。当CPU收到中断请求后，会去调用网络驱动注册的中断处理函数。 网卡的中断处理函数并不做过多工作，发出软中断请求，然后尽快释放CPU。ksoftirqd检测到有软中断请求到达，调用poll开始轮询收包（sk_buff），收到后交由各级协议栈处理。对于UDP包来说，会被放到用户socket的接收队列中。
• 发送数据
  数据拷贝到内核sk_buff ，tcp便复制一份用于超时重传
  添加报头， 软中断通知网卡驱动，sk_buff 放在ring buffer 中

http

http 是一个双向协议

状态码

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

• 「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。

• 「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

• 「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

• 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。

• 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

  301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

• 「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

• 「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。

• 「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。

• 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

• 「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。

• 「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。

• 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

• 「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。

常见字段

• host
• contentlength（解决tcp 沾包问题 ，body 长度）
• keep - alive （http 1.1）
• GET POST
  如果从 RFC 规范定义的语义来看：
  GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。所以，可以对 GET 请求的数据做缓存，这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），而且在浏览器中 GET 请求可以保存为书签。
  POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。所以，浏览器一般不会缓存 POST 请求，也不能把 POST 请求保存为书签。

缓存

• 强制缓存 只要缓存没有过期就直接使用浏览器缓存 状态码 200
  利用cache control 与 expires 来进行控制缓存有效期 ，cache control 优先级高于expires
• 协商缓存 状态码 304 字段 if none match 和if modified since
  last modified 表示最后修改时间
  鹅汤唯一标识相应资源 （优先级更高）
  

http协议

http1.1

优点： header+body 易于理解， 简单易于扩充，应用广泛跨平台

缺点：无状态（可以添加cookie 缓存信息）， 明码传输 ，不安全（https 解决）

特点：长连接，减少tcp连接到重复建立产生的开销，减轻负担，长时间无连接自动断开

性能瓶颈：

1. 相同首部信息冗余，浪费
2. 队头阻塞 请求应答模式导致
3. 服务器被动影响

优化：

1. 合并请求： 以一个大资源的请求替换多个小资源的请求
2. 数据压缩

http2.0

1. 头部压缩 ： hpack 算法 服务器和客户端同时维护一张信息表，发送索引号提高速度
2. 二进制格式：帧传输，分为头信息帧和数据帧
3. 并发传输 ： 多个stream 复用在一条tcp连接
   针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。
   
4. 服务器推送
   客户端和服务器双方都可以建立 Stream， Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。

缺点：
队头阻塞无法真正解决，是因为tcp协议的问题。一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

http3.0（quic）

• 无队头阻塞
  QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题
• 更快的连接建立
  HTTP/3 的 QUIC 协议并不是与 TLS 分层，而是 QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS/1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商
• 连接迁移
  tcp，当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立连接。而 QUIC 协议通过连接 ID 来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

https协议

相比http 增加了ssl/tsl 安全协议，端口号（443） 协议需要第三方（CA）保障

• 混合加密
  利用非对称加密进行交换密钥，采用交换密钥进行对称传输信息
• 摘要算法和数字签名
  计算哈希值确保传输内容未被更改
• 数字证书 第三方认证
  
  建立过程（rsa）：
• 发送协议版本，随机数和密码套件
• 确认版本，发送数字证书加随机数
• 利用浏览器中公钥 获取随机数，并进行加密另一个随机数 发送

HTTPS 协议本身到目前为止还是没有任何漏洞的，即使你成功进行中间人攻击，本质上是利用了客户端的漏洞（用户点击继续访问或者被恶意导入伪造的根证书），并不是 HTTPS 不够安全。

通过 HTTPS 双向认证来避免被中间人抓取数据

rsa 与 ecdhe

rsa：因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。

RSA 和 ECDHE 握手过程的区别：

• RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密；
• 使用了 RSA 密钥协商算法，TLS 完成四次握手后，才能进行应用数据传输，而对于 ECDHE 算法，客户端可以不用等服务端的最后一次 TLS 握手，就可以提前发出加密的 HTTP 数据，节省了一个消息的往返时间（不懂）；
• 使用 ECDHE， 在 TLS 第 2 次握手中，会出现服务器端发出的「Server Key Exchange」消息，而 RSA 握手过程没有该消息；

rpc

RPC（Remote Procedure Call），又叫做远程过程调用。它本身并不是一个具体的协议，而是一种调用方式。

服务发现

在 HTTP 中，你知道服务的域名，就可以通过 DNS 服务去解析得到它背后的 IP 地址，默认 80 端口。

而 RPC 的话，一般会有专门的中间服务去保存服务名和IP信息，比如 Consul 或者 Etcd，甚至是 Redis。想要访问某个服务，就去这些中间服务去获得 IP 和端口信息。由于 DNS 也是服务发现的一种，所以也有基于 DNS 去做服务发现的组件，比如CoreDNS。

底层连接形式

以主流的 HTTP/1.1 协议为例，其默认在建立底层 TCP 连接之后会一直保持这个连接（Keep Alive），之后的请求和响应都会复用这条连接。

而 RPC 协议，也跟 HTTP 类似，也是通过建立 TCP 长链接进行数据交互，但不同的地方在于，RPC 协议一般还会再建个连接池进行复用。

传输的内容

基于 TCP 传输的消息，消息头 Header +消息体 Body。
RPC，定制化程度更高，可以采用体积更小的 Protobuf 或其他序列化协议去保存结构体数据，同时也不需要像 HTTP 那样考虑各种浏览器行为，比如 302 重定向跳转啥的。因此性能也会更好一些，这也是在公司内部微服务中抛弃 HTTP，选择使用 RPC 的最主要原因。
http2.0 其实可能性能会更好但是由于历史原因。

WebSocket

• TCP 协议本身是全双工的，但我们最常用的 HTTP/1.1，虽然是基于 TCP 的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的 WebSocket 协议。
• 在 HTTP/1.1 里，只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。
• 对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用 WebSocket 协议。