欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

我們在看一些關于計算機網絡的數據或文章的時候，最常聽到的就是 TCP、UDP、HTTP 這些，除此之外，我們或多或少可能聽過 QUIC這個東西，一般跟這個詞一起出現的是 HTTP3，也就是HTTP協議的3.0版本，未來2.x 版本的升級方案。

QUIC 由 Google 主導設計研發。我們都知道 HTTP 協議是應用層協議，在傳輸層它使用的是 TCP 作為傳輸協議，當然這僅僅是對于 HTTP/1 和 HTTP/2 而言的。而 QUIC 的設計的對標協議就是 TCP ，也就是說將來只要能使用 TCP 的地方，都可以用 QUIC 代替。

Google 最開始的目的就是為了替換 HTTP 協議使用的 TCP 協議，所以最開始的名字叫做 HTTP over QUIC，后來由 IETF 接管后更名為 HTTP/3。所以，現在說起 HTTP/3 ,實際指的就是利用 QUIC 協議的版本。

TCP 不好嗎，為什么還要 QUIC

TCP 協議作為傳輸層最負盛名的協議，可謂是久經考驗。只要一說到 TCP ，我們都能說出來它是一種面向連接的、可靠的、基于字節流的傳輸層通信協議。

TCP 通過三次握手的方式建立連接，并且通過序號、ACK確認、丟包重傳以及流量控制、擁塞控制等各種繁瑣又細致的方式來保證它的可靠性。

看上去很完美了，那為什么還要重新搞個 QUIC 出來呢，而且還被作為下一代 HTTP 的實現協議。確實不存在完美的協議，TCP 協議在整個發展過程中經過了多次改進，但是由于牽扯到互聯網世界浩如煙海的各種設備，每次更新、修改都要考慮兼容問題，歷史包袱太重，以至于尾大不掉。

所以為了彌補 TCP 的不足，在 TCP 上直接修改不太可能，那最好的方案就是重新開發一套協議。這種協議要吸收 TCP 的精華，又要解決 TCP 的不足，這就是 QUIC 出現的意義。

TCP 的問題-隊頭阻塞

時至今日，互聯網上大多數網站都已經支持 HTTP/2 協議了，你可以在瀏覽器開發者工具中看一下網絡請求，其中的 Protocol 表示網絡請求采用的協議。

HTTP/2的一個主要特性是使用多路復用（multiplexing），因而它可以通過同一個TCP連接發送多個邏輯數據流。復用使得很多事情變得更快更好，它帶來更好的擁塞控制、更充分的帶寬利用、更長久的TCP連接————這些都比以前更好了，鏈路能更容易實現全速傳輸。標頭壓縮技術也減少了帶寬的用量。

采用HTTP/2后，瀏覽器對每個主機一般只需要 一個 TCP連接，而不是以前常見的六個連接。

如下圖所示，HTTP/2 在使用 TCP 傳輸數據的時候，可以在一個連接上傳輸兩個不同的流，紅色是一個流，綠色是另外一個流，但是仍然是按順序傳輸的，假設其中有一個包丟了，那整個鏈路上這個包后面的部分都要等待。

這就造成了阻塞，雖然一個連接可傳多個流，但仍然存在單點問題。這個問題就叫做隊頭阻塞。

QUIC 如何解決的

TCP 這個問題是無解的，QUIC 就是為了徹底解決這個問題。

如下圖所示，兩臺設備之間建立的是一個 QUIC 連接，但是可以同時傳輸多個相互隔離的數據流。例如黃色是一個數據流，藍色是一個數據流，它倆互不影響，即便其中一個數據流有丟包的問題，也完全不會影響到其他的數據流傳輸。

這樣一來，也就解決了 TCP 的隊頭阻塞問題。

為什么要基于 UDP 協議

QUIC 雖然是和TCP 平行的傳輸協議，工作在傳輸層，但是其并不是完全采用全新設計的，而是對 UDP 協議進行了包裝。

UDP 是無連接的，相對于 TCP 來說，無連接就是不可靠的，沒有三次握手，沒有丟包重傳，沒有各種各樣的復雜算法，但這帶來了一個好處，那就是速度快。

而 QUIC 為了達到 TCP 的可靠性，所以在 UDP 的基礎上增加了序號機制、丟包重傳等等 UDP 沒有而 TCP 具有的特性。

既然這么多功能都做了，還差一個 UDP 嗎，完全全新設計一個不好嗎，那樣更徹底呀。

之所以不重新設計應該有兩個原因：

1. UDP 本身就是非常經典的傳輸層協議，對于快速傳輸來說，其功能完全沒有問題。

2. 還有一個重要的原因，前面也說到了，互聯網上的設備太多，而很多設備只認 TCP 和 UDP 協議，如果設計一個完全全新的協議，很難實施。

QUIC 協議

不需要三次握手

QUIC 建立連接的速度是非常快的，不需要 TCP 那樣的三次握手，稱之為 0-RTT（零往返時間）及 1-RTT（1次往返時間）。

QUIC 使用了TLS 1.3傳輸層安全協議，所以 QUIC 傳輸的數據都是加密的，也就是說 HTTP/3 直接就是 HTTPS 的，不存在 HTTP 的非加密版本。

正是因為這樣，所以，QUIC 建立連接的過程就是 TLS 建立連接的過程，如下圖這樣，首次建立連接只需要 1-RTT。

而在首次連接建立之后，QUIC 客戶端就緩存了服務端發來的 Server Hello，也就是加密中所需要的一些內容。在之后重新建立連接時，只需要根據緩存內容直接加密數據，所以可以在客戶端向服務端發送連接請求的同時將數據也一并帶過去，這就是 0-RTT 。

連接不依靠 IP

QUIC 在建立連接后，會為這個連接分配一個連接 ID，用這個 ID 可以識別出具體的連接。

假設我正在家里用 WIFI 發送請求，但是突然有事兒出去了，馬上切換到了蜂窩網絡，那對于 QUIC 來說就沒有什么影響。因為這個連接沒有變，所以仍然可以繼續執行請求，數據該怎么傳還怎么傳。

而如果使用的是 TCP 協議的話，那只能重新建立連接，重傳之前的數據，因為 TCP 的尋址依靠的是 IP 和 端口。

未來展望

隨著 QUIC 協議的不斷完善和推廣，其應用場景將更加廣泛，對互聯網傳輸技術產生深遠的影響。未來的互聯網，將是 QUIC 和 HTTP3 主導的時代。

要知道，HTTP/1 到 HTTP/2，中間用了整整 16 年才完成，這還只是針對協議做改進和優化，而 QUIC 可謂是顛覆性的修改，可想而知，其過程只會更加漫長。

作者：古時的風箏
鏈接：https://juejin.cn/post/7384266820466180148
來源：稀土掘金
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。