QUIC协议浅析与HTTP/3.0

作者: Auditore | 来源:发表于2018-11-29 09:53 被阅读38次

    QUIC协议浅析与HTTP/3.0

    1. 简介

    QUIC(Quick UDP Internet Connections)基于UDP的传输层协议,提供像TCP一样的可靠性。在提高web应用性能上,可以选择在应用层使用HTTP2.0实现多路传输,在物理层使用CDN解决网络拥塞和最后一公里问题。在传输层,目前主要使用TCP,但由于TCP本身的问题(一个充满补丁的丑陋的协议),成为了限制web应用性能的一个瓶颈。
    QUIC是Google新开发的一个基于UDP的协议,它提供了像TCP一样的传输可靠性保证,可以实现数据传输的0-RTT延迟,灵活的设计使我们可以对它的拥塞控制及流量控制做更多的定制,它还提供了传输的安全性保障,以及像HTTP/2一样的应用数据二进制分帧传输。

    而QUIC协议最最吸引人的特性有两点,一是对线头阻塞(HOL)问题的解决更为彻底。基于TCP的HTTP/2,尽管从逻辑上来说,不同的流之间相互独立,不会相互影响,但在实际传输方面,数据还是要一帧一帧的发送和接收,一旦某一个流的数据有丢包,则同样会阻塞在它之后传输的其它与它毫不相干的流的数据的传输。而基于UDP的QUIC协议则可以更为彻底地解决这样的问题,让不同的流之间真正的实现相互独立传输,互不干扰。

    另一个特性切换网络时的连接保持。当前移动端的应用环境,用户的网络可能会经常切换,比如从办公室或家里出门,WiFi断开,网络切换为3G或4G。基于TCP的协议,由于切换网络之后,IP会改变,因而之前的连接不可能继续保持。而基于UDP的QUIC协议,则可以内建与TCP中不同的连接标识方法,从而在网络完成切换之后,恢复之前与服务器的连接。

    由于这些良好的特性,QUIC协议已经有在gmail中得到了大量的应用。

    互联网工程任务组(IETF,协作设计网络协议的行业组织)一直致力于制定标准化的QUIC版本,该版本目前与谷歌的原始提案有很大差异。IETF还希望开发一个使用QUIC的HTTP版本,该版本之前名为HTTP-over-QUIC或HTTP/QUIC。然而,HTTP-over-QUIC不是HTTP/2 over QUIC,而是一种为QUIC设计的新的HTTP更新版。

    因此,身兼IETF旗下HTTP工作组组长和QUIC工作组组长的马克•诺丁汉(Mark Nottingham)提议,将HTTP-over-QUIC改名为HTTP/3,这个提议似乎已得到了广泛接受。HTTP的下一个版本将QUIC列作一项必不可少的基本功能,那样HTTP/3将始终使用QUIC作为其网络协议。

    2. 传输与建立连接上的优势

    2.1 避免前序包阻塞(HOL阻塞)

    多个数据在TCP连接上传输时,若一个数据包出现问题,TCP需要等待该包重传后,才能继续传输其它数据包。但在QUIC中,因为其基于UDP协议,UDP数据包在出问题需要重传时,并不会对其他数据包传输产生影响。


    image

    2.2 零RTT建立连接

    目前TCP与SSL/TLS(1.0,1.1,1.2)每次建连需要TCP三次握手+安全握手,需要4~5个RRT

    2.3 第一次连接

    image

    客户端之前没有连接个此服务器,那么他会发送一个Hello Packet。服务器接到之后,会回复一个数据包。里面包含了安全证书和对此客户端唯一的SYN cookie。客户端接到包之后,首先要做的就是解码,保存好SYN cookie。SYN cookie 类似于令牌,能够验证客户端身份。它的生存周期较短,防止被盗用。这样建立连接只需要1个RTT。

    当客户端接到服务器发来的第一个数据包,没有正确解码,那么它会再次发送一个包要求服务器从新发送它的安全证书,并将SYN cookie附加到这个请求包中,以便让服务器验证请求的正确性和有效性。此时,建立连接需要2个RTT。

    2.4 重复连接

    image

    因为客户端之前已经成功和服务器通信。自然保留了一份服务器的安全证书。当再次想要连接服务器的时候,客户端假设这个安全证书没有过期,还是有效的。加密一个Hello Packet并发送之后。接着不用等回复就可以直接加密其他的数据包并发送。Hello Packet 里面包括一些协商信息和对自己掌握着Client IP的证明等。因为不用等待确认,为了预防丢包等问题,Hello Packet可能会隔一段时间被重传多次,保证减少丢包造成的延迟。比如,先发一个Hello包,之后发送数据包,再发送一个Hello包。

    服务器接到Hello包之后,用自己现有的秘钥解码,如果解码不成功,将把客户端的连接当做第一次连接,重发安全证书等信息。同上介绍的一样。此时,通常会有2个RTT,极端情况下是3个RTT。

    服务器成功解码之后,验证了客户端的安全性之后,就可以继续处理接下来收到的数据包。此时延时是0个RTT。

    3. 优雅的丢包处理

    3.1 FEC前向纠错

    QUIC协议的每个数据包除了本身的数据以外,会带有其他数据包的部分数据,在少量丢包的情况下,可以使用其他数据包的冗余数据完成数据组装而无需重传,从而提高数据的传输速度。具体实现类似于RAID5,将N个包的校验和(异或)建立一个单独的数据包发送,这样如果在这N个包中丢了一个包可以直接恢复出来。除此之外还可以用来校验包的正确性

    3.2 关键包发送多次

    image

    3.3 快速重启会话(支持手机网络切换)

    普通基于tcp的连接,是基于两端的ip和端口和协议来建立的。在网络切换场景,例如手机端切换了无线网,使用4G网络,会改变本身的ip,这就导致tcp连接必须重新创建。而QUIC协议使用特有的UUID来标记每一次连接,在网络环境发生变化的时候,只要UUID不变,就能不需要握手,继续传输数据。

    4. 安全

    前向安全。即使被人抓包存储起来,在未来某个时间点秘钥被破解后仍然不能解密。
    内置的加密模块,支持SNI,因此支持一个IP部署多个证书,默认打开,相比TLS更高效的向前加密。
    https://www.cnblogs.com/mod109/p/7372577.html

    5. 适用场景

    • 长距离传输
    • 手机网络
    • 请求的页面资源数较多,并发的连接数多
    • 要求加密传输

    本文整理自网络,来源见扩展阅读

    6. 扩展阅读

    1. Google的QUIC
    2. HTTP 3.0 将 TCP 协议更换为基于 UDP 的谷歌 QUIC
    3. QUIC浅析

    相关文章

      网友评论

        本文标题:QUIC协议浅析与HTTP/3.0

        本文链接:https://www.haomeiwen.com/subject/iedxcqtx.html