TCP重传和SACK

最近遇到一个问题:

内网http下载会长时间卡顿, 卡顿时候用户电脑显示下载速度为0. 大约等4-5分钟以后, 速度又会恢复正常.

抓包发现, 网络上有少量丢包1%. 出现卡顿的原因就是客户端在等待服务器重传.

如下图, 注意左边的时间戳, 数据包重传等待时间是指数增长的. 当一次丢几个包, 需要逐个重传的时候, 会花很长时间才会重传完毕.

TCP重传和SACK

查阅tcp协议文档, 发现是有快速重传机制的. 即当接收方发现丢包以后, 每接收到发送方的一个后续的包都会发送dup ack给发送方. 发送方连续收到3个dup ack包即启动重传.

经过检查发现上面这里没有触发快速重传的原因是: 接收方返回的Ack包里面因为window这个字段的值出现了变化, 接收方不认为这是dup ack包. 所以导致没有触发快速重传. window是指系统的缓冲区, 一般程序从缓冲区读取数据的时候, window就会变化.

TCP重传和SACK

经过搜索发现ietf在2015年讨论过这个问题, 从讨论的结果来看, SACK能解决这个问题. 而且因为SACK因为很广泛的被支持了, 所以也不打算从TCP协议上修复这个问题. 下面为讨论内容.

根据ietf讨论内容, 搜索了SACK的一些相关文档, SACK=Selective Acknowledgment, 是对ACK包的一种优化, 能够提供SACK相比ACK能够提供更好的重传机制.

linux启动SACK的参数如下:

/etc/sysctl.conf

net.ipv4.tcp_sack =1

发现客户端上没有开启, 开启以后, 问题解决. 抓包如下图.

当出现丢包的时候, 接收方回复的ACK是SACK包, 而且发送方马上就开始了重传. 问题解决.