HTTP / 3用UDP替換TCP以提高網路速度和可靠性 - thenewstack

banq發表於2019-01-17

當初之所以使用TCP,是因為TCP比UDP可靠,這是常識,但是這個常識是有上下文背景的,那就是基於可靠的底層網路。

HTTP / 2透過在同一連線上傳送多個HTTP請求,允許應用程式同時處理請求,從而更好地利用網路頻寬。但只有在網路執行良好時才能實現這些收益。你可以最大化你的吞吐量和頻寬,因為TCP可以達到它可以達到的最大速度,並且所有並行連線都能以最快的速度執行。

這很好,直到網路連線出現問題,例如網路擁塞或在行動網路上從一個小區移動到另一個小區並且資料包丟失。TCP保證傳送資料包的順序是應用程式接收的順序 - 所以如果你錯過了一個,那麼一切都必須停止,直到特定的資料包被重新傳輸。如果將多個請求複用到單個TCP連線上,則所有這些請求都必須停止並等待,即使丟失的資料包可能隻影響其中一個。

這種“線路阻塞問題”是TCP固有的問題,使用UDP透過允許應用程式控制資料包的重傳來修復它。它可以說資料包丟失,但它隻影響這一個資料流,其他資料流可以繼續。

這使得QUIC 在惡劣的網路條件下更加強大

HTTP / 3的連線遷移提議可以擴充套件在不同網路之間移動的穩健性,例如從Wi-Fi到移動寬頻,這通常會因為IP地址的變化而破壞網路連線。透過此提議,您和伺服器之間的識別符號將不是IP地址,而是協議本身內的識別符號。這將允許您在新網路上自動重新啟動整個連線,因此您可以無縫地從Wi-Fi轉到移動連線。原始網際網路的一些假設是,存在相當固定的連線,我們現在正在進入一個非常移動的異構世界。

HTTP / 3還直接整合了TLS,QUIC對資料包傳輸的額外控制也具有優勢。當事情透過網際網路傳送時,它們會被分解成資料包; 在TLS中,有一個傳輸資料緩衝區的概念。如果你想要真正有效率,你想要排列所有這些東西; 這是一個請求,我將對它進行加密並透過網際網路進行傳輸,以便一次性收到所有這些請求並且不會分成較小的資料包,其中一些不會被延遲。如果您控制所有級別,如果您只是假設網際網路是一種不可靠的傳送資料包的方式,那麼您可以控制傳送內容的順序,您可以控制加密它們的方式以及這些加密塊如何傳輸。

與HTTP伺服器的初始連線將更快,因為HTTP / 3取消了通常需要建立連線的一次往返安全。

使用TCP和TLS,連線設定以TCP握手開始:客戶端傳送SYN,伺服器響應SYN + ACK,客戶端使用ACK完成。然後在傳送任何請求之前有一個TLS握手 - 它需要另一個類似的三個訊息交換。QUIC在大多數時間將其壓縮到單個交換。一個關鍵特性是0-RTT,它允許客戶端立即傳送請求; 這是TCP和TLS的一個選項,但你仍然需要等待TCP握手完成。

預設安全
整合TLS還可以提高安全性,因為身份驗證和加密是由網路協議提供的,而不是像TLS這樣的高階協議提供的 - 而且在HTTP / 3中內建TLS,使用它也不是可選的。
當站點使用HTTPS時,瀏覽器現在會在站點沒有加密連線時向您發出警告,而不是顯示鎖定。HTTP / 3和QUIC是這個方向的另一個實現。
更多的QUIC是加密的,這包括攻擊者可能嘗試使用的後設資料。除了一些有助於將資料包識別為QUIC資料包的位元之外,未加密的QUIC資料包的唯一部分是連線的不透明識別符號。這包括TCP和TLS無法保護的內容,例如確認('我還要5個位元組')。

加密實際上將簡化部署QUIC,網際網路往往會干擾新協議,加密將保護QUIC免受干擾。

UDP的主要缺點是數量較少的網路會顯示阻塞或降級UDP的。在這種極少數情況下,我們有HTTP / 2可以依賴。

當使用者訪問站點時,他們的初始連線將透過HTTP或HTTP / 2,伺服器將提供HTTP / 3作為替代; 瞭解提供該連線的標頭的瀏覽器將記住它以供下次訪問,但較舊的瀏覽器和裝置將繼續使用舊協議

 

相關文章