## HTTP/3 雖然 HTTP/2 解決了很多之前舊版本的問題，但是它還是存在一個巨大的問題，雖然這個問題并不是它本身造成的，而是底層支撐的 TCP 協議的問題。 因為 HTTP/2 使用了多路復用，一般來說同一域名下只需要使用一個 TCP 連接。當這個連接中出現了丟包的情況，那就會導致 HTTP/2 的表現情況反倒不如 HTTP/1 了。 因為在出現丟包的情況下，整個 TCP 都要開始等待重傳，也就導致了后面的所有數據都被阻塞了。但是對于 HTTP/1 來說，可以開啟多個 TCP 連接，出現這種情況反到只會影響其中一個連接，剩余的 TCP 連接還可以正常傳輸數據。 那么可能就會有人考慮到去修改 TCP 協議，其實這已經是一件不可能完成的任務了。因為 TCP 存在的時間實在太長，已經充斥在各種設備中，并且這個協議是由操作系統實現的，更新起來不大現實。 基于這個原因，Google 就更起爐灶搞了一個基于 UDP 協議的 QUIC 協議，并且使用在了 HTTP/3 上，當然 HTTP/3 之前名為 HTTP-over-QUIC，從這個名字中我們也可以發現，HTTP/3 最大的改造就是使用了 QUIC，接下來我們就來學習關于這個協議的內容。 ### QUIC 之前我們學習過 UDP 協議的內容，知道這個協議雖然效率很高，但是并不是那么的可靠。QUIC 雖然基于 UDP，但是在原本的基礎上新增了很多功能，比如多路復用、0-RTT、使用 TLS1.3 加密、流量控制、有序交付、重傳等等功能。這里我們就挑選幾個重要的功能學習下這個協議的內容。 **多路復用** 雖然 HTTP/2 支持了多路復用，但是 TCP 協議終究是沒有這個功能的。QUIC 原生就實現了這個功能，并且傳輸的單個數據流可以保證有序交付且不會影響其他的數據流，這樣的技術就解決了之前 TCP 存在的問題。 并且 QUIC 在移動端的表現也會比 TCP 好。因為 TCP 是基于 IP 和端口去識別連接的，這種方式在多變的移動端網絡環境下是很脆弱的。但是 QUIC 是通過 ID 的方式去識別一個連接，不管你網絡環境如何變化，只要 ID 不變，就能迅速重連上。 **0-RTT** 通過使用類似 TCP 快速打開的技術，緩存當前會話的上下文，在下次恢復會話的時候，只需要將之前的緩存傳遞給服務端驗證通過就可以進行傳輸了。 **糾錯機制** 假如說這次我要發送三個包，那么協議會算出這三個包的異或值并單獨發出一個校驗包，也就是總共發出了四個包。 當出現其中的非校驗包丟包的情況時，可以通過另外三個包計算出丟失的數據包的內容。 當然這種技術只能使用在丟失一個包的情況下，如果出現丟失多個包就不能使用糾錯機制了，只能使用重傳的方式了。