QUIC协议浅析与HTTP/3.0

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浅析
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,233评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,013评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,030评论 0 241
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,827评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,221评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,542评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,814评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,513评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,225评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,497评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,998评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,342评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,986评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,055评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,812评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,560评论 2 271
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,461评论 2 266

推荐阅读更多精彩内容