人們普遍對擁塞控制存在誤解，
人們普遍認為設計一個牛逼的擁塞控制演算法就能提高TCP的傳輸性能，
人們普遍認為擁塞控制是為優化存在的，
不僅僅如此，
人們普遍認為有意義的事都是為優化而存在的，
我記得我高中的時候，數學老師講完一道題的巧妙解之后，我總是在下面嚷嚷我還有更麻煩的方法來解這道題，我的意思是不想等下課了大家一個個來問我問題，與其如此，我還不如公開一種大家都懂但更麻煩的方法呢，當大家都在追求奇技淫巧時，我顯得有點特立獨行，
與此類似，TCP的擁塞控制就是一種麻煩的方法，加上擁塞控制機制之后，資料可能傳輸的更慢而不是更快了，帶來的是大家公平暢通，所謂不患寡而患不均，如果你想更快，那就不要擁塞控制，
很多搞TCP加速的個人或者公司，寄希望于設計一個牛逼的擁塞控制演算法，這種思路是多么的幼稚，大錯特錯，他們沒完沒了地閱讀各種演算法的paper，甚至不看正文直接跳到最后的對比資料，企圖尋找一種碾壓CUBIC，碾壓BBR的新演算法，然后在這個新演算法的基礎上魔改，胡亂改一些引數，把小數改大，把13改成23這種，然后拿著一些偶然的資料去抑揚頓挫，
其實網吧打游戲的或者做web的人都比這些專業TCP加速的人理解得更正確，
這些人很明確地希望去掉擁塞控制，去掉AIMD操作，有資料時直接發包就是了，這難道不是更正確的做法嗎？
可能有人知道APPEX，這家公司的做法就很 “正確” ，它們只要保證自己不和自己打架，幾乎是不會進行擁塞控制的，所謂的TCP加速，你需要去設計一個什么時候發包的邏輯，而不是去設計一個控制視窗或者控制速率的發多發少的邏輯，
把紅綠燈的意義看成是為了讓你的車跑的更快，這不是笑話嗎？在一個限速且有紅綠燈的道路上，你想加速？如果你不違章超速，如果你不闖紅燈，你想加速？
來點真實的場景，極端點說，在直連獨享帶寬的情況下，把視窗寫死成網卡速率和RTT的乘積，你就能得到最快的速率，然而現實中卻根本不可能存在這種環境，你拿這個環境下測得的資料去忽悠人，這不是欺騙嗎？
RTT為什么會劇烈抖動？帶寬測量為什么不靠譜？但這些都是常態，不靠譜的是你的認知，
你以為網路上的流量都在拉大檔案嗎？你以為大家都在看直播嗎？你以為一個固定的源到固定的目的地之間的路徑是固定且唯一的嗎？事實上網路上大部分的流量都是一次或幾次pingpong的流量，一個連接的生命周期不超過幾個RTT，這種不可預見且突發的流量才是網路的常態！
看看開車的，騎電瓶車的以及公交地鐵上的人們，看走路的，坐在沙發上以及躺在床上的人們，有多少是在做大檔案傳輸呢？ 是什么動機讓他們拉取一個超過一個螢屏大小的資料呢？人眼瀏覽一屏所需的時間是秒級的，
絕大多數都是胡亂劃來劃去打開一個頁面再關閉，打開一個視屏再下一個吧，每一次資料傳輸的時間大概也就是幾個到幾十個RTT，沒有人能預測誰會在什么時候請求一個一螢屏大小的圖片或者文字，這才是互聯網的常態！
只有你在安裝新app前下載該app安裝包的時候，才會涉及到那么幾十M，幾百M的稍大的檔案傳輸，再加上時不時的更加不可預測且不可管理的UDP流量，事情就更加不利用TCP加速了，
在這種海量無法預測的，短時間突發的，轉瞬即逝的流量海洋中如何加速，你作為一個長連接在那傻乎乎的測量帶寬并且預測丟包，這不是犯傻嗎？你預測的那些行為都是一些早已逝去的連接引發的，人家都已經事了拂衣去了，
按照網吧打游戲的人或者做web的人理解，單純加大初始視窗就能解決絕大多數問題了，別的什么都不用做，在我看來他們是更懂TCP加速的，
與其在一個長連接里搞不靠譜的TCP加速，還不如搞幾個固定1000000000000000初始視窗的fastopen短連接呢，明白人看出來了，哈哈，運營商不支持fastopen怎么辦？這個問題讓網吧打游戲的人或者做web的人毆打你一頓就知道答案了，
又有人想跟我提APPEX，我承認那些人的演算法牛逼，但我還是不看好，我不覺得這種灰色的東西可以長久持續下去，互聯網上公平的速率才是正確的，這是一種博弈正確，任何企圖加速的都是垃圾，
但凡涉及這個話題，我都是噴的態度，但作業歸作業，態度是態度，塵歸塵，土歸土，我個人也是有TCP加速的能力的，事實上，說到底，我自己也是垃圾，
浙江溫州皮鞋濕，下雨進水不會胖，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/264785.html
標籤：AI
上一篇：新手學Python之Jupyter Notebook學習
下一篇：java集合的擴容機制