![我的家用 Debian 路由器和新的快速连接出现奇怪的慢速上行链路问题](https://linux22.com/image/1325167/%E6%88%91%E7%9A%84%E5%AE%B6%E7%94%A8%20Debian%20%E8%B7%AF%E7%94%B1%E5%99%A8%E5%92%8C%E6%96%B0%E7%9A%84%E5%BF%AB%E9%80%9F%E8%BF%9E%E6%8E%A5%E5%87%BA%E7%8E%B0%E5%A5%87%E6%80%AA%E7%9A%84%E6%85%A2%E9%80%9F%E4%B8%8A%E8%A1%8C%E9%93%BE%E8%B7%AF%E9%97%AE%E9%A2%98.png)
昨天我家里有了一条崭新闪亮的 VDSL2 连接!它的规格为 100Mbit/10Mbit,似乎非常接近标准。
现在,我有一个 Debian squeeze linux 机器,用作家庭 NAS 和路由器。它运行 shorewall,启用了 NAT 和 tc。我还有一个 OSX 工作站,通过交换机连接到上述 linux 路由器:
OSX工作站<->转变<->Debian 路由器<->VDSL2 调制解调器<->互联网<->服务器
我针对互联网上的快速服务器进行了测试:
在 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 Workstation 上(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 Workstation 上(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 机器的出站 TCP 速度卡在 2.5Mbit/s。UDP 工作正常,路由器后面的工作站工作正常。
为了简化情况,我将 Shorewall TC 修改为非常基本的级别。我还尝试从 Shorewall 完全关闭 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 上运行的唯一非默认的东西是来自反向移植的 3.2.0 内核。这台机器是一台功能强大的 Xeon 机器,拥有大量 RAM 和 Intel 网卡。所有测试都在很短的时间内完成,几乎没有其他网络流量。并重复多次。我可以从哪里开始调试?
答案1
我找到了解决问题的方法。我所要做的就是关闭网卡上的分段卸载:
ethtool -K eth0 gso off tso off
这帮我解决了这个问题。显然这很常见。
答案2
几点:
1.) TCP 可能需要一点时间才能达到全速 - 无论是在较长的流上找到合适的窗口大小,还是在较短的流上设置时间(即使用 TCP 进行握手时为 1.5 x RTT,而使用 UDP 则立即启动)。10 兆字节的数据量并不大。当您向 1G 标记推进时,您应该会看到 TCP 的平均速度有所提高。
2.) 即使完全优化,可靠性和性能之间也存在权衡。即使在完美的实验室条件下,TCP 也可能对微突发异常敏感。在 DSL 设置上运行(无论速度多快)都可能使流量暴露于不同数量的缓冲、序列化延迟等。同样,这往往会在较长的流量中达到平均水平。UDP(尤其是在性能基准测试中)将尽可能地传输,而不考虑数据包丢失、缓冲区溢出等。
因此,TCP 窗口化的想法是,如果它运行完美,那么我们就会达到这样一种情况:在传输过程中,流量达到最优,开销(即确认、TCP 报头等)百分比最小。实际上,传输中的流量应该允许恒定的带宽 - 即使确认正在流动。TCP 的性能将逐渐接近完全开放的数据传输。
相比之下,UDP 是一种广泛开放的数据传输……
现在 - 不同平台之间的性能差异将取决于 TCP 的具体实现以及系统本身如何确定 I/O 和协议处理的优先级。可能会有一两个调整使这两个值达到更好的平衡。不过,样本的大小仍然是一个问题。测试越多,规模越大,结果就越准确。