隨著 RFC 9114 HTTP/3 規範的正式推出,其底層所使用的傳輸層協定 QUIC 又更進一步的受到大家的矚目。從 HTTP/1.0 開始,到 HTTP/2,不論應用層協定如何改進,傳輸層都是採用 TCP。 TCP 在網路發展的過程中也有很多人討論它的缺點,但因為很多歷史共業導致大幅更新 TCP 協定是很不切實際的,所以想要解決 TCP 諸多問題的唯一去路,就是放棄 TCP 協定,轉而發展新的傳輸層協定 QUIC。
本系列文章會著重於 QUIC 協定的原理以及實現,以及 QUIC 較之前的 TCP + TLS 套餐改進了什麼地方,在設計上做了什麼取捨。
前言 在經過昨天的反思後,今後討論的方向還是會先著重在協定交互的行為,至於封包觀察可以等後續如果在寫程式做實驗的時候,方便拿來觀察程式的運作有沒有符合預期。 今...
前言 在前一天的文章介紹了 Handshake 流程中協商 Connection ID 的過程,但是 Connection ID 是放在 Header 中以明碼...
前言 今天要探討關於 QUIC 的地址驗證(Address Validation) 機制,這個機制主要是要防止一些流量放大攻擊(traffic amplific...
前言 前一天的最後提到了 Server 如果希望在正式建立連線之前驗證 Client 的地址,可以透過傳送 token 來實現,今天就來探討一下關於 token...
前言 前面花了不少篇幅介紹關於 Connection ID 的議題,今天要來說明 Connection ID 真正的用處 - Connection Migrat...
前言 昨天的介紹中我們提到了 QUIC 另一個很重要的機制 - Connection Migration, 也延伸出了 Connection ID 的用途,QU...
前言 前一天的文章中介紹了關於 Path Validation 相關的流程,今天的文章會簡介 Path Validation 與 Connection Migr...
前言 昨天我們講解了 Connection Migration 的概念,今天就來帶著讀者簡單看一下對應的 Source code 實現在哪個 function,...
前言 前幾天的文章中大致講解了 Connection Migration 的流程,也知道一些它依賴的特性是怎麼交互的,今天我們會來簡單看一下 RFC 中所提到關...
前言 接著就要來簡介一下關於 Connection Migration 之後有關擁塞控制的相關議題,擁塞控制在網路傳輸上也是一個非常重要的環節,今天會聚焦在 C...