初識——HTTP3
想了解HTTP3？？那我們就得先知道為啥會出現HTTP3，因此我們需要知道HTTP1.0，HTTP1.1，HTTP2及HTTP3的演變過程。
HTTP
HTTP 是超⽂本傳輸協議，也就是HyperText Transfer Protocol。
HTTP 端⼝號：80
HTTP 由於是明⽂傳輸，所以安全上存在以下三個⻛險： 竊聽⻛險， 篡改⻛險，冒充⻛險。
HTTP1.0和HTTP1.1的主要區別
長連接
HTTP 1.0需要使用keep-alive參數來告知服務器端要建立一個長連接，而HTTP1.1默認支持長連接。
節約帶寬
HTTP 1.1支持只發送header信息(不帶任何body信息)，如果服務器認為客戶端有權限請求服務器，則返回100，否則返回401。客戶端如果接受到100，才開始把請求body發送到服務器。
這樣當服務器返回401的時候，客戶端就可以不用發送請求body了，節約了帶寬。
另外HTTP還支持傳送內容的一部分。這樣當客戶端已經有一部分的資源后，只需要跟服務器請求另外的部分資源即可。這是支持文件斷點續傳的基礎。
HOST域
現在可以web server例如tomat，設置虛擬站點是非常常見的，也即是說，web server上的多個虛擬站點可以共享同一個ip和端口。
HTTP1.0是沒有host域的，HTTP1.1才支持這個參數
HTTP1.1 相比 HTTP1.0 性能上的改進：
使⽤ TCP ⻓連接的⽅式改善了 HTTP1.0 短連接造成的性能開銷。
⽀持管道（pipeline）⽹絡傳輸，只要第⼀個請求發出去了，不必等其回來，就可以發第⼆個請求出去，可以 減少整體的響應時間。
但 HTTP1.1 還是有性能瓶頸：
-
請求響應頭部（Header）未經壓縮就發送，⾸部信息越多延遲越⼤。只能壓縮 Body 的部分；
-
發送冗⻓的⾸部。每次互相發送相同的⾸部造成的浪費較多；
-
服務器是按請求的順序響應的，如果服務器響應慢，會招致客戶端⼀直請求不到數據，也就是隊頭阻塞；
管道（ pipeline）傳輸中如果有⼀個請求阻塞了，那么隊列后請求也統統被阻塞住了
-
沒有請求優先級控制；
-
請求只能從客戶端開始，服務器只能被動響應。
根據HTTP1.1 的性能瓶頸，HTTP2 做了什么優化？
HTTP2
HTTP2 協議是基於 HTTPS 的，所以 HTTP2 的安全性也是有保障的。
那 HTTP2 相⽐ HTTP1.1 性能上的改進：
- 頭部壓縮
HTTP2 會壓縮頭（Header）如果你同時發出多個請求，他們的頭是⼀樣的或是相似的，那么，協議會幫你消除重復的部分。
這就是所謂的 HPACK算法：在客戶端和服務器同時維護⼀張頭信息表，所有字段都會存⼊這個表，⽣成⼀個索 引號，以后就不發送同樣字段了，只發送索引號，這樣就提⾼速度了。
- ⼆進制格式
HTTP2 不再像 HTTP1.1⾥的純⽂本形式的報⽂，⽽是全⾯采⽤了⼆進制格式，頭信息和數據體都是⼆進制，並 且統稱為幀（frame）：頭信息幀和數據幀。
這樣雖然對⼈不友好，但是對計算機⾮常友好，因為計算機只懂⼆進制，那么收到報⽂后，⽆需再將明⽂的報⽂轉 成⼆進制，⽽是直接解析⼆進制報⽂，這增加了數據傳輸的效率。
- 數據流
HTTP2 的數據包不是按順序發送的，同⼀個連接⾥⾯連續的數據包，可能屬於不同的回應。因此，必須要對數據包做標記，指出它屬於哪個回應。每個請求或回應的所有數據包，稱為⼀個數據流（ Stream ）。
每個數據流都標記着⼀個獨⼀⽆⼆的編號，其中規定客戶端發出的數據流編號為奇數，服務器發出的數據流編號為偶數。
客戶端還可以指定數據流的優先級。優先級⾼的請求，服務器就先響應該請求
- 多路復⽤
HTTP2是可以在⼀個連接中並發多個請求或回應，⽽不⽤按照順序⼀⼀對應。
移除了 HTTP1.1中的串⾏請求，不需要排隊等待，也就不會再出現「隊頭阻塞」問題，降低了延遲，⼤幅度提⾼了連接的利⽤率。
舉例來說，在⼀個 TCP 連接⾥，服務器收到了客戶端 A 和 B 的兩個請求，如果發現 A 處理過程⾮常耗時，於是就 回應 A 請求已經處理好的部分，接着回應 B 請求，完成后，再回應 A 請求剩下的部分。
- 務器推送
HTTP2還在⼀定程度上改善了傳統的「請求 - 應答」⼯作模式，服務不再是被動地響應，也可以主動向客戶端發 送消息。
舉例來說，在瀏覽器剛請求 HTML 的時候，就提前把可能會⽤到的 JS、CSS ⽂件等靜態資源主動發給客戶端，減 少延時的等待，也就是服務器推送（Server Push，也叫 Cache Push）。
HTTP2 也存在缺陷
HTTP2多個請求復⽤⼀個TCP連接，⼀旦發⽣丟包， 就會觸發 TCP 的重傳機制 ，⼀個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。 ，就會阻塞住所有的 HTTP 請求。
因此HTTP2也是存在阻塞的問題，那么HTTP3是不是就來解決阻塞問題的呢？？
HTTP3
HTTP3把 HTTP 下層的 TCP 協議改成了 UDP！
我們都知道 UDP 發⽣是不管順序，也不管丟包的，所以不會出現 HTTP1.1 的隊頭阻塞 和 HTTP2 的⼀個丟包全部重傳問題。
眾所周知UDP是不可靠傳輸，那HTTP3怎么做到可靠的呢？？？
UDP是不可靠傳輸的，但基於UDP的 QUIC 協議（ 基於UDP的低時延的互聯網傳輸層協議 ） 可以實現類似 TCP 的可靠性傳輸。
QUIC （Quick UDP Internet Connection） 在應用程序層面（應用層） 實現了 TCP 的可靠性，TLS 的安全性和 HTTP2 的並發性，只需要用戶端和服務端的應用程序支持 QUIC 協議，完全避開了操作系統和中間設備的限制。
用一個等式來描述就是 QUIC = UDP + TLS + HTTP2
什么是操作系統和中間設備的限制？？？？？？
TCP是在操作系統內核和中間設備固件中實現的。要對TCP進行大更改，就必須要通信雙方升級操作系統，中間設備更新固件，部署成本非常高。
通過QUIC改進擁塞控制體現在哪幾個方面？？
- QUIC在應用層即可實現不同的擁塞控制算法，不需要改操作系統和內核。
- 單個程序的不同連接也能支持配置不同的擁塞控制。這樣我們就可以給不同的用戶提供更好的擁塞控制。
- 應用程序變更擁塞控制，甚至不需要停機和升級。
- QUIC還有帶寬預測，RTT監控，發送速率調整等高級算法支持。
擴展幾點：
- QUIC 有⾃⼰的⼀套機制可以保證傳輸的可靠性的。當某個流發⽣丟包時，只會阻塞這個流，其他流不會受到影響。
- TLS3 升級成了最新的 1.3 版本，頭部壓縮算法也升級成了 QPack 。
- HTTPS 要建⽴⼀個連接，要花費 6 次交互，先是建⽴三次握⼿，然后是 TLS/1.3 的三次握⼿。QUIC 直接 把以往的 TCP 和 TLS/1.3 的 6 次交互合並成了 3 次，減少了交互次數。
相關鏈接
文章只是簡單的就HTTP1.1和HTTP2共同的一個阻塞問題來討論HTTP3是如何改進優化的。雖然覺得HTTP3很好，但是現在還未得到普遍使用。如果對HTTP3感興趣可以看下面的相關鏈接，講解更深入。