quic（quick udp internet connections）協定是一種全新的基于udp的web開發協定。
從tcp協定說起
目前，web平台的資料傳輸都基于tcp協定。tcp協定在建立連接配接之前需要進行三次握手（圖1），如果需要提高資料互動的安全性，既增加傳輸層安全協定（tls），還會增加更多的握手次數（圖2）。
圖1，tcp三次握手示意（來源 next generation multiplexed transport over udp (pdf)）
https://yqfile.alicdn.com/e479b4e04aabd13671dc5560f61a60bc1d669f62.png
" >
圖2，tls初始化握手示意（來源 next generation multiplexed transport over udp (pdf)）
正因為tcp協定連接配接建立的成本相對較高，可以通過tcp快速打開（tcp fast open）來減少建立連接配接時的握手次數。但是該技術目前應用較少。
和tcp相反，udp協定是無連接配接協定。用戶端發出udp資料包後，隻能“假設”這個資料包已經被服務端接收。這樣的好處是在網絡傳輸層無需對資料包進行确認，但存在的問題就是為了確定資料傳輸的可靠性，應用層協定需要自己完成包傳輸情況的确認。
此時，quic協定就登場了。quic協定可以在1到2個資料包（取決于連接配接的伺服器是新的還是已知的）内，完成連接配接的建立（包括tls）（圖3）。
圖3，quic協定握手示意（來源 next generation multiplexed transport over udp (pdf)）
quic協定的目的
從前文對比可以看出，quic協定的主要目的，是為了整合tcp協定的可靠性和udp協定的速度和效率。
quic的維基百科頁面介紹了該協定的主要目的：
對于google來說優化tcp協定是一個長期目标，quic旨在建立幾乎等同于tcp的獨立連接配接，但有着低延遲，并對類似spdy的多路複用流協定有更好的支援。 如果quic協定的特性被證明是有效的，這些特性以後可能會被遷移入後續版本的tcp和tls協定（它們都有很長的開發周期）。
值得注意的是，如果quic的特性被證明是有效的，這些特性以後可能會被遷移到後續版本的tcp協定中。
tcp協定的實作是高度管制的。tcp協定棧通常由作業系統實作，如linux、windows核心或者其他移動裝置作業系統。修改tcp協定是一項浩大的工程，因為每種裝置、系統的實作都需要更新。
相反的，udp協定在作業系統層面實作相對簡單，基于udp協定實作新的協定以驗證google對于tcp協定改進的理論，驗證成本相對較低。
quic協定内置了tls棧，實作了自己的傳輸加密層，而沒有使用現有的tls 1.2。同時quic還包含了部分http/2的實作，是以quic的地位看起來是這樣的：
從圖上可以看出，quic底層通過udp協定替代了tcp，上層隻需要一層用于和遠端伺服器互動的http/2 api。這是因為quic協定已經包含了多路複用和連接配接管理，http api隻需要完成http協定的解析即可。
quic特性
避免前序包阻塞
spdy和http/2協定現在都支援将頁面的多個資料（如圖檔、js等）通過一個資料連結進行傳輸。該特性能夠加快頁面元件的傳輸速度，但是對于tcp協定來說，這會遇到前序包阻塞的問題。這是由于tcp協定在處理包時是有嚴格順序的，當其中一個資料包遇到問題，tcp連接配接需要等待這個包完成重傳之後才能繼續進行。是以，即使邏輯上一個tcp連接配接上并行的在進行多路資料傳輸，其他毫無關聯的資料也會是以阻塞。
quic協定直接通過底層使用udp協定天然的避免了該問題。由于udp協定沒有嚴格的順序，當一個資料包遇到問題需要重傳時，隻會影響該資料包對應的資源，其他獨立的資源（如其他css、js檔案）不會受到影響。
減少資料包
前文已經介紹過quic協定在建立連接配接握手時，隻需要1到2個資料包即可。這對于擁有高速網際網路連接配接的網絡環境下可能沒有太大的感覺，因為此時一個資料包的延時大概在10～50ms之間。
一般來說延遲在50ms之内不會有太大的感覺。但是對于無線網絡來說，情況就不太一樣了。且不說傳統2g/3g網絡，即使是4g網絡，用戶端和伺服器之間的延時也通常在100ms以上。傳統tcp+tls協定的傳輸方式，在建立連接配接時的4個資料包和quic協定的1個資料包相比，連接配接建立上就會多耗時300ms以上。
向前糾錯
quic協定有一個非常獨特的特性，稱為向前糾錯（forward error correction），每個資料包除了它本身的内容之外，還包括了部分其他資料包的資料，是以少量的丢包可以通過其他包的備援資料直接組裝而無需重傳。
這類似網絡層的raid 5！
目前預設的備援量是10%，既每發送10個資料包，其備援資料就可以重新建構一個丢失的資料包。
向前糾錯犧牲了每個資料包可以發送資料的上限，但是減少了因為丢包導緻的資料重傳，因為資料重傳将會消耗更多的時間（包括确認資料包丢失、請求重傳、等待新資料包等步驟的時間消耗）。
會話重新開機和并行下載下傳
底層協定切換到udp協定之後的另一大好處是，連接配接不再依賴于來源ip。
對于tcp協定來說，辨別一個tcp連接配接需要4個參數，既來源ip、來源端口、目的ip和目的端口。其中的任一參數改變，tcp連接配接就需要重新建立。
這對于傳統網絡來說影響不大，因為來源和目的ip相對固定。但是在無線網絡中，情況就大不相同了。裝置在移動過程中，可能會因為網絡切換（如從wifi網絡切換到4g網絡環境），導緻tcp連接配接需要重新建立。
quic協定使用了udp協定，不再需要這四元組參數。同時quic協定實作了自己的會話标記方式，稱為連接配接uuid。當裝置網絡環境切換時，連接配接uuid不會發生變化，是以無需重新進行握手。
該特性除了可以減少無謂的連接配接重連之外，還可以充分利用裝置的不同網絡接口，進行資源的并行下載下傳。因為雖然這些網絡接口有不同的ip，但隻要他們能夠共享連接配接uuid，就能夠并行的從伺服器下載下傳資料。
quic協定實踐
chrome浏覽器從2014年開始已經實驗性的支援了quic協定。可以通過在chrome浏覽器中輸入chrome://net-internals/#quic檢視是否已經支援quic協定。如果還未支援，可以在chrome://flags/#enable-quic中進行開啟。
開始chrome浏覽器對quic協定的支援之後，可以在chrome://net-internals/#quic中檢視到目前浏覽器的quic一些連接配接。當然目前隻有google服務才支援quic協定（如youtube、 google.com）。
(點選放大圖像)
關于防火牆
通常系統管理者會關注防火牆的tcp規則，而忽略udp規則。如果要在防火牆之後使用quic協定，除了傳統web服務需要開放的80/tcp、443/tcp之外，針對quic還需要開放443/udp的通路。
服務端使用quic協定
目前支援quic協定的web服務隻有0.9版本以後的caddy。其他常用web服務如nginx、apache等都未開始支援。curl表達了對quic協定支援的興趣。
quic性能優勢
在2015年的博文中，google分享了一些關于quic協定實作的結果。
這些優勢在諸如youtube的視訊服務上更為突出。使用者報告通過quic協定在觀看視訊的時候可以減少30%的重新緩沖時間。
如果youtube收集的報告可靠，可以預見視訊服務提供商會更快的采用quic協定。
總結
quic協定開創性的使用了udp協定作為底層傳輸協定，通過各種方式減少了網絡延遲。
目前quic協定已經在運作在最大的網站上，期待quic協定規範能夠成為終稿，并在其他浏覽器和伺服器中能夠實作。