Fatal编程技术网
  • tcp/
  • 奇怪的TCP转储序列

奇怪的TCP转储序列

tcp

奇怪的TCP转储序列,tcp,connection,reset,seq,Tcp,Connection,Reset,Seq,我的TCP连接存在间歇性但可重复的问题。 发送方（端口64613）在Windows机箱上运行，而接收方（端口14004）在RedHat 6主机上运行。 端口不是问题的一部分：相同的问题发生在不同的端口上 连接正常工作一分钟左右，数据和确认数据包正常流动 但随后会发生以下行为：发送方端的Wireshark捕获显示正在发送的数据包（seq=3020828）： 没有收到任何回发的确认。 发送方还在一个较小的数据包中继续重新发送，最多5次，然后最终放弃连接： 58376 2018-07-16

我的TCP连接存在间歇性但可重复的问题。 发送方（端口64613）在Windows机箱上运行，而接收方（端口14004）在RedHat 6主机上运行。 端口不是问题的一部分：相同的问题发生在不同的端口上

连接正常工作一分钟左右，数据和确认数据包正常流动

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

没有收到任何回发的确认。 发送方还在一个较小的数据包中继续重新发送，最多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显示正在接收的数据包（由于中间网络设备，仅以较小的间隔）：

此外，重新传输的分组接收良好，直至最终重置分组：

    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而不是新的（3020828+1460）

最终，连接中断

接收方拾取新数据包但为以前的序列号生成ACK的原因可能是什么

接收方拾取新数据包但为以前的序列号生成ACK的原因可能是什么

我建议收件人（即RedHat系统中的应用程序）已停止读取数据。这将填满套接字缓冲区，一旦套接字缓冲区已满，操作系统内核将不再接受更多数据。应用程序仍在将数据写入原始发件人。但由于应用程序读取套接字缓冲区已满，因此只有套接字缓冲区中最后一个（仍然未读）数据的ACK将与写入原始发送方的数据一起发送。

如果是这种情况，两个TCP捕获不都至少包含一条“TCP零窗口”控制消息，从接收方返回发送方吗，通知接收窗口已满？@user3239967:我不知道为什么它没有变为零，但宣布的窗口大小至少从20480下降到4096。谢谢，Steffen。我还不太确信：在这种情况下，您是否暗示TCP不会允许接收器暂时减速？预期行为：-如果recv窗口未满（确实是Win=4096>>PacketLen=1460），则应接收并确认数据包-如果recv窗口已满，则应通知发送方，流量控制可按我们在此处观察到的方式启动：窗口有足够的空间，然而，数据包被悄悄地丢弃在接收方），发送方没有得到通知。因此，在任意次数的无用的重新传输之后，连接停止。@user3239967：我也不相信，但这是我能想到的最好的解释。可能还有一些全局限制，即特定套接字缓冲区中会有空间（因此窗口不会为零），但它达到了所有缓冲区可以占用的内存限制，因此数据包被丢弃。 
    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

    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