quic 协议总结

以下内容转载自: https://github.com/y123456yz/reading-and-annotate-quic

client和server协商过程:

1. 客户端发送CHLO到服务端

2. 服务端回送的REJ信息给客户端,同时携带上原地址标识信息和服务端证书信息

3. 客户端再次发送CHLO到服务端

拥塞控制:

QUIC参考TCP的CUBIC拥塞控制算法,并在试探尝试其他拥塞控制算法

试探尝试新的拥塞控制算法:例如每个数据包的转发(包括原始数据包和重传包)都携带一个新的sequece序列化,这样可以避免TCP的重传模糊问题

QUIC-ACK会携带上接收数据包的时间以及发送ack的时间,这样有利于计算往返时延

QUIC-ACK相比TCP的SACK,跟容易实现包的重组,当有包丢失或者

FEC

通过FEC可以从一组FEC报文组中恢复网络传输中丢失的数据包,具体优化方案由发送端决定

连接复用

QUIC连接通过一个64位的连接标识符标识,该标识符由客户端产生。

QUIC的连接建立将版本协商与加密和传输握手交织在一起以减少连接建立延迟。我们将在下面首先描述版本协商。

连接建立延迟

灵活的拥塞控制

多路复用而不存在队首阻塞

认证和加密的首部和载荷

流和连接的流量控制

连接迁移

QUIC采用了两级密钥机制:初始密钥和会话密钥。初次连接时不加密,并协商初始密钥。初始密钥协商完毕后会

马上再协商会话密钥,这样可以保证密钥的前向安全性,之后可以在通信的过程中就实现对密钥的更新。接收方意

识到有新的密钥要更新时,会尝试用新旧两种密钥对数据进行解密,直到成功才会正式更新密钥,否则会一直保留

旧密钥有效。

  QUIC在握手过程中使用Diffie-Hellman算法协商初始密钥,初始密钥依赖于服务器存储的一组配置参数,该参数

会周期性的更新。初始密钥协商成功后,服务器会提供一个临时随机数,双方根据这个数再生成会话密钥。

0-RTT握手过程

    QUIC握手的过程是需要一次数据交互,0-RTT时延即可完成握手过程中的密钥协商,比TLS相比效率提高了5倍,且具有更高的安全性。

    QUIC在握手过程中使用Diffie-Hellman算法协商初始密钥,初始密钥依赖于服务器存储的一组配置参数,该参数会周期性的更新。

    初始密钥协商成功后,服务器会提供一个临时随机数,双方根据这个数再生成会话密钥。

    具体握手过程如下:

    (1) 客户端判断本地是否已有服务器的全部配置参数,如果有则直接跳转到(5),否则继续

    (2) 客户端向服务器发送inchoate client hello(CHLO)消息,请求服务器传输配置参数

    (3) 服务器收到CHLO,回复rejection(REJ)消息,其中包含服务器的部分配置参数

    (4) 客户端收到REJ,提取并存储服务器配置参数,跳回到(1)

    (5) 客户端向服务器发送full client hello消息,开始正式握手,消息中包括客户端选择的公开数。此时客户端根据获取的服务器配置参数和自己选择的公开数,可以计算出初始密钥。

    (6) 服务器收到full client hello,如果不同意连接就回复REJ,同(3);如果同意连接,根据客户端的公开数计算出初始密钥,回复server hello(SHLO)消息,SHLO用初始密钥加密,并且其中包含服务器选择的一个临时公开数。

    (7) 客户端收到服务器的回复,如果是REJ则情况同(4);如果是SHLO,则尝试用初始密钥解密,提取出临时公开数

    (8) 客户端和服务器根据临时公开数和初始密钥,各自基于SHA-256算法推导出会话密钥

    (9) 双方更换为使用会话密钥通信,初始密钥此时已无用,QUIC握手过程完毕。之后会话密钥更新的流程与以上过程类似,只是数据包中的某些字段略有不同。

QUIC包含三种报文包类型:

协商Package、公用复位package、普通帧信息Package

Version Negotiation Packets and Public Reset Packets, and regular packets containing frames.

如果客户端的版本不被服务器接受,则将导致1-RTT的延迟。服务器将发送一个版本协商包给客户端。这个包将设置版本标记,并将包含服务器支持的版本的集合。

当客户端从服务器收到一个版本协商包,它将选择一个可接受的协议版本并使用这个版本重发所有包。

为了避免流ID冲突,流 ID 必须是偶数,如果流是由服务器初始化的话,如果流由客户端初始化则必须为奇数。

0不是一个有效的流 ID。流 1 被保留用来加密握手,它应该是第一个客户端初始化的流。当基于QUIC使用HTTP/2时,

流 3 被保留来为其它流传输压缩的首部,以确保首部的处理和传送可靠且有序。

各种帧格式参考:QUICWireLayoutSpecification.pdf

官方参考地址:https://www.chromium.org/quic

转载自: https://github.com/y123456yz/reading-and-annotate-quic

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

推荐阅读更多精彩内容