quic協議是基於udp封住的乙個協議
quic 在自己的邏輯裡面維護連線的機制，以乙個 64 位的隨機數作為 id 來標識，而且 udp 是無連線的，所以當 ip 或者埠變化 的時候，只要 id 不變，就不需要重新建立連線。
quic 也有個序列號，是遞增的。
任何乙個序列號的包只傳送一次，下次就要加一了。例如，傳送乙個 包，序號是 100，發現沒有返回;再次傳送的時候，序號就是 101 了;如果返回的 ack 100，就是對第 乙個包的響應。如果返回 ack 101 就是對第二個包的響應，rtt 計算相對準確。
quic 定義了乙個 offset 概念。
quic 既然是面向連線的，也就像 tcp 一樣，是乙個資料流，傳送的資料在這個資料流裡面有個 偏移量 offset，可以通過 offset 檢視資料傳送到了**，這樣只要這個 offset 的包沒有來，就要重發; 如果來了，按照 offset 拼接，還是能夠拼成乙個流。
同 http 2.0 一樣，同一條 quic 連線上可以建立多個 stream，來傳送多個 http 請求。但quic 是基於 udp 的，乙個連線上的多個 stream 之間沒有依賴。這樣，假如 stream2 丟了乙個 udp 包，後 面跟著 stream3 的乙個 udp 包，雖然 stream2 的那個包需要重傳，但是 stream3 的包無需等待，就 可以發給使用者。
quic 的流量控制也是通過 window_update，來告訴對端它可 以接受的位元組數。
但是 quic 的視窗是適應自己的多路復用機制的，不但在乙個連線上控制視窗，還在 乙個連線中的每個 steam 控制視窗。
還記得嗎?在 tcp 協議中，接收端的視窗的起始點是下乙個要接收並且 ack 的包，即便後來的包都到 了，放在快取裡面，視窗也不能右移，因為 tcp 的 ack 機制是基於序列號的累計應答，一旦 ack 了一 個系列號，就說明前面的都到了，所以只要前面的沒到，後面的到了也不能 ack，就會導致後面的到 了，也有可能超時重傳，浪費頻寬。
quic 的 ack 是基於 offset 的，每個 offset 的包來了，進了快取，就可以應答，應答後就不會重發， 中間的空擋會等待到來或者重發即可，而視窗的起始位置為當前收到的最大 offset，從這個 offset 到當 前的 stream 所能容納的最大快取，是真正的視窗大小。顯然，這樣更加準確。
可靠的UDP協議 QUIC協議
quic是一種新的傳輸 方式，與tcp相比可以減少延遲。表面上，quic與在udp上實現 的tcp tls http 2非常相似。由於tcp是在作業系統核心和中介軟體韌體中實現的，所以對tcp進行重大改變幾乎是不可能的。但是，由於quic是建立在udp之上的，所以沒有這樣的限制。quic相比於上述介...
linux下的tcp協議棧超時重傳機制
tcp協議有個超時重傳機制，想必大家都比較熟悉。tcp協議是一種傳輸可靠的協議，因此這個機制是必不可少的。那麼今天要 的是在傳送佇列還有資料的情況下，網路連線異常斷開後，協議棧是到底是怎樣來處理這些資料的，資源又是怎樣被 的呢？我這裡先給出幾個測試的結果 1 修改linux系統下的tcp retri...
關於TCP重傳 亂序和重複的問題
tcp是一種巨複雜的協議，本篇文章旨在簡單說明一些資料傳輸過程中常見的問題，對於涉及的演算法目前並不會詳細闡述 主要是個人能力原因 tcp提供兩種重傳的機制，一種是基於時間的超時重傳，一種是基於接收端反饋訊息的快速重傳。相比之下前者占用更少的網路頻寬，但是效率很低。而後者則相反。下面我們來具體看一下...