2022年6月6日，IETF QUIC 和 HTTP 工作组成员 Robin Marx 宣布，经过 5 年的努力，HTTP/3 被标准化为 RFC 9114，这是 HTTP 超文本传输协议的第三个主要版本。同时，HTTP/2 也更新为 RFC 9113标准，HTTP/1.1 和通用 HTTP 语义和缓存概念在 RFC 9110-9112 中也得到了加强。

http协议的终极问题

我们知道http协议的2个特性，就是导致后续我们各种优化和改动的主要原因

• 无连接(每进行一次HTTP通信，都要断开一次TCP连接)
• 无状态

为了解决TCP的多次连接问题，HTTP/1.1提出了持久连接的方法 为了解决无状态导致的冗余重复内容传输，提出的强/协商缓存策略、cookie

可以看出http协议作为网络传输的通道，终极问题都是更快的请求和响应

👆 http协议的分层，分层的概念会另外讲解TODO: 基础分层为

• 物理层
• IP层
• TCP层
• HTTP层

概述HTTP/2

在开始HTTP/3之前，我们先简单总结一下HTTP/2带来的提升和没能解决的问题

从👆【http协议的终极问题】的分层图，可以看出HTTP/2 在HTTP/1.1 的基础上，只是多了一层 Stream 和 HPack 层，用于实现数据用流的形式传输而不是HTTP/1.1的字符数据传输

• 多路复用
  • 基于stream流分帧，实现只建立一个TCP连接，并且并发请求传输不用排队按顺序返回
• 头部压缩
  • 基于Hpack算法，类似字典短字符实现头部字段压缩

HTTP/2还是沿用HTTP/1.1的基座，属于拓展式的优化

所以优化未能解决的问题，也正是整个HTTP的基座的问题— —TCP协议

• 丢包(弱网)场景，单个TCP连接会怎样？
• 即使只有单个TCP连接，一次连接消耗的请求响应来回有4次(慢启动)

不使用TCP协议？

在我们以往的学习知识里，因为IP层不可靠而需要可靠的TCP层，那我们其实可以不使用TCP层做网络传输吗？

TCP层的作用

TCP 协议1.为了更容易传送大数据会数据分割；2.三次握手（three-way handshaking）策略能够确认数据最终是否送达到对方。

替代TCP层的QUIC协议

新的UDP？

和原TCP层一样处于传输层

udp 怎么保证 TCP 的安全性 udp不是面向链接的，而且udp传输的时候，不携带源端IP和源端口号，无法重试 需要添加源IP和端口号，并且增加序列，保证内容完整性。

UDP 与 TCP 的区别

• UDP 协议是面向无连接的，不需要在正式传递数据之前先连接起双方
  • TCP 在发送数据前要进行三次握手建立连接
  • 不可靠: 通信都不需要建立连接，想发就发
• UDP 协议不会对数据报文进行任何拆分和拼接操作，不保证有序且不丢失的传递到对端
  • 在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层
  • 在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作
  • 不可靠: 收到什么数据就传递什么数据,不关心对方是否已经正确接收到数据
• UDP 协议也没有任何控制流量的算法
• TCP 保证数据不丢失且有序到达，有一系列逻辑负担
• UDP 的头部开销小，只有八字节，相比 TCP 的至少二十字节要少得多，在传输数据报文时是很高效的。
  • 两个十六位的端口号，分别为源端口（可选字段）和目标端口
  • 整个数据报文的长度
  • 整个数据报文的检验和（IPv4 可选 字段），该字段用于发现头部信息和数据中的错误
• UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能
• 总的来说 UDP 相较于 TCP 更加的轻便

👆 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。

直播、游戏：TCP 会严格控制传输的正确性，一旦有某一个数据对端没有收到，就会停止下来直到对端收到这个数据。这种问题在网络条件不错的情况下可能并不会发生什么事情，但是在网络情况差的时候就会变成画面卡住，然后再继续播放下一帧的情况

UDP 相比 TCP 简单的多，不需要建立连接，不需要验证数据报文，不需要流量控制，只会把想发的数据报文一股脑的丢给对端 虽然 UDP 并没有 TCP 传输来的准确，但是也能在很多实时性要求高的地方有所作为