Question

我有一个间歇性但可重现的TCP连接问题。接收器（端口14004）位于RedHat 6主机上时，发件人（端口64613）在Windows框上运行。端口不是图片的一部分：不同的端口也会发生相同的问题。

连接正常运行一分钟左右，数据和确认数据包正常流动。

但是随后发生以下行为：发送方的Wireshark捕获显示正在发送的数据包（seq = 3020828）：

    57788   2018-07-16 15:36:20.552618000            10.245.40.74     10.245.54.13     TCP      2974            64613 -> 14004 [ACK] Seq=3020828 Ack=73535403 Win=65536 Len=2920

从未收到任何ACK的

。发送者还会不断地以较小的数据包重传它，直到最终放弃连接之前最多重复5次：

    58376   2018-07-16 15:36:20.851770000             10.245.40.74     10.245.54.13     TCP      1514     [TCP Retransmission] 64613 -> 14004 [ACK] Seq=3020828 Ack=74313583 Win=1296 Len=1460
    58378   2018-07-16 15:36:21.101721000             10.245.54.13     10.245.40.74     TCP      1350            14004 -> 64613 [PSH, ACK] Seq=74313583 Ack=3020828 Win=4096 Len=1296 [TCP segment of a reassembled PDU]
    ...
    60992   2018-07-16 15:36:22.652682000             10.245.40.74     10.245.54.13     TCP      1514     [TCP Retransmission] 64613 -> 14004 [ACK] Seq=3020828 Ack=77762103 Win=1296 Len=1460
    60994   2018-07-16 15:36:22.658427000             10.245.54.13     10.245.40.74     TCP      1514            14004 -> 64613 [ACK] Seq=77762103 Ack=3020828 Win=4096 Len=1460 [TCP segment of a reassembled PDU]
    ...
    91947   2018-07-16 15:36:39.456903000             10.245.40.74     10.245.54.13     TCP      54            64613 -> 14004 [RST, ACK] Seq=3022288 Ack=118789563 Win=0 Len=0

接收方的tcpcap显示正在接收的数据包（由于中间网络设备的原因，只是较小的拆分）：

    13573   2018-07-16 15:36:20.526327000            10.245.40.74     10.245.54.13     TCP      1514            64613 -> 14004 [ACK] Seq=3020828 Ack=73535403 Win=65536 Len=1460
    13575   2018-07-16 15:36:20.526360000            10.245.40.74     10.245.54.13     TCP      1514            64613 -> 14004 [ACK] Seq=3022288 Ack=73535403 Win=65536 Len=1460

还可以很好地接收重发的数据包，直到最终的RESET数据包为止：

    13878   2018-07-16 15:36:20.825430000             10.245.40.74     10.245.54.13     TCP      1514     [TCP Retransmission] 64613 -> 14004 [ACK] Seq=3020828 Ack=74313583 Win=1296 Len=1460
    18810   2018-07-16 15:36:36.047313000             10.245.54.13     10.245.40.74     TCP      29254            14004 -> 64613 [ACK] Seq=114189103 Ack=3020828 Win=20480 Len=29200 [TCP segment of a reassembled PDU]
    ...
    13991   2018-07-16 15:36:21.425465000             10.245.40.74     10.245.54.13     TCP      1514     [TCP Retransmission] 64613 -> 14004 [ACK] Seq=3020828 Ack=74834803 Win=1296 Len=1460
    13993   2018-07-16 15:36:21.433178000             10.245.54.13     10.245.40.74     TCP      27794            14004 -> 64613 [ACK] Seq=74834803 Ack=3020828 Win=4096 Len=27740 [TCP segment of a reassembled PDU]
    ...
    14388   2018-07-16 15:36:22.626436000             10.245.40.74     10.245.54.13     TCP      1514     [TCP Retransmission] 64613 -> 14004 [ACK] Seq=3020828 Ack=77762103 Win=1296 Len=1460
    14390   2018-07-16 15:36:22.632029000             10.245.54.13     10.245.40.74     TCP      32174            14004 -> 64613 [PSH, ACK] Seq=77762103 Ack=3020828 Win=4096 Len=32120 [TCP segment of a reassembled PDU]
    ...
    19416   2018-07-16 15:36:39.431628000             10.245.40.74     10.245.54.13     TCP      60            64613 -> 14004 [RST] Seq=3020828 Win=0 Len=0

正如您在上面看到的，每次接收方用上一个序列号的ACK消息答复时： 3020828的ACK，而不是新的（3020828 + 1460）。

最终，连接断开。

接收器接收新数据包却产生先前序列号的ACK可能是什么原因？

Answer 1

接收器接收新数据包却产生先前序列号的ACK可能是什么原因？

我建议收件人（即RedHat系统上的应用程序）已停止读取数据。这将填满套接字缓冲区，并且一旦套接字缓冲区已满，OS内核将不再接受任何数据。该应用程序仍在通过数据将数据写入原始发送方。但是，由于应用程序读取的套接字缓冲区已满，因此只会将套接字缓冲区中最后一个（并且仍未读取）数据的ACK与写入原始发送方的数据一起发送。

奇怪的TCP转储序列

1 个答案: