tcp_tw_recycle

问题背景

服务通过F5使用lb的方式对外提供服务，client连接某LB VIP的时候，发现client发送了syn，server直接回了rst断了连接。
上网查询相关信息，发现很多的情况是因为打开了tcp_tw_recycle导致的(特别是在NAT的情况下)，那么tw_recycle和tw_reuse有什么联系和关联，又是如何触发问题的呢。

tw_recyle

客户端开启了选项后，tw的socket不会等待2msl的时间，rto时间后就会被释放，对于server端来说，可能某个时刻会有大量的tw链接。打开tw_recycle的话，会打开协议栈的Per-host PAWS机制。导致server看到timestamp小于当前值的话，会rst掉报文，这在nat的情况下会带来一定的问题，因为sip,dip,dport都是固定，连接数量到一定程度的话，一定会有sport的重复，然而各个client的timestamp又不能保证时序，会带来问题。
http://perthcharles.github.io...
那tw_recycle的机制又是如何实现的呢，开启了msl，它将会在超时重发（RTO）间隔后移除（底层会根据当前连接的延迟状况根据RTT来计算RTO值)。但是4.1内核版本之后，此内核参数已经废弃

1. timestamp参数是如何生效的。
2. 打开tw_recycle，为何会导致PAWS。

开启了tw_recycle后，tw socket会立即回收。这时如果ack报文丢失，那么client会重传fin报文，此时server可能已经使用此socket建立新的连接了，并且有报文的交互，在这种情况下，server需要rst掉此链接。那么如何区分是之前的链接，还是新建的链接，协议栈用timestamp来区分，timestamp小于当前的，认定是之前的链接，统一rst。
为什么tw_reuse不会有这样的问题，因为tw_reuse是影响主动发出的链接，tw_reuse的socket发出syn,被对端ack（由于number不一致），本端会回应rst，并重传syn包，不影响连接的建立。
但是tw_recycle会rst掉对端的syn，此时直接影响到连接的建立。换句话说，如果tw_recycle的socket，被复用主动发起syn的话，效果和tw_reuse应该一致。

所以主要区别是
tw_reuse被适用于主动发起的链接，如果五元组匹配
tw_recycle直接释放tw_socket, 影响主动发起和接收的链接。接收的链接会被rst

tw_reuse

tw_reuse只针对出向的连接有效。举例
服务器的某个socket连接现在正处在time_wait的状态。按照正常的逻辑来说，在这个TW socket被回收之前，都不能使用这个ip和port建立新的tcp连接。但是在开启了tw_reuse的情况下，则可以复用这个socket，发出syn包，建立新的连接。

RTT&RTO

RTO: Retransmission TimeOut
RTT: Round Trip Time(往返时间：链路传输时间+路由器排队/处理时间+末端处理时间)

https://juejin.im/post/5c0642...