前言

隨著 RFC 9114 HTTP/3 規範的正式推出，其底層所使用的傳輸層協定 QUIC 又更進一步的受到大家的矚目。從 HTTP/1.0 開始，到 HTTP/2，不論應用層協定如何改進，傳輸層都是採用 TCP。 TCP 在網路發展的過程中也有很多人討論它的缺點，但因為很多歷史共業導致大幅更新 TCP 協定是很不切實際的，所以想要解決 TCP 諸多問題的唯一去路，就是放棄 TCP 協定，轉而發展新的傳輸層協定 QUIC。

本系列文章會著重於 QUIC 協定的原理以及實現，以及 QUIC 較之前的 TCP + TLS 套餐改進了什麼地方，在設計上做了什麼取捨。

預備知識

• 基礎的計算機網路知識
• c 語言基礎

議題規劃

在討論一個技術之前，我們應該重視的是之前的解決方案存在著什麼問題，為了解決它才發展出新的技術，所以在一開始本文會介紹為什麼要發展 QUIC，傳統的解決方案有什麼瓶頸存在，會整理出幾個關鍵的因素，然後會一併介紹這些問題在 QUIC 中是否被解決了，或者因為設計的取捨需要額外的操作才能補足。

文章中期本文會慢慢帶入一些實作的 code，因為如果只講觀念的話有些地方還是會不清楚具體的實現，有了概念之後看 code 可以對整個 QUIC 的流程有更好的理解。除了具體的實作，也會用一些範例來觀察 QUIC 協定是怎麼運作的。

文末將探討 QUIC 目前的一些適用場景，有哪些專案已經導入或者正在考慮轉成 QUIC 協定，當然一個新的技術不可能是完美的，也有一些人提出 QUIC 協定的一些隱患或者缺點，在結尾我們也會一一提出，不過這類型問題都比較屬於開放式的討論，並沒有絕對的是非之分，有些時候只是工程上的取捨。

初步規劃是這樣，但會視情況加一點動手實作的部份，但主軸都會聚焦在 RFC 的概念與具體程式邏輯的連結上。

參賽動機

筆者只是一個在苦思論文題目卻一直生不出來的菸酒生QQ，主要寫這系列文章是在尋找題目的時候順便紀錄自己的研究過程，希望積點陰德讓論文順利生出來。自己在讀 RFC 規範的時候發現讀起來異常的抽象，可能是因為自己沒有真的實作過網路協定的關係，總覺得讀 RFC 到轉成具體的程式邏輯之間有著非常大的差距，所以想試著寫寫看一邊配合 RFC 的介紹一邊看 code 實作，希望這樣可以幫助到大家認識這個後起之秀，當然筆者也是一邊看一邊學，第一次參加鐵人賽這次幾乎沒有囤稿，希望可以撐過30天的考驗XD，也請大家多包含了。

文章中難免會出現一些錯誤，希望各位前輩們多多指教，發現有寫錯的地方都歡迎寄信討論，希望大家可以多給我一點建議!