我们正在与位于思科ASA防火墙后面的中央服务器交谈的RHEL7盒子上遇到问题。
这些机器启动并启动代理，该代理build立并保持与中央服务器的连接。 然后中央服务器周期性地将stream量发送到客户端。 在5分钟的时间里，我们看到代理断开连接，并且无法通过连接发送stream量，除非我们重新启动连接，在此之后它工作正常。
进一步的研究表明，这不仅仅是这个应用程序/代理，实际上我们可以用“nc”来复制它，而不会失败。 我们做了数据包捕获，发现在5分钟的时间内，ASA丢弃了从客户端服务器发送的ACK数据包。 中央服务器将看不到数据包，并继续尝试重新传输。 客户端将得到重发，发送一个ACK，ASA会放弃它 – 冲洗/重复。
在调查捕获时，我们发现在5分钟的时间内，客户端服务器将ACK数据包上的TSVal重置为某个较低的数字。
您可以在下面的数据包捕获中看到数据包101，客户端发送一个TSVal为4294962488的ACK。然后服务器推送更多的数据（数据包102），但是在数据包103上，客户端现在用TSVal设置为196。
No. Time Timestamp Source Destination Protocol Length Info 96 2017-07-11 15:16:04.717785 22:16:04.717785 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107029 Ack=2031069343 Win=29056 Len=35 TSval=1400815609 TSecr=4294947477 97 2017-07-11 15:16:04.717802 22:16:04.717802 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107064 Win=29312 Len=0 TSval=4294952481 TSecr=1400815609 98 2017-07-11 15:16:09.721130 22:16:09.721130 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107064 Ack=2031069343 Win=29056 Len=35 TSval=1400820612 TSecr=4294952481 99 2017-07-11 15:16:09.721152 22:16:09.721152 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107099 Win=29312 Len=0 TSval=4294957485 TSecr=1400820612 100 2017-07-11 15:16:14.724742 22:16:14.724742 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107099 Ack=2031069343 Win=29056 Len=35 TSval=1400825616 TSecr=4294957485 101 2017-07-11 15:16:14.724757 22:16:14.724757 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107134 Win=29312 Len=0 TSval=4294962488 TSecr=1400825616 102 2017-07-11 15:16:19.728187 22:16:19.728187 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107134 Ack=2031069343 Win=29056 Len=35 TSval=1400830619 TSecr=4294962488 103 2017-07-11 15:16:19.728207 22:16:19.728207 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107169 Win=29312 Len=0 TSval=196 TSecr=1400830619 104 2017-07-11 15:16:19.728556 22:16:19.728556 10.158.35.162 10.153.195.227 TCP 66 [TCP Dup ACK 2#1] 4506 → 38208 [PSH, ACK] Seq=3089107169 Ack=2031069343 Win=29056 Len=0 TSval=1400830619 TSecr=4294962488 105 2017-07-11 15:16:19.928307 22:16:19.928307 10.158.35.162 10.153.195.227 TCP 101 [TCP Spurious Retransmission] 4506 → 38208 [PSH, ACK] Seq=3089107134 Ack=2031069343 Win=29056 Len=35 TSval=1400830820 TSecr=4294962488 106 2017-07-11 15:16:19.928319 22:16:19.928319 10.153.195.227 10.158.35.162 TCP 78 [TCP Dup ACK 103#1] 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107169 Win=29312 Len=0 TSval=396 TSecr=1400830820 SLE=3089107134 SRE=3089107169 107 2017-07-11 15:16:19.928702 22:16:19.928702 10.158.35.162 10.153.195.227 TCP 66 [TCP Dup ACK 2#2] 4506 → 38208 [PSH, ACK] Seq=3089107169 Ack=2031069343 Win=29056 Len=0 TSval=1400830820 TSecr=4294962488 ASA然后考虑这个畸形并且丢弃它，因为TSVal不应该递减。
我们尝试通过/ proc / sys / net / ipv4 / tcp_timestamps禁用tcp_timestamps。 这个工作和问题消失，但禁用时间戳可能有其他应用程序通信的其他后果。
此外，问题仍然存在，为什么TSVal会在主机上线5分钟后重置为这么低的数字？ 这只发生在我们的RHEL7u2系统上 – 我们的RHEL6盒子没有遇到这个问题。
任何想法/帮助将不胜感激。
我不认为防火墙应该放弃这些，它应该同时查看序列号和时间戳…我猜测发生的事情是，RHEL 7出于安全原因正在随机化时间戳，但也许防火墙是比较老？