记一次典型的TCP传输吞吐效率问题

简介

客户在ECS上实现了一个供小图片上传的接口，通过高防->SLB->ECS的网络链路将接口发布给终端用户。但是发现上传的速率很不理想，上传600K左右的小图片大约要8秒。初看起来像是高防问题，但是通过排查最终发现这是一个典型的TCP传输吞吐量问题，并且是由于后端服务器端的配置而引起，在此记录下排查过程和相关原理。

梳理和分辨问题

初看起来像是高防问题，但我们还是需要来先分辨下问题。整个传输的链路如下：

客户端 -> 4层高防节点 -> 4层SLB -> 后端RS (ECS)

测试客户端机器，SLB和后端RS都在北京，使用的是4层新高防节点(节点的地理未知不在北京)。从刚开始非常小的信息量，我们有理由怀疑因为新高防节点的引入，造成客户端到后端RS的往返RTT增加会导致上传需要更多时间。但是这个时间增加到600K需要8秒是否正常，从经验判断是不正常的，但是需要更多信息来判断问题出在哪里。

比较关心的信息如下：

这个上传时间增加问题是否是突然发生的，以前的上传时间是多久？–> Answer: 这是第一次，测试就发生。

直接上传SLB是不是也比较慢？–> Answer: 看起来“不慢”。

基于上面的信息，并且确认了高防端没有明显问题，唯一能怀疑的是往返RTT的增加会导致上传需要更多时间。要继续排查下去，目前汇总起来的信息已经没有突破口。只能做更加定量地分析，也就是分别往高防和源站SLB测试上传，看需要多少时间，并且同时抓包来，验证除了RTT之外还有没有影响TCP传输效率的点。

其实上传到SLB也很慢

拿到了进一步的测试结果，大致测试结果如下：

上传文件大小605KB，上传到高防需要要大约8秒：

$ time curl -X POST https://gate.customer.com/xxx/yyy -F "expression=@/Users/customer/test.jpg"

real  0m8.067s

user  0m0.016s

sys 0m0.030s

绑host上传到SLB大约需要2.3秒：

$ time curl -X POST https://gate.customer.com/xxx/yyy -F "expression=@/Users/customer/test.jpg"

real  0m2.283s

user  0m0.017s

sys 0m0.031s

上面的定量分析明确了之前一个不太准确的信息，实际上上传到SLB也很慢，而非之前体感的“不慢”。对于在同一城域网内，RTT时间通常小于10ms, 如果TCP窗口正常的话，客户端将605KB的图片上传到阿里云SLB，一定会是ms级别，而非秒级，2.3秒明显已经很慢了。主观感受上对2秒的体感可能还不是那么强烈，所以容易造成误判。

那么剩余的问题就是要看看为什么上传到高防和SLB都很慢，而且上传到高防更慢。这个只能从抓包里做进一步判断。

分析TCP窗口

通过抓包分析可以有效地收窄(Narrow down) 问题。直接拿到测试的抓包，能避免了很多弯路。客户端上传到高防节点的抓包如下：

可以从抓包中看到如下几个特征：

1. 以62-64号包为例，在上传的最开始一段时间，客户端每给服务器端传输2个报文(每个报文的TCP payload大小是1466-14-40=1412字节)，就需要等待服务器端的ACK，才能继续传下面两个报文。

2. 服务器端发出的报文中的TCP接收窗口一直很小，先后只有2920和2824字节 (在上图中用红框标出)。

3. 在75号包中，服务器端进一步将TCP接受窗口通过TCP Window Update调小，变成2824字节。之后客户端只要传输1个1466字节(TCP payload 1412字节)的报文即出现TCP Window Full，需要等服务器的ACK，再传输下面一个报文。

4. 路径的RTT比较大，且不是很稳定。比如70号报文花费了90ms的RTT，而61号报文只花费了31ms的RTT。

RTT(Round-Trip Time，往返时延)。在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。
往返延时(RTT)由三个部分决定：即链路的传播时间、末端系统的处理时间以及路由器的缓存中的排队和处理时间。其中，前面两个部分的值作为一个TCP连接相对固定，路由器的缓存中的排队和处理时间会随着整个网络拥塞程度的变化而变化。所以RTT的变化在一定程度上反映了网络拥塞程度的变化。

如果比较熟悉TCP协议，那到这里基本上有结论了：服务器端的TCP接收窗口持续很小，同时加上经过高防的RTT比较大，导致TCP吞吐量很小，从而上传慢。如果不太熟悉TCP协议，那么需要解答如下几个问题。

发送端一次能传多大的在途 (in flight)未确认数据量?

TCP传输并不是发送端发送一个数据包，接收端回ACK,，发送端再继续发送下一个数据包。而是允许发送端一次发多个数据包，但是到了一定大小的数据量必须要等待ACK才能发一下批数据包，这个数据量即为：在途数据未确认数据量。

在这个案例中，很明显在途未确认数据一直很小，只有大约1-2个MSS (通常MSS是1460，下面章节会有具体介绍)大小。那么在途未确认数据量是多少呢？这取决于拥塞窗口(cwnd)和接收窗口(rwnd)的最小值。接收窗口大小每次回由对端随着ACK一起发送，而拥塞窗口则由发送端根据链路状态，通过拥塞控制和预防算法进行动态调整。

拥塞窗口

拥塞窗口是根据链路状态来动态调整的，最开始发报文给对端时，没有机会知道链路状态，所以采取比较稳健的方式将拥塞窗口初始值设置得小点，这就是TCP中的慢启动。那么设置多小呢？

RFC的推荐：

4 MSS, RFC 2581 updated this value to 4 segments in April 1999;

10 MSS, most recently the value was increased once more to 10

segments by RFC 6928 in April 2013.

Linux的实现：

较老版本(Linux 2.6.x) 3*MSS

新版本(Linux 3.0.+) 10*MSS

随后如果链路没有丢包，拥塞窗口的大小在慢启动中会指数增长。

接收窗口

在TCP Header中有Window字段，有16个字节。Window本身的范围可以0 ~ 64KB (65535, 2^16-1)。64KB在比较早的网络环境中被认为是一个合适的上限，而利用TCP Options的Window scale字段，这个窗口可以被扩大。比如Window scale为5，则窗口可以在Window字段的基础上放大32 (2^5)倍。
接收窗口大小每次会由对端随着ACK一起发送，我们在Wireshark里面可以看到的Window字段就是接收窗口，而非拥塞窗口。

TCP是个双工传输信道，接收窗口是有方向性的。双发各自向对端通告自己的TCP接收窗口，最终会影响对端向本端的传输效率。比如在这个案例中，客户端向服务器端上传数据，那么服务器端通告的TCP接收窗口会影响客户端向服务端传输数据的效率。

MSS（Maximum Segment Size，最大报文长度）

上面每次客户端发送1466个字节(二层数据帧的总长度)，取决于客户端和服务器在3次握手时所相互通告的MSS，这个字段在TCP Option中。在3次握手中，客户端通告给服务器的MSS是1460字节，服务器通告给客户端的MSS是1412字节，在传输中利用1412作为MSS来传输。所以客户端在传输报文时一个二层数据帧的大小为1412+20+20+14=1466字节。

结论

这里出现的问题的原因为：服务器端的TCP接收窗口很小，限制了在途未确认数据量一直为1 ~ 2个MSS大小，和高防和SLB本身都没有关系。

对于高防的上传报文来说，服务器端的TCP接收窗口持续很小，同时加上经过高防的RTT比较大，导致TCP吞吐量很小。对SLB的测试也能复现接收窗口小的问题，只是因为客户端到SLB是同城传输，所以RTT小很多，总用时也小很多。因为TCP接收窗口比较小，使得上传高防和上传SLB几乎和RTT呈线性关系，这个在正常的TCP传输中是几乎不可能出现的，因为正常的TCP窗口一定是在拥塞控制的过程中增大和调整的。

客户端走高防的RTT如下图：在35毫秒左右。

客户端走SLB的RTT如下图：在8毫秒左右。

解决方案

影响TCP接收窗口的因素

1. TCP receive buffer

A. 系统层面 (net.ipv4.tcp_rmem/net.core.rmem_max/net.ipv4.tcp_adv_win_scale)

TCP接收窗口的大小在Linux系统中取决于TCP receive buffer的大小，而TCP receive buffer的大小默认由内核根据系统可用内存的情况和内核参数net.ipv4.tcp_rmem动态调节。   

net.ipv4.tcp_rmem在Linux 2.4中被引入，设置包括[min, default, max]

min	每个TCP socket receive buffer的最小size，默认值是4K
default	TCP socket receive buffer的默认大小。这个值能够覆盖全局设置net.core.rmem_default定义的初始默认buffer size，默认值是87380字节
max	每个TCP socket receive buffer的最大size。这个值不能覆盖全局设置net.core.rmem_max

如下是一个内核3.10.0版本，内存8G的ECS云主机上的默认值设置

sysctl -a | grep tcp_rmem

net.ipv4.tcp_rmem = 4096 87380 6291456

同时，不是TCP receive buffer的大小就等于TCP接收窗口的大小。有bytes/2^tcp_adv_win_scale的大小分配给应用。如果net.ipv4.tcp_adv_win_scale的大小为2，表示有1/4的TCP buffer给应用，TCP把其余的3/4给TCP接窗口。

B. 进程设置

进程可以利用系统调用setsockopt()设置socket属性，用SO_RCVBUF参数手动设置TCP receive buffer大小。比如NGINX可以在listen中配置rcvbuf=size。

2. net.ipv4.tcp_window_scaling

在前面提到，如果要让TCP接收窗口超过64KB大小，需要利用TCP Options的Window scale字段。而在系统内核参数设置里，对应的就是net.ipv4.tcp_window_scaling参数，这个参数默认是开启的。但是在这个案例中明显不是因为net.ipv4.tcp_window_scaling的原因， TCP接收窗口的大小还远远小于64KB。

问题解决

查看了相关内核参数并没有问题，最终明确问题是因为在Web server中限制了过小的rcvbuf到导致，调整参数后上传速度明显改善。