【Q651】简述 http3，http3 解决了什么问题

[mingshengxiao]

http3是基于UDP协议的。 它主要解决了http1.1和http2都存在的队头阻塞，TCP和TLS的握手时延问题。

[kurodasense]

参考文献：https://www.cnblogs.com/wiesslibrary/p/16446553.html

• stream offset

  • TCP 为了保证可靠性，重传包的包序号和原始的包序号是一致的，这就会导致Tcp 重传的歧义问题。当超时事件 RTO 发生后，客户端发起重传，然后接收到了 Ack 数据。由于序列号一样，这不好判断 Ack 数据到底是原始请求的响应还是重传请求的响应呢。
  • QUIC通过stream offset 来确定这个包在这个stream 中的绝对位置，保证了数据的可靠性。并且用一个packet number(保证严格递增)来代替tcp的sequence number。就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是 N，而是一个比 N 大的值。

• 队头阻塞

  • TCP协议在收到数据包之后，这部分数据可能是乱序到达的，但是TCP必须将所有数据收集排序整合后给上层使用，如果其中某个包丢失了，就必须等待重传，从而出现某个丢包数据阻塞整个连接的数据使用。
  • 如下图所示：Stream2 的第三个 tcp segment 丢失了，TCP 为了保证数据的可靠性，需要发送端重传第 3 个 segment 才能通知应用层读取接下去的数据，虽然这个时候 Stream3 和 Stream4 的全部数据已经到达了接收端，但都被阻塞住了。
  • 而在QUIC中 一个连接上的多个 stream 之间没有依赖。这样假如 stream2 丢了一个 udp packet，也只会影响 stream2 的处理。不会影响 stream2 之前及之后的 stream 的处理。

• 流量控制

  • TCP 为了保证可靠性，窗口左边向右滑动时的长度取决于已经确认的字节数。如果中间出现丢包，就算接收到了更大序号的 Segment，窗口也无法超过这个序列号。
  • 而QUIC通过 window_update 帧告诉对端自己可以接收的字节数，这样发送方就不会发送超过这个数量的数据，并且通过 BlockFrame 告诉对端由于流量控制被阻塞了，无法发送数据。因此就算此前有些 packet 没有接收到，它的滑动只取决于接收到的最大偏移字节数。