1. http2.0，或許是一個過渡協議
a. 它兼容1.1版本，2015年左右發布，目前部分知名網站已經開始使用，它依然基於TCP協議，主要focus on performance。
b. 很多請求都是頭部很多內容，實際傳輸的內容很少，所以http2.0做了頭部壓縮。不過 HTTP/2 並沒有使用傳統的壓縮算法，而是開發了專門的“HPACK”算法，“HPACK”算法是專門為壓縮 HTTP 頭部定制的算法，與 gzip、zlib 等壓縮算法不同，它是一個“有狀態”的算法，需要客戶端和服務器各自維護一份“索引表”，也可以說是字典，壓縮和解壓縮就是查表和更新表的操作
- 這里注意http2中沒有請求/響應行的概念了，都抽象為虛擬頭，與其他頭部一起放到索引表中管理。常見的頭放到靜態表中，新增的頭，放到動態表中。
- 大致原理是，第一次發送請求時的“user-agent”字段長是一百多個字節，用哈夫曼（第一次這個內容還是全量的，所以需要哈夫曼編碼壓縮）壓縮編碼發送之后，客戶端和服務器都更新自己的動態表，添加一個新的索引號“65”。那么下一次發送的時候就不用再重復發那么多字節了，只要用一個字節發送編號就好。
c. 二進制方式傳輸，（注意這里並沒有加密），它把 TCP 協議的部分特性挪到了應用層，把原來的“Header+Body”的消息“打散”為數個小片的二進制“幀”（Frame），用“HEADERS”幀存放頭數據、“DATA”幀存放實體數據。
d. 虛擬流的概念
- HTTP/2 為此定義了一個“流”（Stream）的概念，它是二進制幀亂序的雙向傳輸序列，同一個消息往返的幀會分配一個唯一的流 ID。多個請求對應多個流ID，從而實現多路復用的目的，所以server不需要保持多個TCP鏈接，server端響應能力更好，以前需要為每一個客戶端維持6個TCP的狀態信息，現在只需要一個即可。
- 流還可以設置優先級，比如有些關鍵資源（js，css）可以優先發送
- HTTP/2 還在一定程度上改變了傳統的“請求 - 應答”工作模式，服務器不再是完全被動地響應請求，也可以新建“流”主動向客戶端發送消息，一定程度的雙工。
- 多個請求對應多個流ID，不在是以前的串行發送了，可以一起發送，某個流的數據包全部收到了之后，就可以組裝給上層應用使用了。某個流的數據被卡住或者丟包重串，不影響其他流，這就在應用層解決了對頭阻塞的問題（注意這里TCP的阻塞依然存在）
e. 2015年發布http2的時候，TLS1.3還沒有發布，所以只要求使用使用TLS1.2以上的協議，默認比1.1要求的更高，默認需要使用https加密傳輸。
注意：
http1.1里面的一些優化手段，對於2.0來說，可能起到反作用。比如合並js，css，雪碧圖等。因為過大的文件，容易導致緩存失效，其中一個單元修改了，整個緩存就得重新獲取。
更多的TCP連接，也對server端不友好，更小的資料，往往會很快會被使用，更快地給UI呈現。
2. Http3.0，真正的下一代可靠的高速應用層通信技術
a. http2中始終在使用TCP協議，所以無論如何都還是會有tcp傳輸層的對頭阻塞問題，而http3徹底解決對頭阻塞的問題，正式版本還沒有發布。
- 讓我們從協議棧的角度來仔細看一下。在 HTTP/2 把多個“請求 - 響應”分解成流，交給 TCP 后，TCP 會再拆成更小的包依次發送（其實在 TCP 里應該叫 segment，也就是“段”）。在網絡良好的情況下，包可以很快送達目的地。但如果網絡質量比較差，像手機上網的時候，就有可能會丟包。而 TCP 為了保證可靠傳輸，有個特別的“丟包重傳”機制，丟失的包必須要等待重新傳輸確認，其他的包即使已經收到了，也只能放在緩沖區里，上層的應用拿不出來，只能“干着急”。比如這個流有3個包，現在收到了2個包，還有一個包沒有收到，就會一直等，超時后還會要求重傳。
- 在比如，這里有2個請求，就會有2個stream，我們假定他們編號是stream1，stream2，然后stream1被TCP拆分為p1-1，p1-2，p1-3，共3個包，stream2被TCP拆分出p2-1，p2-2 兩個包。流拆包時可能時亂順（可能會有優先級）給TCP傳輸的，比如p1-1，p1-2，p2-1，p1-3，p2-2的順序。這樣假如網絡不好在傳p1-3時候，一直沒有收到確認收到的ACK消息，就會一直等，可能等到超時重傳p1-3，這樣p2-2就一直不能傳輸，而p2-1就只能呆在緩存區靜靜的等待，就導致了阻塞。
b. 所以google又（google在web協議發展中，總是領先推出一些協議，成為既定事實后，再由標准化組織給他正名，寫入RFC）重新推了QUIC協議，徹底放棄使用TCP協議，而使用基於UDP的QUIC協議。
c. UDP協議不需要3次握手和4次揮手，所以天然比TCP協議快。
d. 同時2018年TLS1.3版本發布，可以獲取更好的加密性能。QUIC 內含了 TLS1.3，只能加密通信，支持 0-RTT 快速建連；
e. QUIC協議自定義了連接機制，在IP地址發送變化，只要雙方的通信Id沒變，就會保持連接，特別適合移動互聯網容易斷網切網的應用場景， 不會像tcp那樣不能變ip和port，如果變了就要重新建立耗時的TCP連接。
f. QUIC自定義重傳機制，由於TCP重傳機制算法不夠優秀，往往不准確超時時間，所以QUIC使用自增ID計算，更好的計算出了重傳時間。
g. 離開了TCP的底層重傳，流之間沒有依賴，包之間沒有依賴，真正實現了多路復用，告訴傳輸數據。
h. 自定義流量控制，采用滑動窗口協議與http2相同。