我已经使用 Linux 机器作为路由器一段时间了。没什么特别的，只是在内核中启用转发、打开伪装，并设置 iptables 以在防火墙上戳几个漏洞。
最近，我的一个朋友指出了一个性能问题。单个 TCP 连接似乎性能很差。您必须打开多个并行 TCP 连接才能获得不错的速度。
例如，我有 10 Mbit 的互联网连接。当我使用类似 Firefox 的 DownThemAll! 扩展程序（可打开多个并行 TCP 连接）从已知快速的源下载文件时，我可以使下行带宽达到最大值，约为 1 MB/s。但是，当我使用 Firefox 中的内置下载管理器（仅使用单个 TCP 连接）下载同一文件时，它开始很快，然后速度下降，直到达到最大值 100 KB/s 到 350 KB/s。
我检查了内部网络，似乎没有任何问题。一切都通过 100 Mbit 交换机。我还在内部（从路由器到我的桌面）和外部（从我的桌面到我在网上拥有的 Linux 机器）运行了 iperf，没有发现任何问题。它的最高速度约为 1 MB/s，这是应该的。Speedtest.net 也报告了 10 Mbits 的速度。
Linux 机器上的负载始终在 0.00、0.00、0.00 左右，并且有足够的可用 RAM。这是一台较旧的笔记本电脑，配有 Pentium M 1.6 GHz 处理器和 1 GB RAM。内部网络连接到内置的 Intel NIC，电缆调制解调器连接到Netgear FA51132位PCMCIA网卡。
我认为问题出在路由器的数据包转发上，但老实说，我不确定问题可能出在哪里。有什么因素会显著减慢单个 TCP 流的速度？
答案1
问题已解决。机器上存在某种硬件问题（仍然不知道是什么问题）。在另一台机器上安装相同的 Linux 发行版并以相同的方式重新配置防火墙和数据包转发后，我不再遇到该问题。
奇怪的。
答案2
这很可能是远程端或您的 ISP 的每个流的性能问题 - 每个单独的流都被限制，要么是故意的（由您的 ISP）要么只是由于拥塞（在远程站点、在您的 ISP 或介于两者之间的任何地方）。
这不太可能是你的错。
举个例子来说明当问题为拥塞时该算法是如何工作的，想象一下一个 Web 服务器，其连接速度为 10000Kbyte/sec，没有其他限制/瓶颈。如果有 100 个活动连接正在下载大型对象，则每个连接（忽略每个客户端和服务器之间的延迟和拥塞差异所导致的差异）平均将获得大约 100Kbyte/sec 的速度。如果您打开了五个连接而不是一个，那么您将获得大约 480Kbyte/sec（10000/104*5）的速度，而每个单独的流将获得大约 95Kbyte/sec（10000/104*1）的速度。当然，在这个例子中，您是唯一一个使用多个连接的人，这在现实生活中不太可能发生。而且，这种计算只有在拥塞下的流量管理导致每个流的平均速率公平时才有效，同样，在现实生活中，有许多因素会导致这种情况发生变化，并且流量管理可能会在任何明确或隐含的每流限制之上施加一些每主机限制。