前言
- 了解一下HTTP发展史:HTTP/0.9-HTTP/1.0-HTTP/1.1-HTTP/2.0
多个TCP连接
在最早的时候,HTTP通过建立多个TCP连接来完成请求,并且每次请求完成就会关闭本次的Tcp 连接,新的请求又要建立新的TCP连接来完成
缺点:每次请求都需要建立新连接,造成性能损耗;
多个请求还会导致数据传输线路上的数据重复,反过来又需要额外的协议在端节点无错误地提取所需信息;
安全性:旧HTTP协议上,Cookie Hack允许重用以前的工作会话来入侵帐户密码,因为HTTP1.1不提供会话端点身份设施,到SSL/TLS的出现才保障了会话的信息安全保密性
Keep-alive
在前面的基础,增加了Keep-Alive,主要解决了每次必须建立新连接的问题,在同一时间(时间可配置)内,同一域名多次请求数据,只建立一个HTTP请求,来达到提高请求效率的目的
缺点:请求的个数限制(6~8个)
管线化
HTTP 克服了同域并行请求限制带来的阻塞,把所有请求一并发给服务器,服务器需要按照顺序一个一个响应
缺点:阻塞问题,某个请求响应阻塞,后面的响应会被阻塞
多路复用
HTTP/2引入了两个非常重要的概念:帧(frame)和流(stream),在服务器和客户端之间交换的通过 HTTP/2 协议发送的双向文本格式帧序列称为“流”。HTTP 协议的早期迭代一次只能传输一个流,并且每个流传输之间存在一定的时间延迟。多路复用就是所有请求的都是通过一个 TCP 连接并发完成,通过一一发送的单个流接收大量媒体内容既低效又耗费资源。
该层允许客户端和服务器将 HTTP 有效负载分解为小的、独立且可管理的交错帧序列。然后在另一端重新组合此信息。在多路复用之前所有的传输是基于基础文本的,在多路复用中是基于二进制数据帧的传输、消息、流,所以可以做到乱序的传输。多路复用对同一域名下所有请求都是基于流,所以不存在同域并行的阻塞。好处概括如下:
- 并行多路复用的请求和响应不会相互阻塞
- 尽管传输多个数据流,但使用单个 TCP 连接来确保有效利用网络资源
- 无需应用不必要的优化技巧 ——例如图像精灵、连接和域分片等——这会损害网络性能的其他领域
- 减少延迟,更快的网络性能,更好的SEO
- 减少运行网络和 IT 资源的运营支出和资本支出
除此外,HTTP2还有诸多其他方面性能、安全性、可靠性上的优点,得益于二进制协议、帧、流概念的引入。
主体
HTTP/3
HTTP/3是第三个主要版本的HTTP协议。与其前任HTTP/1.1和HTTP/2不同,在HTTP/3中,将弃用TCP协议,改为使用基于UDP协议的QUIC协议实现。
QUIC(Quick UDP Internet Connections)由谷歌于2012年首次部署。它依赖于较低级别的UDP协议,重新定义了网络层的边界,重新定义了“用户空间”中的握手、可靠性特性和安全特性,避免了需要升级互联网系统的内核。
协议目录还是草案,要检查网站是否支持HTTP/3:http3check
此变化主要为了解决HTTP/2中存在的队头阻塞问题。由于HTTP/2在单个TCP连接上使用了多路复用,受到TCP拥塞控制的影响,少量的丢包就可能导致整个TCP连接上的所有流被阻塞。
QUIC 项目最初是作为 TCP+TLS+HTTP/2 的替代方案,旨在改善用户体验,尤其是页面加载时间。IETF的QUIC工作组定义了传输层(QUIC)和应用层(HTTP/3)之间的清晰边界,以及从 QUIC Crypto 迁移到TLS 1.3。
由于 TCP 是在操作系统内核和中间盒中实现的,因此对 TCP 进行广泛的重大更改几乎是不可能的。然而,由于 QUIC 是建立在 UDP 之上的,并且传输功能是加密的,所以它没有这样的限制。
基于 TCP+TLS 和 HTTP/2 的 QUIC 和 HTTP/3 的主要特性包括
- 减少连接建立时间 - 在常见情况下为 0 次往返
- 改进的拥塞控制反馈
- 多路复用,没有线头阻塞
- 连接迁移
- 传输可扩展性
- 可选的不可靠交付
HTTP/3(QUIC协议)新特性
零RTT建立连接
传统HTTP/2(所有HTTP/2的浏览器均基于HTTPS)传输数据前需要三次RTT,即使将第一次TLS握手的对称秘钥缓存也需要两次RTT才能传递数据;
对于HTTP/3而言,QUIC集成了TLS加密功能,相较于早期版本TLS1.3有更多的优点,其中最重要的一点是减少了握手所花费的RTT个数,仅仅需要一次RTT即可传递数据,如果将其缓存,就可将RTT减少至零。
其核心就是DH秘钥交换算法:- 客户端向服务端请求数据
- 服务端生成g、p、a三个随机数,用三个随机数生成A。将a保留后,将g、p、A(Server Config)传递到客户端
- 客户端生成随机数b,将b保留后,用g、p、b三个随机数生成B
- 客户端再使用A、b、p生成秘钥K,用K加密HTTP数据并与B一同发送到服务端
服务端再使用B、a、p得到相同秘钥K,并解密HTTP数据
- 连接迁移
传统连接通过源IP、源端口、目的IP、目的端口进行连接,当网络发生更换后连接再次建立时延较长;
HTTP/3使用Connection ID对连接保持,只要Connection ID不改变,连接仍可维持。
Fixed队头阻塞/多路复用
- TCP作为面向连接的协议,对每次请求序等到ACK才可继续连接,一旦中间连接丢失将会产生队头阻塞
- HTTP/1.1中提出Pipelining的方式,单个TCP连接可多次发送请求,但依旧会有中间请求丢失产生阻塞的问题
- HTTP/2中将请求粒度减小,通过Frame的方式进行请求的发送。但在TCP层Frame组合得到Stream进行传输,一旦出现Stream中的Frame丢失,其后方的Stream都将会被阻塞
- 对于HTTP/2而言,浏览器会默认采取TLS方式传输,TLS基于Record组织数据,每个Record包含16K,其中有12个TCP的包,一旦其中一个TCP包出现问题将会导致整个Record无法解密。这也是网络环境较差时HTTP/2的传输速度比HTTP/1.1更慢的原因
- HTTP/3基于UDP的传输,不保证连接可靠性,也就没有队头阻塞的后果。同样传输单元与加密单元为Packet,在TLS下也可避免队头阻塞的问题
拥塞控制
- 热拔插:TCP对于拥塞控制在于传输层,QUIC可在应用层操作改变拥塞控制方法
- 前向纠错(FEC):将数据切割成包后可对每个包进行异或运算,将运算结果随数据发送,一旦丢失数据可据此推算。(带宽换时间)
- 单调递增的Packet Number:TCP在超时重传后的两次ACK接受情况并不支持的很好,导致RTT和RTO的计算有所偏差,HTTP/3对此进行改进,一旦重传后的Packet N会递增
- ACK Delay: HTTP/3在计算RTT时健壮的考虑了服务端的ACK处理时延
- 流量控制
TCP使用滑动窗口的方式对发送方的流量进行控制,而对接收方并无限制。在QUIC中补齐了这一短板,QUIC中接收方从单条Stream和整条连接两个角度动态调整接受的窗口大小。
结语
- HTTP/3 QUIC协议基于UDP实现,也结合了TCP、TLS的优势,相比于TCP传输效率提高,虽然 UDP 确实为 QUIC 和 HTTP/3 提供了一些固有的优势,但它也带来了一些挑战,TCP 多年来一直是主流协议,而UDP不是,因此操作系统和它的软件堆栈通常没有得到优化,这也需要技术上的专研突破
- TLS 是强制性的,旨在使中间设备难以篡改或嗅探流量。这也是为什么经常看到防火墙提供商和供应商将 UDP协议视为一个问题,并提供禁用它的方法,中间商更难检查、监督或过滤 QUIC 流量
- 经过这么多年的发展以及IETF的推动,HTTP3协议肯定是会更加普及,主流的端和操作系统也会支持HTTP3,同时HTTPS over TCP由其兼容性和众多终端的拥趸,相信也还会继续占领一席之地
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。