tcp retransmission 出现的原因_深挖由tcp_tw_recycle引发的业务超时问题（续）

阅读本文约需要10分钟，您可以先关注我们，避免下次无法找到。

01 承上启下

上篇介绍了由tcp_tw_recycle引发的业务超时问题的临时解决方案，以及由此引发成哥的深入思考。

既然本次问题和网络设备的NAT、以及Linux内核TCP参数都有关系，成哥就要从这两方面进行深入挖掘。

上篇详细挖掘了私有云中两处涉及NAT的节点业务流走向。本篇将继续挖掘，深挖TCP参数，彻底刨出问题根源。

02 深挖TCP参数

要想理解TCP参数的深层次含义，就要以timestamps、tcp_tw_recycle等关键词为线索，硬啃Linux用户手册、RFC文档以及Linux内核仓库(Kernel.org git repositories)。

研究文档资料的过程是个艰难的过程，比如需要彻底理解timestamps，就要弄清什么是RTO，什么是RTT、什么是RTTM等等。比如要理解单调递增时间戳，就要理解什么是Per-host PAWS，然后PAWS概念中还有其他一堆概念。

啃文档的过程是反向理解，逐步深入的。这里成哥给大家做个正向展示，方便大家理解。

(1)Timestamp

Timestamp(时间戳)是TCP协议首部中的可选项。

10字节的timestamp选项中，TSval是发送方填写的发送时间。TSecr是发送方收到对方消息包的发送时间，即对方消息包中的TSval，由于这个是SYN包，所以此时并没有收到任何对方的消息，因此T