Web 性能优化 - TCP

原文： https://jkchao.cn/article/5a2...

TCP 负责在不可靠的传输信道之上提供可靠的抽象层，向应用层隐藏了大多数网络通讯的复杂性能，好比丢包重发、按需发送、拥塞控制及避免、数据完整，等等。采用 TCP 数据流能够确保发送的全部字节可以完整地被接收到，并且客户端的顺序也同样。

可是 TCP 设计并未过多顾及时间，由此给浏览器 Web 性能带来了挑战。

三次握手

全部 TCP 链接一开始都必须通过三次握手。客户端与服务器在交换应用数据以前，必须就起始分组序列号，以及其余一些链接相关的细节达成一致。处于安全考虑，序列号由两端随机生成。

• SYN

  客户端选择一个随机序列号 x，并发送一个 SYN 分组，其中可能还包含 TCP 标志和选项。

• SYN ACK

  服务器给 x 加 1，并选择本身的一个随机序列号 y，追加本身的标志和选项，而后返回响应。

• ACK

  客户端给 x 和 y 加 1，并发送握手期间的最后一个 ACK 分组。

客户端能够在发送 ACK 分组以后当即发送数据，而服务器必须等接收到 ACK 分组以后发送数据。

每一个 TCP 链接都要通过三次握手，假若客户端与服务器距离过长，会形成很是大的性能影响。于是，提高 TCP 性能关键在于想办法重用链接。

为解决这个问题，人们在积极寻找各类方案，其中长连接（Keep-Alive）、负载均衡、TFO(tcp fast open)即是其中的一些解决办法。

长连接

Keep-Alive，HTTP 1.1 以后默认开启，指在一个 TCP 链接中能够持续发送多份数据而不会断开链接。

负载均衡

基本原理：客户端（如：ClientA）与负载均衡设备之间进行三次握手并发送 HTTP 请求。负载均衡设备收到请求后，会检测服务器是否存在空闲的长连接，若是不存在，服务器将创建一个新链接。当 HTTP 请求响应完成后，客户端与负载均衡设备协商关闭链接，而负载均衡则保持与服务器之间的这个链接。当有其余客户端（如：ClientB）须要发送 HTTP 请求时，负载均衡设备会直接向服务器之间保持的这个空闲链接发送 HTTP 请求，避免来因为新建 TCP 链接形成的延时和服务器资源耗费。

TFO(tcp fast open)

尽管开启了长连接，但是依然有35%的请求是从新发起一条链接，而握手会形成必定的延迟，TFO 的目标就是为了去除这个延迟，在三次握手期间也能交换数据。

基本原理：

• 客户端发送 SYN 包，包尾加一个 FOC 请求，只有4个字节。
• 服务端收到 FOC 请求，验证后根据来源 ip 地址生成 Cookie（8个字节），将这个 cookie 加载到 SYN + ACK 包的末尾，发送至客户端。
• 客户端缓存获取到的 Cookie 能够给下一次使用。
• 下一次请求开始，客户端发送 SYN 包，这时候后面带上缓存的 Cookie，而后就开始正式发送数据。
• 服务器验证 Cookie 正确，将数据交给上层应用处理获得相应结果，而后在发送 SYN + ACK，再也不等待客户端的 ACK 确认，即开始发送相应数据。

网络拥塞

拥塞：即对供不该求，对资源的需求超过了可用的资源，网络性能降低，整个网络的吞吐量随之负荷的增大而减少，甚至会发生拥塞崩溃的现象。

为了减缓网络拥塞现象，TCP 加入许多机制用来控制双向发送数据的速度。如流量监控、拥塞控制、拥塞预防机制等。

流量控制

流量控制是一种预防发送端过多向接收端发送数据的机制。

滑动窗口是实现流量控制的一种方法，一个简单例子：

设 A 向 B 发送数据。在创建链接时，B 告诉了 A：“个人接收窗口值 rwnd = 400“ （rwnd: receiver window），所以，发送方的发送窗口不能超过接收方给出的接收窗口的数值。TCP 窗口的单位时字节，并非报文段。设每一个报文段的字节长 100，而数据报文段序号的初始值为 1，大写 ACK 表示首部中的确认位 ACK，小写 ack 表示确认字段的值 ack。

从图中能够看出，B 进行了三次流量控制。第一次把窗口减小到 rwnd = 300，第二次又减小到了 rwnd = 100，最后减到 rwnd = 0，即不容许发送数据了。

当 rwnd = 0 时，则意味着必须由应用层先清空缓存区，才能接收剩余数据。这个过程贯穿于每一个 TCP 链接的整个生命周期：每一个 ACK 分组都会携带相应的最新的 rwnd 值，以便两端动态调整数据流，使之适应发送端和接收段的容量及处理能力。

慢启动

尽管流量监控能够防止发送端向接收端过多发送数据，可是发送端和接收端在链接创建之初，并不知道可用带宽是多少，所以须要一个估算机制，而后还能够根据网络中不断变化的条件而动态改变速度。

拥塞控制：防止过多的数据注入到网络中，这样可使网络中的路由器或链路不致于过载。

慢启动是实现拥塞控制的一种方法，此外还有拥塞预防、快速重发和快速恢复。

慢启动，便是在分组被肯定之后，增大窗口大小，慢慢启动。

具体实现以下：

• 发送方经过 TCP 链接初始化并维护一个拥塞窗口变量（cwnd）。并规定发送端与接收端之间最大能够传输的数据量为接收窗口（rwnd）与拥塞窗口（rwnd）的最小值。

  cwnd 最初的值只有一个 TCP 段，1999年提高至 4 个 TCP 段，2013年，提高至 10 个 TCP 段。

• 发送端向接受端发送 TCP 段后，停下来，等待确认。
• 此后，每收到一个 ACK，慢启动算法都会告诉发送端，cwnd 窗口增长一个 TCP 段，并能够多发送两个新的分组。这个阶段称为指数增加阶段。

因为慢启动的设计，限制了可用的吞吐量。对于大型流式下载服务的影响倒不显著，可是对于小文件的传输却很是不利，经常会出现尚未达到最大窗口请求就被终止的状况。

简单演示三次握手与慢启动对简单 HTTP 传输的影响。

链接参数：

• 往返事件：56ms。
• 客户端到服务端带宽：5 Mbit/s。
• 客户端和服务端接收窗口：65 535字节。
• 初始的拥塞窗口：4 段（4 x 1460 字节 = 5.7 KB）。
• 服务器生成响应的处理时间：40 ms。
• 没有分组丢失，每一个分组都要确认，GET 请求只占 1 段。

• 0 ms：客户端发送 SYN 分组开始 TCP 握手。
• 28 ms：服务端响应 SYN - ACK 并指定其 rwnd 大小。
• 56 ms：客户端确认 SYN - ACK，并指定其 rwnd 大小。并当即发送 HTTP GET 请求。
• 84 ms：服务端接收到 HTTP 请求。
• 124 ms：服务器生成 20 KB 的响应，并发送 4 个 TCP 段（假设初始 cwnd 为 4），而后等待 ACK。
• 152 ms：客户端收到 4 个段，并分别发送 ACK 确认。
• 180 ms：服务器针对每一个 ACK 递增 cwnd，而后发送 8 个 TCP 段。
• 208 ms：客户端接收到 8 个段，并分别发送 ACK 确认。
• 236 ms：服务器针对每一个 ACK 递增 cwnd，而后发送剩余 TCP 段。
• 264 ms：客户端收到剩余的 TCP 段，并发送 ACK 确认。

当再次发送相同请求时：

• 0 ms：客户端发送 HTTP 请求。
• 28 ms：服务器收到 HTTP 请求。
• 68 ms：服务器生成 20 KB 响应，此时 cwnd 已经大于发送文件所需的 15 段，所以能够一次性发送全部数据段。
• 96 ms：客户端收到全部 15 个段，分别发送 ACK 确认。

拥塞预防

慢启用使用 cwnd 做为起始值发送数据量，随后成倍增加。直到超过接收系统配置的拥塞阈值（ssthresh）窗口，或者发生分组丢失现象，此时拥塞预防算法介入。

因为已经发生拥堵，必须采起删包措施。须要从新调整 cwnd 大小，此后拥塞预防按照本身的算法来增大 cwnd 以免丢包。若再次丢包，则从头开始。

参考

• TFO
• TCP链接复用
• TCP的流量控制和拥塞控制