为什么你的上传速度总是比下载慢很多？答案不在你的套餐里，而是刻在有线、DSL 和无线这些接入技术本身之中——这里讲清背后原因及代价。
运行一次测速，上传数字几乎总是两者中较小的那个——往往相差十倍甚至更多。这不是故障，也不是你的套餐被限速了：大多数接入网络在设计之初就是为了把数据送给你，而不是从你这里送出去，这种不对称是刻在物理层里的，而不是藏在合同细则中的猫腻。下面讲清楚上传为什么总是分到更小的那一份，以及这个数字为什么比它的大小看起来更重要。
核心要点
- 这种不对称是物理层面的，不是合同条款。 有线宽带、DSL，以及多数固定无线和卫星连接，在设计上就把容量在两个方向上分配得不均衡——这不是换个更贵的套餐就能升级掉的限速。
- 光纤是例外。 光纤到户（FTTH）连接通常是上下行对称的，这也是为什么一旦换用光纤，这个问题大多就不再出现了。
- 上传一旦跑满，代价比数字本身显示的更大。 视频通话、云备份和屏幕共享都直接依赖上传，而一条被占满的上行队列还会拖慢下载所依赖的确认包——于是上传拖累的不只是它自己，还有整条连接。
- 跑满的上行队列是缓冲区膨胀的经典诱因——参见缓冲区膨胀详解了解其原理和修复方法。
- 解读自己的上传数字时，要考虑测试所用的方法——单连接还是并行连接、测试时长，都会左右一次短测所报告的结果。
为什么上传更慢：这是接入技术本身决定的
每一种家庭上网技术，都要把有限的容量分配给你用得最多的方向（下载）和用得最少的方向（上传），而几乎没有一种技术会平均分配。
- 有线宽带（DOCSIS）。 有线网络让整个社区共享一根同轴电缆，按频段划分。历史上，只有很小一部分频谱被分配给上行方向，因为流量模型假设人们主要是在接收数据——网页、视频、下载。较新的 DOCSIS 标准扩大了上行频段，但有线套餐宣传的下载数字通常仍然是上传数字的许多倍，而且那部分上行频段还要和同一节点上的所有其他用户共享。
- DSL。 这种不对称直接写在了名字里：ADSL 就是非对称数字用户线路（Asymmetric Digital Subscriber Line）。这项技术从一开始设计时，就假设一条家用线路主要是在拉取数据而非推送数据，因此在同一对铜线上让下载优先于上传。
- 固定无线和卫星。 这类连接受限于较弱的上行发射功率，而在共享基站或卫星上，还要和同时使用同一份上行容量的其他所有用户竞争。手机或屋顶天线的发射功率，根本无法和基站或卫星地面站相比，所以几乎每种无线接入技术里，上行都是更受限的方向。
- 光纤（FTTH）。 光纤通常是例外：许多光纤到户部署提供的是对称服务，下载和上传共用同一份充裕的容量。这也是为什么"为什么我的上传这么慢"这个问题，一旦有人换用光纤后大多就不再出现——因为在有线和 DSL 上造成这个问题的物理层不对称，在光纤上根本不存在。
这和选哪家运营商无关——关键在于你的线路底层用的是哪种技术。同一套有线电缆基础设施上的两家运营商，会表现出同样失衡的比例；而在同一栋楼里用光纤的两家运营商，通常就不会。
为什么这个小数字的代价比看上去更大
很容易觉得上传数字低无所谓，因为你平时做的大多数事情——浏览网页、看视频、下载文件——几乎用不到它。但有一些常见活动会直接依赖上传，而一条被占满的上传通道，会在不知不觉中损害那些看起来毫不相关的事情：
- 视频通话和屏幕共享会把你自己的音视频持续不断地向上发送。如果你的上传带宽不足或被占满，对方会看到你卡住或掉线，即便你的下载——负责把对方画面传给你的那一部分——看起来完全正常。
- 云备份与同步（照片、文档、视频素材）几乎全是上传流量，一次在后台运行的大型备份可能会悄悄占用你整条上行通道达数小时之久。
- 确认包同样走的是上行。 每一次下载——哪怕是像游戏更新或电影这样的大文件——都依赖你的设备持续向发送方回传一连串小小的确认（ACK）数据包，告诉对方哪些数据已经收到，这样发送方才知道可以继续放心发送。这些 ACK 包走的正是你连接的上传一侧。如果别的什么东西已经占满了上行队列，这些小小的确认包就会被堵在后面，发送方会误以为网络拥塞而放慢速度，于是一次原本和你的上传流量毫无关系的下载，也会慢得像蜗牛。这也是为什么 RFC 6349 定义的 TCP 吞吐量测试框架，要求在测传输速率的同时测量往返时延和缓冲延迟：TCP 的吞吐量取决于数据多快得到确认、下一个窗口多快被放行，所以即便是单向传输，回程路径同样重要。
简而言之：上传不只是"那个更小的数字"。一条被占满的上传通道，甚至能让一次和它毫无关系的下载看起来也像是坏了。
上行队列往往是缓冲区膨胀的起点
刚才那一点——被占满的上传会拖慢共享这条连接的所有其他流量——也正是缓冲区膨胀的经典诱因：你的路由器或调制解调器在链路繁忙时选择把数据排队，而不是丢弃，这只会增加延迟，完全不会体现在带宽数字上。一次大的上传（备份、云同步、视频通话）常常正是那个把上行缓冲区填满的触发点，让一条空闲时测起来毫无问题的连接，在通话或游戏中出现卡顿。如果你的 Ping 在空闲时表现很好，却在你开始上传什么东西的瞬间飙升，这就是该排查的模式——参见缓冲区膨胀详解，了解如何测试空闲与负载下的延迟，以及修复方法（主动队列管理，特别是 FQ-CoDel）。
如何客观看待自己的上传数字
既然已经知道上传本来就该比下载小，下一个问题是：测速刚给你的那个数字，是否真实反映了你的连接。测试本身有两件事会左右结果：
- 单连接还是并行连接。 在完全相同的线路上，只开一条连接的测试和同时开多条并行连接的测试，可能报告出不同的峰值数字，因为单条 TCP 连接远在跑满链路之前，就可能先被往返时间和窗口大小限制住，而多条并行连接能更快地把管道填满。M-Lab 的 NDT（Google 搜索内置测速背后的开源测试）就刻意只用一条 TCP 连接，并在结果旁附上 TCP 层面的细节，因此它在同一条线路上测出的数字可能低于多连接工具，而两者都没有错。不同工具的数字不能直接横向比较，要比就用同一种方法比。
- 测试时长。 一次短测试可能会高估你真实的持续上传能力，因为许多连接在稳定到实际速率之前，会允许一段高于稳态速率的初始突发——一次很短的测试可能在这段突发结束、速率真正稳定下来之前就已经结束，报告的是突发时的数字，而不是你实际上传几分钟后会得到的数字。如果你实测的上传在长时间的真实上传中，表现总是不如快速测试给出的数字，那时长通常就是原因；关于一次次测试结果不一致背后更完整的原因列表，可参见为什么你的网速测试结果总在变。
实用的结论是：不要拿自己的上传数字和下载数字比较，然后断定哪里坏了。应该拿它和你的套餐、接入技术实际承诺的上传能力去比较，并且用一次时长足够、并行连接数足够的测试，来代表真实的持续使用情况。
亲自测一测
BrowserInsight 的网络测速会把上传和下载、延迟、抖动放在一起报告，这样你就能看到自己真实的上下行不对称程度，而不是靠一个孤零零的头条数字去猜。分别在空闲时测一次，再在上传密集的任务（比如备份、视频通话）进行时测一次，你就能同时看到自己的基线上传速度，以及在真实条件下它被吃掉了多少。
常见问题
我的运营商是不是在限制我的上传速度？
通常不是故意的——这个差距几乎总是来自接入技术本身，而不是人为设的上限。有线和 DSL 在设计上就把容量在两个方向上分配得不均衡，所以下载与上传相差 10 倍甚至更多在这些技术上很常见，并不能证明存在限速。如果你用的是光纤，却依然看到很大的差距，那就更值得找运营商核实一下了。
升级套餐能解决上传慢的问题吗？
有时候可以，但不总是。在同一种接入技术（有线、DSL）上升级到更快的套餐，通常会让上传和下载的数字一起提高，但两者之间的比例往往不会改变，因为方向之间的分配是由技术本身决定的，而不是套餐档位。真正能改变这个比例的，是那些提供对称服务的技术，最常见的就是光纤。
为什么我一开始大量上传，下载就会卡住？
因为你下载所需的确认数据包，走的也是连接的上传一侧。如果一次上传占满了上行队列，这些确认包就会被延迟，下载一侧的发送方会误以为网络拥塞而主动放慢速度，于是你的下载变慢了，尽管它自身的带宽根本没有变化。这也是缓冲区膨胀的典型症状——参见缓冲区膨胀详解。
上传速度对游戏重要吗？
没有延迟那么重要，但在一定程度上确实有影响。游戏本身的流量很轻，但如果有别的东西占满了上传（云备份、屏幕共享、家人的视频通话），游戏的小数据包就得在同一条上行队列里排在它们后面，拉高游戏实际感受到的延迟——即便游戏自身对上传的需求微乎其微。
结语
下载数字很大、上传数字很小，这不是 Bug——这正是有线、DSL 以及多数固定无线和卫星连接的设计方式：把共享容量向大多数人用得最多的那个方向倾斜。真正能改变局面的是光纤，在那里这种分配上的差异消失了；此外还要认清一条被占满的上传实际会带来什么代价：不只是上传本身变慢，还会拖慢下载依赖的确认包，并且是缓冲区膨胀的经典成因。把上传和下载放在一起测，用你的接入技术、而不是下载数字来衡量这个结果；如果通话或游戏恰好在有东西在上传时才卡顿，那条上行队列就是该首先排查的地方。
推荐阅读：
