QUIC成為了HTTP/3的標準傳輸協議！
浙江溫州皮鞋溼，下雨進水不會胖。
動機和緣起
記得大概是三四天前，朋友圈被《 3607OwdfGtL5Oqh0rT9xo&from=singlemessage&ascene=1&devicetype=android-24&version=2607023a&nettype=WIFI&abtest_cookie=AwABAAoACwANAAMAJpceAFiZHgCImR4AAAA=&lang=zh_CN&pass_ticket=7OEmeMb9gm%2bKzjsaYV/0ugEyj3YzVtcbayNeyfOYq0%2btUuSJ58Er3ccGaXderVRj&wx_header=1" rel="nofollow,noindex" target="_blank">Google QUIC正式更名 HTTP/3 協議 》這篇文章刷了屏，當時第一感覺就是“我靠，HTTP/2還沒普及呢，怎麼3就來了，TCP真的這麼快就要下課了嗎？”。我真的是虛驚一場，我雖然不喜歡TCP，但還要靠著它吃飯呢…TCP要是下課了，我豈不是有丟飯碗的危險？謝特了。又愛又恨的TCP啊！
讀了全文，發現不是，我也就放了心，至少還能保住飯碗，但同時心裡大罵，TMD垃圾TCP怎麼還不趕緊滾蛋？？！！矛盾，虛偽，貪婪，欺騙，幻想，疑惑，簡單，善變…
我的微信朋友圈裡大幾百號人絕大多數都是幹網際網路這一行的，所以當業界出現一個比較轟動的大新聞時，刷屏就是必然的了。
這裡先給出這篇文章的英文原文連結：
HTTP/3 ： https://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 QUIC ： https://blog.cloudflare.com/the-road-to-quic/
UDP/QUICを使用した高速化 - AKAMAI MEDIA ACCELERATION ： https://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.