Chinaunix首页 | 论坛 | 博客
  • 博客访问: 33844
  • 博文数量: 41
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 80
  • 用 户 组: 普通用户
  • 注册时间: 2016-06-19 19:25
  • 认证徽章:
个人简介

迷茫的开发

文章分类

全部博文(41)

文章存档

2019年(13)

2017年(10)

2016年(18)

我的朋友

分类: C/C++

2017-11-22 19:38:08

原文地址:
https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit


什么是QUIC
QUIC(Quick UDP Internet Connections)是谷歌针对互联网定制的一种全新的传输层协议。

使用QUIC协议,开发者只需要很少、甚至不需要额外的代码,就能解决现代WEB应用程序的一系列传输层和应用层问题。QUIC 基于UDP协议,基本实现了TCP+TLS+HTTP2的功能。现有的协议往往受限与已有的客户端、代理等,独立的QUIC安装协议栈即可使用。


对比TCP+TLS+HTTP2模式,QUIC主要优点有:
低延迟的连接建立
更好的拥塞控制
使用多路技术避免线头阻塞(HOL)
前向纠错
连接迁移


连接建立
完整的连接建立的描述,参见QUIC设计文档[1]。
简单点说,大多数时候,QUIC在发送数据之前,不会先耗费往返时间进行握手,而TCP+TLS需要1-3个往返时间。
在客户端第一次发起连接到服务端时,客户端会花费一个往返时间来保证握手信息的完整性。客户端发送一个早期的client hello(CHLO)报文——空数据报文,服务端会回复一个rejection(REJ)——该报文包含客户端需要进行下去的信息,比如,源地址标识、服务端证书。此时,客户端就可以发送正常的CHLO。当然,如果本地缓存了服务端的证书——已连接过,客户端会直接使用之前连接的证书发起加密的连接到服务端。


拥塞控制
QUIC 支持可插入式的拥塞控制,并且,相比TCP,它为拥塞控制算法提供了更丰富的信息。目前,谷歌实现的QUIC的拥塞算法,是TCP中的Cubic的重实现版,它是谷歌尝试的替代方案。

比如,QUIC的发送报文和重传报文使用不同的序列号,QUIC的发送端可以区分发送ACK和重传ACK ——避免了TCP重传报文的二义性问题[1]。QUIC ACK 携带包处理延迟——对端收到一个包到ack发出的时间、线性增长的序列号。这些都能使往返时间计算更精确。

QUIC ack 帧支持超过256个NACK,所以相比TCP的SACK,QUIC 在重排时更具有弹性,并且在重排或丢失时,可以保持更多的数据在线路中。关于对端到底已收到哪些数据,在客户端和服务器中有更精确的描述。


多路技术
基于TCP上的HTTP2最大的问题之一就是线头阻塞。应用层将TCP连接视为字节流。当一个TCP报文丢失——甚至该报文已经到达了,只是还在队列中,该HTTP2上的所有流到不会继续,直到该丢失报文被遥远的对端重传、接收。

由于QUIC是完全为了多路技术而设计的,某条流上丢失报文的数据通常只会影响该条流。其它流上的帧仍然可以传送,没有数据丢失的流也可以被组装然后交付给应用层。


前向纠错
为了在不重传就能覆盖丢失的报文,QUIC可以通过一个FEC报文补足一组报文。就像RAID-4,FEC报文是该FEC组中的奇偶校验包[2]。如果该组中有一个包丢失了,该丢失的报文可以通过该组的FEC包和该组中的其它数据包恢复。发送方可以决定是否发送FEC报文来优化特定的场景(比如请求的开始和结束)


连接迁移
QUIC连接由客户端随机产生一个64位的ID号来标识。相应的,TCP 连接是由4元组来标识:源IP、源端口、目的IP和目的端口。这就意味着如果一个客户端改变了IP地址(比如从wifi切换到移动数据)或者端口(NAT 转换表丢失,重新进行端口映射),任何已有的TCP连接都失效了。当QUIC客户端改变IP地址时,它只要在新的IP上继续使用之前的连接ID,即使是在发送的请求,也不会被中断。


[1]QUIC 设计文档:https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit
[2]TCP中重传报文中计算的往返时间是不正确的,通常是忽略该次计算。
[3]FEC报文就像是RAID-4中的奇偶校验盘,普通的报文就像RAID-4中的普通数据盘。

阅读(317) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册