BBR是谷歌與2016年提出的TCP擁塞控制演算法，在Linux4.9的patch中正式加入。該演算法一出，瞬間引起了極大的轟動。在CSDN上也有眾多大佬對此進行分析討論，褒貶不一。

  本文首先對原始碼進行了分析，並在此基礎上對BBR演算法進行總結。

####1.原始碼分析

/* Bottleneck Bandwidth and RTT (BBR) congestion control
 *
 * BBR congestion control computes the sending rate based on the delivery
 * rate (throughput) estimated from ACKs. In a nutshell:
 *
 *   On each ACK, update our model of the network path:
 *      bottleneck_bandwidth = windowed_max(delivered / elapsed, 10 round trips)
 *      min_rtt = windowed_min(rtt, 10 seconds)
 *   pacing_rate = pacing_gain * bottleneck_bandwidth
 *   cwnd = max(cwnd_gain * bottleneck_bandwidth * min_rtt, 4)
 *
 * pacing_rate和cwnd是整個演算法最關鍵的核心所在，他們隨著狀態的變化而改變，並以此在實際上控制TCP的發包
 *
 * The core algorithm does not react directly to packet losses or delays,
 * although BBR may adjust the size of next send per ACK when loss is
 * observed, or adjust the sending rate if it estimates there is a
 * traffic policer, in order to keep the drop rate reasonable.
 *
 * Here is a state transition diagram for BBR:
 *
 *             |
 *             V
 *    +---> STARTUP  ----+
 *    |        |         |
 *    |        V         |
 *    |      DRAIN   ----+
 *    |        |         |
 *    |        V         |
 *    +---> PROBE_BW ----+
 *    |      ^    |      |
 *    |      |    |      |
 *    |      +----+      |
 *    |                  |
 *    +---- PROBE_RTT <--+
 *
 * A BBR flow starts in STARTUP, and ramps up its sending rate quickly.
 * When it estimates the pipe is full, it enters DRAIN to drain the queue.
 * In steady state a BBR flow only uses PROBE_BW and PROBE_RTT.
 * A long-lived BBR flow spends the vast majority of its time remaining
 * (repeatedly) in PROBE_BW, fully probing and utilizing the pipe's bandwidth
 * in a fair manner, with a small, bounded queue. *If* a flow has been
 * continuously sending for the entire min_rtt window, and hasn't seen an RTT
 * sample that matches or decreases its min_rtt estimate for 10 seconds, then
 * it briefly enters PROBE_RTT to cut inflight to a minimum value to re-probe
 * the path's two-way propagation delay (min_rtt). When exiting PROBE_RTT, if
 * we estimated that we reached the full bw of the pipe then we enter PROBE_BW;
 * otherwise we enter STARTUP to try to fill the pipe.
 *
 * BBR is described in detail in:
 *   "BBR: Congestion-Based Congestion Control",
 *   Neal Cardwell, Yuchung Cheng, C. Stephen Gunn, Soheil Hassas Yeganeh,
 *   Van Jacobson. ACM Queue, Vol. 14 No. 5, September-October 2016.
 *
 * There is a public e-mail list for discussing BBR development and testing:
 *   https://groups.google.com/forum/#!forum/bbr-dev
 *
 * NOTE: BBR might be used with the fq qdisc ("man tc-fq") with pacing enabled,
 * otherwise TCP stack falls back to an internal pacing using one high
 * resolution timer per TCP socket and may use more resources.
 *
 * Without fq qdisc, there may be some problem about RTT fair when lots of BBR
 * flows share a network but with different RTT.
 * Long RTT may hold more throughput than little one.
 * 詳情可參考相關論文介紹：BBQ演算法
 *
 */
 

#include <linux/module.h>
#include <net/tcp.h>
#include <linux/inet_diag.h>
#include <linux/inet.h>
#include <linux/random.h>
#include <linux/win_minmax.h>

/* Scale factor for rate in pkt/uSec unit to avoid truncation in bandwidth
 * estimation. The rate unit ~= (1500 bytes / 1 usec / 2^24) ~= 715 bps.
 * This handles bandwidths from 0.06pps (715bps) to 256Mpps (3Tbps) in a u32.
 * Since the minimum window is >=4 packets, the lower bound isn't
 * an issue. The upper bound isn't an issue with existing technologies.
 */
 

#define BW_SCALE 24
#define BW_UNIT (1 << BW_SCALE)

/*個人推測這裡的BBR單位意思是使用kb作為單位，不知道理解的是否正確*/
#define BBR_SCALE 8	/* scaling factor for fractions in BBR (e.g. gains) */
#define BBR_UNIT (1 << BBR_SCALE)

/* BBR has the following modes for deciding how fast to send:
 * BBR四種標準狀態
 */
enum bbr_mode {
 

	BBR_STARTUP,	/* ramp up sending rate rapidly to fill pipe */
	BBR_DRAIN,	/* drain any queue created during startup */
	BBR_PROBE_BW,	/* discover, share bw: pace around estimated bw */
	BBR_PROBE_RTT,	/* cut inflight to min to probe min_rtt */
};

/* BBR congestion control block */
struct bbr {
	u32	min_rtt_us;	        /* min RTT in min_rtt_win_sec window */
	u32	min_rtt_stamp;	        /* timestamp of min_rtt_us */
	u32	probe_rtt_done_stamp;   /* end time for BBR_PROBE_RTT mode */
	struct minmax bw;	/* Max recent delivery rate in pkts/uS << 24 */
	u32	rtt_cnt;	    /* count of packet-timed rounds elapsed */
	u32     next_rtt_delivered; /* scb->tx.delivered at end of round */
	u64	cycle_mstamp;	     /* time of this cycle phase start */
	u32     mode:3,		     /* current bbr_mode in state machine */
		prev_ca_state:3,     /* CA state on previous ACK */
		packet_conservation:1,  /* use packet conservation? */
		restore_cwnd:1,	     /* decided to revert cwnd to old value */
		round_start:1,	     /* start of packet-timed tx->ack round? */
		tso_segs_goal:7,     /* segments we want in each skb we send */
		idle_restart:1,	     /* restarting after idle? */
		probe_rtt_round_done:1,  /* a BBR_PROBE_RTT round at 4 pkts? */
		unused:5,
		lt_is_sampling:1,    /* taking long-term ("LT") samples now? */
		lt_rtt_cnt:7,	     /* round trips in long-term interval */
		lt_use_bw:1;	     /* use lt_bw as our bw estimate? */
	u32	lt_bw;		     /* LT est delivery rate in pkts/uS << 24 */
	u32	lt_last_delivered;   /* LT intvl start: tp->delivered */
	u32	lt_last_stamp;	     /* LT intvl start: tp->delivered_mstamp */
	u32	lt_last_lost;	     /* LT intvl start: tp->lost */
	u32	pacing_gain:10,	/* current gain for setting pacing rate */
		cwnd_gain:10,	/* current gain for setting cwnd */
		full_bw_reached:1,   /* reached full bw in Startup? */
		full_bw_cnt:2,	/* number of rounds without large bw gains */
		cycle_idx:3,	/* current index in pacing_gain cycle array */
		has_seen_rtt:1, /* have we seen an RTT sample yet? */
		unused_b:5;
	u32	prior_cwnd;	/* prior cwnd upon entering loss recovery */
	u32	full_bw;	/* recent bw, to estimate if pipe is full */
};

#define CYCLE_LEN	8	/* number of phases in a pacing gain cycle */

/* Window length of bw filter (in rounds): */
static const int bbr_bw_rtts = CYCLE_LEN + 2;

/* 10s未更新最小RTT則進入PROBE_RTT
 * Window length of min_rtt filter (in sec): 
 */
static const u32 bbr_min_rtt_win_sec = 10;

/* Minimum time (in ms) spent at bbr_cwnd_min_target in BBR_PROBE_RTT mode: */
static const u32 bbr_probe_rtt_mode_ms = 200;
/* Skip TSO below the following bandwidth (bits/sec): */
static const int bbr_min_tso_rate = 1200000;

/* We use a high_gain value of 2/ln(2) because it's the smallest pacing gain
 * that will allow a smoothly increasing pacing rate that will double each RTT
 * and send the same number of packets per RTT that an un-paced, slow-starting
 * Reno or CUBIC flow would:
 *
 * 模擬cubic的增加曲線做出的增長係數，這裡類似於慢增長演算法
 */
static const int bbr_high_gain  = BBR_UNIT * 2885 / 1000 + 1;
/* The pacing gain of 1/high_gain in BBR_DRAIN is calculated to typically drain
 * the queue created in BBR_STARTUP in a single round:
 */
static const int bbr_drain_gain = BBR_UNIT * 1000 / 2885;
/* The gain for deriving steady-state cwnd tolerates delayed/stretched ACKs: */
static const int bbr_cwnd_gain  = BBR_UNIT * 2;
/* The pacing_gain values for the PROBE_BW gain cycle, to discover/share bw: */
/* 第一個RTT時間多傳送四分之一，第二次少傳送四分之一以排空佇列，之後以估計視窗值傳送6次，作為一整個迴圈*/
static const int bbr_pacing_gain[] = {
	BBR_UNIT * 5 / 4,	/* probe for more available bw */
	BBR_UNIT * 3 / 4,	/* drain queue and/or yield bw to other flows */
	BBR_UNIT, BBR_UNIT, BBR_UNIT,	/* cruise at 1.0*bw to utilize pipe, */
	BBR_UNIT, BBR_UNIT, BBR_UNIT	/* without creating excess queue... */
};
/* Randomize the starting gain cycling phase over N phases: */
static const u32 bbr_cycle_rand = 7;

/* Try to keep at least this many packets in flight, if things go smoothly. For
 * smooth functioning, a sliding window protocol ACKing every other packet
 * needs at least 4 packets in flight:
 *
 * 至少4個而不是1個是因為考慮到以下因素
 * （1）可能會有ACK延遲累積傳送機制存在
 * （2）往返各2各則一共至少4個
 */
static const u32 bbr_cwnd_min_target = 4;

/* To estimate if BBR_STARTUP mode (i.e. high_gain) has filled pipe... */
/* If bw has increased significantly (1.25x), there may be more bw available: */
static const u32 bbr_full_bw_thresh = BBR_UNIT * 5 / 4;
/* But after 3 rounds w/o significant bw growth, estimate pipe is full: */
static const u32 bbr_full_bw_cnt = 3;

/* "long-term" ("LT") bandwidth estimator parameters... */
/* The minimum number of rounds in an LT bw sampling interval: */
static const u32 bbr_lt_intvl_min_rtts = 4;
/* If lost/delivered ratio > 20%, interval is "lossy" and we may be policed: 
 * 論文中丟包率大於20%會有暴跌，就是這裡帶來的
 */
static const u32 bbr_lt_loss_thresh = 50;
/* If 2 intervals have a bw ratio <= 1/8, their bw is "consistent": */
static const u32 bbr_lt_bw_ratio = BBR_UNIT / 8;
/* If 2 intervals have a bw diff <= 4 Kbit/sec their bw is "consistent": */
static const u32 bbr_lt_bw_diff = 4000 / 8;
/* If we estimate we're policed, use lt_bw for this many round trips: */
static const u32 bbr_lt_bw_max_rtts = 48;

/* Do we estimate that STARTUP filled the pipe?檢測STARTUP是否結束 */
static bool bbr_full_bw_reached(const struct sock *sk)
{
	const struct bbr *bbr = inet_csk_ca(sk);

	return bbr->full_bw_reached;
}

/* Return the windowed max recent bandwidth sample, in pkts/uS << BW_SCALE. 最大探測頻寬*/
static u32 bbr_max_bw(const struct sock *sk)
{
	struct bbr *bbr = inet_csk_ca(sk);

	return minmax_get(&bbr->bw);
}

/* Return the estimated bandwidth of the path, in pkts/uS << BW_SCALE. 設定估計頻寬為LT_bw或者最大探測頻寬*/
static u32 bbr_bw(const struct sock *sk)
{
	struct bbr *bbr = inet_csk_ca(sk);

	return bbr->lt_use_bw ? bbr->lt_bw : bbr_max_bw(sk);
}

/* Return rate in bytes per second, optionally with a gain.
 * The order here is chosen carefully to avoid overflow of u64. This should
 * work for input rates of up to 2.9Tbit/sec and gain of 2.89x.
 */
static u64 bbr_rate_bytes_per_sec(struct sock *sk, u64 rate, int gain)
{
	rate *= tcp_mss_to_mtu(sk, tcp_sk(sk)->mss_cache);
	rate *= gain;
	rate >>= BBR_SCALE;
	rate *= USEC_PER_SEC;
	return rate >> BW_SCALE;
}

/* Convert a BBR bw and gain factor to a pacing rate in bytes per second. */
static u32 bbr_bw_to_pacing_rate(struct sock *sk, u32 bw, int gain)
{
	u64 rate = bw;

	rate = bbr_rate_bytes_per_sec(sk, rate, gain);
	rate = min_t(u64, rate, sk->sk_max_pacing_rate);
	return rate;
}

/* 初始化pacing rate
 * Initialize pacing rate to: high_gain * init_cwnd / RTT. 
 */
static void bbr_init_pacing_rate_from_rtt(struct sock *sk)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct bbr *bbr = inet_csk_ca(sk);
	u64 bw;
	u32 rtt_us;

	if (tp->srtt_us) {		/* any RTT sample yet? */
		rtt_us = max(tp->srtt_us >> 3, 1U);
		bbr->has_seen_rtt = 1;
	} else {			 /* no RTT sample yet */
		rtt_us = USEC_PER_MSEC;	 /* use nominal default RTT */
	}
	bw = (u64)tp->snd_cwnd * BW_UNIT;
	do_div(bw, rtt_us);
	sk->sk_pacing_rate = bbr_bw_to_pacing_rate(sk, bw, bbr_high_gain);
}

/* pacing_rate是控制速率的關鍵手段
 * Pace using current bw estimate and a gain factor. In order to help drive the
 * network toward lower queues while maintaining high utilization and low
 * latency, the average pacing rate aims to be slightly (~1%) lower than the
 * estimated bandwidth. This is an important aspect of the design. In this
 * implementation this slightly lower pacing rate is achieved implicitly by not
 * including link-layer headers in the packet size used for the pacing rate.
 */
static void bbr_set_pacing_rate(struct sock *sk, u32 bw, int gain)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct bbr *bbr = inet_csk_ca(sk);
	u32 rate = bbr_bw_to_pacing_rate(sk, bw, gain);

	/*如果未收到ACK則呼叫初始化速率*/
	if (unlikely(!bbr->has_seen_rtt && tp->srtt_us))
		bbr_init_pacing_rate_from_rtt(sk);	
	if (bbr_full_bw_reached(sk) || rate > sk->sk_pacing_rate)
		sk->sk_pacing_rate = rate;
}

/* Return count of segments we want in the skbs we send, or 0 for default. */
static u32 bbr_tso_segs_goal(struct sock *sk)
{
	struct bbr *bbr = inet_csk_ca(sk);

	return bbr->tso_segs_goal;
}

static void bbr_set_tso_segs_goal(struct sock *sk)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct bbr *bbr = inet_csk_ca(sk);
	u32 min_segs;

	min_segs = sk->sk_pacing_rate < (bbr_min_tso_rate >> 3) ? 1 : 2;
	bbr->tso_segs_goal = min(tcp_tso_autosize(sk, tp->mss_cache, min_segs),
				 0x7FU);
}

/* Save "last known good" cwnd so we can restore it after losses or PROBE_RTT 儲存上次使用的擁塞視窗*/
static void bbr_save_cwnd(struct sock *sk)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct bbr *bbr = inet_csk_ca(sk);

	if (bbr->prev_ca_state < TCP_CA_Recovery && bbr->mode != BBR_PROBE_RTT)
		bbr->prior_cwnd = tp->snd_cwnd;  /* this cwnd is good enough */
	else  /* loss recovery or BBR_PROBE_RTT have temporarily cut cwnd */
		bbr->prior_cwnd = max(bbr->prior_cwnd, tp->snd_cwnd);
}

/*擁塞視窗事件觸發：如果在探測階段則設定pacing rate*/
static void bbr_cwnd_event(struct sock *sk, enum tcp_ca_event event)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct bbr *bbr = inet_csk_ca(sk);

	if (event == CA_EVENT_TX_START && tp->app_limited) {
		bbr->idle_restart = 1;
		/* Avoid pointless buffer overflows: pace at est. bw if we don't
		 * need more speed (we're restarting from idle and app-limited).
		 */
		if (bbr->mode == BBR_PROBE_BW)
			bbr_set_pacing_rate(sk, bbr_bw(sk), BBR_UNIT);
	}
}

/* Find target cwnd. Right-size the cwnd based on min RTT and the
 * estimated bottleneck bandwidth:
 *
 * cwnd = bw * min_rtt * gain = BDP * gain 核心公式
 *
 * The key factor, gain, controls the amount of queue. While a small gain
 * builds a smaller queue, it becomes more vulnerable to noise in RTT
 * measurements (e.g., delayed ACKs or other ACK compression effects). This
 * noise may cause BBR to under-estimate the rate.
 *
 * To achieve full performance in high-speed paths, we budget enough cwnd to
 * fit full-sized skbs in-flight on both end hosts to fully utilize the path:
 *   - one skb in sending host Qdisc,
 *   - one skb in sending host TSO/GSO engine
 *	
 *   - one skb being received by receiver host LRO/GRO/delayed-ACK engine
 * 此處解釋為啥最少需要4個包	
 * Don't worry, at low rates (bbr_min_tso_rate) this won't bloat cwnd because
 * in such cases tso_segs_goal is 1. The minimum cwnd is 4 packets,
 * which allows 2 outstanding 2-packet sequences, to try to keep pipe
 * full even with ACK-every-other-packet delayed ACKs.
 */
static u32 bbr_target_cwnd(struct sock *sk, u32 bw, int gain)
{
	struct bbr *bbr = inet_csk_ca(sk);
	u32 cwnd;
	u64 w;

	/* If we've never had a valid RTT sample, cap cwnd at the initial
	 * default. This should only happen when the connection is not using TCP
	 * timestamps and has retransmitted all of the SYN/SYNACK/data packets
	 * ACKed so far. In this case, an RTO can cut cwnd to 1, in which
	 * case we need to slow-start up toward something safe: TCP_INIT_CWND.
	 */
	if (unlikely(bbr->min_rtt_us == ~0U))	 /* no valid RTT samples yet? */
		return TCP_INIT_CWND;  /* 初始值10 be safe: cap at default initial cwnd*/

	w = (u64)bw * bbr->min_rtt_us;

	/* Apply a gain to the given value, then remove the BW_SCALE shift. */
	cwnd = (((w * gain) >> BBR_SCALE) + BW_UNIT - 1) / BW_UNIT;

	/* Allow enough full-sized skbs in flight to utilize end systems. */
	cwnd += 3 * bbr->tso_segs_goal;

	/* Reduce delayed ACKs by rounding up cwnd to the next even number. */
	cwnd = (cwnd + 1) & ~1U;

	return cwnd;
}

/* 儲存視窗，方便從PROBE_RTT進入時恢復
 * An optimization in BBR to reduce losses: On the first round of recovery, we
 * follow the packet conservation principle: send P packets per P packets acked.
 * After that, we slow-start and send at most 2*P packets per P packets acked.
 * After recovery finishes, or upon undo, we restore the cwnd we had when
 * recovery started (capped by the target cwnd based on estimated BDP).
 *
 * TODO(ycheng/ncardwell): implement a rate-based approach.
 */
static bool bbr_set_cwnd_to_recover_or_restore(
	struct sock *sk, const struct rate_sample *rs, u32 acked, u32 *new_cwnd)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct bbr *bbr = inet_csk_ca(sk);
	u8 prev_state = bbr->prev_ca_state, state = inet_csk(sk)->icsk_ca_state;
	u32 cwnd = tp->snd_cwnd;

	/* An ACK for P pkts should release at most 2*P packets. We do this
	 * in two steps. First, here we deduct the number of lost packets.
	 * Then, in bbr_set_cwnd() we slow start up toward the target cwnd.
	 */
	if (rs->losses > 0)
		cwnd = max_t(s32, cwnd - rs->losses, 1);

	if (state == TCP_CA_Recovery && prev_state != TCP_CA_Recovery) {
		/* Starting 1st round of Recovery, so do packet conservation. */
		bbr->packet_conservation = 1;
		bbr->next_rtt_delivered = tp->delivered;  /* start round now */
		/* Cut unused cwnd from app behavior, TSQ, or TSO deferral: */
		cwnd = tcp_packets_in_flight(tp) + acked;
	} else if (prev_state >= TCP_CA_Recovery && state < TCP_CA_Recovery) {
		/* Exiting loss recovery; restore cwnd saved before recovery. */
		bbr->restore_cwnd = 1;
		bbr->packet_conservation = 0;
	}
	bbr->prev_ca_state = state;

	if (bbr->restore_cwnd) {
		/* Restore cwnd after exiting loss recovery or PROBE_RTT. */
		cwnd = max(cwnd, bbr->prior_cwnd);
		bbr->restore_cwnd = 0;
	}

	if (bbr->packet_conservation) {
		*new_cwnd = max(cwnd, tcp_packets_in_flight(tp) + acked);
		return true;	/* yes, using packet conservation */
	}
	*new_cwnd = cwnd;
	return false;
}

/* Slow-start up toward target cwnd (if bw estimate is growing, or packet loss
 * has drawn us down below target), or snap down to target if we're above it.
 */
static void bbr_set_cwnd(struct sock *sk, const struct rate_sample *rs,
			 u32 acked, u32 bw, int gain)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct bbr *bbr = inet_csk_ca(sk);
	u32 cwnd = 0, target_cwnd = 0;

	if (!acked)
		return;

	if (bbr_set_cwnd_to_recover_or_restore(sk, rs, acked, &cwnd))
		goto done;

	/* If we're below target cwnd, slow start cwnd toward target cwnd. */
	target_cwnd = bbr_target_cwnd(sk, bw, gain);
	if (bbr_full_bw_reached(sk))  /* only cut cwnd if we filled the pipe */
		cwnd = min(cwnd + acked, target_cwnd);
	else if (cwnd < target_cwnd || tp->delivered < TCP_INIT_CWND)
		cwnd = cwnd + acked;
	cwnd = max(cwnd, bbr_cwnd_min_target);

done:
	tp->snd_cwnd = min(cwnd, tp->snd_cwnd_clamp);	/* apply global cap */
	if (bbr->mode == BBR_PROBE_RTT)  /* drain queue, refresh min_rtt */
		tp->snd_cwnd = min(tp->snd_cwnd, bbr_cwnd_min_target);
}

/* End cycle phase if it's time and/or we hit the phase's in-flight target. */
static bool bbr_is_next_cycle_phase(struct sock *sk,
				    const struct rate_sample *rs)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct bbr *bbr = inet_csk_ca(sk);
	bool is_full_length =
		tcp_stamp_us_delta(tp->delivered_mstamp, bbr->cycle_mstamp) >
		bbr->min_rtt_us;
	u32 inflight, bw;

	/* The pacing_gain of 1.0 paces at the estimated bw to try to fully
	 * use the pipe without increasing the queue.
	 */
	if (bbr->pacing_gain == BBR_UNIT)
		return is_full_length;		/* just use wall clock time */

	inflight = rs->prior_in_flight;  /* what was in-flight before ACK? */
	bw = bbr_max_bw(sk);

	/* A pacing_gain > 1.0 probes for bw by trying to raise inflight to at
	 * least pacing_gain*BDP; this may take more than min_rtt if min_rtt is
	 * small (e.g. on a LAN). We do not persist if packets are lost, since
	 * a path with small buffers may not hold that much.
	 */
	if (bbr->pacing_gain > BBR_UNIT)
		return is_full_length &&
			(rs->losses ||  /* perhaps pacing_gain*BDP won't fit */
			 inflight >= bbr_target_cwnd(sk, bw, bbr->pacing_gain));

	/* A pacing_gain < 1.0 tries to drain extra queue we added if bw
	 * probing didn't find more bw. If inflight falls to match BDP then we
	 * estimate queue is drained; persisting would underutilize the pipe.
	 */
	return is_full_length ||
		inflight <= bbr_target_cwnd(sk, bw, BBR_UNIT);
}

static void bbr_advance_cycle_phase(struct sock *sk)
{
	struct tcp_sock *tp = tcp_sk(sk);
	struct bbr *bbr = inet_csk_ca 
 

            
  
           

              
              
            
            
相關推薦
			   
            
            
            
 

    

    
    
TCP擁塞控制演算法BBR原始碼分析
     
 
							
							
							  BBR是谷歌與2016年提出的TCP擁塞控制演算法，在Linux4.9的patch中正式加入。該演算法一出，瞬間引起了極大的轟動。在CSDN上也有眾多大佬對此進行分析討論，褒貶不一。
  本文首先對原始碼進行了分析，並在此基礎上對BBR演算法進行總結。
## 

  
 

    

    
    
Ubuntu16.04 x64伺服器配置最新tcp擁塞控制演算法bbr
     
 
								
								            
							
							
							BBR原理

不多說了，請看這篇博文！



配置步驟


用uname檢視linux核心版本，只有4.9以上的才支援bbr這個演算法。

uname -ir

# possible output

4 

  
 

    

    
    
幾種TCP擁塞控制演算法的分析
     
 
                幾種TCP擁塞控制演算法的分析擁塞控制演算法是實現TCP的重要元件，目前已有非常多的TCP Congestion Control Algorithm. 不同的演算法有自己的優化特性和工作區域。首先，本文簡單介紹一下TCP擁塞避免演算法的工作原理；其次，介紹Reno, Vega 

  
 

    

    
    
TCP擁塞控制演算法 優缺點 適用環境 效能分析
     
 
								
								            
						
                
【摘要】對多種TCP擁塞控制演算法進行簡要說明，指出它們的優缺點、以及它們的適用環境。
【關鍵字】TCP擁塞控制演算法 
優點    缺點   適用環境公平性

公平性

公平性是在發生擁塞時各源端（ 

  
 

    

    
    
tcp擁塞控制演算法
     
 
                

需要說明一下，如果你不瞭解TCP的滑動視窗這個事，你等於不瞭解TCP協議。我們都知道，TCP必需要解決的可靠傳輸以及包亂序（reordering）的問題，所以，TCP必需要知道網路實際的資料處理頻寬或是資料處理速度，這樣才不會引起網路擁塞，導致丟包。

所以，TCP引入了 

  
 

    

    
    
TCP擁塞控制演算法 調整TCP擁塞控制演算法 TCP Congestion Avoidance Algorithm
     
 中美之間的線路質量不是很好，rtt較長且時常丟包。TCP協議是成也丟包，敗也丟包；TCP的設計目的是解決不可靠線路上可靠傳輸的問題，即為了解決丟包，但丟包卻使TCP傳輸速度大幅下降。HTTP協議在傳輸層使用的是TCP協議，所以網頁下載的速度就取決於TCP單執行緒下載的速度（因為網頁就是單執行緒下載的）。丟包使 

  
 

    

    
    
使用標準方式在 Ubuntu 16.04 下啟用 TCP 擁塞控制之 BBR
     
 
                BBR 簡介BBR 是 Google 推出的一個「TCP 擁塞控制演算法」，它是以 Linux 核心模組的形式載入，可以最大化 Linux Server 的網路吞吐量。簡單地說，開啟 BBR 的 Linux Server 和不開啟 BBR 的 Linux Server，在持續 

  
 

    

    
    
網路擁塞控制之TCP擁塞控制演算法
     
 
							
							
							

為了防止網路的擁塞現象，TCP提出了一系列的擁塞控制機制。最初由V. Jacobson在1988年的論文中提出的TCP的擁塞控制由“慢啟動(Slow start)”和“擁塞避免(Congestion avoidance)”組成，後來TCP Reno版本中又針 

  
 

    

    
    
TCP擁塞控制演算法 — CUBIC的補丁（四）
     
 
                
描述

以下是提交者Stephen Hemminger對這個patch的描述：
enable high resolution ack time if needed
This is a refined version of an earlier patch by Lucas  

  
 

    

    
    
來自Google的TCP BBR擁塞控制演算法解析
     
 
  寫本文的初衷一部分來自於工作，更多的來自於發現國內幾乎還沒有中文版的關於TCP bbr演算法的文章，我想搶個沙發。本文寫於2016/10/15！
         本文的寫作方式可能稍有不同，之前很多關於OpenVPN，Netfilt 

  
 

    

    
    
開啟TCP BBR擁塞控制演算法
     
 
							
							
							什麼是BBR

　　TCP BBR是谷歌出品的TCP擁塞控制演算法。TCP-BBR的目標就是最大化利用網路上瓶頸鍊路的頻寬，儘量跑滿頻寬，並且儘量不要有排隊的情況。BBR可以起到單邊加速TCP連線的效果。 
　　BBR演算法，Google已經提交到Linux主線 

  
 

    

    
    
現代網際網路的TCP擁塞控制(CC)演算法評談
     
 
							
							
							動機

寫這篇文章本質上的動機是因為前天發了一個朋友圈，見最後的寫在最後，但實際上，我早就想總結總結TCP擁塞控制演算法點點滴滴了，上週總結了一張圖，這周接著那些，寫點文字。

前些天，Linux中國微信公眾號推了一篇文章，上班路上仔細閱讀了一下，感受頗深，一方 

  
 

    

    
    
Google's BBR擁塞控制演算法模型解析
     
                 在進入這篇文章的正文之前，我還是先交代一下背景。1.首先，我對這次海馬臺風對深圳的影響非常準確，看過我朋友圈的都知道，沒看過的也沒必要知道，白賺了一天”在家辦公“是收益，但在家辦公著實效率不高，效果不好。2.我為什麼可以在週五的早上連發3篇部落格，一方面為了彌補因為颱風造成”在 

  
 

    

    
    
Linux Kernel 4.9中BBR擁塞控制演算法的優勢
     
 
                

本文轉載自《Linux Kernel 4.9 中的 BBR 演算法與之前的 TCP 擁塞控制相比有什麼優勢？》

中國科大 LUG 的 @高一凡 在 LUG HTTP 代理伺服器上部署了 Linux 4.9 的 TCP BBR 擁塞控制演算法。從科大的移動出口到新加坡 D 

  
 

    

    
    
TCP擁塞控制——慢開始與擁塞避免演算法
     
 
                

1.引言

計算機網路中的頻寬、交換結點中的快取和處理機等，都是網路的資源。在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能就會變壞。這種情況就叫做擁塞。

擁塞控制就是防止過多的資料注入網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控 

  
 

    

    
    
Google BBR擁塞控制演算法模型初探
     
 

女主宣言
本文出自於ADDOPS團隊，該文章是一篇興趣觸發的探索性文章，作者是一名剛畢業的小鮮肉，買新系統，去自己探索bbr演算法，難能可貴，並且給出了詳細的部署步驟，也能讓大家在興趣之餘跟著步驟試一把，並且簡單描述了該演算法的使用場景和基本原理。bbr在劣質網路下能充分利用頻寬，並且也已經併入了新版本的 

  
 

    

    
    
TCP協議滑動視窗協議以及擁塞控制演算法
     
 
                

http://blog.csdn.net/liuchen1206/article/details/8599542
什麼是滑動視窗協議？ 

   一圖勝千言，看下面的圖。簡單解釋下，傳送和接受方都會維護一個數據幀的序列，這個序列被稱作視窗。傳送方的視窗大小由接受方確定，目 

  
 

    

    
    
tcp/ip下，擁塞控制演算法
     
 
                

TCP的RTT演算法

從前面的TCP重傳機制我們知道Timeout的設定對於重傳非常重要。
設長了，重發就慢，丟了老半天才重發，沒有效率，效能差；設短了，會導致可能並沒有丟就重發。於是重發的就快，會增加網路擁塞，導致更多的超時，更多的超時導致更多的重發。
而且，這個超時 

  
 

    

    
    
TCP擁塞控制算法縱橫談-Illinois和YeAH
     
 平鋪   val   就會   變種   進一步   window   red   loss   原理   
周五晚上。終於下了雨。所以也終於能夠亂七八糟多寫點松散的東西了...方法論問題。這個題目太大以至於內容和題目的關聯看起來有失偏頗。只是也無所謂，既然被人以為“沒有方法論”而歧視了。這裏也就拋出一些偽 

  
 

    

    
    
讓人非常easy誤解的TCP擁塞控制算法
     
 先來   模塊   階段   聯網   進程   分布   detail   體驗   尊重   
正文非常多人會覺得一個好的TCP擁塞控制算法會讓連接加速，這樣的觀點是錯誤的。恰恰相反，全部的擁塞控制算法都是為了TCP能夠在貪婪的時候懸崖勒馬，大多數時候。擁塞控制是減少了數據發送的速度。        我