无法在对称 Internet 连接上实现全速
我们正在使用商业以太网连接（3Mbit 上传，3Mbit 下载）并尝试了解我们测试的带宽速度的问题。上传大文件时，我们维持 340 KB/s；下载我们维持340KB/s。然而，当我们同时运行这些传输时，两个传输速度会不稳定地上升和下降，两者的平均速度约为 250 KB/s。我们使用 Hatteras HN404 CPi，并且绕过了路由器（将机器直接插入 Hatteras；将 NIC 设置为全双工）。
这是预期的吗？在这种类型的 Internet 连接上，最大上传是否会干扰最大下载？
We are using a business Ethernet connection (3Mbit upload, 3Mbit download) and trying to understand issues with our tested bandwidth speeds. When uploading a large file we sustain 340 KB/s; downloading we sustain 340KB/s. However when we run these transfers simultaneously the two transfer speeds rise and fall erratically with a average speed for both at around 250 KB/s. We're using a Hatteras HN404 CPi and we've bypassed the router (plugged a machine directly into the Hatteras; set the NIC to full-duplex).
Is this expected? Should a max upload interfere with a max download on this type of Internet connection?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您确定瓶颈是您的连接吗？
当不同系统上同时上传和下载时，或者仅当一个系统同时处理上传和下载时，您是否也会看到此行为？
如果当独立机器执行工作时问题消失，则瓶颈可能更靠近硬盘驱动器。
Are you sure the bottleneck is your connection?
Do you also see this behavior when the simultaneous upload and download are occurring on different systems, or only when one system is handling both the upload and download?
If the problem goes away when independent machines are doing the work, the bottleneck is likely closer to the hard drive.
根据我在低端产品线的经验，这听起来是预料之中的。在家庭线路上，我发现流量整形和更改缓冲区大小可以提供巨大的帮助。
没有任何异常流量整形的 TCP/IP 将有利于最激进的流量，而牺牲其他一切。就您而言，这意味着对传出 ACK 的响应以及下载等将被延迟，甚至可能被丢弃。查看您的 HN404 是否支持基于类的排队或类似的功能，然后尝试一下。
This sounds expected from my experience with lower end lines. On a home line, I've found that traffic shaping and changing buffer sizes can be a huge help.
TCP/IP without any unusual traffic shaping will favor the most aggressive traffic at the expense of everything else. In your case, this means responses to the outgoing ACKs and such for the download will be delayed or maybe even dropped. See if your HN404 supports class based queuing or something similar and try it out.
是的，这是预期的。这是任何连接受到限制或限制的情况下的症状。如果您的上行链路饱和，则会影响您的下行链路，反之亦然。
这是因为连接的速率限制会影响 TCP 握手确认数据包 (ACK)，并破坏这些数据包流动的正常“平衡”。
本页对电缆调制解调器故障排除技巧进行了非常详尽的描述，尽管它不限于电缆调制解调器：
那么如何避免这种情况呢？最好的方法是对各个会话实施某种流量整形或 QoS（服务质量），以根据总可用带宽的百分比将其限制为最大吞吐量。
例如，在我的家庭网络上，我有它，这样任何出站连接都可以利用我的 192Kbps 上行链路的 67%（2/3）以上。这意味着任何单个出站会话只能使用 128Kbps，因此可以通过防止上行链路饱和来保护我的下行链路速度。
在大多数情况下，您可以根据任何可用的条件（例如源 IP、目标 IP、协议、端口、时间等）执行此类流量整形。
Yes it is expected. This is symptomatic of any case in which you have a throttled or capped connection. If you saturate your uplink it will affect your downlink and vice versa.
This is because the your connection's rate-limiting impacts the TCP handshake acknowledgement packets (ACKs) and disrupts the normal "balance" of how these packets flow.
This is very thoroughly described on this page about Cable Modem Troubleshooting Tips, although it is not limited to cable modems:
So how do you avoid this? The best way is to implement some sort of traffic-shaping or QoS (Quality of Service) on individual sessions to limit them to a maximum throughput based on a percentage of your total available bandwidth.
For example on my home network I have it so that no outbound connection can utilize any more than 67% (2/3rd) of my 192Kbps uplink. That means any single outbound session can only utilized 128Kbps, therefore protecting my downlink speed by preventing the uplink from becoming saturated.
In most cases you are able to perform this kind of traffic-shaping based on any available criteria such as source ip, destination ip, protocol, port, time of day, etc.
看来我对同时传输速度的看法是错误的。传输程序错误计算了 250KB/s 的向上和向下速度（似乎一直显示较高的平均速度）。显然，商业以太网（在本例中是 Speakeasy 提供的 XO 电路）仅支持总共 3Mb，而不支持向上和向下（总共 6Mb）。因此，如果我同时向上和向下传输，理论上我应该只有 1.5Mbit 向上和向下传输或最大 187.5KB/s（如果开销为零）。
It appears that I was wrong about the simultaneous transfer speeds. The 250KB/s speeds up and down were miscalculated by the transfer program (seemed to have been showing a high average speed). Apparently the Business Ethernet (in this case it is an XO circuit provisioned by Speakeasy) only supports 3Mb total, not up AND down (for 6Mbit total). So if I am transferring up and down at the same time in theory I should only have 1.5Mbit up and down or 187.5KB/s at the maximum (if there was zero overhead).