1. 程式人生 > >QUIC成為了HTTP/3的標準傳輸協議!

QUIC成為了HTTP/3的標準傳輸協議!

浙江溫州皮鞋溼,下雨進水不會胖。

動機和緣起

記得大概是三四天前,朋友圈被《Google QUIC正式更名 HTTP/3 協議》這篇文章刷了屏,當時第一感覺就是“我靠,HTTP/2還沒普及呢,怎麼3就來了,TCP真的這麼快就要下課了嗎?”。我真的是虛驚一場,我雖然不喜歡TCP,但還要靠著它吃飯呢…TCP要是下課了,我豈不是有丟飯碗的危險?謝特了。又愛又恨的TCP啊!

讀了全文,發現不是,我也就放了心,至少還能保住飯碗,但同時心裡大罵,TMD垃圾TCP怎麼還不趕緊滾蛋??!!矛盾,虛偽,貪婪,欺騙,幻想,疑惑,簡單,善變…

我的微信朋友圈裡大幾百號人絕大多數都是幹網際網路這一行的,所以當業界出現一個比較轟動的大新聞時,刷屏就是必然的了。

這裡先給出這篇文章的英文原文連結:
HTTP/3https://daniel.haxx.se/blog/2018/11/11/http-3/
大家可以連同評論一起來看。請先閱讀原文或者譯文,本文不再包含原文的內容和評論。

我並沒有第一時間發出感概,依然如故地,我要讓事情冷卻幾天,在忘卻的救主將要降臨之前,沉澱出一些剝離了主觀刺激的東西,然後再寫下來。


正文

當一個新的東西出現時,首先是絕大多數人的歡呼,緊接著是少數人的批判,然後是較多的人的批評,最後這個新的東西是否逐漸趨於平庸,泯然眾人,取決於是否有人有破有立。做一個批評者容易,做一個建設者很難,做一個批判者更難,後者決定了新東西是否可以持續蓬勃發展。

QUIC出來已經好幾個年頭了,但是一直都侷限在給TCP補刀的位置,比如哪里哪里說TCP效能不好了,然後有人會說,用QUIC試試吧。這是頭一次,讓QUIC成為HTTP/3的標準傳輸協議,用於取代TCP。當然,這並不是一蹴而就的,但如果這是真的,那麼TCP就是傳統的,而QUIC則是新生代。

這段故事和墨洛溫王朝的丕平向加洛林王朝的過渡何其相似。日光之下,並無新事。

TCP作為傳統的傳輸控制協議,誕生在上世紀70年代那個特殊的環境裡。最初的需求就是一對一的Telnet遠端登入,計算機網路誕生伊始的第一個傳輸實驗就是字元的傳輸,這為遠端控制計算機提供了依據。在那次實驗中,由於誤碼傳丟了幾個字元,在這樣的背景下,TCP協議似乎是唯一正確的協議。

基於單字元的停等協議,字元流水線化傳輸的GBN協議,基於塊傳輸的SR協議,三者中,似乎只有GBN是唯一正確的選擇,停等協議在長RTT時效率太低,SR協議會亂序,對接收端記憶體要求很高且會影響終端響應度。於是,TCP協議的模版就是GBN。事情開始進化。

眾所周知,後來的TCP引入了SR,即SACK機制,但這個SR卻是閹割版的,我們知道,TCP的option裡面的SACK段的數量是有限制的,所以TCP並沒有實現嚴格的SR。隨後為了應對網際網路的擁塞,為了提高頻寬的利用率,各種擁塞控制演算法層出不窮,然而TCP的本質問題依然存在,即 TCP的GBN基因決定了TCP是適合序列字元傳輸的,而不適合塊傳輸

這導致了TCP的大檔案傳輸效能非常不佳。

我考慮過很久這個問題,TCP的問題到底出在哪裡。曾經我以為TCP的效能消耗應該歸咎於握手,按序,確認,現在很多人依然是這樣認為的,但是那只是小Tips,雖然在短連線中,0-RTT勢在必行,但在長連線中,握手開銷可以忽略,此外,保序性是由傳輸的內容決定的,這也無關協議,就算TCP不保序,應用層自己也要保序。

問題出在傳輸本身,即 :

  • 是要在傳輸過程中保序,還是在接收過程中保序;
  • 是要在傳輸過程中保持連線,還是在應用程式中保持連線
  • 連線的目標是一個服務還是一個地址。

TCP協議把傳輸內容的屬性和傳輸協議進行了強繫結,導致了TCP很多問題是解決不了或者很難解決的,比如:

  • 隊頭擁塞問題
    由於TCP採用了GBN機制,只要有一個數據包丟失,接收滑動視窗就會塞住,直到這個丟失的資料包造成的空洞被補上。而QUIC則採用完全的SR機制,解決了這個問題。
    對於需要保序的內容,只要在應用接收時保序就可以了,QUIC並不care傳輸的過程,這是QUIC解決隊頭擁塞問題的關鍵。
    HTTP/2在使用TCP時,其隊頭擁塞問題已經成了HTTP/2的Stream機制的嚴重阻礙,幸運的是,HTTP/3將會將其掃除!
    TCP是在傳輸過程中保序,QUIC則是在應用接收過程中保序。
  • 移動問題
    TCP協議把連線和TCP四元組進行了強繫結,其中只要有一個因素變了,連線就變了。我們知道IP標識了一個網路介面(在OSI模型下則是一個終端)的位置,TCP的四元組強繫結直接導致了TCP無法支援IP地址的漂移。
    QUIC不再採用IP地址和埠來標識連線,這便可以支援IP地址和埠的任意漂移。
    TCP是在傳輸過程中保持連線,QUIC則是在應用程式中保持連線。
  • 組播問題
    在計算機聯網的直接且迫切的需求驅動下,TCP必然只需要實現一對一的連線就可以了,TCP埠號本身就是在同一臺計算機內部,端到端的傳輸控制多路複用的產物,所以TCP無法支援一對多的傳輸。
    QUIC基於UDP,而UDP是可以支援組播的,雖然QUIC本身並未直接聲稱支援組播,但這並不難。換句話說,QUIC“連線”的只是一個IP/UDP對,該地址對如何解釋,是解釋成一個應用程式,還是解釋成一組應用程式,和傳輸協議無關。

嗯?是不是忘記了評價一下安全特性?

是的,我是故意的。

安全問題是比較特殊的。非常特殊。

任何人都希望在任何機制上加入安全模組,但任何人都不希望安全模組發生作用。這就像警察機構,沒有警察,人們會覺得不安全,但是警察一旦出動,必然意味著某些不好的事情發生了。換句話說,人們只是希望安全模組靜靜地待在那裡就好了。

這意味著如果最初沒有直接且迫切的需求,僥倖心理總是讓人忽略安全模組的設計。安全模組本身就是一種懶惰機制,出了事才會想到。最初的村落和城市是不設防的,受到侵略後才開始築牆,TCP/IP網路最初也是裸奔的,後來出現了安全問題才開始出現IPSec,VPN等。如今網路安全問題相關的需求已經是直接迫切的需求了,如果要設計一個新的協議,那麼安全機制必然內建其中。

IPv6也好,QUIC也好,都是新的協議,內建安全機制是必須且正確的選擇,如果沒有內建安全機制,那才是不應該的。所以,我並不認為QUIC協議內建安全機制是多麼多麼轟動的一件事。


TCP在發展了30多年以後,似乎TCP本身就成了TCP/IP網路的代名詞。在我的職業生涯裡,自從我畢業開始,就一直被籠罩在其陰影或者光環之下。

我找的第一份正式的工作是長春一家做教學軟體的公司,面試的時候問了我一大堆關於TCP的東西,雖然最後一直在離職也沒用到,但確實問了,我記得我把書上能背下來的都背下來了,結果還不錯。後來我換了很多工作,幾乎每一次面試都有TCP的內容,從默寫協議頭,描述三次握手,到擁塞控制演算法,BBR原理,從socket引數的含義到TCP在Linux核心的實現,我的天啊,TCP的內容越來越多,以至於我最近的一份工作面試期間,幾乎所有的問題都是TCP相關,當我這麼多年逐漸對TCP有了從表面到本質的認知之後,我想我有資格噴它幾句了。

不光我自己,幾年來我也面試過別人,自己問的很多問題也是TCP相關,只要是做網路的,那就必然要懂TCP,雖然我並不是這麼認為的,但我並不是拍板的人,我只是一個執行者。

就在前幾個月,我推薦了幾個網路技術功底了不得的朋友去華為,大概推薦了三個部門,最後都是以“不瞭解TCP”為理由而bypass,包括BAT在內的幾家國內“大牌”網際網路公司,我也推薦過很多人,失敗的點均和“對TCP不瞭解”相關。就好像網路技術和TCP之間是可以劃等號的。

確實,現在人們普遍的認知就是,如果不懂TCP,你很難被認為非常精通網路。

但在主觀層面上客觀地講,TCP真的就是一個解決問題的協議嗎?它在解決問題的同時是否帶來了更多的問題呢?

我認為TCP還助長了一些很不好的風氣,除了大型網際網路公司的招聘偏見之外,我認為還有下面的點:

  • TCP破壞了IP網路的節點對等性
    TCP的連線保持讓 一條流很容易被識別,只需要解析協議頭即可。這讓透明的IP層或者TCP層代理變得很容易實現,直接導致了各種中間NAT裝置以及中間防火牆的出現。
    被洗腦了30年的專家們可能認為防火牆並不完全是壞事,但請再次注意安全問題,安全本應該是一個協議自己要保證的內秉屬性,一切依靠在外部實現的安全都只是助力。
    IP網路本身就是一個完全對等的網路,後來IPv4感覺地址不夠用了,提出了NAT方案,然而NAT最終更多的解決的是地址隱藏的問題,而不是地址不夠用的問題,這讓IP網路變得不再對等。這非常諷刺。本來應該在應用層實現的服務代理,在IP層更加容易實現,只要修改一下被識別的TCP流的IP地址和埠就可以了,這非常簡單易行。試想,如果最終流行起來的協議不是TCP而是UDP,NAT還會這麼容易實現嗎?
    想想TCP和UDP哪個打洞更加容易些?哪個更容易,哪個地址隱藏的效果就不好,如果效果不好,那麼大量成本就不會砸在上面。
  • 擁塞控制問題
    這是1988年以後的事了。在批判TCP之前,我首先要證明AIMD用在UDP上不會出現類似的問題。而這個非常難。
    TCP協議非常嚴格,但是背後的GBN卻是非常魯莽,我們看GBN原理中導致問題的根源:
    在這裡插入圖片描述
    原始的GBN設計留給了 如何重傳 太多的操作空間,而如何重傳這件事又直接取決於 如何判斷丟包, 這導致了大量的擁塞控制演算法的出現!如果演算法不統一,那麼公平性就難以保證,TCP/IP網路的公平博弈便無法保證,資源共享將會成為一句空話。
    雖然後來的SACK緩解了丟包的誤判導致的重傳,但本質並沒有變化,隨著頻寬越來越大,SACK受到的限制將會越來越嚴重。
    QUIC以及其基於的UDP有這個問題嗎?原則上你也可以設計一個 一個包發兩遍 的QUIC擁塞控制演算法,但是可能沒有人會那麼做。當有一種保證公平的可操作方案時,當留下的灰色空間很小時,便沒有人會去破壞公平。QUIC基於完全的SR,它可以很精確地判斷丟包和選擇重傳,成為劣幣的博弈成本比較高,那便無法驅逐良幣。
    世界從此美好。

評價一個技術本不應該帶入主觀情緒,但這本來就是一篇散文,而不是什麼技術文件,所以也就隨性了。

縱使TCP問題再多,它至少給我和我的家庭帶來了收入,依靠TCP我們全家生活地還不錯,哈哈。


曾經,我是不Care HTTP協議的,我一直把自己定位成搞底層的,比如核心,比如網絡卡,比如IP路由這些才是底層,而HTTP則只是一個Web服務使用的應用層協議而已,無非也就是一個Apache/Nginx這種,沒意思。後來我發現很多Apache/Nginx玩的很溜的,對TCP也玩的很溜,然後我就對HTTP協議有了新的認知。

所有TCP/IP核心的問題都是由上層順勢被發現的。當解決了select/poll的問題以及主機程序排程的問題後,最終問題一定會壓向TCP。隨著網際網路應用場景的越發豐富,HTTP是最先感受到變化並傳遞變化的,事實上,在Google等公司的主導下,HTTP最終還擁抱了變化,HTTP/2似乎解決了HTTP/1的任何問題。然而一成不變的是TCP。

嗯,高鐵跑在了普通軌道上降速150km/h執行,車沒有問題,是路不好。

所有問題都是TCP的問題。

於是HTTP/3徹底拋棄了TCP。那麼HTTP/3何時到來?


先看一個連結:
【重要】通訊品質向上にむけた取り組みについてのお知らせ:https://www.ocn.ne.jp/info/announce/2018/06/22_1.html
這是2018年6月份的一個公告,可以一鍵翻譯。

你猜,把網際網路應用從TCP切到QUIC需要多久?面臨什麼問題?

站在當代,我們很容易評價歷史,卻無法預知未來。我們很容易說出我們有什麼問題,卻無法用一種平滑的方案去解決這個問題。

QUIC取代TCP很難,因為TCP的歷史包袱太重。

幾乎所有的有狀態防火牆,狀態NAT設計,負載均衡裝置,均完全依賴TCP的狀態機,如果換成QUIC,這些裝置將一夜之間全部失效!我們知道,我們之所以可以上網,可以使用網際網路做我們想做的事情,幾乎嚴重依賴這些裝置,甚至大型運營商也都會在所謂的 出入口 裝置上做一些基於狀態的動作,如果說一條 UDP連線 的源IP由一個運營商切到另一個運營商了,基於固定IP進行資料包分類的策略是不是就失效了呢?

就想象一下IPv6的部署難度就知道QUIC也將面臨同樣體量的問題,但它們之間的不同點在於,IPv6的部署是自底而上的,終端使用者完全感覺不到變化,然而QUIC卻直接是由業務驅動的,QUIC可能就是快,使用者能感知體驗變好了。

當然了,很多人會懟我,認為我好像已經被QUIC洗了腦,或者說對TCP過於憎惡,現在終於有第二個選擇了。其實,我是用看待新事物的普遍觀點來分析 QUIC事件 的,還是那句話, 新的東西縱然它有很多不足,你要諒解它的不足,給它發展的空間和時間,而不是一味地懟。

QUIC目前依然尚未得到大規模的部署,依然有很多坑,比如它的擴充套件性確實很不好,這意味著大規模商用部署的路程還非常遙遠,但這至少確實是第二個選擇,有選擇,就有機會。

總之吧,要樂觀,事情總是往好的一面去發展,所有的問題都是能解決的問題。

附上幾篇比較好的文章連結:
The Road to QUIChttps://blog.cloudflare.com/the-road-to-quic/
UDP/QUICを使用した高速化 - AKAMAI MEDIA ACCELERATIONhttps://blogs.akamai.com/jp/2017/05/udpquic---akamai-media-acceleration.html


附文:關於批判和辯證

這篇文章源自於我對TCP的批判,然而在我沒找到更好的替代者之前,我只能在朋友圈或者部落格上罵罵咧咧。現在有人提出QUIC作為HTTP/3的標準傳輸協議了,我便可以放心噴了。

其實我自覺自己的辯證性批判做的很好,一直都很好。我不會盲目地去懟一個東西,也不會去盲目吹捧一個東西。

比較令我痛苦的是,我不喜歡中國傳統文化,但我卻很贊同中國傳統文化,這是很難做到的,很難做到的事,過程一定是痛苦的。不信你試試。

到了杭州入職,我感到非常幸運,我突然發現有很多人能和我一起討論那些 亂七八糟毫無意義 的東西了。

臨時租住在公司附近,室友是個練太極的,我們經常聊一些“沒有意義”的東西,最近的培訓中,又接觸到一位超級辯證但卻不那麼唯物主義的高人。我想有機會真的就可以“舉酒屬客,誦明月之詩,歌窈窕之章。”了吧。


  • 為什麼喜歡尋找外星人
    因為我們希望通過尋找外星人,從而更好地界定我們自己,區分出來“我們”和“他們”。
    如果沒有這種慾望,先人在造詞的時候,如何會造出“他們”呢?不是我們無聊,而是我們孤獨和迷茫,所以我們一定要不斷尋找“他們”。和“他們”不一樣的地方,那就是“我們”!
  • 希臘的和諧和中國的和諧
    希臘人喜歡辯論,喜歡爭論,視為和諧,中國人強調不爭,視為和諧。站在類別間和諧立場上,爭論才能區別你我他,彼此公平,才是和諧,否則便是立場不清晰,視為混沌;站在整體的立場上,不爭則無損,總能量最大,視為和諧,否則則大傷元氣。都對,也都不對。
  • 對人和對事
    把一個人的本性和這個人所持有的觀點區分開來,是困難的。當我在為一個罪犯辯護的時候,我其實也在給自己抹黑。
    所以不要輕易和自己的領導進行爭吵。
  • 中國文化和西方文化
    中國文化是封閉自省的,西方文化是一路走到黑的並冠以“進步”的代名詞。西方文明會持續作惡而不會自省,最終世界滅亡。
  • 田園生活和汽車空調
    汽車的意義是什麼?它真的代表比田園生活更好的生活工具嗎?你坐車是去幹什麼?去上班,上班幹什麼?掙錢,掙錢幹什麼?換車換房裝逼…
    所以現代化生活的意義是什麼?是在維持現代化生活而已?是真的嗎?
  • 取消關注“微信運動”
    作為一個狂熱的徒步愛好者,我終於在上週日把微信運動取消關注了,那天我一路小跑兩個小時完成了西湖景區東面山脊的穿越。自己自覺找爽點就好了,沒有必要通過一顆爭強好勝不服輸的心去激勵自己多走幾步了。

浙江溫州皮鞋溼,下雨進水不會胖。
zhejiang wenzhou skinshoe wet,rain flooding water will not fat.