罗剑锋透视HTTP协议学习笔记---32 | 未来之路：HTTP/3展望

32 | 未来之路：HTTP/3展望

HTTP/2 的“队头阻塞”
HTTP/2部分解决了HTTP的队头阻塞问题，但由TCP带来的队头阻塞问题，不从协议底层改造是无法解决的。TCP有丢包重传机制，所有数据对TCP而言就是有序的字节流，所以虽然在HTTP层面流是乱序的，收发次序互不影响，但在TCP层面TCP分组仍然是有序的，在弱网场景下，如果队头发生丢包重传，就会有队头阻塞问题。
HTTP/3从协议底层进行改造，底层协议替换为UDP,并实现了QUIC协议，QUIC协议集成了TLS，并实现了类似HTTP/2的多路复用，流管理，彻底解决了HTTP的队头拥塞问题。

QUIC 协议及特点
quic的一个重要改变是底层支持协议用UDP替换了TCP，并整合了TLS1.3,TCP连接管理，拥塞控制。
gQUIC -iQUIC[QUIC-Transport]

QUIC 内部细节
支持连接迁移
引入了Packet面向连接，Packet包括若干的Frame,

QUIC整合了TLS1.3而不是建立在TLS连接上，节省了一次连接。
QUIC的层次结构：
QUIC包，对应连接，实现了连接迁移，即切换不同网络时，底层IP发生变化，但逻辑上还是同一个连接，连接没有断，不需要重连。
QUIC包里封装了QUIC frame实现了流和流的管理。和HTTP/2中流的区别，QUIC的流分为双向和单向，双向流等同于HTTP/2中的流，单向流约等于HTTP/2的0号流。流编号扩大到62位，最低2位是标记位。
xxxx00 双向流客户端发起
xxxx01 双向流服务端发起
xxxx10 单向流客户端发起
xxxx11 单向流服务端发起
所以和HTTP/2相反，偶数流都是客户端发起，奇数流是服务端发起
QUIC frame里封装HTTP/3 frame
HTTP/3报头压缩使用QPACK

HTTP/3 服务发现
HTTP/3未静态定义host:port参数，使用是需要先建立HTTP/2连接，由服务端通过alt-svc帧，携带h3=host:port通知浏览器切换到HTTP/3,客户端异步连接到指定主机端口，并断开HTTP/2连接。

课后作业：

IP 协议要比 UDP 协议省去 8 个字节的成本，也更通用，QUIC 为什么不构建在 IP 协议之上呢？
QUIC是个专用协议，只针对HTTP服务，其它应用用不了，感觉还是建立在UDP上比较好，QUIC应该可以建立在IP协议上，不知道协议设计者是怎么考虑的。

说一说你理解的 QUIC、HTTP/3 的好处。
使用TLS1.3+，彻底解决了HTTP队头阻塞问题，支持连接迁移，QPACK解决HPACK队头阻塞问题。

对比一下 HTTP/3 和 HTTP/2 各自的流、帧，有什么相同点和不同点。
相同：都用流+frame+多路复用的方式，解决了HTTP层面的队头阻塞
不同：HTTP/3基于QUIC，还解决了TCP导致的队头阻塞。