TCP性能优化

添加时间：2024-04-15 12:17:24

本次和大家聊一下TCP性能优化。

TCP全称为Transmission Control Protocol，每一个IT人士对TCP都有一定了解。TCP协议属于底层协议，对于大部分研发人员来说，这是透明的，无需关心TCP的实现与细节。

不过如果想做深入的性能优化，TCP是绕不过去的一环。要讲TCP性能优化，必须先回顾一下TCP的一些细节。让我们先来看一下TCP的首部格式

TCP报文段首部的前20个字节是固定的，后面有4n字节是根据需要而增加的选项（n是整数）。因此TCP首部的最小长度是20字节。

序号：字段值指的是本报文段所发送的数据的第一个字节的序号
确认号：是期望收到对方下一个报文段的第一个数据字节的序号。若确认号为=N，则表明：到序号N-1为止的所有数据都已正确收到
ACK：仅当ACK=1时确认号字段才有效，当ACK=0时确认号无效。TCP规定，在连接建立后所有的传送的报文段都必须把ACK置为1
SYN：在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1，因此SYN置为1就表示这是一个连接请求或连接接受报文
窗口：窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化。
选项：

最大报文段长度MSS：

以太网Ethernet最大的数据帧是1518字节。以太网帧的帧头14字节和帧尾CRC校验4字节（共占18字节），剩下承载上层协议的地方也就是Data域最大就只剩1500字节. 这个值我们就把它称之为MTU。
为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替，MSS一般在1420~1460，1460是由1500 - 20（IP头）- 20/60（TCP头）计算出的。

窗口扩大选项：TCP首部中窗口字段长度是16位，因此最大的窗口大小为64K字节。可以将窗口最大值增大到2^（16+14）-1=2^30-1

所有TCP连接一开始都要经过三次握手，如下图所示：

SYN: 客户端选择一个随机序列号x，并发送一个SYN分组，其中可能还包括其他TCP标志和选项。
SYN ACK: 服务器给x加1，并选择自己的一个随机序列号y，追加自己的标志和选项，然后返回响应。
ACK: 客户端给x和y加1并发送握手期间的最后一个ACK分组。

上面的内容我们在书上看过多次，这次我们用wireshark抓包看一下详情：

本机ip为192.168.1.102，服务器ip为122.51.162

三次握手完成后，客户端与服务器之间就可以通信了。

这个启动通信的过程适用于所有TCP连接，因此对所有使用TCP的应用具有非常大的性能影响，因为每次传输应用数据之前，都必须经历一次完整的往返。

三次握手带来的延迟使得每创建一个新TCP连接都要付出很大代价。而这也决定了提高TCP应用性能的关键，在于想办法重用连接。

TFO(TCP fast open)允许服务器和客户端在连接建立握手阶段交换数据，从而使应用节省了一个RTT的时延。

但是TFO会引起一些问题，因此协议要求TCP实现必须默认禁止TFO。需要在某个服务端口上启用TFO功能的时候需要应用程序显示启用。

查看：sysctl net.ipv4.tcp_fastopen

设置：sysctl -n net.ipv4.tcp_fastopen=0x203

限制：并不能解决所有问题，它虽然有助于减少三次握手的往返时间，但却只能在某些情况下有效，如随同SYN分组一起发送的数据净荷有最大尺寸限制、只能发送某些类型的HTTP请求，以及由于依赖加密cookie，只能应用于重复的连接。

效果：经过流量分析和网络模拟，谷歌研究人员发现TFO平均可以降低HTTP事务网络延迟15%、整个页面加载时间10%以上。在某些延迟很长的情况下，降低幅度甚至可达40%。

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

Keep-Alive能够实现，需要服务端支持：

Httpd守护进程，如nginx需要设置keepalive_timeout

keepalive_timeout=0：建立tcp连接 + 传送http请求 + 执行时间 + 传送http响应 + 关闭tcp连接 + 2MSL
keepalive_timeout>0：建立tcp连接 + (最后一个响应时间 – 第一个请求时间) + 关闭tcp连接 + 2MSL

另外TCP自身也有Keep-Alive，是检测TCP连接状况的保鲜机制

net.ipv4.tcpkeepalivetime：表示TCP链接在多少秒之后没有数据报文传输启动探测报文
net.ipv4.tcpkeepaliveintvl：前一个探测报文和后一个探测报文之间的时间间隔
net.ipv4.tcpkeepaliveprobes：探测的次数

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

流量控制是一种预防发送端过多向接收端发送数据的机制。否则，接收端可能因为忙碌、负载重或缓冲区容量有限而无法处理。为实现流量控制，

TCP连接的每一方都要通告自己的接收窗口（rwnd），其中包含能够保存数据的缓冲区空间大小信息。

第一次建立连接时，两端都会使用自身系统的默认设置来发送rwnd。每个ACK分组都会携带相应的最新rwnd值，以便两端动态调整数据流速，使之适应发送端和接收端的容量及处理能力。

最初的TCP规范分配给通告窗口大小的字段是16位的，这相当于设定了发送端和接收端窗口的最大值（2的16次方即65 535字节）。为解决这个问题，RFC 1323提供了“TCP窗口缩放”（TCPWindow Scaling）选项，可以把接收窗口大小由65 535字节提高到1G字节！

缩放TCP窗口是在三次握手期间完成的，其中有一个值表示在将来的ACK中左移16位窗口字段的位数。

客户端与服务器之间最大可以传输数据量取rwnd和cwnd变量中的最小值。

开启窗口缩放，能使接收窗口大小从2^16升级到2^30，可以获得更好的传输性能。

查看：sysctl net.ipv4.tcp_window_scaling

设置：sysctl -w net.ipv4.tcp_window_scaling=1

效果：比起不开启窗口缩放，能够充分利用带宽

这里讲述一下带宽延迟积。BDP（Bandwidth-delay product，带宽延迟积）数据链路的容量与其端到端延迟的乘积。这个结果就是任意时刻处于在途未确认状态的最大数据量。

发送端或接收端无论谁被迫频繁地停止等待之前分组的ACK，都会造成数据缺口，从而必然限制连接的最大吞吐量。

无论实际或通告的带宽是多大，窗口过小都会限制连接的吞吐量。

知道往返时间和两端的实际带宽也可以计算最优窗口大小。这一次我们假设往返时间为100 ms，发送端的可用带宽为10 Mbps，接收端则为100 Mbps+。还假设两端之间没有网络拥塞，我们的目标就是充分利用客户端的10 Mbps带宽：

窗口至少需要122.1 KB才能充分利用10 Mbps带宽！如果没“窗口缩放，TCP接收窗口最大只有64 KB，无论网络性能有多好，永远无法充分利用带宽。

接收窗口对性能很重要，但拥塞窗口比接收窗口更重要。

客户端与服务器之间最大可以传输（未经ACK确认的）数据量取rwnd和cwnd变量中的最小值，而一开始的cwnd很小，通过慢启动算法不断增大。

慢启动和拥塞避免的算法有很多，这里使用Tahoe版本的TCP版本进行展示，这个也是带有拥塞控制功能的第一个TCP版本，使用的拥塞避免算法为AIMD（Multiplicative Decrease and Additive Increase，倍减加增）。

SS：Slow Start，慢启动阶段。TCP 刚开始传输的时候，速度是慢慢涨起来的，除非遇到丢包，否则速度会一直指数性增长。
CA：Congestion Avoid，拥塞避免阶段。当拥塞窗口大于ssthresh后， CWND增长速度会下降，不再像 SS 那样指数增，而是线性增。
超时：当数据发送方感知到丢包时，会记录此时的 CWND，并计算合理的 ssthresh 值，一般ssthresh会置为超时时CWND的一半，发送端会骤降 CWND 到最初始的状态，当 CWND 重新由小至大增长，直到 sshtresh 时，不再 SS 而是 CA

服务器会有一个默认cwnd初始值。最初，cwnd的值只有1个TCP段。1999年4月，RFC 2581将其增加到了4个TCP段。2013年4月，RFC 6928再次将其提高到10个TCP段。

问题：cwnd大小达到N所需的时间

解：

下面我们就来看一个例子，假设：

? 客户端和服务器的接收窗口为65535字节（64 KB）；

? 初始的拥塞窗口：4段（RFC 2581）；

? 往返时间是56 ms（伦敦到纽约）；

这个例子说明网络正常情况下，要达到最大传输量，需要224ms。因为慢启动限制了可用的吞吐量，而这对于小文件传输非常不利，因为拥塞控制尚处于slowstart阶段，传输就完毕了。

查看：

写脚本
probe kernel.function("tcp_init_cwnd").return
{
printf("tcp_init_cwnd return: %d\ ", $return)
}
把服务器内核升级到最新版本（Linux：3.2+）

设置：在内核中增加一个控制initcwnd的proc参数，/proc/sys/net/ipv4/tcp_initcwnd。该方法对所有的TCP连接有效。

限制：初始拥塞窗口不能设置特别大，否则会导致交换节点的缓冲区被填满，多出来的分组必须删掉，相应的主机会在网络中制造越来越多的数据报副本，使得整个网络陷入瘫痪。行业内各大cdn厂商都调整过init_cwnd值，普遍取值在10-20之间

效果：

名词解释：SSR（Slow-Start Restart，慢启动重启）会在连接空闲一定时间后重置连接的拥塞窗口。

原因：在连接空闲的同时，网络状况也可能发生了变化，为了避免拥塞，理应将拥塞窗口重置回“安全的”默认值。

查看： sysctl net.ipv4.tcp_slow_start_after_idle

设置： sysctl -w net.ipv4.tcp_slow_start_after_idle=0

效果：对于那些会出现突发空闲的长周期TCP连接（比如HTTP的keep-alive连接）有很大的影响，具体提升性能根据网络性能和数据量大小不同而不同

拥塞控制算法对TCP性能影响很大，除了上面提到的AIMD算法，还有众多其他算法。

PRR（Proportional Rate Reduction，比例降速）就是RFC 6937规定的一个新算法，其目标就是改进丢包后的恢复速度。

效果：根据谷歌的测量，实现新算法后，因丢包造成的平均连接延迟减少了3%~10%。

设置：升级服务器。PRR现在是Linux 3.2+内核默认的拥塞预防算法。

方案：

减少传输冗余数据
压缩要传输的数据：gzip、protobuf、webp等
再快也快不过什么也不用发送

方案：

多机房部署服务器
使用CDN

队首（HOL，Head of Line）阻塞：如果中途有一个分组没能到达接收端，那么后续分组必须保存在接收端的TCP缓冲区，等待丢失的分组重发并到达接收端。这一切都发生在TCP层，应用程序对TCP重发和缓冲区中排队的分组一无所知，必须等待分组全部到达才能访问数据。在此之前，应用程序只能在通过套接字读数据时感觉到延迟交付。