初识——HTTP3 初识——HTTP3

初识——HTTP3
- HTTP
- HTTP1.0和HTTP1.1的主要区别
- HTTP2
- HTTP3
- 相关链接

初识——HTTP3 想了解HTTP3？？那我们就得先知道为啥会出现HTTP3，因此我们需要知道HTTP1.0，HTTP1.1，HTTP2及HTTP3的演变过程。
HTTP HTTP 是超?本传输协议，也就是HyperText Transfer Protocol。
HTTP 端?号：80
HTTP 由于是明?传输，所以安全上存在以下三个?险：窃听?险，篡改?险，冒充?险。
HTTP1.0和HTTP1.1的主要区别长连接
HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接，而HTTP1.1默认支持长连接。
节约带宽
HTTP 1.1支持只发送header信息(不带任何body信息)，如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器。
这样当服务器返回401的时候，客户端就可以不用发送请求body了，节约了带宽。
另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。
HOST域
现在可以web server例如tomat，设置虚拟站点是非常常见的，也即是说，web server上的多个虚拟站点可以共享同一个ip和端口。
HTTP1.0是没有host域的，HTTP1.1才支持这个参数
HTTP1.1 相比 HTTP1.0 性能上的改进：
使? TCP ?连接的?式改善了 HTTP1.0 短连接造成的性能开销。
?持管道（pipeline）?络传输，只要第?个请求发出去了，不必等其回来，就可以发第?个请求出去，可以减少整体的响应时间。
但 HTTP1.1 还是有性能瓶颈：

请求响应头部（Header）未经压缩就发送，?部信息越多延迟越?。只能压缩 Body 的部分；
发送冗?的?部。每次互相发送相同的?部造成的浪费较多；
服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端?直请求不到数据，也就是队头阻塞；

管道（ pipeline）传输中如果有?个请求阻塞了，那么队列后请求也统统被阻塞住了
没有请求优先级控制；
请求只能从客户端开始，服务器只能被动响应。

根据HTTP1.1 的性能瓶颈，HTTP2 做了什么优化？

HTTP2 HTTP2 协议是基于 HTTPS 的，所以 HTTP2 的安全性也是有保障的。
那 HTTP2 相? HTTP1.1 性能上的改进：

头部压缩

HTTP2 会压缩头（Header）如果你同时发出多个请求，他们的头是?样的或是相似的，那么，协议会帮你消除重复的部分。
这就是所谓的 HPACK算法：在客户端和服务器同时维护?张头信息表，所有字段都会存?这个表，?成?个索引号，以后就不发送同样字段了，只发送索引号，这样就提?速度了。

?进制格式

HTTP2 不再像 HTTP1.1?的纯?本形式的报?，?是全?采?了?进制格式，头信息和数据体都是?进制，并且统称为帧（frame）：头信息帧和数据帧。

文章图片
这样虽然对?不友好，但是对计算机?常友好，因为计算机只懂?进制，那么收到报?后，?需再将明?的报?转成?进制，?是直接解析?进制报?，这增加了数据传输的效率。

数据流

HTTP2 的数据包不是按顺序发送的，同?个连接??连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。每个请求或回应的所有数据包，称为?个数据流（ Stream ）。
每个数据流都标记着?个独???的编号，其中规定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数。
客户端还可以指定数据流的优先级。优先级?的请求，服务器就先响应该请求

文章图片

多路复?

HTTP2是可以在?个连接中并发多个请求或回应，?不?按照顺序??对应。
移除了 HTTP1.1中的串?请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，?幅度提?了连接的利?率。
举例来说，在?个 TCP 连接?，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程?常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。

务器推送

HTTP2还在?定程度上改善了传统的「请求 - 应答」?作模式，服务不再是被动地响应，也可以主动向客户端发送消息。
举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会?到的 JS、CSS ?件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

HTTP2 也存在缺陷

HTTP2多个请求复??个TCP连接，?旦发?丢包，就会触发 TCP 的重传机制，?个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。，就会阻塞住所有的 HTTP 请求。

因此HTTP2也是存在阻塞的问题，那么HTTP3是不是就来解决阻塞问题的呢？？

HTTP3 HTTP3把 HTTP 下层的 TCP 协议改成了 UDP！
我们都知道 UDP 发?是不管顺序，也不管丢包的，所以不会出现 HTTP1.1 的队头阻塞和 HTTP2 的?个丢包全部重传问题。

众所周知UDP是不可靠传输，那HTTP3怎么做到可靠的呢？？？

UDP是不可靠传输的，但基于UDP的 QUIC 协议（基于UDP的低时延的互联网传输层协议）可以实现类似 TCP 的可靠性传输。
QUIC （Quick UDP Internet Connection）在应用程序层面（应用层）实现了 TCP 的可靠性，TLS 的安全性和 HTTP2 的并发性，只需要用户端和服务端的应用程序支持 QUIC 协议，完全避开了操作系统和中间设备的限制。
用一个等式来描述就是 QUIC = UDP + TLS + HTTP2

什么是操作系统和中间设备的限制？？？？？？

TCP是在操作系统内核和中间设备固件中实现的。要对TCP进行大更改，就必须要通信双方升级操作系统，中间设备更新固件，部署成本非常高。

通过QUIC改进拥塞控制体现在哪几个方面？？

QUIC在应用层即可实现不同的拥塞控制算法，不需要改操作系统和内核。
单个程序的不同连接也能支持配置不同的拥塞控制。这样我们就可以给不同的用户提供更好的拥塞控制。
应用程序变更拥塞控制，甚至不需要停机和升级。
QUIC还有带宽预测，RTT监控，发送速率调整等高级算法支持。

扩展几点：

QUIC 有??的?套机制可以保证传输的可靠性的。当某个流发?丢包时，只会阻塞这个流，其他流不会受到影响。
TLS3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack 。
HTTPS 要建??个连接，要花费 6 次交互，先是建?三次握?，然后是 TLS/1.3 的三次握?。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。

相关链接文章只是简单的就HTTP1.1和HTTP2共同的一个阻塞问题来讨论HTTP3是如何改进优化的。虽然觉得HTTP3很好，但是现在还未得到普遍使用。如果对HTTP3感兴趣可以看下面的相关链接，讲解更深入。
科普：QUIC协议原理分析
【初识——HTTP3】QUIC网络协议简介