TCP重传案例分析1

一次HTTPS超时重传问题：从抓包来看：

.225是服务器端 239.21是客户端。

故障现象比较简单 就是27725-27731 的6个2320B大包被丢弃，一般是某个地方的buffer被打满导致。但这个抓包中有一个非常神奇的地方始终没想明白。

 

28930的FIN的seq是33553 等于27743的seq32788+len765

1.可以理解为28930是对27743的超时FIN 两者间隔时间40s

2.28930的FIN其实是对28989的FIN（全量重传完毕），抓包采集过程时间戳有问题？

 

 

 

27725的报文seq是17708 该报文在customer侧一直没有收到直到27746-27748被三次DupAck，然后通过SACK重传的能力在27751完成重传。

但在27751-28753 完成了18868-25828的重传。

27743 seq=32788 + len765 = 33553

27746 没有sack ack为17708 => 此时17708-33553均未收到

27747 sack:TCP Option - SACK 31628-32788 ACK=17708=>收到了27741

27748 sack:TCP Option - SACK 31628-33553 ACK=17708 =>收到了27743

27752 sack:TCP Option - SACK 17708-18868 31628-33553 ACK=18868 =>收到了27751的重传

//此时开始 ACK已经大于SACK了，说明customer侧收到了17708-18868的报文的重传(此时server端重传的31628-33553已经被接收)

27782 sack:TCP Option - SACK 18868-20028 31628-33553 ACK=20028

27834 sack:TCP Option - SACK 20028-21188 31628-33553 ACK=21188

27905 sack:TCP Option - SACK 21188-22348 31628-33553 ACK=22348

28040 sack:TCP Option - SACK 22348-23508 31628-33553 ACK=23508

28306 sack:TCP Option - SACK 23508-24668 31628-33553 ACK=24668

28752 seq=24668 len=1160 累加=25828 (上一次传输的时候27728是seq=24668+len2320)

28753 sack:TCP Option - SACK 24668-25828 31628-33553 ACK=25828

28930: FIN PSH ACK seq=33553

//此时收到了编号27751-28752的7个重传(重传是基于ACK+SACK已有报文后的编号进行重发）

28932 sack:TCP Option - SACK 31628-33585 ACK=25828 ==> 28753的sack没有触发继续的重传？

28936 sack:TCP Option - SACK 25828-26988 31628-33585 ACK=26988

28942 sack:TCP Option - SACK 26988-28148 31628-33585 ACK=28148

28944 sack:TCP Option - SACK 28148-29308 31628-33585 ACK=29308

28985 sack:TCP Option - SACK 29308-30468 31628-33585 ACK=30468

28989 sack:TCP Option - SACK 30468-31628 ACK=33585

//编号28933-28986 继续重传了seq25828-31628 

 

==> 此时触发28930的FIN才对。

 

 

参考文档：

https://blog.csdn.net/networker_2016/article/details/80088403

http://www.360doc.com/content/12/0830/11/21412_233159098.shtml