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，進行新的握手、協商。