簡介
很多小夥伴可能還沉浸在HTTP1.1的世界無法自拔，但是時代的洪流已經帶領我們來到了HTTP3的世界了。是的，你在橋上看風景，而橋邊的房子上有人正在看你。
為了不被時代所拋棄，今天給大家講解一下HTTP3的新特性。
HTTP成長介紹
HTTP的全名叫做超文字傳輸協議，是全球資訊網所基於的應用層傳輸協議。最初的版本是HTTP 0.9，是在80年的後期產生的，後面在1996年升級到了1.0.
但是HTTP1.0滿足不了日益增長的物質文化需求和對美好世界的嚮往。所以在1997年出現了HTTP1.1，隨後到2014年，HTTP1.1都一直都在更新。
然後到了2015年，為了適應快速傳送的web應用和現代瀏覽器的需求，在Google的SPDY專案基礎上發展出了新的HTTP2協議。
又過了4年，在2019年，Google又開發出了一個新的協議標準QUIC協議，它就是HTTP3的基石，其目的是為了提高使用者與網站和API互動的速度和安全性。
不同HTTP協議解決的問題
不同HTTP協議解決的問題也是不同的，HTTP1.1有什麼問題呢？
-
因為HTTP1.1一個連線中資料是順序傳輸的，所以會有Head-of-line Blocking的問題，如果前面是一個大的資料包，則會導致後續資料包的阻塞。
-
HTTP1.1無法對請求頭和cookie進行壓縮，所以傳輸效率會比較低。
-
為了保證緩衝區不會溢位，HTTP1.1有一個TCP慢啟動的功能，作為擁塞控制措施，協議反覆探測網路以計算可用容量，但是這樣就會導致多次資料的傳輸，從而導致訊息的延時。
對於HTTP2來說，它使用二進位制進行訊息傳輸，並且將訊息拆分成一個個的stream，在stream中又包含了多個frame，允許資源通過多路複用使用同一個連線傳送，解決了行頭阻塞的問題，並且還支援資料包的優先順序和伺服器推送。
但是HTTP2的伺服器推送會導致應用程式變得複雜，TCP級別的頭阻塞的問題在資料包丟失並且必須重新以正確的順序重新傳送時，仍然可能發生。
要注意，HTTP/2是HTTP/1.1的擴充套件，而不是它的替代品。 應用程式語義保持不變，具有相同的HTTP方法、狀態程式碼、URI和標頭欄位。 所以HTTP/2可以被用在任何使用HTTP/1.1的地方。
HTTP/2在客戶端和伺服器之間使用單個TCP連線，該連線在互動期間保持開啟狀態。
雖然HTTP/2支援併發，但是過多的併發會導致HTTP/2伺服器接收到大批量的請求，從而導致請求超時。
HTTP3和QUIC
HTTP/3的目標是通過解決HTTP/2的傳輸相關問題，在所有形式的裝置上提供快速、可靠和安全的Web連線。為此，它使用了一種不同的傳輸層網路協議，稱為QUIC，該協議最初由Google開發的。
感慨一下，雖然最近中國在系統的應用方面有了一定的進步，但是看看這些底層的協議，還都是外國人搞出來的。
HTTP/2和HTTP/3的根本區別在於，HTTP/2底層使用的是TCP協議，而HTTP/3使用的是QUIC，而QUIC的底層使用的是UDP協議。
我們看一下HTTP/2和HTTP/3的協議棧對比：
TCP協議主要保證服務的可靠性和有序交付，但是TCP需要同握手來建立連線，這樣做是為了確保客戶端和伺服器都存在並且他們願意並且能夠交換資料。但是，它也需要一個完整的網路往返才能完成，然後才能在連線上完成任何其他操作。 如果客戶端和伺服器端相距比較遠，那麼就需要花費較多的時間來進行連線。
我們知道UDP是無連線的，所以它要比TCP簡單很多。它不需要TCP這種建立多次連線的步驟，只需要傳送資料包出去就夠了。
所以使用QUIC的優點就在於減少了系統的延時，適用於可以容忍一些資料丟包的情況，比如線上遊戲、廣告競價、線上視訊、實時流等地方。
另外因為UDP支援廣播，所以HTTP3還適用於廣播應用中，如精確時間協議和路由資訊協議等。
另外HTTP3還可以用在物聯網、大資料和VR等方面。
既然HTTP3使用的是QUIC協議，那麼QUIC到底是什麼呢？
通常來說QUIC是一種通用傳輸協議，與TCP非常相似。為什麼要打造一套新的協議呢？這是因為現有的TCP協議擴充套件起來非常困難，因為已經有太多太多的裝置使用了各種不同的TCP協議的版本，如果想直接在現有的TCP協議上進行擴充套件非常困難，因為需要給這麼多臺裝置進行升級幾乎是不可能完成的任務。
所以QUIC在選擇在UDP協議之上進行構建。QUIC使用UDP，主要是因為希望能讓HTTP/3更容易部署，因為它已經被網際網路上的所有裝置所知並已實現.
QUIC實際上就是在UDP基礎上重寫了TCP的功能，但是又比TCP更加智慧，更高效的實現了TCP的核心功能。
接下來我們看下QUIC具體有哪些特徵。
TLS1.3
TLS主要用來保證客戶端和伺服器端在資料傳輸過程的資料安全性，可以對明文資料進行加密傳輸。TLS1.3是TLS協議的最新版本，在舊的版本如TLS1.2中，客戶端和伺服器端的握手至少需要兩次網路往返，但是在TLS1.3中，將其減少到只有一次往返。
雖然在HTTP/2中是支援無加密傳輸模式，但是預設情況下所有的現代瀏覽器都不支援這種模式，所以HTTP/2必須配合HTTPS一起使用。長遠看來HTTPS肯定是未來的趨勢，所以在QUIC中，直接就使用了TLS 1.3協議。QUIC本身就封裝了TLS1.3。
這樣做的好處就是QUIC沒辦法執行明文，所以更加的安全。並且QUIC內建了加密協議，將傳輸和加密握手合二為一，節省了往返。
因為QUIC是全程加密的，所以對於某些ISP和中間網路來說，無法再對網路資料進行分析和統計，所以可能會限制它的使用。並且因為QUIC是單獨對每個資料包進行加密的，在高併發的情況下，可能會造成效能問題。
解決HoL阻塞
傳統的HTTP1.1和HTTP2底層協議是TCP，雖然HTTP2在應用層可以將不同檔案的資料拆分成一個個的stream放在同一個連線中進行傳輸。但是對於TCP本身來說，它並不知道這些stream屬於不同的檔案，它會將其當成同一個檔案。所以如果傳送資料丟包的情況，TCP會重新傳送所有的檔案包。從而導致HOL阻塞的問題。
而QUIC更加細粒度一點，它可以在每個流的基礎上執行丟包檢測和恢復邏輯。從而只會重發失敗的流，而不是整個檔案。
連線的遷移
在TCP中，如果我想要建立客戶端和伺服器端的連線，需要知道這4個元素：客戶端IP地址 + 客戶端埠 + 伺服器IP地址 + 伺服器埠。
如果這4個元素中有一個傳送了變化，則需要重新建立TCP連線。並且需要根據應用程式級協議，重新啟動程式中的操作。
比如你正在下載一個大的檔案，但是網路地址突然發生了變化，則可能需要重新請求該檔案。
為了解決這個問題，QUIC引入了一個名為連線識別符號(CID)的概念 。 每個連線都在上述4個元素中額外分配一個編號，用於標記客戶端和伺服器端的唯一連線。
因為這個CID是由QUIC定義的，所以不會隨著網路遷移的變化而變化。從而不需要新的握手，這種情況被稱為連線遷移 。
總結
好了，今天的HTTP/3和QUIC就介紹到這裡，雖然我們沒有涉及到底層的更多細節，但是相信大家應該都聽得明白了，再總結一下，QUIC實際上行就是在UDP協議之上，再造了一個更加高階有效的TCP協議。
本文已收錄於 http://www.flydean.com/03-http3/
最通俗的解讀，最深刻的乾貨，最簡潔的教程，眾多你不知道的小技巧等你來發現！
歡迎關注我的公眾號:「程式那些事」,懂技術，更懂你！