为什么对称通道不能同时获得相等的上传和下载速度？

Question

为什么对称通道不能同时获得相等的上传和下载速度？

4

我被分配到一个项目，我的代码应该同时在同一FTP或HTTP服务器上上传和下载一些文件。速度被测量，并从中得出一些结论。现在的问题是，在高速连接上，我们在吞吐量方面得到了预期的结果，但是在慢速连接（想象一下理想的CDMA 1xRTT链接）上，要么下载要么上传会以牺牲另一个方向为代价获胜。我有一个"更高的身体"，他确信CDMA 1xRTT连接是对称的，因此我们应该能够在这个链接上以等效速度（每个方向约100 kbps）进行数据传输。我的测量结果表明，如果不对缓冲区大小和数据链路限制进行大量调整，就不可能在上述条件下拥有相同的速度。我尝试了我的多线程代码，并创建了一个简单的批处理文件，自动化Windows的ftp.exe进行数据传输-结果相同。所以，问题是：在慢速对称链接上是否真的可能进行数据传输，使速度相等？ "更高的身体"的期望是正确的吗？如果是，您有什么建议，我应该如何修改代码以实现这样的吞吐量？

- wasker

这是一种1xRTT连接，它是模拟的，因此连接的质量是有保证的。 - wasker

亚当，我正在寻找一些理论。 - wasker

尽管您可能正在编写相关软件，但问题是关于网络而不是编程。如果有意愿的话，请不要给我发送电子邮件告诉我重新打开问题，这里还有数百其他人可以做到这一点。 - Robert Gamble

Adam，这是标准的CDMA 1x连接。 - wasker

我有打开它的权力，并且同意Robert的建议将其关闭。我确定许多管理员已经看到并同意。尽管如此，它仍然可以得到投票支持，但没有其他普通用户认为它应该超过0。 - Adam Davis

显示剩余14条评论

2个回答

1

我认为整个高速双向等速的问题是因为我的上层机构认为他们在上行和下行都有144 kbps（即两条管道）。而实际上，我们只有一条144 kbps的管道，在传输文件时会切换方向。

如果我说得对或错，请评论告诉我。

- wasker

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Adam Davis · Accepted Answer

CDMA 1x由最多15个9.6kbps的通道组成。这将导致总吞吐量为144kbps。

其中两个通道用于命令和控制信号（与基站通话、关联/取消关联、短信流量、铃声等）。

剩下的就是最多124.8kbps了。

-->每个通道都是单向的。<--

它们根据需要动态切换和分配。

通常下载比上传更快，因为这是典型的手机调制解调器使用。但是你永远不会获得超过120kbps的总聚合带宽。

在实践中，由于1xRTT编码、错误纠正、重传等开销，即使你拥有所有可能的通道，你通常也只能体验到60kbps至90kbps之间的速度。

这意味着你可能只能同时获得30kbps-60kbps的上传和下载速度。

此外，由于通道动态切换（以及基站控制这一点比你的调制解调器更多 - 他们需要小心地管理基站通道，以便为语音通话保留通道），当它切换通道时，你会失去时间 - 这不是一个瞬间的过程。

因此 - 理论上，1xRTT可以为你提供一条单向124kbps的链接，但由于开销、切换时间、基站容量或电话公司出于其他原因限制这种连接，你不能依赖对称链接。

注意：

这将在一定程度上根据提供商和调制解调器而变化。例如，有些调制解调器有16个通道，有些提供商支持16个通道。在某些情况下，这些调制解调器和提供商能够很好地配合，为应用程序提供完整的144kbps聚合原始带宽，只需一个专用通道（必须非常努力）来处理控制、切换和其他问题。即使是这样，在调制解调器通信的开销、PPP的开销、IP的开销、TCP的开销之后，你仍然只能获得大约100-120kbps的总带宽，上传和下载都是如此。

最后，没有任何提供商支持透明传输IP流量。换句话说，如果你的调制解调器正在移动，调制解调器将切换到新的基站，但你将完全丢失PPP会话，并且必须重新启动它以及所有的TCP会话等。你通常不会获得相同的IP地址，因此你的TCP会话将无法优雅地恢复。

这种转换的“有趣”之处在于，即使您不移动，也可能发生这种情况。如果一个基站负载过重，如果您足够接近，您可能会被转移到另一个基站——还有其他一些因素可能会使您的调制解调器进行转移，即使您没有移动。因此，请确保考虑到这一点，因为您似乎很想保持全双工、对称的通道开放。编写能够恢复正常运行的内容已经很困难了，更别提预测并快速执行了。您最好与调制解调器制造商（例如Kyocera）密切合作，否则您将无法获得控制调制解调器芯片组所需的低级文档。

-Adam