TCP BBR失速控制的一個小trick一個小patch

昨晚淩晨抵達深圳，今早時間有限，于是就長話短說，但無論如何還是會有一些輸出的，這次關于BBR。我曾經說過，我是不需要太多睡眠的，淩晨3點睡，照樣早上6點起，應該可以把華為的人熬到cusi吧…不得而知了。

  晚上的火車上，手機充電很難，于是我拿着紙筆比劃着一些傳統的東西，好不容易蹭到了一個充電樁…滿格100%後我看了幾篇技術文章，其中有一個猛烈點的關于BBR的優化，當然這個不是我寫的，雖然參考了我寫的東西但還不是我寫的，雖然我知道怎麼寫但我從來沒寫過反而還故意誤導而反寫。

  我看到了人性！看到了人自私的本質。…好吧，我承認，Google的BBR 2.0已經在逐漸滿足人們貪婪的本質了，這很OK，非常OK，然而非常容易被惡意利用。是以，我強烈反對這種控制論範疇的代碼開源，強烈反對。

  沒有人知道如何衡量公平性，是的，沒有人知道，人們也不在乎。人們在乎的是，以激進為榮，以退讓為恥，哪怕大家玉石俱焚反正隻要你不成功我就很欣慰…

  雲青青兮欲雨，水淡淡兮生煙，杭州西湖美景卻擠滿了拍照發朋友圈的人扔下成噸的垃圾，TCP…也就不說了…

  倚南窗以寄傲，審容膝之易安。小橋流水，可與鴻儒暢談，江南煙雨中，杯酒杯茶可與思緒共勉，走在泥濘的土路上，仰頭，想起了5年前…

BBR失速控制

很多人是真的不懂這些細節的，從多少次的聊天中就可以得知。前一篇文章說了TCP失速的原理：

從CUBIC/BBR的TCP ACK失速說起：https://blog.csdn.net/dog250/article/details/80140194

這裡展示一下TCP BBR失速控制的原理：

可以看到，之是以沒有發生真正的失速，是因為通過某種方式補償了cwnd，即通過extral來補償！

  總之，失速控制的關鍵在于，你要保持一個足夠大的視窗，在由于ACK丢失，聚集(而不是原始資料丢失)引起的失速時仍然有足夠的發送視窗。

  請注意，這是一個主動的補償，而非盲目的補償，相比那些滿天飛的把視窗增加 n n <script type="math/tex" id="MathJax-Element-1">n</script>倍，把參數調大這種拍腦袋的做法，這種方案明顯是可取的。另外值得注意的是，如何計算目前的extral呢？我這裡采用了一種常見的方案，當然還有另一種BBR推崇的方案(然而我并不喜歡)：

• 我的方案：采用移動指數平均來取extral；
• BBR的方案：采用Window max來取extral。

哪個好？自己決定，反正思路就在這裡，萬變不離其宗。這也挺無趣的。

我的一個BBR失速控制patch

還是那句話，看破不說破，不傳播負能量。通過上面的圖解，很容易看出這種場景的解法，那麼下面就是一個怎麼做的patch：

--- tcp_bbr.c   -- :: -
+++ tcp_bbr_new.c       -- :: -
@@ -, +, @@
  */
 #include <linux/module.h>
 #include <net/tcp.h>
+#include <linux/skbuff.h>
 #include <linux/inet_diag.h>
 #include <linux/inet.h>
 #include <linux/random.h>
@@ -, +, @@
                unused_b:;
        u32     prior_cwnd;     /* prior cwnd upon entering loss recovery */
        u32     full_bw;        /* recent bw, to estimate if pipe is full */
+       u32     sextral;
+       u64     ack_interval;
+
 };

 #define CYCLE_LEN      8       /* number of phases in a pacing gain cycle */
@@ -, +, @@
                cwnd = cwnd + acked;
        cwnd = max(cwnd, bbr_cwnd_min_target);

+       if (!rs->losses) 
+               cwnd += bbr->sextral;
+
 done:
        tp->snd_cwnd = min(cwnd, tp->snd_cwnd_clamp);   /* apply global cap */
        if (bbr->mode == BBR_PROBE_RTT)  /* drain queue, refresh min_rtt */
@@ -, +, @@
 {
        struct tcp_sock *tp = tcp_sk(sk);
        struct bbr *bbr = inet_csk_ca(sk);
+       u32 extral;
        u64 bw;
+       u64 temp;
+
+       bbr->ack_interval = tcp_stamp_us_delta(tcp_clock_us(), bbr->ack_interval);

        bbr->round_start = ;
        if (rs->delivered <  || rs->interval_us <= )
@@ -, +, @@
        bw = (u64)rs->delivered * BW_UNIT;
        do_div(bw, rs->interval_us);

+       temp = (u64)rs->delivered*bbr->ack_interval;
+       extral = (u64)rs->delivered - do_div(temp, rs->interval_us);
+       if (extral > ) 
+               bbr->sextral = bbr->sextral - (bbr->sextral >> ) + (extral >> );
+
        /* If this sample is application-limited, it is likely to have a very
         * low delivered count that represents application behavior rather than
         * the available network rate. Such a sample could drag down estimated
@@ -856,6 +872,8 @@
        bbr->cycle_idx = 0;
        bbr_reset_lt_bw_sampling(sk);
        bbr_reset_startup_mode(sk);
+       bbr->ack_interval = 0;
+       bbr->sextral = 0;

        cmpxchg(&sk->sk_pacing_status, SK_PACING_NONE, SK_PACING_NEEDED);
 }
@@ -952,3 +970,4 @@
 MODULE_AUTHOR("Soheil Hassas Yeganeh <[email protected]>");
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_DESCRIPTION("TCP BBR (Bottleneck Bandwidth and RTT)");
+// for Linux 4.14 by zhaoya the shabi!
           

有人就要問了，這麼做真的可以嗎？哦，我不明白所謂的可以指的是可以幹什麼…

  答案是，這麼做不可以，這麼做什麼都不可以，這隻是思路，這不是傳遞件！另外，這麼做很有可能你會付出成本代價…

  如今類似的神器已經太多了，我也不怕得罪誰，我就實話實說。當初醫院排隊，12306搶票，後來上海拍車牌，然後就是各種學區房的擠搶占…總之我們已經處于一個資源必須搶，搶不到就毀的現實中，所有人的心理都是趨向于損人不利己，請注意這個不利己詞，非常重要！不管自己成不成功，隻要别人失敗就行。

  這是典型的結果導向的惡果！我過不去，那麼大家就都别過去，就這麼簡單。延伸到技術，那就是TCP加速！BBR是一個很不錯的算法，然而它錯在開源，結果被一大幫懷着各種目的的人改參數放大招，結果就是網際網路傳輸通路越來越一塌糊塗，BBR給了人們犯罪的一把利器，一把沒有開刃的刀具，但絕不是一把沒有子彈的槍。

…

相信任何人都不希望傳播技術負能量，用技術手段去控制資源據為己有，如果有能力，也不會任由那些不懂裝懂的工具小子持續作惡。

後記

對了，昨天在高鐵站買了一本書，在非常累的時候看看也是不錯的，這本書是筆名二混子寫的《半小時漫畫世界史》，講得非常好，我一直都想自己寫一本這樣的集子，但最終還是行動力欠佳…本來我是想看看這本書之後對于細節跟作者線上讨教一番的，但是沒有發現可以怼的地方，是以我想線下讨教，有熟悉的人幫忙引薦一下，我想我和作者可以成為朋友…