Can you summarize the following document?
        
  傳輸控制協議 (TCP) 旨在提供一個在兩個端點之間傳送資料流的介面。將資料傳送到TCP系統可以確保資料以完全相同的形式傳遞到另一端,否則連線將提示存在錯誤。  為此,TCP將資料分解成網路資料包,並在每個資料包中新增少量資料。該附加資料包括用於檢測丟失或無序傳輸的資料包的序列號,以及允許檢測資料包資料中的錯誤的校驗和。當任何一個問題出現時,TCP使用自動重複請求(ARQ)來告訴傳送者重新傳送丟失或損壞的資料包。  在大多數實現中,TCP會將連線上的任何錯誤視為阻塞,停止進一步傳輸,直到錯誤得到解決或連線被視為失敗。如果使用單個連線來傳送多個資料流,就像在HTTP/2協議中那樣,所有這些資料流都會被阻止,儘管其中只有一個可能有問題。例如,如果在下載用於收藏夾圖示的GIF影象時出現一個錯誤,頁面的其餘部分將等待問題得到解決。  由於TCP系統被設計成看起來像一個“資料管道”,或流,它故意包含很少的對它傳輸的資料的理解。如果資料有額外的要求,如使用TLS加密,這必須由執行在傳輸控制協議之上的系統設定,使用傳輸控制協議與連線另一端的類似軟體進行通訊。每種設定任務都需要自己的握手過程。這通常需要多次往返請求和響應,直到建立連線。由於長距離通訊的固有延遲,這會給整個傳輸增加大量開銷。

  QUIC旨在提供幾乎等同於TCP連線的可靠性,但延遲大大減少。它主要通過兩個理解HTTP流量的行為來實現這一點。  第一個變化是在連線建立期間大大減少。由於大多數HTTP連線都需要TLS,因此QUIC使協商金鑰和支援的協議成為初始握手過程的一部分。 當客戶端開啟連線時,伺服器響應的資料包包括將來的資料包加密所需的資料。這消除了TCP上的先連線並通過附加資料包協商安全協議的需要。其他協議可以以相同的方式進行服務,並將多個步驟組合到一個請求中。 然後,這些資料既可用於初始設定中的後續請求,也可用於未來的請求。  QUIC使用UDP協議作為其基礎,不包括丟失恢復。相反,每個QUIC流是單獨控制的,並且在QUIC級別而不是UDP級別重傳丟失的資料。這意味著如果在一個流中發生錯誤,協議棧仍然可以獨立地繼續為其他流提供服務。 這在提高易出錯鏈路的效能方面非常有用,因為在大多數情況下TCP協議通知資料包丟失或損壞之前可能會收到大量的正常資料,但是在糾正錯誤之前其他的正常請求都會等待甚至重發。 QUIC在修復單個流時可以自由處理其他資料,也就是說即使一個請求發生了錯誤也不會影響到其他的請求。  QUIC包括許多其他更普通的更改,這些更改也可以優化整體延遲和吞吐量。例如,每個資料包是單獨加密的,因此加密資料時不需要等待部分資料包。 在TCP下通常不可能這樣做,其中加密記錄在位元組流中,並且協議棧不知道該流中的更高層邊界。這些可以由執行在更上層的協議進行協商,但QUIC旨在通過單個握手過程完成這些。  QUIC的另一個目標是提高網路切換期間的效能,例如當移動裝置的使用者從WiFi熱點切換到行動網路時發生的情況。 當這發生在TCP上時,一個冗長的過程開始了:每個現有連線一個接一個地,然後根據需要重新建立。期間存在較高延遲,因為新連線需要等待舊連線超時後才會建立。 為解決此問題,QUIC包含一個連線識別符號,該識別符號唯一地標識客戶端與伺服器之間的連線,而無論源IP地址是什麼。這樣只需傳送一個包含此ID的資料包即可重新建立連線,因為即使使用者的IP地址發生變化,原始連線ID仍然有效。  QUIC在中實現,而不是在作業系統核心中實現。當資料在應用程式之間移動時,這通常會由於上下文切換而呼叫額外的開銷。 但是在QUIC下協議棧旨在由單個應用程式使用,每個應用程式使用QUIC在UDP上託管自己的連線。最終差異可能非常小,因為整個HTTP/2堆疊的大部分已經存在於應用程式(或更常見的庫)中。 將剩餘部分放在這些庫中,基本上是糾錯,對HTTP/2堆疊的大小或整體複雜性幾乎沒有影響。  QUIC允許更容易地進行未來更改,因為它不需要更改核心就可以進行更新。 QUIC的長期目標之一是新增前向糾錯和改進的擁塞控制。  關於從TCP遷移到UDP的一個問題是TCP被廣泛採用,並且網際網路基礎設施中的許多中間裝置被調整為UDP速率限制甚至阻止UDP。 Google進行了一些探索性實驗來描述這一點,發現只有少數連線存在此問題。所以Chromium的網路堆疊同時開啟QUIC和傳統TCP連線,並在QUIC連線失敗時以零延遲迴退到TCP連線。

  由Google建立並以QUIC的名稱提交給IETF的協議與隨後在IETF中建立的QUIC完全不同(儘管名稱相同)。 最初的Google QUIC(也稱為gQUIC)嚴格來說是通過加密UDP傳送HTTP/2幀的協議,而IETF建立的QUIC是通用傳輸協議,也就是說HTTP以外的其他協議(如SMTP、DNS、SSH、Telnet、NTP)也可以使用它。重要的是要注意並記住其差異。 自2012年以來,Google在其服務及Chrome中使用的QUIC版本(直到2019年2月)為Google QUIC。隨著時間的推移,它正在逐漸變得類似於IETF QUIC(也稱為iQUIC)。

  

  BBR 演算法主要出發點是,資料包丟失可能並不意味著網路擁塞。例如,一瞬間的無線電干擾,資料包就可能會丟失。Cubic 和其他基於擁塞的演算法不區分這種虛假的損失和真正的擁塞,在兩種情況下都降低了它們的傳送速率。另一方面,BBR不那麼容易受到驚嚇。  因此,即使面對次優的網路條件,BBR也能提供持續的吞吐量效能。

  

  Google Chrome於2012年開始開發QUIC協議並且於Chromium版本 29 (2013年8月20日釋出) 釋出。QUIC協議在當前Chrome版本中被預設開啟,活躍的會話列表在codice_1中可見。

  截至2017年,有三種活躍維護中的實現。谷歌的伺服器及谷歌釋出的原型伺服器使用Go語言編寫的quic-go及Caddy的試驗性QUIC支援。在2017年7月11日,LiteSpeed科技正式在他們的負載均衡(WebADC)及 LiteSpeed 伺服器中支援QUIC。截止 17 年 12 月, 97.5%的使用 QUIC 協議的網站在 LiteSpeed 伺服器中執行。  另有幾種不再維護的社群產品,基於Chromium實現並且減少使用依賴的libquic、提供libquic的Go語言繫結的goquic、打包為Docker映象的用來轉換為普通HTTP請求的反向代理quic-reverse-proxy。
快速UDP網路連線(英語:Quick UDP Internet Connections,縮寫:QUIC)是一種實驗性的網路傳輸協定。由Google開發,在2013年實作。QUIC使用UDP協議,它在兩個端點間建立連線,且支援多路複用連線。在設計之初,QUIC希望能夠提供基於TLS/DTLS的網路安全保護,減少資料傳輸及建立連線時的延遲時間,雙向控制頻寬,以避免網路擁塞。Google希望使用這個協定來取代HTTPS/HTTP協定,使網頁傳輸速度加快,計劃將QUIC提交至因特網工程任務小組(IETF),讓它成為下一代的正式網路規範。2015年6月,QUIC的網路草案被正式提交至網際網路工程任務組。2018 年 10 月,網際網路工程任務組 HTTP 及 QUIC 工作小組正式將基於 QUIC 協議的 HTTP()重新命名為HTTP/3以為確立下一代規範做準備。