接著就要來簡介一下關於 Connection Migration 之後有關擁塞控制的相關議題,擁塞控制在網路傳輸上也是一個非常重要的環節,今天會聚焦在 Connection Migration 之後擁塞控制的處理。
因為 QUIC 算是一個複雜的網路協定,所以關於 QUIC 的 Loss Detection 以及 Congestion Control 不是放在 RFC9000 中,而是另外一篇獨立的 RFC9002 QUIC Loss Detection and Congestion Control,有興趣想深入研究的讀者可以參考。
在經過連線遷移後,新的地址所在網路的網路頻寬不一定會跟之前的頻寬相同,所以 QUIC 規定不能把原本遷移前地址的擁塞控制狀態或者 RTT estimation 用於新的地址。
在確認對端遷移成功,並通過驗證後,Server 必須要立刻重置 congestion controller 的狀態,將 round-trip time estimator 設為初始值。例外狀況是今天遷移過去的地址跟源地址只有 port 不同,因為如果 address 沒有變只有 port 改變的話通常都是 NAT 或者其他中間設備的機制,這種情況實作方可以選擇將原先的狀態保留。
有關擁塞控制的實作,也算是 QUIC 的一個大賣點,因為是在 user space 的緣故,所以實作者可以封裝成動態調整的策略,比起以往 tcp 放在 kernel space 相比,要測試或者更改的難易度都降低了不少,RFC9000 在這個章節描述的處理方式也僅是建議,實作 lib 的人可以根據自己的需求調整。