quic
，即quick udp internet connection，類似於spdy
，相同也是由google公司在現有已存協議之上進行了擴充套件設計，而旨在降低網路延遲。之前我曾介紹過spdy的相關資訊，spdy工作在應用層，而這裡的quic工作在傳輸層。儘管quic的名字暗示著它類似於乙個被改動過的udp協議，但它的目標卻是優化或替換那些須要使用面向鏈結的應用程式中所採用的tcp協議。
由於光速不變，並且拋開網路繁忙這些額外總體因素（由於我們這裡考慮的是區域性，要做的目標也是區域性優化，因此總體因素屬於更上一層的研究），那麼在網路上，隨意確定兩端之間的往返時延rtts（round trip times）基本上是固定的，因此，降低單個連線網路延遲的唯一辦法就是讓建立一條連線所需耗費的rtts個數盡量的少。從這個需求能夠看出，對於tcp協議本身而言，已經非常難做到相應的優化了，一方面是由於tcp所要求的握手協議、擁塞控制等固定了其所必須的rtts個數，而還有一方面是由於tcp實現於作業系統協議棧內，要改變實際使用者的作業系統必然是相當難的。
quic嘗試解決那些spdy無法涵蓋的問題點。首先是tcp對頭堵塞，其次是tcp擁塞閥門堵塞，也就是這兩個點導致的spdy優勢無法充分發揮。這非常好理解，我們知道spdy是跑在tcp協議之上的，假設瓶頸在tcp這一層，那麼上層做再多的優化都是白搭。
另外，spdy採用的ssl/tls也會帶來兩個效能問題：1，恢復已斷的開會話將引進乙個額外的握手，而這純粹僅僅是ssl/tls協議的設計如此，並不是安全或其它什麼特別的原因。2，對歷史資料報的解決須要按順序進行，這將導致延遲資料報所帶來的延遲影響更大。因此，quic一開始就被設計有類似於tls加密這種功能，從而避免對ssl/tls的使用，降低相應的開銷。
在此之前，googleproject師已經針對這些詳細問題提出了一些解決方式。比方tcp fast open（tfo）可用於降低連線到曾經已經訪問過的同樣server的rtts。quic揉合了這些舊解決方式，以及一些新的方案，用於重點解決乙個應用場景，即從同一臺server，利用攜帶多個資料流的tls加密連線資料傳輸的web應用程式服務。
簡單來看，quic的目標是在udp協議之上提供一種可建立面向鏈結的服務。嗯，聽上去不錯，儘管我對詳細細節也是茫然不清，但貌似看懂了它的意思是想針對詳細的場景，結合傳統tcp和udp協議兩者各自的長處，合二為一。
或
QUIC簡單介紹
quic 即quick udp internet connection，類似於spdy 相同也是由google公司在現有已存協議之上進行了擴充套件設計，而旨在降低網路延遲。之前我曾介紹過spdy的相關資訊，spdy工作在應用層，而這裡的quic工作在傳輸層。儘管quic的名字暗示著它類似於乙個被改動...
QUIC協議文件翻譯 什麼是QUIC
quic是乙個谷歌提出的新的網際網路協議。quic解決出現在現在網路協議的一些傳輸層和應用層的問題，而且幾乎不需要應用更改。quic和tcp tls http2十分相似，但是基於udp實現。使用quic作為乙個獨立的協議可以做到一些別的協議做不到的創新，因為它們受到傳統客戶端和中介軟體的阻礙。和tc...
QUIC包頭保護
quic使用秘鑰 過段時間更換一次 對應用資料加密後，需要單獨對包頭加密。長報頭加密字段 1 1 t t e e e e version length fields 短報頭加密字段 0 1 s e e e e e destination connection id 0 32 144 普通字段 e e...