为什么我无法在对称通道上获得相同的上传和下载速度？

我被分配到一个项目,我的代码应该同时在同一个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会话将无法正常恢复.

这种扭曲的"有趣"方面是即使你不动也会发生这种情况.如果一个基站被加载,如果你足够接近,你可能会转移到另一个基站 - 即使没有你移动,还有其他东西可能使你的调制解调器转移.因此,请务必考虑到这一点,因为您似乎热衷于保持全双工,对称通道打开.编写能够优雅地恢复的东西是很难的,没关系预测它并快速完成.您最好与调制解调器制造商(例如Kyocera)密切合作 - 否则您将无法获得有关如何在您需要的低级别控制调制解调器芯片组的文档.

-亚当