TCP服务器停止发送SYN/ACK，而只是在几个正常TCP会话之后发送ACK

我有几千台NAT背后的设备与两台服务器通信。每个设备都位于一个本地路由器（比如调制解调器/路由器）的后面，在这个路由器上，它们可以连接到一个拥有数千个设备的专用网络，在这个专用网络的网关上，来自数千个设备的TCP会话可以动态地将NAT过载/PAT连接到单个全局IP地址上的端口。这意味着，假设设备1将与服务器通信，连接将来自路由器的全局ip：端口号1。一旦设备1通话完毕，NAT关联被删除，当设备2想要与同一服务器通话时，远程路由器可以为设备2分配相同的全局端口，即服务器可以看到新的TCP连接来自路由器的全局ip端口：端口号\u 1

设备本身启动TCP连接，对一个小文件执行HTTP post，断开TCP连接，为下一个文件建立新连接，等等。这对大约20个文件都可以正常工作，之后在SYN上，设备只从服务器返回ACK，没有SYN。ACK的ACK编号与SYN上的序列号完全不同。设备在1秒后立即发送RST、后退并尝试从同一源端口发送SYN，但仍为ACK，因此在放弃之前，它会一直后退到3、6、12、24、48秒。在设备的RST上，它似乎在使用ACK中的SEQ，试图关闭旧连接（从服务器角度看）

远程主机是AWS ELB。以下是我们的假设和我们的尝试：

远程路由器必须以比目标服务器（ELB）更快的速度处理TCP会话死机、超时NAT和重用全局端口。这可能会导致ELB处于TCP_TIME_WAIT状态，这就是它用ACK响应SYN的原因。由于ELB的TCP时间等待未知，假设它是Linux内核中的标准60秒默认值，它将匹配远程路由器上的post FIN/RST NAT超时。然而，我们在路由器上将其更改为70秒，以避免任何竞争条件。这并没有使问题消失

我们认为，如果远程路由器更快地终止NAT，它会在设备退避时为SYN重试分配一个新的NAT。如果dest服务器上的问题与远程路由器上正在使用的全局端口号有关，那么看到新的SYN来自路由器IP上的新全局端口应该会导致它脱离怪异状态。现在，虽然我们可以看到这项工作，但看起来新分配的NAT端口在服务器上也遇到了同样的问题，它返回了一个虚假的ACK，但有另一个不同的ACK号

另一个假设是，只有当SYN上的SEQ低于上次连接上使用远程路由器上相同全局端口的序列号时，才会发生这种情况。i、 e.虚假ACK上的ACK编号始终高于SYN上的SEQ。（我们将Wireshark切换为绝对序列号以查看此情况）。然而，事实证明，我们正在看到SYN SEQ大于虚假ACK上的ACK数的实例。所以这个理论被搁置了

我们现在不知道这里会发生什么。我们怀疑新连接与旧连接具有相同的全局端口，但是，如果是这样的话，（a）通过使路由器保持NAT更长的时间，它应该阻止它，并且（b）通过让路由器更早地终止NAT并为相同的连接尝试分配不同的NAT，这应该避免了问题

如果您能在这里帮助我们理解这种行为，我们将不胜感激

Wireshark跟踪此处：

请注意，跟踪已被匿名化（IPs和MAC已被替换），所有具有有效负载的TCP数据包已被删除。问题的第一个实例开始于数据包129，第二个实例数据包382，然后是463、699、816、1120、1278、1323等等

---

查看跟踪中的最后一个实例，这就是我们缩短路由器上NAT post FIN/RST超时的地方。您可以看到，前四次ACK的AKC编号为2899295595。但是在5号上，ACK是3102149417。6号电话是4158039292。这是因为在这里，路由器被设置为更快地超时NAT，因此这些尝试来自路由器上不同的全局端口。如果问题与全局端口和使用全局端口的前一个连接有关，则应已停止该问题。但问题依然存在，这让我们相信这与源端口无关，而是由TCP SYN本身的某些东西造成的。

您的路由器是cisco ASR1001吗

我遇到了几乎相同的问题，并将ip nat转换超时（动态nat）值设置为默认值（86400秒）。我以前的超时设置是600秒

---

一些客户端在我的NAT网络中进行了一些长TCP会话。正如您所说，如果我删除NAT会话的速度比两个端点都快，它将中断现有会话。

请注意，跟踪中“TCP确认未看到的段”的激增是因为我过滤掉了所有具有有效负载的TCP数据包以确保机密性（它们与问题无关）。我包括了连接历史记录，以表明设备在遇到此问题之前，在多个会话上发送数据时没有任何问题。服务器故障比这里更能说明这个问题。请把它贴在那里。不过最好不要交叉贴。