QUIC (Quick UDP Internet Connection) 是最近 Google 想要推的一個新的網路規範, 顧名思義, 它的目的就是快！
Google 有這麼多聰明人, 取名字自然不含糊. QUIC 唸起來和 quick 相同, 可以很直接地聯想在一起. 其實, 就算是這個 protocol 沒有用到 UDP, 歷史上也沒有發明過 internet, 都還是可以兜出 QUIC = quick connection. 哈！
那麼 QUIC 快在哪裡呢？快在兼具 UDP (User Define Protocol) 的輕巧, 以及 TLS (Transport Layer Security) 的保護. UDP 的輕巧當然是相對於 TCP (Trasmission Control Protocol) 來的, 如果大部份都走 UDP, 當然傳輸速度就會增加, 讓我們複習一下.
| 協定 | 優點 | 缺點 |
| TCP | 可靠 | 慢 |
| UDP | 快 | 不保證收到 |
簡單地說, 可以把 QUIC 解釋為 TLS + TCP 的改良版, 並且是用 UDP 來實現. 當然, Google 不會傻到撞牆, 傳了一路 UDP 又另外傳一路 TCP, 而是把 TLS 和 TCP 的內容包裝到 UDP 裡面. 所以按照下圖, TLS + TCP 可以通, QUIC + UDP 也可以通. 那 SPDY 又是什麼呢？這個晚點再說, 先假裝沒看到. 基本上它已經變成了 HTTP2 的一部分.
那麼, Google 宣稱的快速 hand shake 又是如何做到的呢？根據 [2], client 會先送 inchoate client hello 給不認識的主機, 主機也不客氣地回 REJ. 由於這個 REJ 裡面會帶有 source address 和 server certificates 的資料, 所以並沒有白白被拒絕. 這時再送一次 client hello (CHLO), 應該就會對了, 後續可能就會收到 server hello (SHLO) .
或曰, 難道其他人都想不出有這招, 只有 Google 的人想得到? 當然不是這樣. 根據 TLS 的規格 – RFC5246 [3] 7.4.1.2, client hello 原本就要帶著一些資訊送給 server. 7.4.1.3 說 server hello 要回傳 client 看得懂的演算法, 或者傳 fail. 因此在現行規格下, server 可能根本不願意吐出資訊給冒冒失失的 client. Ref [2] 說: They may be several rounds of inchoate client hello before the client receives all the information that it needs because the server maybe unwilling to send a large proof of authenticity to an unvalidate IP address.
所以, 所謂的 0 round 或是 1 round hand shake 都是宣傳的噱頭. 這需要有夠傻的 server 願意配合才行. 一個捏造的 IP client 送一個小封包, server 就要大陣仗地把自己的認證資訊都吐出來, 這樣聽起來 server 很容易被攻擊耶. 除了這一步有風險之外, 後續的資料會受到 TLS 的保護. 根據 Ref [4], QUIC 整個 channel 都有加密.
根據 [5], 其實 QUIC 有考慮到被攻擊的事. 一個合法的 clinet 需要 proof of ownership of an address, proof of data received. 前者的精神是 server 會把一個值傳給 client, 看 client 是否可以回傳它. 後者的精神是, 通常網路攻擊就是 client 不理會 server 而瘋狂地送出 data. Quic 的相容性 SERVER 會檢查 client 到底有沒有消化過先前送出的資料. 做法是在某個特定的 bit 做 0/1 的隨機變換, client 要忠實地反映這個變化, 才算是真的 user, 而不是攻擊者.
QUIC 另外有幾個優點在於: 用錯誤更正碼 (Forward Error Correction) 代替 TCP 的重傳, 減少重傳的數量. 事實上, 網路很好的時候幾乎都不會重傳, 網路愈糟, 愈需要重傳, 形成一個惡性循環. 因此 QUIC 基於 UDP 可以理解. 但假如 QUIC 把 TCP 幹掉了, 以後網路上都是 QUIC, 等到頻寬吃完了, 不就互相排擠, 讓 packet 掉光光?
Well, QUIC 有兩招可以處理這個狀況 [5]. 他會送出 Congestion Feedback Frame. 這就像是網路頻寬金絲雀, 金絲雀死了, 就知道有問題了. 另外一招是測量 ack 的間距, 如果 sender 偷偷加速封包的傳送, round trip 的時間卻沒有拉大, 表示網路還很空, 還可以送快一點. 技術細節類似於 Linux 用的 cubic congestion algorithm.
[結語] Server 和 client 之間, 除了 internet 還有很多 router, switch, 如果全部更新是很大的商機吧！那某大網路 IC 設計公司會大漲嗎？哈！
[後記] 今天在 FB 上看到人家分享 QUIC 的文章, 重點倒也不是介紹技術, 而是捧 Google 的厲害. 雖然沒有寫什麼十三億人都驚呆了, 但是意思也差不多. 只講優點不講缺點之餘, 也沒有起到科普的作用, 只是打擊了一下工程師們脆弱的心靈而已. 台灣企業也努力過, 聯發科追過 Wimax 規格, 瑞昱試著訂 UWB 規格, 雖然都功虧好幾簣. 不過該做得還是可以再試一下, 也許有一天就成功了. 九陽豆漿機冠名贊助的真經上說過: “他驚由他驚, 大江閃星星, 他呆任他呆, 隨處有 WIFI." 在驚嘆之餘, 其實只要花一兩個小時就可以略跪門栓, 比一昧佩服人家然後驚呆來得好.
[ref]
1. TCP 與 UDP
Cash Chou's Blog 