HTTP3撲面而來

http3 進行時

HTTP3協議基於Google的 QUIC 協議，由互聯網工程任務組（IETF）來制定。目錄仍是草案，已經進行到第33版。

HTTP3 是基於 QUIC 協議的 http。傳輸層是UDP+QUIC，應用層還是HTTP，即request/respose, request裏也還是method, url, headers, body等等，從應用層的角度來看，你的代碼無需修改就能夠遷移到新的協議版本上來。

檢查網站是否支持http3協議：

https://http3check.net/?host=...

curl 工具從7.67之後的版本增長對http3的實驗性支持。

curl --http3 https://nghttp2.org:8443/

檢查瀏覽器是否支持http3協議：

https://http3.is

今年10月，Facebook 號稱超 75% 的流量已使用 QUIC 和 HTTP/3協議。

http 1.1 與http2 及http3協議的比較

與http2同樣，http3也採用加密的二進制協議，不一新的是http3是基出UDP協議的。

關於爲何http3會採用UDP協議，帶來了哪些好處，能夠參考http3詳解。 cURL的做者 Daniel Stenberg 對此有很詳細的說明。包括協議僵化、TCP隊關阻塞、減小延遲、安全等都有說明，且有中文譯文，值得一看。

一些相關規範草案：

• 0-RTT
• H3-29
• H3-27
• H3-Q050
• H3-T051
• H3-T050
• H3-Q046
• H3-Q043
• Q046
• Q043

零往返時間恢復 Zero Round Trip Time Resumption (0-RTT)

當有人在瀏覽器中輸入您網站的地址時，幕後發生了不少事情……

1. DNS查找 —— 將您的網站地址轉換爲IP地址的位置，這是瀏覽器實際用於請求您的網站的地址。由於通常會經過你的網絡供應商（ISP）所提供的 DNS 服務器實現查找，且找到後都會緩存一段時間，這一般相對較快且延遲較低。
2. TCP握手 —— 瀏覽器將請求發送到已提供的IP地址，嘗試與服務器創建鏈接–這須要1次往返（請求和響應）。
3. TLS握手 —— 創建鏈接後，瀏覽器和服務器如今能夠決定他們都但願使用哪一種加密協議– TLS 1.2和更低版本須要2次往返，而TLS 1.3能夠下降到1次往返。
4. 頁面提取 —— 如今他們正在使用相同的語言，瀏覽器請求您網站的內容，而後服務器將其返回-這須要再進行一次往返。

0-RTT 零往返時間恢復, 最先是TLS 1.3 提出和一種恢復鏈接的機制。即恢復連接時直接使用以前已經交換地的密鑰加密應用數據，而無需再經歷單獨的創建 TCP 鏈接和 TLS 交換密鑰的客戶端服務器以前的數據往返。

0-RTT容許在無需任何往返的狀況下恢復會話。

這裏給一個總結...

• TLS 1.2（及更低版本）

  • 新會話：DNS + 4次往返
  • 續會：DNS + 3次往返

• TLS 1.3

  • 新會話：DNS + 3次往返
  • 續會：DNS + 3次往返

• 具備0-RTT的TLS 1.3

  • 新會話：DNS + 3次往返
  • 續會：DNS + 2次往返

從理論上講，0-RTT由於使用之前的密鑰，確實能夠對網站來進行重放攻擊。所以，在實施時須要一直保持謹慎，通常僅容許GET請求與0-RTT一塊兒使用。因爲GET請求永遠不要修改服務器上的任何內容，只能返回結果，這意味着網站風險更小。

H3-29

打開 https://http3.is/ 網站：
普通青年看到的是這樣的一個畫面：

文藝青年用Mac對chrome加參數打開：

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-quic --quic-version=h3-29

則看到了這樣的畫面：
mp4

同時在開發者工具欄會看到h3-29協議：

若是第一連接時沒有顯示動畫，觀察一下服務器的響應頭，能夠看到：

alt-svc: h3-29=":443";ma=86400,h3-27=":443";ma=86400

這實際是在告訴客戶端能夠升級到h3協議上。這時再刷新頁面，chrome會切換到h3協議上去。這樣就實現了新舊協議的過渡升級。