TCP vs UDP：同一文件下载速度实测对比

TCP 与 UDP 下载速度对比？

一个实时的 TCP vs UDP 速度测试，并解释你刚才看到的现象。 可靠、有序、会重传丢失的数据。 快速、无序、不重传任何东西。 点击按钮。两者从同一台服务器获取完全相同的文件—— ……随机数据。一个通过普通 TCP 连接传输。 另一个通过 WebTransport 传输，这是一种基于 QUIC/UDP 的传输方式，其行为就像真实的 UDP：数据包可能乱序到达，任何丢失的数据包就 永远丢失了——这里没有任何东西会替你重试或重发。这就是最原始形态的 UDP 丢包， 这里没有任何人为减速或为了效果而丢弃数据包。 在缓慢或不稳定的连接上，先试试较小的文件——飞行中的数据包更少，UDP 传输完全有可能 一个包都不丢就完成。更大的文件则给丢包更多出现的机会。 在短距离、干净的连接上——比如你的浏览器和这个演示服务器之间的连接—— 你应该预期两种传输都会快速且完整地完成，通常 UDP 传输会明显更快完成。 这不是巧合，但也不是全部真相。继续往下读，了解你刚才看到的现象。 摘要。上面的第 1 节对同一个文件执行了两次下载——一次 通过 TCP，一次通过 UDP——针对真实服务器、通过你真实的网络连接， 没有模拟减速，也没有模拟丢包。下面的第 2 到第 10 节 解释为什么两个结果会是那样：每种协议实际上对你的数据做了什么， 为什么一个可靠而另一个不可靠，以及为什么两者在今天仍然重要。 TCP——传输控制协议，定义于 RFC 9293——是 面向连接的。在你的数据哪怕一个字节开始移动之前，双方 会执行三步握手，以确认连接存在： 客户端 服务器 | ------------------- SYN -------------------> | | <----------------- SYN-ACK ------------------ | | -------------------- ACK -------------------> | | | | 连接已建立 | 图：客户端向服务器发送 SYN 包；服务器回复 SYN-ACK； 客户端发送 ACK；连接现已建立。 这次握手在你任何数据开始移动之前就要花费一个完整的往返时间—— 客户端的第一个数据包必须到达服务器，服务器的回复必须回来， 然后客户端才能发送其他任何东西。在延迟为 50 毫秒的连接上， 下载甚至还没开始就已经花掉了 50 毫秒。 一旦连接打开，TCP 保证三件你的应用永远不必操心的事： 所有这些记录工作都必须传到某个地方，而它们通过附加在 每一个 TCP 段上的头部来传输——在你数据开始之前，最少就有 20 字节： 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 源端口 | 目的端口 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 序列号 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 确认号 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 偏移|保留 |U|A|P|R|S|F| | | | |R|C|P|S|Y|I| 窗口 | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 校验和 | 紧急指针 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 字段依次为：源端口、目的端口、序列号、确认号、 数据偏移、保留位、控制标志（URG、ACK、PSH、RST、SYN、FIN）、窗口、 校验和以及紧急指针。 图 2. TCP 头部——每个段 20 字节的记录开销。 UDP——用户数据报协议，定义在一份只有三页的文档中， RFC 768——是无连接的。没有握手。发送方将一个数据包 （称为数据报）寻址到目的地并放到网络上。这就是整个 协议。 作为交换，头部缩小到几乎不存在——8 字节，是 TCP 最小头部的四分之一： 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 源端口 | 目的端口 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 长度 | 校验和 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 字段依次为：源端口、目的端口、长度和校验和。 图 3. 完整的 UDP 头部——8 字节，仅此而已。 注意那个头部里没有什么：没有序列号，没有确认号， 没有窗口大小。UDP 的校验和可以告诉接收方一个数据报到达时已损坏—— 但没有任何机制要求重发。它只会被直接丢弃。 三项独立的成本叠加起来，全都是为了可靠性： 这些都不是缺陷——这正是该协议的全部意义所在。一个网页、一封邮件， 或者一个下载的文件中间缺了一块，并不是那个页面、邮件或文件更快的版本。 而是一个损坏的版本。TCP 用速度换取一项保证：到达的内容 正是发送的内容。 UDP 更快的原因正好相反：它跳过了所有这三项成本。没有 握手，没有确认记录，没有刻意的逐步加速。发送的第一个数据包 就已经携带数据，之后每个数据包都与之前的数据包无关。 你放弃的是 TCP 一直在提供的一切。如果一个 UDP 数据包丢失了，在协议层面 没有任何东西会注意到——不会报错，不会重传。应用 要么不需要那个数据（每秒六十帧视频中的一帧过时画面）， 要么必须在上面自行构建恢复机制，这正是 QUIC （第 8 节）这类协议所做的。 浏览器无法打开原始 UDP socket——这是刻意的沙箱限制， 而不是缺失的功能，而且无论发起请求的代码是 JavaScript 还是 WebAssembly，这一限制都同样适用。浏览器标签页中能用的最接近的东西，也是驱动 UDP 的

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）