Chromium QUIC逻辑

• 1 背景
• 2 正文
• • 2.1 针对某个ip:port的请求
  • 2.2 超时逻辑
  • 2.3 回滚逻辑
  • 2.4 30S的QUIC失败等待

1 背景

最近在使用Chromium的网络库Cronet，对其内部QUIC的使用逻辑做了一些总结。

2 正文

2.1 针对某个ip:port的请求

1. 第一次请求会根据TLS ALPN协议的协商结果以HTTP/1.1或者HTTP/2发起，分析HTTP响应携带的“alt-svc”头，将该ip:port、QUIC端口、ma(max alive，也就是ttl)、服务端支持的QUIC版本等信息记录到本地支持QUIC的服务列表中；
2. 第二次请求可能仍然会以HTTP/1.1或者HTTP/2发起，但是同时建立一个quic_connection，并触发QUIC的握手、协商，如果成功，则在连接池中缓存该quic_connection，并且Chromium会自动评估是否使用QUIC替换HTTP来请求本次数据；
3. 后续该域名的所有请求将使用该quic_connection，以QUIC协议传输数据。

2.2 超时逻辑

有两个基本的超时时间：

1. 握手超时，代表连接发起、握手的超时时间，默认10S；
2. 空闲超时，代表长时间没有数据传输quic_connection回收的超时时间，协商成功前5S，协商成功后30S。

2.3 回滚逻辑

1. 一个还未协商成功的quic_connection并不会被使用；
2. 一个已经协商成功的quic_connection，如果在一次HTTP请求之前UDP被Block，那么在等待空闲超时后，QUIC的数据请求失败，会自动回滚到HTTP(1/2)，一旦回滚到HTTP，这个连接将被标记(UDP不可用)，不再使用QUIC；
3. 如果在QUIC数据传输的过程中，UDP被Block，那么在等待空闲超时后，QUIC的数据请求失败，不会被回滚到HTTP，但是下次请求仍然会尝试使用QUIC，因为UDP有可能可用。

2.4 30S的QUIC失败等待

对一次HTTP请求来说，30S是一个漫长的等待，可以考虑将时间改短，付出的代价是quic_connection缓存时间变短，有可能不得不频繁创建新的quic_connection，进行新的握手、协商。