记一次典型的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