iT邦幫忙

2022 iThome 鐵人賽

DAY 20
0
Modern Web

快還要更快,讀作 quick 的下一代傳輸層協定: QUIC系列 第 20

【Day 20】Connection Migration(五): 遷移後的擁塞控制

  • 分享至 

  • xImage
  •  

前言

接著就要來簡介一下關於 Connection Migration 之後有關擁塞控制的相關議題,擁塞控制在網路傳輸上也是一個非常重要的環節,今天會聚焦在 Connection Migration 之後擁塞控制的處理。

因為 QUIC 算是一個複雜的網路協定,所以關於 QUIC 的 Loss Detection 以及 Congestion Control 不是放在 RFC9000 中,而是另外一篇獨立的 RFC9002 QUIC Loss Detection and Congestion Control,有興趣想深入研究的讀者可以參考。

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 的人可以根據自己的需求調整。

reference


上一篇
【Day 19】Connection Migration(四): 可能會出現的安全問題
下一篇
【Day 21】Connection Migration(六): 連線遷移的隱私相關議題
系列文
快還要更快,讀作 quick 的下一代傳輸層協定: QUIC23
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言