前言

由於筆者沒有囤稿的關係，所以每日的主題都是當天想的，下次知道要乖乖先備一些稿子來用 今天的議題想跟大家討論一下 QUIC 被檢討過的缺點之一，前面都是說優點似乎有點過於偏頗，今天站在反面的角度來思考看看。

CPU 使用量

QUIC 的賣點之一就是實現在 user space 帶來極高的彈性，無論是更新或者修正錯誤都不需要更改 kernel 內容，但也帶來一些副作用。

其中一個為人詬病的就是 QUIC 的 CPU 開銷，在早期的一些研究顯示相較於實現在 kernel space 的 TCP，QUIC 在相同主機運行 Server 的開銷需要接近兩倍的 CPU 開銷，所以在性能全面提昇的同時，本身硬體的花費不容小覷。

這也讓 QUIC 的一個優點倍受質疑，很多人說 QUIC 在 IOT 的場景可以表現的很好，像是可以快速啟動連線的 0-RTT 或者在 user space 實現帶來的傳送可靠性也優於單純基於 UDP 的交換資料。 但邊緣的節點資源總是受限的，在切換的 QUIC 之前也要評估邊緣的運算能力是否能承受 QUIC 在 user space 實現帶來的 CPU 開銷。

有些人為了解決這個問題也提出是否能將 QUIC 實現在 kernel，但這樣不是又回到老路了嗎XD 捨棄 QUIC 的靈活性實現在 kernel space 也不一定能跑贏已經在 kernel 中經過無數優化的 TCP。

有關於 QUIC 的 CPU 開銷議題就在這邊簡單介紹一下，這類型的議題並沒有一定的對錯，讀者們也不妨思考一下你們心目中的理想解決方案。當然最好的解決方案就是花錢升級設備