linux - 关于拥塞下tcp行为的几个问题

标签 linux tcp congestion-control

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

以下是问题:

  1. When there is re-transmission, what will happen to sender side congestion window (snd_cwnd)? The os is linux kernel 3.4.42. As is said the snd_cwnd will be reduced to 1 when there is re-transmission. If this is the case, why packet 6179, 6180 can still be sent?
  2. why 6179, 6180 did not get ACKed? Instead 6178 can get ACKed, means packets can get through.
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

最佳答案

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

Understanding Linux Network Internals

有关 TCP 的更多信息,请参阅:

TCP/IP Illustrated

关于linux - 关于拥塞下tcp行为的几个问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23719056/

相关文章:

linux - 使用参数运行 Linux shell 脚本

linux - 如何在使用 GDB 生成进程核心文件之前预测其大小?

networking - sshuttle 如何避免 TCP-over-TCP 诅咒?

TCP 拥塞窗口大小..?

c - 在套接字上设置 TCP ECN (C Linux)

c++ - 如何获取进程中的定时器个数?

linux - Perl CPAN 安装 - 依赖性问题

c - TCP服务器在C中一次监听多个客户端

node.js - Compute Engine Express 两个端口

java - 在 java 中维护 TCP 套接字有多昂贵