我被分配到一个项目，我的代码应该在同一 FTP 或 HTTP 服务器上同时执行一些文件的上传和下载。对速度进行了测量，并由此得出了一些结论。
现在，问题在于，在高速连接上，我们在吞吐量方面获得了几乎预期的结果，但在慢速连接（想想理想的 CDMA 1xRTT 链接）上，无论下载还是上传都会以相反的方向为代价获胜。我有一个“更高的身体”，他确信 CDMA 1xRTT 连接是对称的，因此我们应该能够在此链路上以相同的速度（每个方向约 100 kbps）执行数据传输。
我的测量结果表明，如果不对缓冲区大小和数据链路节流方面的代码进行大量调整，就不可能在上述条件下具有相同的速度。我尝试了我的多线程代码，还创建了一个简单的批处理文件，它可以自动执行 Windows 的 ftp.exe 以执行数据传输——结果相同。
所以，问题是：真的有可能在一条慢速对称链路上以同等速度执行数据传输吗？“更高的身体”是否符合他们的期望？如果是，您对我应该如何处理我的代码以实现这样的吞吐量有什么建议吗？
PS。我完全重写了这个问题，所以很明显它属于这个网站。
CDMA 1x 包含多达 15 个 9.6kbps 流量的信道。这导致总吞吐量为 144kbps。
两个通道用于命令和控制信号（与基站通话、关联/解除关联、SMS 流量、振铃信号等）。
这样一来，您就可以获得高达 124.8kbps 的速度。
--> 每个通道都是一种方式。<--
它们根据需要动态切换和分配。
通常，您将获得比上传更多的下载，因为这是典型的手机调制解调器使用。但是你永远不会得到超过 120kbps 的总总带宽。
在实践中，由于 1xRTT 编码、纠错、重新发送等开销，即使您拥有所有可能的通道，您通常也会体验到 60kbps 到 90kbps 之间的速度。
这意味着您可能只能同时获得 30kbps-60kbps 的上传和下载。
此外，由于动态切换频道（以及基站比调制解调器控制更多这一事实 - 他们需要仔细管理基站频道以保持频道免费进行语音通话），您在切换频道时会浪费时间 - 这是不是一个瞬间的过程。
所以 - 理论上，1xRTT 可以为您提供 124kbps 的一种方式，但由于开销、切换时间、基站容量或电话公司出于其他原因简单地限制此类连接，您不能依赖对称链路。
笔记：
这将在一定程度上根据提供商和调制解调器而有所不同。例如，有些调制解调器有 16 个通道，有些供应商支持 16 个通道。在某些情况下，这些调制解调器和提供商可以很好地协同工作，可以为应用程序提供完整的 144kbps 聚合原始带宽，只有一个专用通道（必须非常努力地工作）来处理控制、切换和其他问题。尽管如此，尽管如此，随着调制解调器通信的开销，然后是 PPP 的开销，然后是 IP 的开销，然后是 TCP 的开销，你仍然看到可能 100-120kbps 的总带宽，无论是上行还是下行。
最后，还没有提供商支持 IP 流量的透明传输。换句话说，如果您的调制解调器正在移动，调制解调器将切换到一个新的基站，但您将完全放弃 PPP 会话并必须重新启动它，以及所有 TCP 会话等。您通常不会获得相同的 IP 地址，因此您的 TCP 会话将无法正常恢复。
这种转折的“有趣”方面是即使你不移动也可能发生这种情况。如果一个基站负载下降，如果您离得足够近，您可能会被转移到另一个基站 - 即使您不移动，还有其他一些事情可能会使您的调制解调器转移。因此，请务必考虑到这一点，因为您似乎热衷于保持全双工、对称通道的开放。很难写出能够优雅地恢复的东西，没关系预测它并快速完成。您最好与调制解调器制造商（如京瓷）密切合作，否则您将无法获得有关如何在所需的低级别控制调制解调器芯片组的文档。
-亚当
我认为在两个方向上都具有高速等速的整个戏剧是因为我的较高的身体认为他们在上行链路上有 144 kbps 并且在下行链路上有 144 kbps（== 两个管道）。而实际上我们有 144 kbps 的 ONE 管道，当我传输文件时它正在切换方向。
如果我对或错，请评论我。