31｜HTTP/3：甩掉TCP、TLS 的包袱，构建高效网络
HTTP2 核心特性使用了多路复用技术，通过一个TCP并行发送多个请求，使得带宽可以更好的利用，也避免了TCP冷启动的问题，同时实现了头部压缩和服务器推送等功能，只需要一个TCP连接就可以解决了HTTP1.1队头拥塞的问题
- HTTP2依然有缺陷，引出HTTP3的设计
- HTTP/2解决了应用层队头拥塞的问题，基于TCP协议的协议离不开TCP的影响，期初TCP是为了单连接设计的，TCP连接可以看做两台计算机之间的虚拟管道，，另一端将数据按顺序放入管道，最终数据以相同顺序出现在管道的另一头
- HTTP1.1传输数据时将一段的数据拆分为一个个按照顺序排列的数据包，通过网络层传输到接收端，接收端通过重新组合得到完整的原始数据
- 如果有一个数据丢包了，整个TCP连接就会处于暂停状态，通过重传机制重新传输，TCP连接可以看成一个按顺序传输的管道，管道任意一个数据丢失，都要等待其顺序重传之后然后在接着之后的数据执行，单个数据包造成丢失的阻塞称为TCP的对头阻塞
- HTTP2中，多个请求在一个TCP管道中，任意一路数据流出现丢包，则会阻塞该TCP连接中的所有请求，不同于HTTP1.1，HTTP1.1中同一域名下可以维持六个TCP连接，即使其中一个发生了阻塞也不会影响到其他五个的连接
- 丢包率增加后，HTTP2的传输效率会越来越差，超过2%的丢包率后HTTP1.1的传输效率会比HTTP2好
- TCP握手过程也是影响效率的一个重要因素
- 网络延迟(RTT: Round Trip Time)数据包从浏览器发送到服务器再从服务器返回到浏览器这个整个往返时间为RTT，也是反应网络性能的指标（发送端到接收端的往返时间）
- 使用了HTTPS的话还需要TLS协议安全传输，TLS也有握手过程，所以整个建立会有两次握手延迟
- TCP连接与服务器三次握手，需要在消耗完1.5个RTT才能完成数据传输
- TLS1.2/1.3大致需要1~2个RTT时间
- 所以在传输数据之前需要有3~4个RTT消耗，如果服务器较远的话，一个RTT消耗一百毫秒以上，那整体的速度就会明显的感觉到慢了
- 中间设备僵化(物理设备升级迭代少，有可能做不了向下兼容或者向上预备的功能)
- 操作系统(TCP协议通过操作系统内核实现，应用程序能够使用不能修改，操作系统更新通常滞后于软件更新，所以更新内核中的TCP协议很困难)
- HTTP/3选择一个折中的方法 - UDP协议，基于UDP实现类似TCP多路数据流和传输可靠性等功能，这一套功能称为QUIC协议
- 协议栈： (应用层)HTTP/3 --> QUIC --> 多路数据流 --> TLS、有序交付 --> 快速握手、可靠性 --> UDP(传输层)
- 集合功能:
- 实现了类似TCP流量控制，传输可靠性的功能: UDP虽然不可靠，但是QUIC在UDP基础上增加一层保证数据可靠性，提供数据包重传、拥塞控制和其他TCP存在的特性
- 继承TLS加密功能，QUIC使用TLS1.3，较早期版本TLS1.3有更多优点，其中一个减少了握手所花费的RTT个数
- 实现了HTTP/2的多路复用，一个物理连接上有多个独立逻辑数据流，能实现数据流的单独传输，解决TCP队头阻塞的问题
- 实现快速握手功能，实现0-RTT或者1-RTT建立连接，以最快的速度发送接收数据，提升首次打开页面速度
- 目前服务端和浏览器端没有对HTTP3提供较为完整的支持， 虽然Chrome在早年已经支持自己版本的QUIC，但是跟官方的QUIC差异很大
- 部署HTTP3存在非常大的问题，因为系统内核对UDP的优化远远没有达到TCP的优化程度
- 中间设备僵化，设备对UDP优化程度远远低于TCP，使用QUIC协议是丢包率达到3~7%
- 分析了HTTP2的一些问题，主要是TCP队头拥塞，建立TCP连接延时和TCP协议僵化的问题
- 对于TCP的内部问题，官方选择了基于UDP协议实现的QUIC协议
- QUIC可以看成集成了TCP+HTTP/2多路复用和TLS等的一些功能协议，从协议最底层对WEB文件传输做了彻底的优化，对于改动了的底层协议，推动起来阻力仍然不小
- 所以从标准到实践到协议优化还有很长的路，底层协议导致HTTP/3增长之路缓慢