我家Debian路由器上的奇怪的慢上行链路问题和新的快速连接

昨天我得到了一个新的闪亮的VDSL2连接家！它的亮度为100Mbit / 10Mbit，似乎非常接近标准。

现在，我有一个Debian挤压linux盒子作为家庭NAS和路由器。它正在运行shorewall，启用了NAT和tc。我还有一个OSX工作站通过交换机连接到所述linux路由器：

OSX工作站 < - > Switch < - > Debian路由器 < - > VDSL2调制解调器 < - > Internet < - > 服务器

我在互联网上对我的快速服务器进行了测试：

在Linux路由器上，TCP：

$ iperf -c server -p 3333
------------------------------------------------------------
Client connecting to server, TCP port 3333
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[  3] local xxx.yyy.bbb.ccc port 41982 connected with xxx.yyy.bbb.ccc port 3333
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  2.89 MBytes  2.42 Mbits/sec

以上是问题所在。上行链路应为~10Mbit，而不是2.4Mbit。下面，您可以看到UDP工作正常。

在Linux路由器上，UDP：

$ iperf -u -c server -p 60008 -b 9M
------------------------------------------------------------
Client connecting to server, UDP port 60008
Sending 1470 byte datagrams
UDP buffer size: 1.00 MByte (default)
------------------------------------------------------------
[  3] local xxx.yyy.bbb.ccc port 56484 connected with xxx.yyy.bbb.ccc port 60008
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  10.7 MBytes  9.00 Mbits/sec
[  3] Sent 7658 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec  10.7 MBytes  9.00 Mbits/sec  0.251 ms    0/ 7657 (0%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

在OSX工作站（NAT后面）TCP上：

$ iperf -c server -p 3333
------------------------------------------------------------
Client connecting to server, TCP port 3333
TCP window size: 65.0 KByte (default)
------------------------------------------------------------
[  5] local 192.168.9.141 port 54388 connected with xxx.yyy.bbb.ccc port 3333
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec  13.2 MBytes  11.1 Mbits/sec

linux路由器背后的OSX似乎不受linux路由器问题的影响。怎么会发生这种情况？UDP工作正常。

在OSX工作站（NAT后面）UDP：

$ iperf -u -c server -p 60008 -b 9M
------------------------------------------------------------
Client connecting to server, UDP port 60008
Sending 1470 byte datagrams
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[  5] local 192.168.9.141 port 64588 connected with xxx.yyy.bbb.ccc port 60008
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec  10.7 MBytes  9.00 Mbits/sec
[  5] Sent 7658 datagrams
[  5] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  5]  0.0-10.0 sec  10.7 MBytes  9.00 Mbits/sec  0.133 ms    0/ 7658 (0%)

正如你所看到的，linux盒子停留在2.5Mbit / s的出站TCP上。UDP工作正常，路由器后面的工作站工作正常。

为了简化这种情况，我将Shorewall TC修改为一个非常基本的水平。我也尝试从岸墙完全关闭TC而没有任何影响。：

tcdevices：

#INTERFACE  IN-BANDWITH OUT-BANDWIDTH
eth0        -           12000kbit

tcclasses：

#INTERFACE      MARK    RATE            CEIL        PRIORITY    OPTIONS
eth0            1       full            full        1           default

tcrules：

#MARK           SOURCE          DEST            PROTO   PORT(S) CLIENT   USER
1:F             0.0.0.0/0       0.0.0.0/0       icmp    echo-request
1:F             0.0.0.0/0       0.0.0.0/0       icmp    echo-reply

你知道问题出在哪里吗？我在Debian上运行的唯一非默认操作是来自backports的3.2.0内核。这个盒子是一个功能强大的Xeon机器，有很多RAM和Intel网卡。所有测试都在很短的时间内完成，几乎没有其他网络流量。并重复多次。我在哪里可以开始调试？

我找到了问题的解决方案。我所要做的只是关闭网卡上的分段卸载：

ethtool -K eth0 gso off tso off

这解决了我的问题。显然它很常见。

几点：

1.）TCP可能需要一点时间才能达到全速 - 无论是在较长流量上找到适当的窗口大小还是在较短流量上找到适当的窗口大小（即1.5 x RTT与TCP进行握手以及立即启动时） UDP）。10兆字节的数据不是很多。当您向1G标记推进时，您应该看到TCP的平均速度提高。

2.）即使完全优化，也需要在可靠性和性能之间进行权衡。即使在完美的实验室条件下，TCP也可能对微爆流非常敏感。在DSL设置上运行（无论多快）可能会将流量暴露给可变量的缓冲，序列化延迟等。同样，这往往会在较长的流量上平均。UDP（特别是在性能基准测试中）将尽可能地传输，而不考虑数据包丢失，缓冲区溢出等。

因此，使用TCP窗口的想法是，如果它完美运行，那么我们就会遇到这样一种情况：飞行中的最佳流量具有最小可能的开销百分比（即确认，TCP报头等）。实际上，传输中的流量应该允许恒定的带宽 - 即使确认正在流动。TCP的性能将渐近地接近广泛的数据传输。

相比之下，UDP是一种广泛的数据传输......

现在 - 各种平台之间的性能差异将取决于TCP的特定实现以及系统本身如何优先考虑I / O和协议处理。可能会有两个调整或两个将使两个值更好地进行平价。但是，样本的大小仍然是一个问题。测试越多，尺寸越大，结果越准确。