字节一面：如何用 UDP 实现可靠传输？

我记得之前在群里看到，有位读者字节一面的时候被问到：「如何基于 UDP 协议实现可靠传输？」

很多同学第一反应就会说把 TCP 可靠传输的特性（序列号、确认应答、超时重传、流量控制、拥塞控制）在应用层实现一遍。

实现的思路确实这样没错，但是有没有想过，既然 TCP 天然支持可靠传输，为什么还需要基于 UDP 实现可靠传输呢？这不是重复造轮子吗？

所以，我们要先弄清楚 TCP 协议有哪些痛点？而这些痛点是否可以在基于 UDP 协议实现的可靠传输协议中得到改进？

在之前这篇文章：TCP 就没什么缺陷吗？，我已经说了 TCP 协议四个方面的缺陷：

• 升级 TCP 的工作很困难；
• TCP 建立连接的延迟；
• TCP 存在队头阻塞问题；
• 网络迁移需要重新建立 TCP 连接；

现在市面上已经有基于 UDP 协议实现的可靠传输协议的成熟方案了，那就是 QUIC 协议，已经应用在了 HTTP/3。

这次，聊聊 QUIC 是如何实现可靠传输的？又是如何解决上面 TCP 协议四个方面的缺陷？

QUIC 是如何实现可靠传输的？

要基于 UDP 实现的可靠传输协议，那么就要在应用层下功夫，也就是要设计好协议的头部字段。

拿 HTTP/3 举例子，在 UDP 报文头部与 HTTP 消息之间，共有 3 层头部：

整体看的视角是这样的：

接下来，分别对每一个 Header 做个介绍。

Packet Header

Packet Header 首次建立连接时和日常传输数据时使用的 Header 是不同的。如下图，注意我没有把 Header 所有字段都画出来，只是画出了重要的字段：

Packet Header

细分这两种：

• Long Packet Header 用于首次建立连接。
• Short Packet Header 用于日常传输数据。

QUIC 也是需要三次握手来建立连接的，主要目的是为了确定连接 ID。

建立连接时，连接 ID 是由服务器根据客户端的 Source Connection ID 字段生成的，这样后续传输时，双方只需要固定住 Destination Connection ID（连接 ID ），从而实现连接迁移功能。所以，你可以看到日常传输数据的 Short Packet Header 不需要在传输 Source Connection ID 字段了。

Short Packet Header 中的 Packet Number 是每个报文独一无二的编号，它是严格递增的，也就是说就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是 N，而是一个比 N 大的值。

为什么要这么设计呢？

我们先来看看 TCP 的问题，TCP 在重传报文时的序列号和原始报文的序列号是一样的，也正是由于这个特性，引入了 TCP 重传的歧义问题。

TCP 重传的歧义问题

比如上图，当 TCP 发生超时重传后，客户端发起重传，然后接收到了服务端确认 ACK 。由于客户端原始报文和重传报文序列号都是一样的，那么服务端针对这两个报文回复的都是相同的 ACK。

这样的话，客户端就无法判断出是原始报文的响应还是重传报文的响应，这样在计算 RTT（往返时间） 时应该选择从发送原始报文开始计算，还是重传原始报文开始计算呢？

• 如果算成原始报文的响应，但实际上是重传报文的响应（上图右）࿰