自译-仅为自己学习,不喜勿喷~(文末有原文链接)
HTTP已经被chrome的canary和curl支持了,可以下载自行体会
chrome:latest Canary build,启动时需要设置参数“--enable-quic” 和 “--quic-version=h3-23”,不知道怎么设置的,直接点击跳转 command-line arguments.
curl: brew install--HEAD -s https://raw.githubusercontent.com/cloudflare/homebrew-cloudflare/master/curl.rb
为什么要使用HTTP3(http的1.0,1.1,2.0对比)?
在深入讨论HTTP/3前让我们先大概过一下HTTP的发展历程,以便说明HTTP/3为什么是必须的
1996年HTTP/1.0的发布定义了今天HTTP报文的基本格式(假定HTTP/0.9不存在).在HTTP/1.0中clients和servers的每个request/response都会创建TCP连接,这意味着所有的请求都必须经过TCP和TLS握手才能传递数据,这中间的消耗是很大的.(这个问题在1.1中的解决方案是keep-alive保持连接,在2中的解决方案是concurrently multiplex并发多路复用)
比较难受的是HTTP/1.0不是在建立连接之后立即传输数据,而是强制执行一个叫“slow start”的预热期(搞得和冬天开车一样,热车.传说中的慢启动).“start slow”出现时为了解决网络拥塞问题(这个问题时什么以后在看吧).但是因为每个连接都需要慢启动,那肯定就很慢了
在HTTP/1.1引入了一个全新的东西:“keep-alive”,clients可以复用TCP连接了.虽然多个请求可以公用一个连接了,但是必须按序序列化:也就是一个连接在同一刻只能处理请求/响应(还不是很完美).
随着互联网的发展,并发请求/返回的需求更强烈了:浏览器访问网站获取更多的资源(css,js,images,font…).但是请记住HTTP/1.1,在同一时间,同一TCP连接上只能处理一个请求.当然在网络层它可以并发的创建多个TCP连接去处理同一个源的请求,但是这样一来使用“keep-alive”的意义就没那么大了.
在10年之后,SPDY和HTTP/2引入了“stream”的概念:本质上是实现在同一个TCP连接上并发处理多个不同的HTTP的抽象,这样浏览器确实可以更有效的复用TCP.
但是HTTP/2依然不是好的解决方案.HTTP/2确实解决了低效使用单TCP连接的问题.但是还会引出了新的问题:“head-of-line blocking”(这个问题也是随后在理解).
聊聊HTTP3
这就是为什么HTTP/3诞生的原因:HTTP/3使用了一个新的网络传输协议QUIC在传输层引入了streams作为一等公民取代TCP作为会话的传输层.QUIC流共享同一个QUIC连接,所以在创建新的QUIC流时不需要额外的握手和慢启动,但因为QUIC streams时独立传递的所以一个流丢包并不会影响其他的流.这可能是因为QUIC数据包是基于UDP数据包的.UDP的使用较TCP有更大的灵活性,且能使QUIC实现在用户空间中完全生存-就像TCP一样协议的更新和操作系统没有绑定关系.使用QUIC,HTTP级的流能被完全的映射到QUIC流上,这样可以获得HTTP/2的全部好处而不是“head-of-line blocking”
QUIC还结合了典型的TCP三次握手和TLS 1.3握手,结合这些步骤意味着加密和身份认证是被默认提供的,同时也是为了更快的建立连接.换句话说,即使是全新的QUIC连接被初始化建立,也比TCP+TLS快
但是,为什么不仅仅使用基于QUIC的HTTP/2,而是创造一个权限的HTTP修订版?毕竟HTTP/2也提供了流复用的特性.事实证明,这比全新QUIC要复杂的多.
尽管某些HTTP/2的特性能很容易映射到QUIC上,但不是所有哦(有时间再看不是的有哪些).
http3过去-现在-未来:https://blog.cloudflare.com/http3-the-past-present-and-future/
