把今天所有下载场景简化到最底层，你会发现一个不太浪漫的事实：无论你用 Chrome、Edge 还是 Safari 去点一个下载链接，你和那个文件之间永远只有一条 TCP 连接。HTTP/1.1 时代是一条，HTTP/2 时代是多条复用，但它们最终都要汇到同一个源站 IP、同一个进程、同一条网卡上。这就是我们今天要讨论的“独木桥”。

1996 年问世的 HTTP/1.0，以及后来迅速接班的 HTTP/1.1，设计目标都极其朴素：让一台服务器把一个文件，可靠地，按顺序地发给一个客户端。整个互联网的头二十年，几乎所有下载工具——网际快车、FlashGet、迅雷的早期版本、Internet Download Manager——做的事情都是一件事：把这条独木桥跑满，跑得再快一点。

问题是，这条桥再怎么修宽，它还是一根。源站机柜里的硬盘 IO 是有限的，出口带宽是按月计费的，机房所在的地理位置决定了一大半的延迟。当一个热门资源同时被几十万人点下“下载”，最先撑不住的不是带宽数字，而是排队逻辑本身。

带宽够，可是抢不过

2010 年代前后，中国用户对“下载”这个动作最直观的体验，就是“种子下载速度可以飞起来，但同样的资源用浏览器下，慢得像蜗牛”。这两件事的根本差异不在带宽，在分发结构。HTTP 下载和 FTP 下载是典型的“客户端-服务器”模式，你和文件之间永远是 N 对 1 的关系；P2P 下载则是 N 对 N，每一台正在下载的电脑同时也是一台正在上传的电脑。

理解这件事，比理解任何具体技术细节都重要。当我们要下载一部 50GB 的 Windows 镜像，如果源站只卖得动 10Gbps 出口，而全国有 5 万人想下，平均到每人的速度就是 200KB/s。这不是协议慢，不是网线慢，是这条独木桥上排队的总人数超出了它的物理承载力。

TCP 的“安全网”也是拖累

HTTP/FTP 建立在 TCP 之上，TCP 的设计哲学是“宁可慢一点，也不能丢一个包”。这个哲学在 1980 年代局域网时代非常合理，但放到今天的高延迟、高丢包环境里，就成了一种拖累。TCP 一旦检测到丢包，会启动“拥塞控制”——主动降速、慢慢爬升、再降速、再爬升。一次跨太平洋的下载，可能在第一次丢包后就被砍掉一半速度，而这一刀下去，可能要花十几秒才能重新恢复。

更麻烦的是连接建立过程。TCP 三次握手至少需要 1 个 RTT(round-trip time)，TLS 1.3 再加 1 到 2 个 RTT 才能完成密钥协商。跨太平洋的 RTT 大约 150 毫秒，跨大西洋大约 80 毫秒。在 5G、卫星互联网这种 RTT 频繁波动到几百毫秒的网络里，光是“握手”这一步就吃掉用户好几秒钟的体感等待时间。

HTTP 下载的最大问题不是它太慢，而是它只有一个源。当源的带宽、地理、运维中任何一环出问题，所有客户端同时失去服务。

单点故障的影子

HTTP/FTP 模型还有一个隐含假设：服务器永远在线、文件永远不被删除。这个假设在真实世界里脆弱得可笑。一个网盘关闭、一个网站备案失效、一次机房断电，就能让成千上万个曾经可以下载的链接，在几秒钟之内集体“404”。这就是 HTTP 下载的“软删除”问题——它没有任何机制告诉你，这个文件今天还能不能下到。

当你点开一个 2015 年的老资源，得到的大概率是一个“该资源已被删除”的提示。可笑的是，文件可能还完整地躺在某个硬盘上，只是发布者换了一个 IP、关了一个站点，或者就是忘了续费云盘。

成本问题：中心化分发是一场军备竞赛

从服务器运营者的视角看，HTTP/FTP 下载是一个完全没有规模效应的成本模型。一个 100MB 的小文件被下载 10 万次和被下载 100 万次，后者的带宽成本是前者的整整 10 倍。运营方只能靠两种方式扛住：要么提前把带宽买得足够大，祈祷峰值能用满；要么限制单用户下载速度，把高峰烫平。无论哪种，本质都是“中心化分发”这个模型自带的天花板。

今天很多大型下载站的做法，听起来已经很现代——他们买 CDN 加速、买对象存储、买 BGP Anycast，但骨子里还是一根独木桥：文件从源站推到 CDN 边缘节点那一刻起，分发效率就被 CDN 节点的数量和位置锁死了。CDN 能让独木桥变宽，但没法让它变成一座桥。

这不是历史的终结，是结构的局限

HTTP 和 FTP 当然不会消失。普通网页浏览、API 请求、小文件分发，它们仍然是最合适的工具。我们不是在宣告它们的死亡，而是在指出它们的适用边界：当用户量级上升到数万、十万，文件体积上升到 GB 级别，分发地理跨度上升到跨大洲，HTTP/FTP 这根独木桥就会开始显露出它的物理极限。

下一篇我们会看到一个 2003 年的中国工程师如何绕过这根独木桥——他既不等待更好的协议，也不等待更大的带宽，而是把独木桥的逻辑整个改掉，让下载这件事开始“同时从很多地方”取数据。这就是 P2SP，以及它背后的迅雷。

参考资料