​HTTP/3来啦,你还在等什么?赶紧了解一下(下)

xiaohui 技术 2019年2月14日发布
Favorite收藏

导语:这篇文章对过去三十年来IETF对HTTP的标准化过程进行了简单的介绍,由于篇幅原因,我在本文没有过多介绍技术细节,而是以一个时间轴的方式理清HTTP/3的演变过程。

上篇文章主要介绍互联网协议标准化过程中的重要意义和流程,接下来我会讲到HTTP/3的出现过程。

Cloudflare的运行代码

Cloudflare是一家美国的跨国科技企业,总部位于旧金山,在英国伦敦亦设有办事处。Cloudflare以向客户提供网站安全管理、性能优化及相关的技术支持为主要业务。通过基于反向代理的内容分发网络(CDN, Content Delivery Network)、任播(Anycast)技术 、基于nginx+lua架构的Web应用防火墙(WAF, Web Application Firewall) 及分布式域名解析服务(Distributed Domain Name Server)等技术,Cloudflare可以帮助受保护站点抵御包括分布式拒绝服务攻击(DDoS, Distributed Denial of Service)在内的大多数网络攻击,确保该网站长期在线,同时提升网站的性能、访问速度以改善访客体验,这也是Cloudflare成为新协议和不断发展的协议的早期采用者的原因,比如HTTP/2,他们还测试了一些实验性或尚未完成的特性,如TLS 1.3和SPDY。Cloudflare提供的安全服务是帮助网站阻止来自网络的黑客攻击、垃圾邮件等,并提升网页的浏览速度,这和一般的安全软件往往会影响网页的运行速度大相径庭。目前Cloudflare在全球拥有152个数据中心 ,如果用户使用了其服务,那么网络流量将通过Cloudflare的全球网络智能路由。Cloudflare会自动优化用户的网页交付,以期达到最快的页面加载时间以及最佳性能。Cloudflare提供包括CDN、优化工具、安全、分析以及应用等服务。

在IETF标准化过程中,将这些正在运行的代码部署在各种不同的真实网络上,可以帮助我们了解协议在实践中的运作情况。我们将现有的专业知识与实验信息结合起来,以帮助改进正在运行的代码。

对新的协议进行不断地测试和应用只是标准制定过程中的部分要求,另外还要知道标准什么时候该修改,什么时候该把旧的标准完全替代。有时这与面向安全的协议有关。例如,由于POODLE漏洞,Cloudflare默认禁用SSLv3。在其他情况下,落后协议会被技术更先进的协议取代,比如Cloudflare不赞成使用SPDY而赞成支持HTTP/2。

在安全Web时间轴上,相关协议的引入和废弃用橙色线条表示。垂直虚线有助于将Cloudflare事件与相关IETF文档关联起来。例如,Cloudflare在2016年9月引入了TLS 1.3支持,而最终文档RFC 8446 则是与两年后的2018年8月发布。

5.png

HTTPbis重构协议的过程

HTTP/1.1是一个非常成功的协议,时间表显示1999年后,IETF没有对此协议进行太多修改。然而,经过多年的追踪还是发现了RFC 2616的潜在问题,该问题会导致一些互操作性问题。此外,其他RFC如2817和2818对该协议进行了扩展,2007年IETF决定启动一个新的修改工作来改进HTTP协议规范。

简言之,HTTPbis决定重构RFC 2616,并修改同时发布的其他规范。决定把文件分成几部分。HTTPbis决定将勘误文档分成几部分进行修复,这也是它在2007年12月发布了6个I-D的原因:

· draft-ietf-httpbis-p1-messaging

· draft-ietf-httpbis-p2-semantics

· draft-ietf-httpbis-p4-conditional

· draft-ietf-httpbis-p5-range

· draft-ietf-httpbis-p6-cache

· draft-ietf-httpbis-p7-auth

6.png

该图显示了在最终标准协议发布之前,这项工作是如何在长达7年的起草过程中慢慢发展迭代的,可以看出期间共发布了27个草案版本。2014年6月,所谓的RFC 723x系列发布(x范围从0到5),HTTPbis主席用“RFC2616已死”来庆祝这一成就。

HTTP/3是如何出现的?

当IETF忙着研究RFC 723x系列标准时,互联网世界的发展也经历了快速的迭代变化,就有的HTTP协议必须通过增强、扩展才能适应新的形势。俗话说,企业是市场最敏感的回应者,谷歌很早就开始用一种叫SPDY的东西。SPDY(读作“SPeeDY”)是Google开发的基于TCP的应用层协议,用以最小化网络延迟,提升网络速度,优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议,而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级以及HTTP标头压缩。谷歌表示,引入SPDY协议后,在实验室测试中页面加载速度比原先快64%。SPDY协议的主要作用是提高web浏览的性能,而这也是HTTP的目标。2009年底SPDY v1发布,2010年SPDY v2也发布了。

互联网工程任务组(IETF)对谷歌提出的SPDY协议进行了标准化,于2015年5推出了类似于SPDY协议的 HTTP 2.0 协议标准(简称HTTP/2)。谷歌因此宣布放弃对SPDY协议的支持,转而支持HTTP/2。谷歌称,计划于 2016 年初在 Chrome 中移除 SPDY,并将为Chrome 40 添加 HTTP/2 协议支持。

此外,著名的开源HTTP服务器软件 Nginx 也于2015年9月移除了对SPDY的支持,转而支持HTTP/2。

鉴于此,未来会有越来越多的浏览器和Web服务器选择支持HTTP/2而非SPDY,以前支持SPDY的浏览器和Web服务器也会通过升级取消对SPDY的支持转为支持HTTP/2。

之所以我们建议网站不要部署SPDY,而是部署HTTP,就是因为SPDY采用了HTTP的核心范式,只是对交换格式进行了轻微的修改。现在看来,这些都可以通过HTTP明确划分的语义和语法实现。语义描述了请求和响应交换的概念,包括方法、状态代码、头字段(元数据)和主体部分(有效载荷)。语法描述如何将语义映射到连接上的字节。

HTTP/0.9、HTTP/1.0和HTTP/1.1共享许多了许多语义,这几版协议还通过TCP连接发送的字符串的形式共享语法。SPDY采用HTTP/1.1语义,并将语法从字符串更改为二进制,这是一个非常有趣的话题,但是我们今天就不深入这个话题了。

谷歌对SPDY的测试表明,改变HTTP语法是有可操作空间的,而保留现有的HTTP语义是有价值的。例如,保持URL格式以使用https://避免了许多可能会影响采用的问题。

正是看到了这些积极的测试结果,IETF决定是时候考虑HTTP/2.0了。2012年3月IETF 83会议期间HTTPbis会议对HTTP/2.0制定了据要求、目标和成功的衡量标准。其中明确指出,“HTTP/2.0仅表示有线格式与HTTP/1.x的格式不兼容”。

HTTP/2 (原名HTTP/2.0)即超文本传输协议 2.0,是下一代HTTP协议。是由互联网工程任务组(IETF)的Hypertext Transfer Protocol Bis (httpbis)工作小组进行开发。是自1999年http1.1发布后的首个更新。HTTP 2.0在2013年8月进行首次合作共事性测试。在开放互联网上HTTP 2.0将只用于https://网址,而 http://网址将继续使用HTTP/1,目的是在开放互联网上增加使用加密技术,以提供强有力的保护去遏制主动攻击。DANE RFC6698允许域名管理员不通过第三方CA自行发行证书。

7.png

在那次会议上,提交审议的I-D包括draft-mbelshe-httpbis-spdy-00draft-montenegro-httpbis-speed-mobility-00draft-tarreau-httpbis-network-friendly-00 。最终,SPDY草案被采纳,并在2012年11月以draft-ietf-httpbis-http2-00的形式正式形成协议草案。2015年,RFC 7540 – HTTP/2 正式被发布,在两年多的时间里,总共经历了18个草案。在此规范期间,HTTP/2的语法精确性出现了一些分歧,这也是HTTP/2和SPDY不兼容的原因。

近几年IETF的主要精力都投入到了HTTP协议的跟踪和制定中了,且任务相当繁忙,HTTP/1.1重构和HTTP/2标准化要同时进行。这与21世纪初多年的平静形成了鲜明对比。所以你一定要查看完整的时间表,以真正了解近几年IETF这几年所做的工作。

由于HTTP/2正处于标准化阶段,所以暂时使用SPDY和并对其进行试验仍然有一定的价值。 Cloudflare在2012年8月引入了对SPDY的支持,直到2018年2月才弃用它,当时我们的统计数据显示,只有不到4%的Web客户端继续需要SPDY。同时,我们在RFC发布后不久的2015年12月引入了HTTP/2支持,当时我们的分析表明有相当一部分Web客户端可以直接利用HTTP/2。

SPDY和HTTP/2协议的Web客户端支持首选使用TLS的安全选项,2014年9月引入通用SSL(用户无需向证书发放机构申请和配置证书就可以使用的SSL证书)有助于确保所有注册到Cloudflare的网站都能够在我们引入这些新协议时利用这些它们。

gQUIC

谷歌在2012年到2015年间继续实验,他们分别发布了SPDY v3和v3.1。同时他们还开始研究gQUIC(当时的发音是as quick),最初的公开规范于2012年初发布。

gQUIC的早期版本使用了SPDY v3形式的HTTP语法,这个选择是合理的,因为HTTP/2标准还没有制定完成。SPDY二进制语法被打包成可以在UDP数据报中发送的QUIC包,这与HTTP传统上依赖的TCP传输有所不同。以上的描述,简化成图就是以下的样子:

8.png

SPDY over gQUIC蛋糕模型

gQUIC使用巧妙的技巧来实现性能,技巧之一就是打破应用程序和传输之间的清晰分层。这在实践中就意味着gQUIC只支持HTTP。以至于gQUIC(当时被称为“QUIC”)一度成为HTTP的下一个替代方案。尽管在过去的几年中,QUIC不断地发生变化(我们稍后将对此进行讨论),但直到今天,QUIC这个术语仍然被人们理解为最初的仅用于HTTP的变体。不幸的是,这是在讨论协议时经常引起混淆的原因。

后来gQUIC继续进行实验并最终使用了更接近HTTP/2的语法。二者语法如此接近,以至于大多数人简单地将其称之为"HTTP/2 over QUIC"。但是,由于技术限制,HTTP/2和QUIC之间还是有一些非常细微的差别,比如如何序列化和交换HTTP标头。虽然这只是一个很小的区别,但实际上意味着HTTP/2 over QUIC与IETF的HTTP/2是不兼容。

归根结底,互联网协议除了能提高传输性和稳定性之外,最重要的就是安全方面了。gQUIC就没有选择使用TLS来提供安全性,相反,谷歌开发了一种名为QUIC Crypto的不同方法。该方法的一个有趣的方面就是加快安全握手的新方法,先前与服务器建立了安全会话的客户端可以重用信息来进行“零往返时间”即0-RTT握手,0-RTT后来被TLS 1.3采纳。

HTTP/3目前的标准化状态

到目前为止,你应该已经熟悉了标准化的工作原理,gQUIC的标准化过程也没有什么太大的不同。人们对谷歌规范以I-D格式编写非常感兴趣。2015年6月,谷歌提交了题为“QUIC:基于UDP的HTTP/2安全可靠传输”的draft-tsvwg-quic-protocol-00,其语法几乎是HTTP/2。

谷歌宣布将在布拉格的IETF 93举办一场“Bar BoF”发布会。对于那些好奇什么是“Bar BoF”的人,请参阅RFC 6771

9.png

简而言之,谷歌与IETF合作的结果是,QUIC似乎在传输层提供了许多优势,并且它应该与HTTP分离,重新引入层之间的清晰分离层。此外,有人倾向于返回基于TLS的握手(由于TLS 1.3在此阶段正在进行,并且正在整合0-RTT握手,因此并没有那么糟糕)。

大约一年后的2016年,谷歌提交了一套新的I-D:

· draft-hamilton-quic-transport-protocol-00 

· draft-thomson-quic-tls-00 

· draft-iyengar-quic-loss-recovery-00 

· draft-shade-quic-http2-mapping-00 

这里是关于HTTP和QUIC产生混淆的另一个来源,draft-shade-quic-http2-mapping-00名为“使用QUIC传输协议的HTTP/2语义”,它将自己描述为“在QUIC上的HTTP/2语义映射”。然而,这种说法很不恰当。HTTP/2是在维护语义的同时对原有的语法进行了修改。此外,"HTTP/2 over gQUIC"从未对语法进行过准确描述,原因我在前面已经介绍过了。

目前这个IETF版本的QUIC是一个全新的传输协议,应该说制定一个全新的传输协议是一项很艰巨的任务,不过在发布该计划之前,IETF先衡量了一下各个组织成员的实际利益。为此,2016年在柏林举行的IETF 96会议上IETF举行了正式的讨论会议。我们很幸运能够亲自参加这次会议,在会议结束时各个成员达成了共识; QUIC将被IETF标准化。

用于将HTTP映射到QUIC的第一个IETF QUIC I-D是draft-ietf-quic-http-00,该草案采用了Ronseal方法,并将其名称简化为“HTTP over QUIC”。不幸的是,该草案没有完全完成预定的修订工作,而且在整个草案中存在许多引用HTTP/2术语的地方。I-D新的负责人Mike Bishop发现了这一点,并开始修复和HTTP/2有关的错误。在01草案中,原来的描述改为“基于QUIC的HTTP语义映射”。

随着时间的推移和版本的演变, 对“HTTP/2” 术语的使用逐渐减少了,仅有的使用仅仅是对RFC 7540 部分的引用。到2018年10月,I-D已经是第16版了。虽然HTTP over QUIC 与HTTP/2相似,但它最终还会是一个独立的、不向下兼容的HTTP语法。然而,对于那些不密切跟踪IETF发展的人来说,他们并没有从文档名称的变化之处捕捉到这种差异。标准化的作用之一就是帮助大家提高通信便利和互操作性。然而,像命名这样简单的事情反而造成了标准制定的混乱,这是大家原来都没有想到的(你可能也在HTTPtre或HTTPter两个名称上犯过糊涂)。

回想一下IETF 在2012年所说的“HTTP/2.0仅表示有线格式与HTTP/1.x的格式不兼容”这句话,可以说IETF遵循了当初的承诺。在IETF 103发布之前和发布期间,经过深思熟虑,各方一致同意将“HTTP over QUIC”重命名为HTTP/3。

但是RFC 7230和RFC7231不支持IETF目前对语义和语法的定义!

有时文档标题可能会令人困惑,比如描述语法和语义的当前HTTP文档有:

RFC 7230——超文本传输协议(HTTP/1.1):消息语法和路由;

RFC 7231——超文本传输协议(HTTP/1.1):语义和内容;

我们可能会对这些名称进行过多的解读,并认为基本的HTTP语义是特定于HTTP版本的,即HTTP/1.1。然而,事实并非如此。鉴于这些混乱, HTTPbis工作组正在努力解决这个问题。一些成员正在进行新一轮的文件名称修订,且这项工作现在正在进行,且是HTTP核心工作。目前,工作组计划将把原来的六份草案压缩成以下三份:

HTTP语义(draft-ietf-httpbis-semantics)

HTTP缓存(draft-ietf-httpbis-caching)

HTTP/1.1消息语法和路由(draft-ietf-httpbis-messaging)

在这个新结构下,很明显的可以看出HTTP/2和HTTP/3是通用HTTP语义的语法定义,这并不意味着它们除了语法之外没有自己的特性。

总结

这篇文章对过去三十年来IETF对HTTP的标准化过程进行了简单的介绍,由于篇幅原因,我在本文没有过多介绍技术细节,而是以一个时间轴的方式理清HTTP/3的演变过程。简而言之,HTTP/3只是一种新的HTTP语法,适用于IETF QUIC,这是一种基于UDP的多路复用和安全传输。

本文翻译自:https://blog.cloudflare.com/http-3-from-root-to-tip/如若转载,请注明原文地址: http://www.4hou.com/technology/16117.html
点赞 5
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论