【问题标题】:How TCP flow's rate change when congestion occur拥塞发生时 TCP 流的速率如何变化
【发布时间】:2019-07-30 13:35:41
【问题描述】:

感谢您点击我的问题。

我正在做一个小实验来了解 TCP 流在拥塞时的行为。

在这个实验中,我发现当拥塞发生时,tcp 流的速率比我想象的要大得多。

由于它的拥塞控制,我认为它的速率最多应该减半。

但在我的实验中并没有。

你能给我一点提示吗?下面是我的实验。

感谢您再次点击



我使用Mininet 构建了一个小型网络,由两台主机和一个交换机组成。

H1 - S1 - H2 ,所有链路带宽 80Mbps

然后,我使用iperf3 生成从 H2 到 H1 的流量,如下所示

#H1
iperf3 -s -p 1212 -f m -i 1

#H2
iperf3 -c 10.0.0.1 -p 1212 -t 10000 -f m -b 70M

表示H2以70Mbit/s的速度向H1发送TCP数据包

(iperf3 在应用层控制其 TCP 速率。)

然后我们可以在H1(服务器端)看到报告

-----------------------------------------------------------
Server listening on 1212
-----------------------------------------------------------
Accepted connection from 10.0.0.2, port 51786
[ 17] local 10.0.0.1 port 1212 connected to 10.0.0.2 port 51788
[ ID] Interval           Transfer     Bandwidth
[ 17]   0.00-1.00   sec  7.49 MBytes  62.8 Mbits/sec                  
[ 17]   1.00-2.00   sec  8.14 MBytes  68.3 Mbits/sec                  
[ 17]   2.00-3.00   sec  8.54 MBytes  71.7 Mbits/sec                  
[ 17]   3.00-4.00   sec  8.60 MBytes  72.2 Mbits/sec                  
[ 17]   4.00-5.00   sec  7.98 MBytes  66.9 Mbits/sec                  
[ 17]   5.00-6.00   sec  8.80 MBytes  73.9 Mbits/sec                  
[ 17]   6.00-7.00   sec  8.21 MBytes  68.9 Mbits/sec                  
[ 17]   7.00-8.00   sec  7.77 MBytes  65.1 Mbits/sec                  
[ 17]   8.00-9.00   sec  8.30 MBytes  69.7 Mbits/sec                  
[ 17]   9.00-10.00  sec  8.45 MBytes  70.9 Mbits/sec                  
[ 17]  10.00-11.00  sec  8.32 MBytes  69.7 Mbits/sec   

此时,我使用linux tc 限制 S1 端口(s1-eth1,从 H2 到 H1 的出口)

sudo tc qdisc del dev s1-eth1 root
sudo tc qdisc add dev s1-eth1 root tbf rate 40mbit latency 10ms burst 1mbit

那么结果如下

[ 17]   0.00-1.00   sec  7.76 MBytes  65.0 Mbits/sec                  
[ 17]   1.00-2.00   sec  8.09 MBytes  67.9 Mbits/sec                  
[ 17]   2.00-3.00   sec  8.53 MBytes  71.5 Mbits/sec                  
[ 17]   3.00-4.00   sec  8.47 MBytes  71.0 Mbits/sec                  
[ 17]   4.00-5.00   sec  8.08 MBytes  67.8 Mbits/sec                  
[ 17]   5.00-6.00   sec  8.09 MBytes  67.9 Mbits/sec                  
[ 17]   6.00-7.00   sec  8.74 MBytes  73.3 Mbits/sec                  
[ 17]   7.00-8.00   sec  7.81 MBytes  65.6 Mbits/sec                  
[ 17]   8.00-9.00   sec  8.35 MBytes  70.0 Mbits/sec                  
[ 17]   9.00-10.00  sec  4.56 MBytes  38.3 Mbits/sec                  
[ 17]  10.00-11.00  sec  4.56 MBytes  38.2 Mbits/sec                  
[ 17]  11.00-12.00  sec  4.56 MBytes  38.2 Mbits/sec                  
[ 17]  12.00-13.00  sec  4.56 MBytes  38.2 Mbits/sec                  
[ 17]  13.00-14.00  sec  4.56 MBytes  38.2 Mbits/sec       

如你所见,它的速率约为 40Mbps。

我认为当拥塞发生时,TCP状态应该变成slow start,然后它的速率应该会变小很多。但它没有。

我检查了iperf3 源代码,但它只是使 TCP 流量达到来自应用层的数量。因此它对 TCP 算法的行为没有影响。

为什么会这样?我不知道...

你能给我一点提示吗?我很感激你!

【问题讨论】:

  • 以更好的分辨率查看正在发生的事情的最有效方法(1 秒对于网络来说是很长的时间)我建议使用 Wireshark 或类似工具捕获流量。
  • @C.Gonzalez 非常感谢!我现在监控流量!

标签: networking tcp iperf congestion-control


【解决方案1】:

首先,我必须在实验前正确设置参数。

1)在设置链路带宽时,我们可以在TC设置中设置burst size(或mtu size)。

看起来对iperf TCP 流量的波动有影响。

当突发大小较小时,其速率波动或较低,超出我的预期。

2)另外,我们可以在切换时设置MTU大小(Jumbo frame size)。

因为我用的是OVS(OpenVSwitch),所以我把参数设置为the site

3) 并且,我们可以使用ethtool来设置接口卡的MTU大小。 你可以看到this site


上述参数设置好后,最好观察一下TCP速率。

尽管拥塞,但 TCP 速率并不小的原因似乎是RTT 值小

the slide 一样,TCP 在每个 RTT 上传输其数据包。

在我的实验中,RTT 的值要小得多,因为两个主机之间只有一条边。

因此,在第二个尺度中,看起来主机并没有降低它的速率,但实际上它确实如此。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-01-03
    • 2017-08-09
    • 1970-01-01
    • 1970-01-01
    • 2013-09-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多