分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

                上週六寫了《 在Wireshark的tcptrace圖中看清TCP擁塞控制演算法的細節(CUBIC/BBR演算法為例)》，收到一封郵件，說我文中的圖示畫錯了。
        確實，關於CUBIC，我只說了纏繞，關於BBR我只說了順延，並沒有說具體如何，甚至我沒有提一嘴關於重傳的細節，更別說在圖示裡展現了。這是我的錯。話不能說一半，因此才寫下本文，把另一半也寫出來。
        炒股的人喜歡看K線，並且很有用，所以我決定把TCP的“K線”描述透徹。這是因為TCP與股票幾乎是一致的。它們都是不可預測的！任何聲稱可以預測它們的，都是傻逼！不管是股票還是TCP擁塞控制，都大量使用了移動指數平均，很多人認為移動指數平均旨在預測走勢，但這樣的想法錯了！移動指數平均從來不是為了預測的，它這是幫助你：
1.是否要做出反應；
2.如果需要做出反應，如何第一時間做出反應！

------------------------------------------------------------------

------------------------------------------------------------------

現在開始，我將展示tcptrace圖的細節！值得注意的是，我所展示的tcptrace圖解，有一個前提，這些pcap檔案都是在TCP傳送端抓取的，否則一切將無效。我後面會寫單獨的文章來描述這個關係。現在開始吧！

超時丟包檢測

這是TCP中經典的丟包檢測方案，也是TCP在最初被設計的時候採用的方案，此後它一直被保留至今，雖然後來出現了很多針對丟包檢測的優化，但對資料包的超時重傳一直都是最後一道防線。其tcptrace細節如下：

快速重傳

仔細觀察超時丟包時的tcptrace圖，並注意到以下的陰影區域：

平行四邊形覆蓋的黃色區域表示，在交換機或者路由器由於佇列滿載實際丟包到TCP傳送端通過超時檢測到這個丟包事件的期間，還是有資料包可以被接收端收到的。把佇列中的可以被正常處理的排隊資料包沿著時間軸展開，就是上面這塊黃色的平行四邊形區域。
        在路由器看來，這是可以被正常轉發的資料包，在TCP看來，這也是實實在在收到的資料包，只是中間夾雜著丟包導致的空洞，即上圖中的紅色三角形區域。TCP利用這個事實，可以快速檢測到丟包，然後進入善後處理階段，這就是TCP的快速重傳機制。所謂的“快速”是相對超時重傳而言的。
        按照上述解釋，我把快速重傳的圖示列如下：

可以看出，不管是哪種重傳，在tcptrace圖上都是一致的。tcptrace圖中的ACK線，理想線，傳送線將整個傳送行為分割成了幾大塊，下圖分別從縱向inflight序列號以及橫向RTT時間來分別解釋tcptrace：

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

請注意，在本文開始的那兩幅圖關鍵的幾個紅色圈圈點的事件，就是上圖中總結出來的幾條線的相交處！現在要點題了啊！

不同擁塞演算法的tcptrace

TCP擁塞控制演算法的不同，本質上就在於其檢測和應對上圖中任意兩條線交點的措施之不同！
        一般而言，基於丟包的擁塞控制演算法，都使用上述的第一幅圖，檢測序列號與幾條線的相交點，反之基於延時的擁塞控制演算法則使用上述的第二幅圖，檢測RTT與幾條線的相交點。以下簡單說一下幾個經典的演算法使用那個交匯點：
1.CUBIC演算法：使用垂直的序列號線與最大快取線的相交點，一旦相交，則進入快速恢復階段，結束沿著3次曲線的前行。
2.BBR演算法：檢測垂直的序列號線與理想線的相交點，同時監控水平的RTT線與理想線的相交點，保證不偏離。
3.Vegas演算法：檢測水平的RTT線與理想線的交叉點，並基於此調節傳送速率。
------------------------------------------------------------------
仔細看上面的tcptrace圖示解析，或者說你自己用wireshark抓了一個包出來，你能理解為什麼傳送線的斜率一直都是正的(向上)而不是偶爾變成負數(向下)啊？！
首先，在TCP的標準以及其Linux實現中，所有型別的資料傳送，不管是新資料傳送，還是重傳老資料，都是從低序列號傳送到高序列號的，因此，這個tcptrace圖在任意位置都不會看起來是向下走向的，但是也正因為此，一旦發生丟包，整個傳送線並不是連續的：

我們看到了上圖左邊比較好看，比較連續的線，但那是不可能的(資料不會按照序列號從高到低的順序傳送)。為了讓曲線更加直觀些，為什麼不能直接使用速率線呢？
        這是另外一個圖，不是tcptrace圖，本文不談，後面會寫專門的文章。
------------------------------------------------------------------
通過本文，你可能已經明白了tcptrace怎麼看，但是你能用它解決問題嗎？通過上面幾幅圖，你可以看出以下的事實：
        一旦線路達到飽和，ACK線斜率不會隨著你的傳送速率的變大而變大，這意味著什麼？這意味著資料排隊了！在BBR演算法看來，它可以發現這個現象主動降低傳送速率，最終避免排隊！然而對於CUBIC而言，它會無視這種現象，它甚至不會去採集ACK確認資料的速率。另一方面，如果你使用了CUBIC演算法，且路徑中存在一個深佇列快取，那麼在其爆滿之前，傳送線在垂直方向距離理想線的距離會非常大，水平方向看，RTT增加的量也會非常大，這些不用理論分析，從圖上就可以直觀的看出來，如果tcptrace圖在你手上，你就可以直觀的看出來。此時，即便傳送端主動降低了傳送速率(當然對於CUBIC而言這是不可能的，但是對於Vegas或者Hybrid之類的演算法而言，是可能的)，採集到ACK線斜率的降低也要經過一個RTT的時間，如果此時RTT已經由於排隊變得很大，那麼一旦丟包將是一場悲劇。這是因為，深佇列快取中在丟包發生之前就快取了非常多的資料包，這些大量的資料包在相當長的一段時間持續被轉發並被ACK，這件事會在相當長的一段時間掩蓋或者說隱瞞掉丟包的事實，從而造成旁氏騙局造成的透支的代價非常之大！ 【注意，旁氏騙局被揭穿所需的時間越久，透支的代價就越大！】
        另外，在tcptrace圖中，我們要注意到理想線和傳送線之間的夾角，它決定了丟包的時機和發現丟包的時間點，它和第一次丟包時發現的佇列快取的大小一起決定了重傳率，這些也是可以非常直觀的看出來的。
------------------------------------------------------------------
最後，我來說下文中“理想線”的真實含義。
毫不誇張地說，這條線決定了一切！
然而，這條線並不可見！
Oh！Shit！
TCP的擁塞控制演算法就是要找到這條線，並且讓傳送線追其蹤跡！至於說是纏繞它前行還是緊貼它前行，無非只是不同的追隨方式罷了。這裡必須要注意的是，傳送線的前進是滯後於理想線的。你可以把傳送線看作是理想線的反饋！那麼這裡就出現了兩個必須回答的問題：
1.如果頻寬有空餘，理想線斜率增加了，傳送線有什麼機制可以發現並跟著把斜率陡上去？
2.如果頻寬吃緊了，理想線斜率變緩了，傳送線有什麼機制可以發現並跟著把斜率緩下來？
這兩個問題的不同答案定義了不同的擁塞控制演算法。
        我們再次以CUBIC和BBR為例，看它們是怎麼回答這兩個核心問題的。

CUBIC的答案：

問題1的答案

CUBIC不監控頻寬，它只是單純地從理想線下面一個斜率很低的起點開始按照一條固定的3次曲線方式不斷增加斜率，最終一定會與理想線相交，這意味著它“追上了”理想線！

問題2的答案

CUBIC在回答問題1的時候，顯然以追上理想線為目標，然而它並不知道自己是否已經追上理想線，沒有任何標誌性事件，所以只能有一個“你已經過頭了”的警示來勸其止步！此時CUBIC的傳送線將下穿理想線，直到掉到理想線以下，一次不行就多次，因為如果傳送線依然在理想線上面，那個“你已經過頭了”的警告會一直存在。
        所以說，對於CUBIC而言，它採用纏繞的方式螺旋狀追著那根它看不到的理想線前行。

BBR的答案：

問題1的答案

BBR會時不時的定期用更大的斜率的傳送線去探測一下，如果帶來的ACK線斜率也跟著變陡，根據tcptrace圖可以看出，固有RTT不變的情況下，說明理想線也變抖了，BBR會繼續，直到ACK線不再繼續變抖。然後貼著理想線往前走。採用這種方式，BBR是大的時間尺度上，不會掉隊。如果說CUBIC採取了一條本來就是螺旋狀的3次曲線來纏繞理想線，那麼BBR就是藉助了ACK線的反饋來緊貼理想線。

問題2的答案

BBR演算法會監控RTT，我們從tcptrace圖中可以看到RTT在排隊的時候會怎樣，BBR演算法可以檢測到排隊這件事。當其發現這件事，從圖中我們可以看出，這意味著本來平行於理想線的傳送線與理想線相交了！這意味著理想線變緩了，緊隨著理想線的節奏，傳送線會主動變緩。
------------------------------------------------------------------
任何回答不準上面兩個問題的那些個擁塞控制演算法，都是扯淡！
------------------------------------------------------------------
在此，我借用一句安全領域加密演算法選型方面的名言，來自Bruce Schneier：
Anyone can invent an encryption algorithm they themselves can't break; it's much harder to invent one that no one else can break!
在你充分“證明‘自己會被證明是正確的’”之前，慎用自己發明的方案！可能有點繞，一句歌詞可能更加明瞭些：我是一個瓦斯行老闆之子，在證明自己有獨立賺錢的本事以前，我的父親要我在家裡幫忙送瓦斯。
------------------------------------------------------------------
佈雷斯悖論是個真理，增加資源，只會加重擁塞而不是緩解！雖然你用Linux tc工具模擬的延時看上去好像把你自己PC上的兩臺虛擬機器模擬成了深圳到烏魯木齊之間的鏈路，但是tcptrace會揭穿這一切的。你永遠都無法消解真實網路與TC模擬之間的差異，你知道原因嗎？
        原因很簡單！你模擬的延時是基於快取的，它是可以Bloat的，而實際的網路，如果只是距離和光速帶來的BDP，是不會被Bloat的。換句話說，你模擬的管道是可以膨脹的，然而真實的管道是不會膨脹的，懂了嗎？如果還是不懂，請理解以下事實，第二類快取是共享的，第一類快取是獨佔的，你只能模擬第二類快取！           

給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow