QUIC已被廣泛部署和使用，可提供更低的延遲、更高的安全性和更強大的數據交付。
文 / LiveVideoStack
IETF近期發布了QUIC RFC 9000，並由RFC 9001、RFC 9002和RFC 8999支持（其中，RFC8999定義了QUIC協議版本無關的規范，RFC9001定義了QUIC與TLS的協議映射、RFC9002定義了QUIC協議的丟失恢復與擁塞控制）。這意味着QUIC Version 1已經正式標准化，並且QUIC部署將從使用臨時草案版本轉向新創建的Version 1。與此同時，有最新消息指出QUIC Version 1以一種新的互聯網傳輸技術作為標准發布，可提高Web應用程序的性能、安全性和隱私性。據悉，IETF也將很快發布HTTP/3，這也將是第一個設計用於QUIC的應用程序協議。
隨着QUIC標准化版本的宣布，目前Facebook、Akamai、Microsoft、Cloudflare、Ericsson、F5、Fastly和Google都已部署了QUIC和HTTP/3。
回顧QUIC的演進歷程，它最初由Google的Jim Roskind設計。2012年實現部署，2013年隨着實驗范圍的擴大而公開發布，並於2016年提交給IETF作為標准化的考量，開始了QUIC的標准化過程。QUIC名字的由來最初是根據“快速UDP互聯網連接”（即Quick UDP Internet Connection）的首字母縮寫提出的，而IETF使用的QUIC一詞並不是首字母的縮寫，它只是作為協議的名稱。
在IETF對QUIC進行標准化的過程中，也有眾多公司對其采取進一步的自研工作以優化自身的網絡傳輸，如：騰訊雲（QUIC-Supermind）、阿里巴巴淘系技術架構團隊（XQUIC）、快手（KQUIC）等。
Technician Comments
對於QUIC的此次標准化版本的發布，業內的老師也有着不同的看法：
嗶哩嗶哩/高級工程師 - 王盛：“標准化版本其實挺完善了，希望繼續加快qlog和spinbit自旋位規范的標准化。 ”
阿里巴巴淘系技術部/高級技術專家 - 劉彥梅（喵吉）：“ IETF QUIC經過4年多的時間終於定稿第一版。可以看到在制定QUIC標准過程中，標准化工作組做了很多設計機制上的改進，包括像CID的協商和更新機制、long / short header packet設計、連接遷移、丟包檢測和重傳恢復機制，以及HTTP/3和QPACK頭部壓縮算法的設計等，這些都使得協議的靈活性和擴展性得到很大提升。
QUIC標准化版本的發布，會使得這項技術在行業的推廣更容易得到認可，並使得更多互聯網用戶從中獲益。過去在可靠傳輸場景，IETF QUIC已經證明了它相對於TCP能夠帶來的體驗提升；同時標准化工作組還有一篇非可靠傳輸Datagram擴展草案，相信對於音視頻場景的傳輸協議演進，也會起到進一步的推進作用。”
編輯：Teresa Li
關於QUIC RFC9000的更多信息：
https://www.rfc-editor.org/rfc/rfc9000.html