當初之所以使用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作為替代; 了解提供該連接的標頭的瀏覽器將記住它以供下次訪問，但較舊的瀏覽器和設備將繼續使用舊協議

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！