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已经被接收)

<