今天換一下風格，嘗試用一個短小的漫畫講一個小概念，
這個概念如此重要，以至于推動了HTTP甚至TCP的不斷發展，
先從1989年蒂姆·伯納斯·李設計的HTTP協議開始，
HTTP的特點是：發一個Http Request，然后等著Http Response回來，然后再發下一個Http Request....
蒂姆·伯納斯·李想不到的是， 幾十年以后， 頁面變得非常復雜
HTTP協議這種請求->等待回應的模式，引發了隊頭阻塞的問題
這些HTTP請求組成了一個佇列，如果佇列頭部的請求的回應不回來，后面的都得等著，
很明顯， 一個很簡單的解決方案是多建立幾個佇列：多建立幾個TCP連接
另外一個方案就是多路復用 ：把每個請求和回應當成一個流(Stream) ，每個Stream都有一個ID，
每個Stream可以有多個幀(Frame)，Frame中保存資料，
在同一個TCP連接上，可以有多個多個幀混合著在“流動”，
HTTP 一下子發出3個請求， 它們的Stream次序是 1， 2， 3
但是回傳的Stream次序是 2，1， 3， 1 ， 次序亂了，
但是沒關系，有Stream ID做關聯，瀏覽器很容易知道請求和回應的對應關系，
HTTP 升級成了 HTTP/2 ，（詳情參見《HTTP之大明郵差》）
問題似乎解決了 ？
不，站在TCP的角度看， 它不會意識到HTTP層有Stream的存在，一旦TCP層出現丟包，依然會出現隊頭阻塞的問題！
現在瀏覽器可以直接使用TCP#1 中的 b.js， 但是由于TCP#2丟了，按照TCP協議的要求，TCP#3中的資料是不能使用的， 雖然其中的資料是完整的h.css，還必須等待TCP#2重傳，
問題的本質就是站在TCP的視角看，它看到資料是沒有含義的二進制流而已，
如果修改一下TCP協議，讓他理解這些“Stream”呢？
不行，TCP是在作業系統內核中實作的，想改TCP就得改作業系統，然后部署到全世界所有的網路設備上，這就難了，
所以現在只能調整一下作業系統中網路的引數而已，
既然改不了現有的TCP， 那我們就創造一個新的協議出來，讓這個新協議能意識到“Stream”的存在
這個新協議，就是Google提出的QUIC！
如果瀏覽器收到了QUIC #1, #3, #4, 但是QUIC #2丟失了， 會發生什么情況呢？
#4 可以暫時保存，等待 #2的重新傳輸，
雖然QUIC不知道Stream中傳輸的資料到到底是什么含義，但是通過引入Stream , QUIC徹底解決了隊頭阻塞的問題！
當然，由于Stream的概念下移到了QUIC中，那HTTP中的Stream就不需要了，
HTTP/2就升級成了HTTP/3，
不過， QUIC是基于UDP實作的，TCP的那些優秀特性，它不得不重新實作一遍了，
QUIC不在作業系統內核中，意味著應用程式可以對它任意定制，例如輕松地控制各種擁塞演算法的實作，
QUIC作為新協議，除了上面說的可以解決隊頭阻塞問題之外，還有很多優點：
1.減少RTT時間
2. 改善擁塞控制
3. 連接遷移
4. 集成TLS，更加安全
小結：TCP協議已經統治了世界50年，基于TCP的HTTP也30多歲了，在新的環境，它們的弊端逐漸暴露，一個突出的問題就是HTTP和TCP的隊頭阻塞問題，QUIC和HTTP/3有可能是解決之道，
不過想替換TCP可不是那么簡單的事情，今年6月IETF 才發布了QUIC的規范RFC9000，根據w3techs的統計，至今只有5.8%的網站在使用QUIC，主要是Google的網站，QUIC任重而道遠，
點擊下方圖片，查看更多文章吧 ！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/292342.html
標籤：其他