-1

下面的 tcpdump 日志是从我最近运行的测试中复制的。一开始一切都很顺利。然后客户端最终压倒了路由器，然后很多数据包 [# - 6176] 被丢弃（永远不会看到它们的 ACK）。然后在 6177，由于 rto 定时器超时而触发重传。

所以这里有问题：

  1. 当有重传时，发送方拥塞窗口（snd_cwnd）会发生什么？操作系统是 linux 内核 3.4.42。如前所述，当重新传输时，snd_cwnd 将减少为 1。如果是这样，为什么还可以发送6179、6180包？
  2. 为什么 6179、6180 没有得到确认？相反，6178 可以得到确认，这意味着数据包可以通过。
6174    2.881075    10.203.85.190   207.198.102.53  TCP 1426    58206 > 80 [ACK] Seq=6379071 Ack=1 Win=13824 Len=1358 TSval=4294945643 TSecr=2532115493
6175    2.881094    10.203.85.190   207.198.102.53  TCP 1426    58206 > 80 [ACK] Seq=6380429 Ack=1 Win=13824 Len=1358 TSval=4294945643 TSecr=2532115493
6176    2.881114    10.203.85.190   207.198.102.53  TCP 1426    58206 > 80 [ACK] Seq=6381787 Ack=1 Win=13824 Len=1358 TSval=4294945643 TSecr=2532115493
6177    3.227347    10.203.85.190   207.198.102.53  TCP 1426    [TCP Retransmission] 58206 > 80 [ACK] Seq=5887475 Ack=1 Win=13824 Len=1358 TSval=4294945685 TSecr=2532115493
6178    3.323055    207.198.102.53  10.203.85.190   TCP 68  http > 58206 [ACK] Seq=1 Ack=5888833 Win=980480 Len=0 TSval=2532115623 TSecr=4294945685
6179    3.326368    10.203.85.190   207.198.102.53  TCP 1426    58206 > 80 [ACK] Seq=6383145 Ack=1 Win=13824 Len=1358 TSval=4294945694 TSecr=2532115623
6180    3.326454    10.203.85.190   207.198.102.53  TCP 1426    58206 > 80 [ACK] Seq=6384503 Ack=1 Win=13824 Len=1358 TSval=4294945694 TSecr=2532115623
6181    3.727429    10.203.85.190   207.198.102.53  TCP 1426    [TCP Retransmission] 58206 > 80 [ACK] Seq=5888833 Ack=1 Win=13824 Len=1358 TSval=4294945735 TSecr=2532115623
6182    3.813101    207.198.102.53  10.203.85.190   TCP 68  80 > 58206 [ACK] Seq=1 Ack=5890191 Win=980480 Len=0 TSval=2532115746 TSecr=4294945735
6183    3.813606    10.203.85.190   207.198.102.53  TCP 1426    58206 > 80 [ACK] Seq=6385861 Ack=1 Win=13824 Len=1358 TSval=4294945743 TSecr=2532115746
6184    3.813822    10.203.85.190   207.198.102.53  TCP 1426    58206 > 80 [ACK] Seq=6387219 Ack=1 Win=13824 Len=1358 TSval=4294945743 TSecr=2532115746
6185    4.197341    10.203.85.190   207.198.102.53  TCP 1426    [TCP Retransmission] 58206 > 80 [ACK] Seq=5890191 Ack=1 Win=13824 Len=1358 TSval=4294945782 TSecr=2532115746
6186    4.294162    207.198.102.53  10.203.85.190   TCP 68  80 > 58206 [ACK] Seq=1 Ack=5891549 Win=980480 Len=0 TSval=2532115866 TSecr=4294945782
6187    4.297450    10.203.85.190   207.198.102.53  TCP 1426    58206 > 80 [ACK] Seq=6388577 Ack=1 Win=13824 Len=1358 TSval=4294945792 TSecr=2532115866
6188    4.297675    10.203.85.190   207.198.102.53  TCP 1426    58206 > 80 [ACK] Seq=6389935 Ack=1 Win=13824 Len=1358 TSval=4294945792 TSecr=2532115866
4

2 回答 2

0

当您发送 TCP 数据包时，将创建一个重传计时器（针对每个数据包）；如果 ACK 在定时器超时时没有出现，则数据包将被重传。此过程将发生多次（特定于操作系统且可配置），如果所有尝试均不成功，则连接将失败。有关 Linux 中 TCP/IP 实现的更多信息，我强烈建议您参考：

了解 Linux 网络内部结构

有关 TCP 的更多信息，请参阅：

TCP/IP 图解

于 2014-05-18T17:27:33.687 回答
0

这与 F-RTO 有关，请参阅 rfc 5682。

在传统算法（非 F-RTO）中，它是这样完成的：

当重传超时发生时，TCP 发送方进入 RTO 恢复，此时拥塞窗口初始化为一个段，未确认的段使用慢启动算法重传。

以下是 F-RTO 的运作方式：

当重传定时器到期时，F-RTO 发送方照常重传第一个未确认的段。在超时后偏离正常操作，然后它尝试为超时后到达的第一个确认传输新的、以前未发送的数据（通常是两个段，如果有足够的数据和拥塞窗口允许），假设确认会提前窗户。

所以这就解释了为什么会发送 6179 和 6180。至于为什么没有收到他们的 ACK，我认为这是一些系统级别的错误，需要解决。

于 2014-05-19T02:20:23.393 回答