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

客户在ECS上遇到600K小图片上传耗时约8秒的问题,最初怀疑高防导致,但进一步分析发现是服务器端TCP接收窗口过小引起。通过抓包分析,确认服务器端TCP接收窗口限制了在途未确认数据量,结合较大的RTT,导致TCP吞吐量降低。调整服务器接收缓冲区大小后,问题得到解决。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

客户在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=@/Use
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值