iOS开发总结Android前端修仙之路

QUIC协议浅析与HTTP/3.0

2018-11-29  本文已影响38人  Auditore

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浅析
上一篇下一篇

猜你喜欢

热点阅读