一般而言,收到3个DACK后就会触发快速重传。当然这个3是经验值,具体可以查看RFC。通过sysctl查看和修改该值。下面是一个简单的实验,为了触发快速重传,实验中使用tc命令设置丢包率为1%。
[root@bogon tmp]# sysctl -a | grep reorder
net.ipv4.tcp_reordering = 3
[root@bogon tmp]# sysctl net.ipv4.tcp_reordering=6
net.ipv4.tcp_reordering = 6
[root@bogon tmp]# sysctl -a | grep reorder
net.ipv4.tcp_reordering = 6
目前,tcp已经支持SACK option了,发送端可以知道接收端究竟没收到了什么包,哪些包已经收到了。对于那些已经收到的包就不需要重传了。如果缺失多个包,发送端可以直接发送多个丢失的包。
如果不支持SACK呢,那么已经收到的包,就不会告诉发送端那些包已经收到了,那么发送端是不是就会把后面已经被接受的包也再重传一次呢?不是的。
发送端先发送一个需要的包,等着。接收端会把乱序的包放到一个乱序队列,当收到丢失的包后,把后面收到的包从乱序队列取出来拼接在一起,就直接传后面的吧。
我认为,有了sack之后,可以提高重传的效率,毕竟很快知道哪些丢失了,直接把丢失的包重传。而没有sack的话,就需要一个一个确认后再传,慢一些。
有了sack之后,可以提高重传的效率,毕竟很快知道哪些丢失了,直接把丢失的包重传。而没有sack的话,就需要一个一个确认后再传,慢一些。
如下,存在sack的情况,快速重传那个丢失的包,不需要等待确认,直接发送后续的包: