从HTTP/1.1到HTTP/3，解决了一些旧的协议问题，引入了有用的新特性。HTTP/1.1HTTP/1.1通过在传输层和应用层之间加入SSL/TSL解决了数据不安全的问题，但是它也有一些其他的不足。同时一个连接只能对应一个请求。对于同一个域名，大多数浏览器最多同时允许6个并发请求，只允许客户端主动发起请求。一个请求只能对应同一个会话中多个请求的一个响应，头信息将被重复传输。针对以上情况，增加了一个新的协议SPDY。SPDYSPDY（speedy的缩写）是一种基于TCP的应用层协议。它强制使用SSL/TLS。SPDY不用于替代HTTP。它只是修改了HTTP请求和响应的传输方式。它只需要添加一个SPDY层。现在有些服务端应用不需要任何修改，SPDY就是HTTP/2的前身。HTTP/2HTTP/2（类似于HTTP+SPDY，SSL不是强制的，但大部分都会用到SSL）在底层传输上做了很多改进和优化，但是在语义上完全兼容HTTP/1.1，比如请求方法（如GET、POST）、StatusCode、各种Headers等都没有变。超快的加载速度在HTTP/2测速网站可以看到HTTP/2和HTTP/1.1对170张32*48像素的小图组成的大图的加载速度对比。那为什么会有这么大的差别呢，因为HTTP/2在很多方面都做了调整。二进制格式从HTTP/2开始以二进制格式传输数据，而不是HTTP/1.1的文本格式。多路复用新的二进制帧机制改变了客户端和服务器之间交换数据的方式。这里有几个新概念。?流：已建立连接上的双向字节流。?消息：对应于逻辑消息的完整数据帧序列。?帧：HTTP2.0通信的最小单位。每个帧都包含一个帧头，至少标识了当前帧所属的流。每个数据流以消息的形式发送，消息由一个或多个帧组成。这些帧可以乱序发送，然后根据每个帧头中的流标识符重新组合。该图包含在同一连接上传输的多个数据流：客户端正在向服务器传输数据帧（流5），同时，服务器正在向服务器发送一系列无序的流1和3客户端框架。此时，3个请求/响应在一个连接上并行交换。将HTTP消息分解成单独的帧，交错发送，然后在另一端重新组合它们是HTTP2.0的重要增强。事实上，这种机制会在整个Web技术栈中引发一系列连锁反应，从而带来巨大的性能提升。?并行发送请求，交错互不干扰?并行发送响应，交错互不干扰?仅使用一个连接并行发送多个请求和响应?消除不必要的延迟，从而减少页面加载时间?无需做了很多工作来绕过HTTP1.x的连接限制（例如图像精灵，合并CSS\JS，嵌入CSS\JS\Base64图片，域名分片）为每个HTTP通信进行头部压缩两者都携带一组头部来描述转移的资源及其属性。在HTTP1.x中，这些元数据以纯文本形式发送，通常会为每个请求增加500-800字节。当包含HTTPcookie时，添加的有效负载通常会达到千字节。为了减少这些开销并提高性能，HTTP2.0压缩了标头元数据。客户端和服务器缓存最后一次请求，只发送不同的请求头。静态表存储常见的请求头，动态表随新请求添加新的请求头。客户端和服务端同步保存两张表，一张表头信息对应一个索引。如果索引表中存在请求头，则只需要发送索引号。服务器推送HTTP1只允许客户端主动发起请求，一个请求只能对应一个响应。HTTP2.0添加的一个新特性是服务器可以对一个客户端请求发送多个响应。服务器除了响应初始请求外，还可以在客户端不明确请求的情况下额外向客户端推送资源。一个Web应用程序中可能有几十个资源。如果服务端能够主动将资源推送给服务端，客户端就不需要分析服务端提供的文档，一一查找，可以减少额外的时间延迟。服务器推送功能应用于网页中嵌入的CSS、JavaScript或其他资源。它也带来了这些好处。客户端可以缓存推送的资源。客户端可以拒绝推送的资源。推送的资源可以被不同的页面共享。服务器可以根据优先级推送资源。以上是HTTP/2提供的新特性。解决了HTTP1的缺点，但它也有自己的一些问题。如果在队头阻塞请求中丢失了一个数据包，则后续请求将被阻塞。这个时候会等待丢失的包被重发，这是由TCP底层决定的。握手延迟HTTP2的传输层协议仍然使用TCP，仍然存在握手链路。RTT（RoundTripTime）：往返时延，可以简单理解为往返通信时间。建立连接，一个100ms左右的RTT加上TLS握手需要300ms，还是需要不少时间。为了解决以上问题，HTTP/3有了HTTP/3。HTTP/3由谷歌开发。它摒弃了TCP协议，改用基于UDP协议的QUIC协议。解决队头阻塞QUIC协议使用的UDP协议，直接丢乱序数据即可，无需排队等待请求的响应，不存在队头阻塞问题.解决握手延迟，UDP连接不需要“握手”，所以不存在“握手延迟”问题。疑问1.UDP不需要建立连接。如何保证“可靠传输”？UDP接收数据包，如果丢失则不会重传。如果直接连接应用层HTTP协议，数据可能不完整。这里在应用层和传输层也加入了QUIC协议。如果丢包，会通知对方的QUIC层，重传丢包。也就是说，QUIC保证了“可靠传输”，相当于实现了TCP的功能。2.为什么谷歌不开发一个不同于TCP和UDP的新的传输层协议？目前世界上的网络设备基本上只识别TCP和UDP。如果要修改传输层，就意味着操作系统的内核也要修改。此外，许多新的TCP特性由于缺乏广泛的支持而没有得到广泛部署或使用。因此，开发和应用一种新的传输层协议是极其困难的。连接迁移TCP基于4个元素（源IP、源端口、目标IP、目标端口）。切换网络时，至少有一个元素会发生变化，从而导致连接发生变化。当连接发生变化时，如果仍然使用原来的TCP连接，会导致连接失败，必须等待原来的连接超时，然后重新建立连接。所以我们有时会发现，当切换到新网络时，即使新网络状况良好，内容加载仍然需要很长时间（可能存在网络异常）。QUIC的连接不受这4个元素的影响。当4个元素发生变化时，仍然保持原来的联系。QUIC连接不是通过4个元素来标识的，而是使用一组ConnectionID（连接ID）来标识一个连接，即使IP或者端口发生变化，只要ConnectionID不变，连接仍然可以得到维护。当设备连接到Wi-Fi时，将正在进行的下载从蜂窝网络连接转移到更快的Wi-Fi连接。当Wi-Fi连接不再可用时，将连接转移到蜂窝连接。总结HTTP/1存在请求数量受限、服务端无法主动推送消息、头部信息过多等问题。HTTP/2增加了二进制数据、多路复用、头部压缩和服务器推送功能，并且有队头阻塞和握手延迟。问题HTTP/3使用基于UDP的QUIC协议，解决了队头阻塞和握手延迟的问题，增加了连接迁移的特性。以上就是HTTP/2和HTTP/3的介绍。更多关于前端和网络协议的内容可以参考我的其他博文，持续更新中~参考：《Web性能权威指南》参考视频：《网络协议从入门到底层原理》
