为什么迅雷X限制不住上传速度？解答TCPIP网络底层协议开销那点事
自从伊文转行去做产品策划之后，好久没在阳台上写点什么了。恰逢临近年关手上的事情少了许多，就寻思着回到阳台再给大家写点有价值的东西。就在刚才，伊文在微博上看到这么一条吐槽。
这位雷友将迅雷的上传速度限制为 33KB/s，但是左侧显示的“当前上传速度”为 213.44KB/s，于是他吐槽说“迅雷太坑人”。
其实不少雷友，也对迅雷有着“限制不住上传”的传统印象，但实际上这是产品交互设计上的不足导致的误解。
为什么说是误解？
首先我们得从基础的下载原理说起。
我们都知道，下载是个接收信息的过程，而上传是个发送信息的过程。
如果做个拟人化的比喻，下载就是用耳朵听，上传则是用嘴巴说。
现在，假设A要给B念一句诗“苟利国家生死以”。
我们把A给B念这句诗的过程，想象成下载一个文件，这个过程是这样的。。。
A：“我要念诗了，你听到了吗？”
B：“我听到了，这句诗有几个字？”
A：“有7个字，你听到了吗？”
B：“我听到了，你念吧”
A：“第1个字 苟 你听到了吗？”
B：“我听到第1个字了”
A：“第2个字 利 你听到了吗？”
B：“我听到第2个字了”
A：“第3个字 国 你听到了吗？”
B：“我听到第3个字了”
A：“第4个字 家 你听到了吗？”
B：“我听到第4个字了”
A：“第5个字 生 你听到了吗？”
B：“我听到第5个字了”
A：“第6个字 死 你听到了吗？”
B：“我听到第6个字了”
A：“第7个字 以 你听到了吗？”
（A等了5秒还没收到B的回应，于是重复了一遍）
A：“第7个字 以 你听到了吗？”
B：“我听到第7个字了”
（你一定在想，为什么要这么麻烦呢？这是因为网络的可靠性并不总是很好，偶尔会发生A说了某句话，B没有听到的情况。这样虽然麻烦，却能避免信息在传输过程中丢失。）
由此可见，下载一个文件的过程，实际上是个对话过程。B在听到一个字之后，必须要说“我听到了”，A才会说出下一个字，并非简单的A说B听。
在这个对话过程中，“苟利国家生死以”这7个字是要传输的“文件数据”，除此以外的对话内容，我们可以称为“协议通讯”。
当你了解基本原理之后，你应该能够理解。下载文件数据的过程，必然会产生用于“协议通讯”的上传流量。下载速度越快，协议通讯产生的上传速度也越快。
这一原理，对于所有下载行为都是适用的。包括我们通过局域网复制文件时，也会观察到大量的上传。
现在我们回头来看看吐槽的这位雷友，他虽然限制上传速度为 33KB/s，但是他同时在以5.55MB/s的高速进行下载，协议通讯肯定会产生不小的上传速度。
还记得我前面说过“这是产品交互设计上的不足导致的误解”吗？
这个不足就在于迅雷显示的“当前上传速度”是包含了“协议通讯”产生的上传速度的。
而限制上传速度的选项，只限制了上传“文件数据”的速度，不限制“协议通讯”的上传速度。
因为限制了“协议通讯”的上传速度，就会严重拖慢下载速度。
这才造成了“迅雷限制不住上传速度”的问题。
所以，在未来的迅雷版本中，我们会将协议通讯产生的上传速度单独展示并加以说明。
希望各位雷友能够理解，迅雷真的不是要坑你。。。
转：http://yangtai.xunlei.com/?p=10922
{:3045:} 本帖最后由 ntgeralt 于 2019/10/18 02:38 编辑
我试过迅雷10.1.9.326 ，三个BT任务全部暂停。迅雷提示0K/S上传，但360小窗口检测到迅雷还是700K/S+上传……
另外楼主，你的服务器是不是在埃塞俄比亚啊，广东移动连这个网站超慢啊…… ntgeralt 发表于 2019/10/18 02:37
我试过迅雷10.1.9.326 ，三个BT任务全部暂停。迅雷提示0K/S上传，但360小窗口检测到迅雷还是700K/S+上传… ...
在美国，超卡的 学习了
很多时候 迅雷依然比较快无法放弃
页:
[1]