为什么套接字连接被阻止并且TCP内核不断重传[ACK]数据包

Question

我们面临的一个问题是，从一段时间以后，特定的套接字连接将被阻止，客户端的tcp内核将继续转发[ACK]数据包。

拓扑流程如下：

   Client A ←→ Switch A ← Router A:NAT ← .. Internet .. 
               → Router B:NAT → Switch B ←→ Server B

以下是WireShark捕获的数据包：
A）服务器

1. 8013 > 6757 [PSH, ACK] Seq=56 Ack=132 Win=5840 Len=55     
2. 6757 > 8013 [ACK] Seq=132 Ack=111 Win=65425 Len=0     

B）客户

//lines 3 and 4 are exactly the same as line 1 and 2      
3. 8013 > 13000 [PSH, ACK] Seq=56 Ack=132 Win=5840 Len=55      
4. 13000 > 8013 [ACK] Seq=132 Ack=111 Win=65425 Len=0     
5. 13000 > 8013 [PSH, ACK] Seq=132 Ack=111 Win=65425 Len=17     

[TCP Retransmission]          
6. 13000 > 8013 [PSH, ACK] Seq=132 Ack=111 Win=65425 Len=17         

8013是服务器端口，6757是客户端NAT端口。

为什么即使服务器已经收到一个[ACK]数据包（请参见数据包2），TCP内核为什么仍继续发送[ACK]数据包以告知客户端它已接收到数据包1（请参见数据包4、5和6）？ 发生问题时，连接双方均不会关闭套接字。

数据包6之后，连接断开，我们无法再通过该套接字将任何内容发送到服务器。

         psuedocode:  
         //client
         serverAddr.port =htons(8013) ;
         serverAddr.ip = inet_addr(publicIPB);
         connect(fdA, serverAddr,...);         

         //server
         listenfd = socket(,SO_STREAM,);
         localAddr.port = htons(8013);
         localAddr.ip = inet_addr(INADDR_ANY);
         bind(localAddr...)
         listen(listenfd, 100);

         ...
         //using select model
         select(fdSet, NULL, NULL, NULL);
         for(...)
         {
         if (FD_ISSET(listenfd))
            {
            ...
              }
         ...
         }

更新
UP1。 这是重现该问题的具体步骤

1. 给定三台计算机，分别为PC1，PC2和PC3。 这三个都在RouterA后面，而服务器在RouterB后面。

2. 给定两个用户U1和U2。 U1从PC1登录，U2从PC3登录。 U1和U2都将在自身和服务器之间建立tcp连接。 现在，U1能够通过其tcp连接将数据发送到Server，然后Server将所有数据中继到U2。 到目前为止，一切正常。

   表示与U1和服务器之间的TCP连接的服务器端点相对应的套接字号：U1-OldSocketFd

3. 不要注销U1，然后拔下PC1的电缆。 然后，U1从PC2登录，现在它与服务器建立了新的TCP连接。

   表示与U1和服务器之间的TCP连接的服务器端点相对应的套接字号：U1-NewSocketFd

   从服务器端，当它使用U1更新其Session时，它将调用close(U1-OldSocketFd) 。

4.1。 在第3步之后大约30秒，我们发现U1无法通过其新的TCP连接将任何数据发送到服务器。

4.2。 在第3步中，如果服务器没有立即调用close(U1-OldSocketFd) （在U1和Server之间建立了相同的第二个新连接），而是服务器在70-80秒内调用了close(U1-OldSocketFd) ，则一切正常。

UP2。 路由器B在端口8013上使用端口转发。
UP3。 运行服务器的Linux操作系统的一些参数。

    net.ipv4.tcp_tw_reuse = 1
    net.ipv4.tcp_tw_recycle = 1

Answer 1

数据包1（与3相同）和数据包2（与4相同）通过后，您的客户端似乎正在向服务器（数据包5）传输17个字节的数据。 我不知道第一次交换数据包之后会有多少个数据包5出现，所以我不知道会在多少时间后发生。 您的伪代码没有澄清它，因为它只显示套接字初始化，它没有显示哪一方在什么时候尝试传输什么数据。 在这种情况下， 梯形图可能对表示协议交换很有用。

在任何情况下，服务器显然都不会确认这17个字节的数据，因此它们将再次传输（数据包6）。

除非您对网络，防火墙或NAT路由器有任何问题，或者其他原因导致丢包，否则应该没有任何理由可以使服务器接收TCP交换的较早部分，但显然不能接收5或6包再次，在先前的数据交换和数据包5之间是否经过了大量时间（例如，足够的时间使NAT路由器，防火墙或负载平衡器使连接失效）？

Answer 2

根据您重现该问题和UPD3的步骤，可能是由于

net.ipv4.tcp_tw_recycle = 1

原因是内核正在尝试在到期时间之前回收TIME_WAIT连接（这要感谢tw_recycle）。

该答案说明了tw_reuse和tw_recycle的行为方式（此处关注NAT部分）。

根据重现步骤并观察4-1和4-2，当您立即调用fclose（）时，连接进入TIME_WAIT状态，从那里tw_recycle可以继续进行，并假定由于此端已关闭连接，因此套接字可以回收利用。 从服务器的角度来看，由于连接来自同一主机，因此tw_recycle启动。

当您改为在调用fclose（）之前等待时，由于未从服务器的POV触发断开连接，因此它将假定连接仍处于活动状态，这阻止了tw_recycle进入，有可能/可能会强迫创建全新的连接。

根据1 ，为避免受到协议POV的侵害，您有2种情况：

• 禁用tw_reuse和tw_recycle
• 启用tw_reuse，启用TCP时间戳，禁用tw_recycle

鉴于您的网络拓扑，tw_recycle可能总是会触发无连接性条件。