HTTP3.0(QUIC的實現機制)

回顧HTTP2.0

HTTP1.1在應用層以純文本的形式進行通訊，每次通訊都要帶完整的HTTP的頭，並且不考慮pipeli模式的化，每次的過程老是像上面描述的那樣一去一回。那樣在實時性、併發想上都存在問題

頭部壓縮：HTTP2.0會對HTTP的頭進行必定的壓縮，將原來每次都要攜帶的大量key value在兩端創建一個索引表，對相同的頭只發送索引表中的索引

HTTP2.0協議將一個TCP的鏈接中，切分紅多個流。每一個流都有本身的ID，並且流能夠是客戶端發服務端，也能夠是服務端發客戶端，它其實只是一個虛擬的通道。流是有優先級的

HTTP2.0還將全部的傳輸信息分割爲更小的信息和幀，並對它們採用二進制格式編碼。常見的幀有Header幀，用於傳輸Header內容，而且會開啓一個新的流，再就是Data幀，用來傳輸正文實體。多個Data幀屬於一個流

經過這兩種機制，http2.0的客戶端能夠將對個請求不一樣的流中，而後將請求內容拆成幀，進行二進制傳輸。這些真能夠打散亂序發送，而後根據每一個幀首部的流標識符從新組裝，而且能夠根據優先級，決定先處理那個流的數據

二進制傳輸就是以上

例子：

假設一個頁面要發送三個獨立的請求，一個獲取css，一個獲取js，一個獲取圖片jpg。若是使用HTTP1.1就是串行的，可是若是使用HTTP2.0，就能夠在一個鏈接裏，客戶端和服務端均可以同時發送多個請求或迴應，並且不用按照順序一對一對應

http2.0成功解決了http1.1的隊首阻塞問題，同時，也不須要經過http1.x的pipeline機制用多條tcp鏈接來實現並行請求和響應；減小了tcp鏈接數對服務器性能的影響，同時將頁面的多個數據css，js，jpg等經過一個數據連接進行傳輸，可以加快頁面組件的傳輸速度。

QUIC協議

HTTP2.0 也是基於TCP協議的，tcp協議在處理包時是有嚴格順序的

當其中一個數據包遇到問題，TCP鏈接須要等待找個包完成重傳以後才能繼續進行，雖然HTTP2.0經過多個stream，使得邏輯上一個tcp鏈接上的並行內容，進行多路數據的傳輸，然而這中間沒有關聯的數據，一前一後，前面stream2的幀沒有收到，後面stream1的幀也會所以堵塞

因而google的 QUIC協議從TCP切換到UDP

• 機制一：自定義鏈接機制
  一條tcp鏈接是由四元組標識的，分別是源ip、源端口、目的端口，一旦一個元素髮生變化時，就會斷開重連，從新鏈接。在次進行三次握手，致使必定的延時

在TCP是沒有辦法的，可是基於UDP，就能夠在QUIC本身的邏輯裏面維護鏈接的機制，再也不以四元組標識，而是以一個64
位的隨機數做爲ID來標識，並且UDP是無鏈接的，因此當ip或者端口變化的時候，只要ID不變，就不須要從新創建鏈接

• 機制二：自定義重傳機制
  tcp爲了保證可靠性，經過使用序號和應答機制，來解決順序問題和丟包問題

任何一個序號的包發過去，都要在必定的時間內獲得應答，不然一旦超時，就會重發這個序號的包，經過自適應重傳算法（經過採樣往返時間RTT不斷調整）

可是，在TCP裏面超時的採樣存在不許確的問題。例如發送一個包，序號100，發現沒有返回，因而在發送一個100，過一陣返回ACK101.客戶端收到了，可是往返的時間是多少，無法計算。是ACK到達的時候減去第一仍是第二。

QUIC也有個序列號，是遞增的，任何宇哥序列號的包只發送一次，下次就要加1，那樣就計算能夠準確了

可是有一個問題，就是怎麼知道包100和包101發送的是一樣的內容呢？quic定義了一個offset概念。QUIC既然是面向鏈接的，也就像TCP同樣，是一個數據流，發送的數據在這個數據流裏面有個偏移量offset，能夠經過offset查看數據發送到了那裏，這樣只有這個offset的包沒有來，就要重發。若是來了，按照offset拼接，仍是可以拼成一個流。

• 機制三： 無阻塞的多路複用

有了自定義的鏈接和重傳機制，就能夠解決上面HTTP2.0的多路複用問題

同HTTP2.0同樣，同一條 QUIC鏈接上能夠建立多個stream，來發送多個HTTP請求，可是，QUIC是基於UDP的，一個鏈接上的多個stream之間沒有依賴。這樣，假如stream2丟了一個UDP包，後面跟着stream3的一個UDP包，雖然stream2的那個包須要從新傳，可是stream3的包無需等待，就能夠發給用戶。

• 機制四：自定義流量控制

TCP的流量控制是經過滑動窗口協議。QUIC的流量控制也是經過window_update，來告訴對端它能夠接受的字節數。可是QUIC的窗口是適應本身的多路複用機制的，不但在一個鏈接上控制窗口，還在一個鏈接中的每一個steam控制窗口。

在TCP協議中，接收端的窗口的起始點是下一個要接收而且ACK的包，即使後來的包都到了，放在緩存裏面，窗口也不能右移，由於TCP的ACK機制是基於序列號的累計應答，一旦ACK了一個序列號，就說明前面的都到了，因此是要前面的沒到，後面的到了也不能ACK,就會致使後面的到了，也有可能超時重傳，浪費帶寬

QUIC的ACK是基於offset的，每一個offset的包來了，進了緩存，就能夠應答，應答後就不會重發，中間的空檔會等待到來或者重發，而窗口的起始位置爲當前收到的最大offset，從這個offset到當前的stream所能容納的最大緩存，是真正的窗口的大小，顯然，那樣更加準確。