HTTP/3就要来了,先看看我的解读
副标题[/!--empirenews.page--]
然而技术的发展总是让人目不暇接,2018年10月,HTTP/3又发布了。虽然已经有一些中文技术媒体做了报道,但大多数是翻译的,而且内容大同小异。最近我专门学习了点关于HTTP/3的知识,在这里随便写写,和大家做个分享。 先简单回顾一下HTTP/2吧。自从1999年HTTP 1.1发布之后,Web一直在迅猛发展,可惜HTTP协议一直没有更新。等不及的Google自己搞了个SPDY(读音是“speedy”),并依靠Chrome浏览器大肆推广。看到SPDY的效果确实很好(可以带来近50%的性能提升),IETF推动制定了HTTP/2。 SPDY和HTTP/2的主要特性展示如下 如今HTTP/2已经不新鲜了,根据2019年2月对访问量最大的1000万个网站的统计,33.5%已经支持HTTP/2。在国内,如果你打开浏览器看看调试模式,会发现各大厂已经广泛使用HTTP/2,尤其是放置css、js、图片的资源站,HTTP/2基本是标配。这也很好理解,基本什么都不用做,就可以直接享受多路复用带来的好处,何乐而不为? 在传统HTTP中,概念模型非常简单:下层TCP通讯与上层HTTP完全不搭架,但TTP与TCP的“连接”是重合的,TCP传输的单位是packet,HTTP则采用request-response的模型。 在HTTP/2中,概念模型有所变化,HTTP/2中传输的基本单位是帧(frame)。与HTTP 1.1的明文传输不同的是,HTTP/2的帧是二进制的,同时TCP承载的“逻辑连接”叫数据流(stream),所有的状态流转、流控、优先级等等特性都是在数据流上实现的。HTTP/2中为大家所津津乐道的“多路复用”,简单说就是把数据流分解为多个帧,多个数据流的帧混合之后以同一个TCP连接来发送。 值得注意的是,HTTP有1.0和1.1的区分,所以写作HTTP 1.0,HTTP 1.1,但HTTP/2不会有其它小版本,所以不要写作HTTP 2.0,而应当写成HTTP/2。 虽然HTTP/2已经带来了巨大的性能提升,但大家对性能的渴求是没有止境的。在应用层的许多问题解决之后,下一个优化的重点就是传输层了。无论SPDY还是HTTP/2,传输层协议都是TCP,TCP有一些娘胎里带来的问题,比如慢启动,如果拥塞窗口尺寸设置不合理,TCP的性能会急剧下降。关于这个问题,网络上已经有许多讨论,这里不赘述。 另一个重要问题是,HTTP/2的多路复用带来的效果并不如想象的那么好。虽然HTTP/2中的传输连接可以多路复用,但仍然无法避免队头阻塞的情况出现。因为TCP是需要保证有序的,假如单个TCP连接同时承载了四路逻辑连接,其中某个逻辑连接丢包了,则其它三路都会受影响,都必须从丢包的时刻开始重传,这无疑是极大的浪费。测试表明,如果丢包率超过2%,那么HTTP/2甚至不如HTTP 1.1,因为HTTP 1.1中各连接物理隔离,不会互相影响。 所以思路自然就是“改掉TCP的这些毛病”。考虑到现实中已经有成千上万的网络设备,它们只能识别TCP和UDP,软件不会进化,如果更新TCP协议当然不可行——虽然2014年12月发布了TCP的Fast Open,但现实应用中的情况并不让人满意。因此,可用的只有UDP了。对了,还有人考虑过SCTP,但SCTP在队头阻塞、TLS、四次握手等方面仍然存在缺陷,尚不能让人满意。 大概有人听过QUIC(读音quick),知道它是基于UDP的HTTP,也知道它依然是Google最先提出来的。确实,上次是Google率先搞出了SPDY,这次Google又率先搞出了QUIC。根据Google本意,QUIC是把传统的HTTP/TCP/IP协议栈中的TCP换成UDP(当然需要加密),能通过加密的UDP传输HTTP/2的帧。 按照Google的说法,这样的好处很多,比如UDP建立连接的延迟会低很多,而且避免了队头阻塞。除此之外,Google还提供了一个非常诱人的特性FEC(Forward Error Correction)。简单说,它想做到的是,一旦有packet丢失,接收方可以根据之前和之后的packet推断出丢失packet的数据,这样就避免了重传。但是这样必然要求增加冗余载荷,或者说,这就是网络协议中的RAID 5。按照目前看到的资料,其冗余比例大概是10%,也就是说,每10个pakcet中的冗余信息,就可以重构一个packet。 尽管Google的QUIC很先进,但QUIC不止这一家,IETF也有QUIC,如今已经改名HTTP/3,所以Google的QUIC有时候也写作gQUIC。与Google单纯在传输层动手,应用层基本沿用HTTP/2不同,IETF的QUIC是一个混合方案,既包括传输层的改动,也包括HTTP层的改动(比如全新的头部压缩)。从另一个角度来说,它更“完整”。虽然理论上QUIC也可以支持HTTP之外的其它上层应用,但目前这只是计划而已,第一版QUIC并不包含这方面内容。 在2018年11月,IETF正式宣布,HTTP-over-QUIC更名为HTTP/3。 本文讨论的是IETF版本的QUIC,Google已经宣布,会逐步把IETF的规范纳入自己的协议版本,实现相同的规范。 虽然TCP有各种问题,但换成UDP的话,TCP的不少功能也需要原样移植过来。许多人都知道,TCP是可靠的传输协议,而UDP是不可靠的。HTTP/3当然不能不可靠,所以它必须自己实现有序性、错误侦测、重传、拥塞控制、传输节奏调整等等特性。 HTTP/2“似乎”必须用到HTTPS,但规范并不强求HTTP/2使用HTTPS,也就是说,如果你用HTTP来跑HTTP/2,理论上也是可以成立的,虽然这有点怪异。 与此相反,QUIC的所有连接都是加密的,目前采用的是TLS 1.3。如果你仔细观察上面的图就会发现,TLS 1.3是“囊括”在QUIC当中的,也就是说,QUIC建立连接的握手过程当中就同时完成了加密握手。HTTP/3的握手很快,如果两台主机之间建立过连接,并且缓存了之前的secret,只要客户端验证之前缓存的server config就可以直接建立连接,相当于0-RTT,否则也只需要1-RTT就可以建立连接。此外,QUIC还容许在0-RTT的情况下从一开始就捎带数据,传统的“建立连接-加密握手-发送数据”如今可以三步并作一步(这个0-RTT和1-RTT的实现都非常有意思,有兴趣的话应当找资料来看看)。 (编辑:淮安站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |