客户端和服务器之间的中间人networking节点引入的TCP捎带？

看了很多传输过程中发生的变化，我终于发现了一个能够合理解释为什么客户端正在考虑来自服务器的数据包乱序的问题。

查看时间戳选项，特别是查看从服务器到客户端的数据包的时间戳值字段。 从服务器来看，这些数据源始于从SYN-ACK中的7236650到最后一个数据包中的7246570。

但是，在客户端收到时，SYN-ACK数据包中的时间戳值已被修改为值1068916716.其余数据包从服务器发送到客户端，而不修改时间戳记值。

所以从客户的angular度来看，时间戳从1068916716到7236708.换句话说，它正在倒退，这当然是客户考虑数据包失序的一个合理的原因。

所以，你有我的猜测是你的问题的根本原因是SYN-ACK中的时间戳被破坏。

在达到这个猜测之前，我从包迹线上观察了很多其他有趣的事实。 虽然这些其他数据点并不能解释你的问题，但它们可能仍然是相关的数据点供进一步调查。 我使用Wireshark来检查数据包捕获，但是任何可以解码所有TCP头的工具都可以。

• 有一些NAT正在进行。 来自客户端的数据包始发源IP为192.168.43.87，源IP为10.53.72.193。 由于在两个RFC 1918范围之间进行NAT是不常见的，所以我猜测有两层NAT发生。 我想192.168.43.87映射到一个公共IP接近客户端，然后到10.53.72.193靠近服务器。 （随着修改量的发生，客户端口号保持不变，这有点令人惊讶。）
• 注意从客户端到服务器的数据包的IPID字段，我注意到这一点：它们从0x5b1f开始，并从该值开始递增，直到到达最后一个数据包的0x51d3 。 但是，在接收端，第一个数据包在到达时具有不同的IPID。 它是0xd5f5 。 我还注意到ID为0x51c2的数据包被延迟，并在ID为0x51c4的数据包之后到达。
• 得到IPID字段的SYN数据包也被重新sorting。 这不应该引起任何问题，但是表明一个中间盒已经把这个SYN包完全拉开了，并且产生了一个类似于最原始点的新包。 我们也可以看到，对于这个特定的数据包，TTL在传输中增加了。
• 损坏的IPID，丢弃的ACK分组或延迟的重传都不会造成任何问题。 服务器确实回复了请求，延迟的数据包没有任何意义，因为它是服务器已经收到的数据包的重新传输。
• 来自服务器的数据包上的0x2770从SYN-ACK数据包上的0x0000开始，然后从第二个数据包上的0x2770到最后的0x2770 。
• 只有ID为0x2766的数据包丢失了。 剩下的ID按顺序到达客户端。
• 窗口缩放选项在飞行中被修改。 服务器发送9，客户端收到7。
• 丢失的数据包是请求本身的ACK。 这个丢失的数据包解释了为什么客户端重新发送请求。
• 服务器处理请求并产生回复的时间超过200毫秒。 延迟一个ACK很长时间是不可接受的。 以防万一它可以捎带在一个有效载荷数据包上，这可能是可以的。 但是，如果在几个毫秒内没有有效载荷分组出现，那么ACK应该被自己传送。
• 当收到HTTP回复的第一部分（和请求的ACK）的数据包（ID为0x2767的数据包）时，客户端用初始SYN-ACK的序列号的SYN-ACK而不是刚收到的数据包进行响应。 它忽略了它所得到的ACK并不断重发请求。 换句话说，客户端的行为就好像刚收到一个无序的数据包。 如果客户端只是因为服务器向客户端丢失了ACK而这样做，那么显然这是客户端TCP堆栈中的一个错误。 我怀疑这个数据包有什么问题。 此数据包在从服务器到客户端的传输中广告的窗口大小增加了。 然而，由于窗户几乎没有满，这不太可能成为问题。
• 密切关注绝对序列号（而不仅仅是Wireshark中默认显示的相对值），我注意到序列号从客户端传送到服务器，但是在从服务器到客户端的过程中被修改。 只要在从客户端到服务器的传输中相应地修改了确认的序列号，这应该不会引起任何问题。

在ICMP错误信息中发现时，涉及的中间件没有办法调整所有的更改。 因此，我相信在发送数据包之前有select地减lessTTL可以用来识别沿途的哪个路由器正在encryption数据包。 （除非提供商决定放弃所有相关的ICMP数据包，否则您将无法debugging问题，如果是这种情况，则应该查找其他提供商。）