TCP 拥塞控制对数据延迟的影响.docx

第

TCP拥塞控制对数据延迟的影响

哈喽大家好，我是咸鱼

今天分享一篇文章，是关于TCP拥塞控制对数据延迟产生的影响的。作者在服务延迟变高之后进行抓包分析，结果发现时间花在了TCP本身的机制上面：客户端并不是将请求一股脑发送给服务端，而是只发送了一部分，等到接收到服务端的ACK，然后继续再发送，这就造成了额外的RTT，这个额外的RTT是由TCP的拥塞控制导致的

原文链接：/posts/5181

这是上周在项目上遇到的一个问题，在内网把问题用英文分析了一遍，觉得挺有用的，所以在博客上打算再写一次。

问题是这样的：我们在当前的环境中，网络延迟1ms，服务的延迟是2ms，现在要迁移到一个新的环境，新的环境网络自身延迟(来回的延迟，RTT，本文中谈到延迟都指的是RTT延迟)是100ms，那么请问，服务的延迟应该是多少？

我们的预期是102ms左右，但是现实中，发现实际的延迟涨了不止100ms，P99到了300ms左右。

从日志中，发现有请求的延迟的确很高，但是模式就是200ms,300ms甚至400ms左右，看起来是多花了几个RTT。

接下来就根据日志去抓包，最后发现，时间花在了TCP本身的机制上面，这些高延迟的请求都发生在TCP创建连接之后。

首先是TCP创建连接的时间，TCP创建连接需要三次握手，需要额外增加一个RTT。为什么不是两个RTT？因为过程是这样的：

+0A-BSYN

+0.5RTTB-ASYN+ACK

+1RTTA-BACK

+1RTTA-BData

即第三个包，在A发给B之后，A就继续发送下面的数据了，所以可以认为这第三个包不会占用额外的时间。

这样的话，延迟会额外增加一个RTT，加上本身数据传输的一个RTT，那么，我们能观察到的最高的RTT应该是2个RTT，即200ms，那么为什么会看到400ms的请求呢？

从抓包分析看，我发现在建立TCP连接之后，客户端并不是将请求一股脑发送给服务端，而是只发送了一部分，等到接收到服务端的ACK，然后继续在发送，这就造成了额外的RTT。看到这里我恍然大悟，原来是cwnd造成的。

cwnd如何分析，之前的博文中也提到过。简单来说，这是TCP层面的一个机制，为了避免网络赛车，在建立TCP连接之后，发送端并不知道这个网络到底能承受多大的流量，所以发送端会发送一部分数据，如果OK，满满加大发送数据的量。这就是TCP的慢启动。

那么慢启动从多少开始呢？

Linux中默认是10.

/usr/src/linux/include/net/tcp.h:

/*TCPinitialcongestionwindowasperdraft-hkchu-tcpm-initcwnd-01*/

#defineTCP_INIT_CWND10

也就是说，在小于cwnd=10*MSS=1448bytes=14480bytes数据的情况下，我们可以用2RTT发送完毕数据。即1个RTT用于建立TCP连接，1个RTT用于发送数据。

下面这个抓包可以证明这一点，我在100ms的环境中，从一端发送了正好14480的数据，恰好是用了200ms：

100ms用于建立连接，100ms用于发送数据

如果发送的数据小于14480bytes（大约是14K），那么用的时间应该是一样的。

但是，如果多了即使1byte，延迟也会增加一个RTT，即需要300ms。下面是发送14481bytes的抓包情况：

多出来一个100ms用于传输这个额外的byte

慢启动，顾名思义，只发生在启动阶段，如果第一波发出去的数据都能收到确认，那么证明网络的容量足够，可以一次性发送更多的数据，这时cwnd就会继续增大了（取决于具体拥塞控制的算法）。

这就是额外的延迟的来源了。回到我们的案例，这个用户的请求大约是30K，响应也大约是30K，而cwnd是双向的，即两端分别进行慢启动，所以，请求发送过来+1RTT，响应+1RTT，TCP建立连接+1RTT，加上本身数据传输就有1RTT，总共4RTT，就解释的通了。

解决办法也很简单，两个问题都可以使用TCP长连接来解决。

PS：其实，到这里读者应该发现，这个服务本身的延迟，在这种情况下，也是4个RTT，只不过网络环境A的