㈠ 手機怎麼設置提高網速
不管是在家或者出門，相信大家都會遇倒網速突然變慢的問題，可能有些小夥伴會以為是5G出來了，所以4G給限速了，其實不是的，在過去一年，4G用戶就提升了近一倍，但是基站並沒有提升這么多呀，就像是一個WiFi你一個人用跟一大家子人用一樣，總會慢下來的，不過如果經常遇到這種事情倒是很煩心的，今天就給大家分享一個提高網速的方法，能夠瞬間提高網速喲！下面將會有具體的方法，可以讓手機設置裡面調節一下，就能夠提高網速，效果真的很明顯。
現在這里拿vivo手機為例，（帶殼截圖沒找到安卓手機，見諒~）其實安卓手機都是相差不多的，如果有小夥伴使用的手機找不到這些選項，可以在評論區發個言，咱知無不言，言而有信，有問必答！首先我們打開設置，找到「移動網路」選擇你的流量主卡點擊進入，選擇新建一個接入點（APN）；
點擊「新建接入點」，在「APN」處輸入「CMETS」,「MCC」處輸入「460」，「MNC」處輸入「01」，之後我們點擊完成，這樣的一套設置下來，你再使用就會發現網速有所提高啦。
那麼上方是安卓手機的教程，蘋果手機也是可以採用類似這樣的方法，步驟如下：
首先打開設置找到「無線區域網」，點擊「感嘆號」，選擇配置DNS，這個時候我們選擇「手動」，在點擊「添加伺服器」，在裡面輸入「114.114.114.114」，最後點擊存儲即可；
那麼網速是與信號直接畫上勾的，iPhone手機的因特爾基帶有缺陷，屬於先天問題，沒辦法進行根治，只能緩解，如果你所在的區域信號本就不好，使用體驗差到沒邊的話，推薦你還是換上一部安卓手機作為備用吧！那麼更換手機的時候可要記得備份好重要數據，如果無意丟失，可以使用它來恢復。
㈡ 華為手機apn怎麼設置網速快
手機APN怎樣設置網速最快呢？APN指一種網路接入技術，用戶通過手機上網時必須配置APN參數，它可以決定了手機連接移動網路的方式。通過修改APN參數連接到用戶較少的APN接入點可以避免網路擁堵，提高手機移動數據網路速度及穩定性。
華為手機（其他品牌手機修改方法大致相同）：
1、打開手機設置 –> 移動網路 –> 移動數
據 –> 選擇你用於上網的卡 –> 選擇接入點名稱（APN）。
2、新建APN，名稱可以隨意填寫，APN參數最重要，需要根據網路類型設置相應參數，例如移動卡：默認的APN是【cmnet】，可以試試用戶較少的【cmtds】APN接入點。聯通卡：默認APN是【3gnet】，建議試試【uninet】和【wonet】兩個接入點。其他參數如非必要默認設置即可，完成後保存一下。
3、選擇新建的APN接入點，用網速測試軟體可以判斷網速是否得到提升（測速大概需要10~100M流量）。
㈢ TCP擁塞控制及BBR原理分析
導語：TCP擁塞控制不僅僅是網路層的概念，可以將其歸屬於控制論的范疇。在TCP的演進過程中，出現了很多優秀的思想和演算法，以實現網路傳輸過程中，在公平競爭性的前提下，盡可能地利用帶寬資源。本文介紹TCP發展過程中出現的幾種擁塞控制演算法，並著重介紹BBR的原理。
TCP擁塞控制不僅僅是網路層的概念，可以將其歸屬於控制論的范疇。在TCP的演進過程中，出現了很多優秀的思想和演算法，以實現網路傳輸過程中，在公平競爭性的前提下，盡可能地利用帶寬資源。
公平性是在發生擁塞時各源端（或同一源端建立的不同TCP連接或UDP數據報）能公平地共享同一網路資源（如帶寬、緩存等）。處於相同級別的源端應該得到相同數量的網路資源。產生公平性的根本原因在於擁塞發生必然導致數據包丟失，而數據包丟失會導致各數據流之間為爭搶有限的網路資源發生競爭，爭搶能力弱的數據流將受到更多損害。因此，沒有擁塞，也就沒有公平性問題。
TCP層上的公平性問題表現在兩方面：
（1）面向連接的TCP和無連接的UDP在擁塞發生時對擁塞指示的不同反應和處理，導致對網路資源的不公平使用問題。在擁塞發生時，有擁塞控制機制的TCP會按擁塞控制步驟進入擁塞避免階段，從而主動減小發送到網路的數據量。但對無連接的數據報UDP，由於沒有端到端的擁塞控制機制，即使網路出現了擁塞，也不會減少向網路發送的數據量。結果遵守擁塞控制的TCP數據流得到的網路資源越來越少，沒有擁塞控制的UDP則會得到越來越多的網路資源。
（2）TCP連接之間也存在公平性問題。產生問題的原因在於使用了不同的擁塞控制演算法，一些TCP在擁塞前使用了大窗口尺寸，或者它們的RTT較小，或者數據包比其他TCP大，這樣它們也會多佔帶寬。
擁塞控制主要包括四個過程：1）慢啟動；2）擁塞避免；3）擁塞發生；4）快速恢復。
RTT ：數據包從發出去到收到對它的ack的來回時間，採用平滑方式計算RTT
RTO ：重傳超時。簡單的如RTO=n*RTT, n=3（或其他RTO計算方法）
SACK ：TCP Option攜帶多組ACK信息
FR ：Fast Retransmission，收到3個p ack後，即可認為發生了丟包。不需要等待RTO超時即可重傳丟失的包。
ER ：Early Retransmission，無法產生足夠的pack和沒有新的數據包可以發送進入網路的情況下，減少觸發FR的p ack數量，以達到觸發FR的目的。
TLP ：如果發生了尾丟包，由於尾包後面沒有更多的數據包，也就沒有辦法觸發任何的pack。實際上，Google統計超過70%的RTO是尾丟包導致沒有任何p
ack 。TLP演算法是通過發送一個loss probe包，來產生足夠的SACK/FACK的信息以觸發RF。
Pacing ：控制發送速率，防止bursting
流控 ：Flow control站在單條TCP連接的維度，目的是讓發送方發包的速度，不超過接收方收包的能力。所以流控解決的問題是，如何在接收方可承受的范圍內，讓單條 TCP 連接的速度最大化。通過滑動窗口機制實現。
擁塞控制 ：Congestion control站在整個互聯網的維度，讓網路里所有TCP連接最大化共享網路通道的同時，盡可能的少出現網路擁塞現象，讓網路世界裡的每一個參與者既公平又高效。
cwnd ：發送窗口，擁塞窗口；在擁塞控制過程中窗口大小值變化。
rwnd ：接收窗口，通知發送者能夠發送的數據大小。
sliding window ：滑動窗口，只是一種抽象機制概念；在發送請求及收到ack的過程中滑動。
歷史上出現的各種TCP擁塞控制演算法，其本質是針對擁塞控制的四個過程做策略調整。按照演算法依據的因素，可以簡單的分為以下類型：
因為Reno等演算法是後續演算法的基礎，這里詳細的描述下Reno演算法的過程。
（1）慢熱啟動演算法 – Slow Start
（2）擁塞避免演算法 – Congestion Avoidance
當cwnd >= ssthresh時，就會進入「擁塞避免演算法」。演算法如下：
（3）擁塞狀態演算法 – Fast Retransmit
Tahoe是等RTO超時，FR是在收到3個plicate ACK時就開啟重傳，而不用等到RTO超時。擁塞發生時：
（4）快速恢復 – Fast Recovery
Reno演算法以其簡單、有效和魯棒性，應用最廣泛。該演算法所包含的慢啟動、擁塞避免和快速重傳、快速恢復機制，是現有的眾多演算法的基礎。從Reno運行機制中很容易看出，為了維持一個動態平衡，必須周期性地產生一定量的丟失，再加上AIMD機制--減少快，增長慢，尤其是在大窗口環境下，由於一個數據報的丟失所帶來的窗口縮小要花費很長的時間來恢復，這樣，帶寬利用率不可能很高且隨著網路的鏈路帶寬不斷提升，這種弊端將越來越明顯。另外，丟包並不一定是網路擁塞，可能是網路常態，但是基於丟包的擁塞控制並不能區分。
vegas通過對RTT的非常重的監控來計算一個基準RTT。然後通過這個基準RTT來估計當前的網路實際帶寬，如果實際帶寬比我們的期望的帶寬要小或是要多的活，那麼就開始線性地減少或增加cwnd的大小。
中間路由器緩存數據導致RTT變大，認為發生擁塞；RTT不公平性，當不同的數據流對網路瓶頸帶寬進行競爭時，具有較小RTT的TCP數據流的擁塞窗口增加速率將會快於具有大RTT的TCP數據流，從而將會佔有更多的網路帶寬資源。
在發送端做帶寬估計，當探測到丟包時，根據帶寬值來設置擁塞窗口、慢啟動閾值。 那麼，這個演算法是怎麼測量帶寬的？每個RTT時間，會測量一次帶寬，測量帶寬的公式很簡單，就是這段RTT內成功被ACK了多少位元組。Westwood會根據RTT變化來判斷丟包是否是網路擁塞造成的，還是網路常態的丟包。如果時延變化不明顯，就認為是非網路擁塞，此時cwnd減少的比較小。
BIC-TCP是Linux 2.6.18默認擁塞控制演算法，依賴丟包條件觸發。BIC-TCP認為TCP擁塞窗口調整的本質就是找到最適合當前網路的一個發送窗口，為了找到這個窗口值，TCP採取的方式是(擁塞避免階段)每RTT加1，緩慢上升，丟包時下降一半，接著再來慢慢上升。BIC-TCP的提出者們看穿了事情的本質，其實這就是一個搜索的過程，而TCP的搜索方式類似於逐個遍歷搜索方法，可以認為這個值是在1和一個比較大的數(large_window)之間，既然在這個區間內需要搜索一個最佳值，那麼顯然最好的方式就是二分搜索思想。
BIC-TCP就是基於這樣一個二分思想的：當出現丟包的時候，說明最佳窗口值應該比這個值小，那麼BIC就把此時的cwnd設置為max_win，把乘法減小後的值設置為min_win，然後BIC就開始在這兩者之間執行二分思想--每次跳到max_win和min_win的中點。
BIC也具備RTT的不公平性。RTT小的連接，窗口調整發生的速度越快，因此可能更快的搶占帶寬。
CUBIC在設計上簡化了BIC-TCP的窗口調整演算法，在BIC-TCP的窗口調整中會出現一個凹和凸(這里的凹和凸指的是數學意義上的凹和凸，凹函數/凸函數)的增長曲線，CUBIC使用了一個三次函數(即一個立方函數)，在三次函數曲線中同樣存在一個凹和凸的部分，該曲線形狀和BIC-TCP的曲線圖十分相似，於是該部分取代BIC-TCP的增長曲線。另外，CUBIC中最關鍵的點在於它的窗口增長函數僅僅取決於連續的兩次擁塞事件的時間間隔值，從而窗口增長完全獨立於網路的時延RTT，使得連接之間保持良好的RRTT公平性。
來看下具體細節：當某次擁塞事件發生時，Wmax設置為此時發生擁塞時的窗口值，然後把窗口進行乘法減小，乘法減小因子設為β，當從快速恢復階段退出然後進入到擁塞避免階段，此時CUBIC的窗口增長開始按照「凹」式增長曲線進行增長，該過程一直持續直到窗口再次增長到Wmax，緊接著，該函數轉入「凸」式增長階段。該方式的增長可以使得窗口一直維持在Wmax附近，從而可以達到網路帶寬的高利用率和協議本身的穩定性。
CUBIC窗口的增長函數：W(t) = C * (t-K)3 + Wmax, 其中C和β為常量。
t為當前時間距上一次窗口減小的時間差，而K就代表該函數從W增長到Wmax的時間周期。
通俗一點講，假如我們知道了Wmax，那麼CUBIC的核心思想就是需要在連續兩次擁塞期間執行完上面的三次函數增長曲線
BBR通過實時計算帶寬和最小RTT來決定發送速率pacing rate和窗口大小cwnd。完全摒棄丟包作為擁塞控制的直接反饋因素。
傳統的擁塞控制演算法是計算cwnd值來規定當前可以發送多少數據，但是並不關注以什麼樣的速度發送數據。如果簡單而粗暴地將窗口大小（send.cwnd、recv.cwnd的最小值）數據全部突發出去，這往往會造成路由器的排隊，在深隊列的情況下，會測量出rtt劇烈地抖動。bbr在計算cwnd的同時，還計算了一個與之適配的pacing rate，該pacing rate規定cwnd指示的一窗數據的數據包之間，以多大的時間間隔發送出去。
我們知道，網路工作的最優點是在物理鏈路延遲狀態下，以最大速率傳輸數據。傳統的擁塞控制演算法思想是根據數據傳輸及ACK來確定RTT，但是這個RTT並不是物理鏈路延時，可能包含了路由器緩存耗時，也可能是擁塞狀態下的耗時。傳統的帶寬計算也是在不斷的試探逼近最優發送窗口，並在RTT或者統計周期內計算帶寬。這種情況下，RTT並不是真正的物理鏈路延遲，帶寬也有可能是在有路由緩存或丟包狀況下計算得到，那麼必然得到的不是精準的值。
BBR摒棄了丟包和實時RTT作為擁塞控制因素。引入BDP管道容量來衡量鏈路傳輸水平。BBR追求的是在鏈路最小RTT（物理鏈路延遲）的狀態下，找到最大帶寬。
首先我們認為網路最優點是可以達到的。下面描述RTT及收包速率與數據包投遞速率的關系。
圖中上半部分的過程可以描述為：隨著數據包投遞速率增加，如果沒有超過最優帶寬，則RTT不會變化，此時的RTT是物理鏈路延遲。隨著投遞速率繼續增加，這時中間路由節點可能出現需要緩存數據包的情況，這會導致RTT變大。如果投遞速率繼續增加，超過路由緩存能力，則可能出現丟包。
圖中下半部分的過程可以描述為：隨著數據包投遞速率增加，如果沒有超過最優帶寬，則發送方確認接收端收到的數據速率增加。隨著投遞速率繼續增加，因為數據包緩存在中間路由，這些包並不能及時得到ACK，因此發送方得到的ACK速率，即發送發確認接收方收到數據的速率會維持不變。如果投遞速率繼續增加，超過路由緩存能力，則可能出現丟包。
1）應答了多少數據，記為delivered；
2）應答1）中的delivered這么多數據所用的時間，記為interval_us。
將上述二者相除，就能得到帶寬：bw = delivered/interval_us；該計算方法不關注數據包ack及順序，是純粹的標量。
我們可以根據圖示很容易算出從Delivered為7時的數據包被確認到X被確認為止，一共有12-7=5個數據包被確認，即這段時間網路上清空了5個數據包。我們便很容易算出帶寬值了。
當10s內沒有發現最小RTTProp時，就要進入ProbeRTT狀態。在ProbeRTT狀態，僅發4MSS/RTT(接近停止發送)，從而排空鏈路上的數據包，測量真實的RTTProp。這里帶來的一個問題是，在一個RTT時間內以4MSS速率發送可能會造成抖動，特別是長RTT場景。具體的參考willko文章《GBN手札-BBR實時大數據傳輸之痛》。
㈣ vivo手機網速很慢，要怎麼解決
1、打電話給運營商客服來刷新上網數據：由於運營商分配給每個賬號的存儲空間較小，使用時間長了，難免會因為積累了較大的歷史數據，從而造成手機上網速度過慢。用戶只需致電當地運營商的人工客服，尋求刷新數據的幫助，在15分鍾後進行一次開關機，上網速度問題便可以有效的解決，並有明顯的提升。
2、選擇設置CMTDS接入點提升網速：可以通過對手機的設置來提升上網速度。由於大部分手機都是CMNET或者CMWAP，因此在類似上下班高峰期，人流較為密集的區域，極易造成網路擁堵，因此改變接入點來躲避擁堵。
手機使用注意事項
1、需要注意當手機用流量上網卡頓，或者存在手機信號不好導致網路緩慢的時候，可以選擇換一張電話卡。電信卡網速雖快但是在很多地方一點都不太好，移動卡網速不快但是信號較穩定。
2、不明鏈接和不明網站不要點擊，點擊鏈接和網站都可能被下載惡意程序。安裝手機應用要謹慎，對於非正規渠道的盡量不要安裝，只要是知名的公司開發的應用一般都能在各大主流應用平台下載。
3、需要注意安卓手機不像蘋果有著嚴格的後台控制機制，所以要經常性的清理內存，換手機前要對舊的手機進行清理，通過進入工程模式三清數據是最快捷的一種清理數據方式。
以上內容參考人民網-手機信號差竟然是因為這些！3招教你提高手機信號、人民網-Wifi信號滿格 網速緩慢需調整
㈤ 如何開啟 Linux BBR 演算法提升網路速度
僅在Ubuntu，Arch，Manjaro 下測試過，其它發行版同理。
Arch/Manjaro
雖然 Arch/Manjaro 可以直接安裝 linux49 包。但默認沒有開啟 BBR。需要手動編譯。下載 manjaro/packages-corelinux49 包的所有文件，將 config 以及 config.x86_64 文件中的
# CONFIG_TCP_CONG_BBR is not setCONFIG_DEFAULT_CUBIC=y
改為
CONFIG_TCP_CONG_BBR=yCONFIG_DEFAULT_BBR=y
然後將 PKGBUILD 中第二三個 hash 改為 'SKIP'. 執行 makepkg -si 即可。
Ubuntu
Ubuntu 需要手動安裝：
$ mkdir linux49; cd linux49$ wget
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900-generic_4.9.0-040900.201612111631_amd64.deb$
wget
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-image-4.9.0-040900-generic_4.9.0-040900.201612111631_amd64.deb$
wget
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900_4.9.0-040900.201612111631_all.deb$
sudo dpkg -i '*.deb'
㈥ BBR演算法中輪數計算方法
輪數在擁塞演算法中是一個重要的概念，基於丟包的擁塞演算法中，比如reno演算法在擁塞避免階段，每輪進行一次擁塞窗口加1，bic演算法也是每輪進行一次擁塞窗口增加，只是增加的幅度不同，而基於時延的擁塞演算法，如vegas演算法，檢測出一輪內的最小rtt_us值，與rtt_min對比推斷得到當前網路的數據包排隊的情況。這些例子中可以看出，對於演算法的實現都需要考慮輪數的統計。
那演算法是如何計算輪數的呢？主要分為三種，一種形如reno，bic這類演算法中，輪數的計算建立在 某一輪能發送snd_cwnd個數據包，當累計了snd_cwnd個數據包確認，就為一輪結束。演算法中有個snd_cwnd_cnt變數用來累計當前輪已經收到了多少的數據包確認，當該值大於等於擁塞窗口snd_cwnd，就認為一輪結束了。
以reno為例，w為控制增窗的頻率快慢，reno中等於snd_cwnd
void tcp_cong_avoid_ai(struct tcp_sock *tp, u32 w)
{
if (tp->snd_cwnd_cnt >= w) { //累計了snd_cwnd個ack數據包
if (tp->snd_cwnd < tp->snd_cwnd_clamp)//未超過申明的最大窗口值
tp->snd_cwnd++;
tp->snd_cwnd_cnt = 0; //累計ack個數清零
} else {//累計ack個數
tp->snd_cwnd_cnt++;
}
}
第二類，如vegas這種基於時延的擁塞演算法中，用序列號進行區分，記錄某一輪的起始點對應的snd_nxt，當snd_nxt所對應的數據包沒有發生重傳，被接收端ack確認的時間即為一個rtt，也就是一輪，如下圖所示，數據包a被ack確認時，只有線段SEQ1以上的數據包是之後發送的，當這區間某個數據包被ack確認，說明已經經過了一輪rtt，新一輪中，只有線段SEQ2以上的數據包是之後發送的。
以vegas演算法為例，
if (after(ack, vegas->beg_snd_nxt)) {
/* Do the Vegas once-per-RTT cwnd adjustment. */
/* Save the extent of the current window so we can use this
* at the end of the next RTT.
*/
vegas->beg_snd_nxt = tp->snd_nxt;
...
}
第三種就是bbr演算法中所使用的輪數計算方法，用時間來區分，每個數據包發送都記錄當前交付到對端的數據包個數delivered，某一時刻T為一輪的起始點，對應的交付到對端個數為D，時間小於T的記錄的delivered都小於D，之後發送的數據包記錄的delivered都大於等於D，當接收端收到ack(sack)數據包對應發送的delivered大於等於D，說明T時刻之後發送的數據包至少有個一到達了接收端，即經過了一輪RTT。
如上圖所示，時刻T1所對應的tp->delivered 為D，那時刻T1右側發送的數據包都是之後發送的，記錄prior_delivered都大於等於D，當兩個重傳數據包被ack確認時，其對應的prior_delivered都為D，說明T1時刻之後發送的兩個數據包經過一個RTT傳輸已經被接收，已經經過了一輪，開始了新一輪，而此時tp->delivered為D+2，之後發送的數據包記錄的prior_delivered都大於等於D+2，當收到ack確認的數據包記錄的prior_delivered大於等於D+2，說明時間已經又過了一輪，新一輪已經開始。
/* See if we've reached the next RTT */
if (!before(rs->prior_delivered, bbr->next_rtt_delivered)) {
bbr->next_rtt_delivered = tp->delivered;
bbr->rtt_cnt++;
bbr->round_start = 1;
...
}
rs->prior_delivered就為每個ack(sack)確認的包發送時記錄的tp->delivered值，當其大於等於某一輪起始的delivered值，就為新一輪開始。
這三種不同的方法，bic演算法中這樣處理是由於比如窗口每輪增加5個包，並不是一輪結束後窗口加5，而是每經過1/5的窗口值就進行擁塞窗口加1的操作。vegas演算法中，需要統計一輪內最小rtt_us，需要知道某一輪的起始和結束點，定期的重置當前輪內追蹤到的最小rtt_us以及調整窗口值。然而，BBR演算法不僅負責擁塞避免階段的發包，而且還接管了擁塞丟包狀態下發包行為，而vegas演算法中的輪數計算只能用於不丟包的open/disorder狀態，假設某個時刻發生大面積丟包，擁塞窗口驟降，需要經過兩三輪的重傳才能重傳完畢，才能推進snd_una，進而更新輪數。這對BBR來說是非常不合適了，因為已經擁塞丟包了，網路狀況很有可能已經變差了，而這時卻因為計算出來的輪數偏小，不能及時的更新最大帶寬值，進而延遲了網路處於擁塞的狀態時間。
㈦ 手機為什麼用數據上網那麼慢怎麼辦
手機使用數據網路上網網速慢的原因如下：
1、手機使用的數據網路非4G網路，可以在手機設置應用頁面中將連接的數據網路切換為4G，即可提升網路速度；
2、手機信號所處區域內覆蓋的基站承載設備過多或者是基站信號不佳，導致網路訪問擁堵，可以在別的時段再使用數據網路；
㈧ OpenVZ 開啟 BBR 技術說明
首先，對 Google 公司發明的 BBR TCP 擁塞控制演算法表示致敬。
網上有大量的 OpenVZ 開啟 BBR 的帖子，但是基本上只有操作，沒有技術說明和分析。
本文的目的是這些帖子涉及到的技術以及相關思路進行一些說明。
所謂擁塞控制演算法，其要解決的問題是判斷網路是否擁堵，從而控制發包速率以及重傳等。
在 Google 的 BBR 出現之前，所有的擁塞控制演算法都是以是否丟包來作為判斷標准，一旦有丟包，就認為可能有網路擁塞，隨之降低發包速度。這類演算法在網路傳輸需要跨大洋，或者有一些外部干擾導致丟包的情況下，會誤判為網路擁塞。
BBR 演算法其判斷是否擁塞是基於數據包傳輸的網路延時。這是基於這樣一個事實：如果網路延時增加了，那麼有可能在某個設備上數據包有排隊，因此網路是已經過載了，需要降低速度。而對丟包，不進行傳輸速度的控制。其中後者對譬如中美之間的網路訪問這樣的案例速度上有質的提升。
當前大部分基於 OpenVZ 的虛擬機內核都不支持 BBR，因此需要把 TCP 協議棧運行在用戶態。
要在用戶態運行網路協議棧，我們使用的技術名為 LKL (Linux Kernel Library)，即將內核編譯成為一個動態鏈接庫，可以通過對指定程序設置 LD_PRELOAD 這個環境變數來使的該程序調用 LKL 中定義的函數而不是系統原生的函數。通過這種方式，我們調用的網路函數實際上使用了LKL中的網路函數，其是支持BBR的。關於 LD_PRELOAD 的更多信息，可以參考附錄鏈接。
要使用 LKL，我們需要在外部創建一個網路設備，然後將這個網路設備作為參數傳遞給 LKL，那麼流經該網路設備的流量就會被 LKL 處理。
出於簡要起見，對於本文涉及到 OpenVZ 虛擬機，我們稱呼其為 ss。
我們期望發往 ss 的流量直接被用戶態程序處理而不經過 ss 的 TCP 協議棧，而直接發送到 LKL 處理的網路設備。
要在進入 TCP 協議棧前劫持流量，這可以通過 iptables 改變 IP 包目的地址，使其轉變為通過 LKL 處理的網路設備來實現。至於改變成什麼 IP 地址取決於哪些路由表。一般簡單起見。可以改成和 LKL 處理的網路設備同一個網段。
在網上流行的帖子中，清一色用了 haproxy 放在應用程序前面，實際上這並不是必須的。完全可以在應用程序前面加上 LD_PRELOAD 來實現應用程序支持 BBR。另外，這個 Haproxy 也是一個普通的 Haproxy，沒什麼特殊的。
對於引入 Haproxy 的原因，我猜想除了後面我會提到 LKL 虛擬網路設備的問題，還可以通過在程序前端監聽多個埠，來轉發到後端同一個服務，從而達到流量分散比較容易隱藏的目的。
這里講到的 LKL 虛擬網路設備主要是指 tun/tap 中的 tap 設備。
在程序運行過程中 LKL 會去讀取虛擬網卡的內容，對環境變數中指定的 IP 地址進行響應，如果多個 LKL 都去讀取同一塊虛擬網卡，在數據源上可能會有沖突（譬如A程序已經讀取過導致B程序讀取不到？未驗證）。也可能會導致被劫持的 IP 地址沖突（譬如兩個 LKL 程序都配置了同一個 IP 地址）。因此在這種情況下需要用多個虛擬網卡（這會導致配置復雜和維護困難）或者就用 Haproxy 作為中間人，轉發請求到後端應用。我猜想這是網上帖子引入 Haproxy 的一個主要原因。
在網上的帖子中，能夠ping 10.0.0.2 那是使用了 LKL 應用程序開啟後才可以的。推測可能是 LKL 初始化的時候會自己開啟一些線程。
部署參考： https://blog.kuoruan.com/116.html
技術參考：
㈨ 擁塞演算法
基於包丟失檢測的 Reno、NewReno 或者 cubic 為代表，其主要問題有 Buffer bloat 和長肥管道兩種。和這些演算法不同，bbr 演算法會以時間窗口內的最大帶寬 max_bw 和最小 RTT min_rtt，並以此計算發送速率和擁塞窗口
RTProp : round-trip propagation time BtlBW : bottleneck bandwidth，bbr 演算法關於擁塞窗口的核心就是計算 BtlBW 和 RTprop，根據這兩者值計算 BDP
bbr 演算法輸出 pacing_rate 和 cwnd 兩個數據。pacing_rate 決定發包速率，cwnd 為窗口大小
TCP Tahoe 和 Reno
這兩個演算法是根據其第一次加入到4.3BSD的時間回溯命名的，兩個名字對應自其第一次出現時BSD的代號，而代號分別取自太浩湖（Lake Tahoe）和其附近的城市裡諾市
• Tahoe：如果收到三次重復確認——即第四次收到相同確認號的分段確認，並且分段對應包無負載分段和無改變接收窗口——的話，Tahoe演算法則進入快速重傳，將慢啟動閾值改為當前擁塞窗口的一半，將擁塞窗口降為1個MSS，並重新進入慢啟動階段
• Reno：如果收到三次重復確認，Reno演算法則進入快速重傳，只將擁塞窗口減半來跳過慢啟動階段，將慢啟動閾值設為當前新的擁塞窗口值，進入一個稱為「快速恢復」的新設計階段
Fast recovery
是Reno演算法新引入的一個階段，在將丟失的分段重傳後，啟動一個超時定時器，並等待該丟失分段包的分段確認後，再進入擁塞控制階段。如果仍然超時，則回到慢啟動階段
TCP Vegas
至1990年代中期，TCP量度延遲和RTT都是以傳輸緩存中最後一個被傳送的分段包為准。vegas通過度量傳輸緩存中每個傳送分段包來代替只量度一個分段包，通過每次度量的平均值來增加擁塞窗口。該演算法取名自內華達州最大的城市拉斯維加斯。不過由於一些資源公平性原因，該演算法並沒有在彼得森的實驗室之外廣泛部署。一些研究認為該演算法和其他擁塞演算法混合使用，可能會導致性能競爭不及其他演算法。在各種TCP擁塞演算法的比較研究中，Vegas被認為是最平滑的控制演算法，其次為CUBIC
TCP New Reno
TCP New Reno是對TCP Reno中快速恢復階段的重傳進行改善的一種改進演算法，其定義於RFC 6582，覆蓋了原有在RFC 3782和RFC 2582的舊定義。
在Reno的快速恢復中，一旦出現3次重復確認，TCP發送方會重發重復確認對應序列號的分段並設置定時器等待該重發分段包的分段確認包，當該分段確認包收到後，就立即退出快速恢復階段，進入擁塞控制階段，但如果某個導致重復確認的分段包到遇到重復確認期間所發送的分段包存在多個丟失的話，則這些丟失只能等待超時重發，並且導致擁塞窗口多次進入擁塞控制階段而多次下降。而New Reno的快速恢復中，一旦出現3次重復確認，TCP發送方先記下3次重復確認時已發送但未確認的分段的最大序列號，然後重發重復確認對應序列號的分段包。如果只有該重復確認的分段丟失，則接收方接收該重發分段包後，會立即返回最大序列號的分段確認包，從而完成重發；但如果重復確認期間的發送包有多個丟失，接收方在接收該重發分段後，會返回非最大序列號的分段確認包，從而發送方繼續保持重發這些丟失的分段，直到最大序列號的分段確認包的返回，才退出快速恢復階段。
New Reno在低錯誤率時運行效率和「選擇確認」（Selective ACKnowledgement，SACK）相當，在高錯誤率仍優於Reno
TCP Hybla
TCP Hybla旨在消除由於高延遲地面線路或者衛星無線鏈路下導致的RTT過長而對TCP鏈接的影響。它通過對擁塞窗口動態分析來修改，來減少對RTT的性能依賴
TCP BIC 和 CUBIC
TCP BIC（Binary Increase Congestion control）旨在優化高速高延遲網路（即根據RFC 1072所定義的「長肥網路」（long fat network，LFN））的擁塞控制，其擁塞窗口演算法使用二分搜索演算法嘗試找到能長時間保持擁塞窗口最大值的值。Linux內核在2.6.8至2.6.18使用該演算法作為默認TCP擁塞演算法。
CUBIC則是比BIC更溫和和系統化的分支版本，其使用三次函數代替二分演算法作為其擁塞窗口演算法，並且使用函數拐點作為擁塞窗口的設置值。Linux內核在2.6.19後使用該演算法作為默認TCP擁塞演算法
TCP Westwood和Westwood+
TCP Westwood改良自New Reno，不同於以往其他擁塞控制演算法使用丟失來測量，其通過對確認包測量來確定一個「合適的發送速度」，並以此調整擁塞窗口和慢啟動閾值。其改良了慢啟動階段演算法為「敏捷探測（Agile Probing）」，和設計了一種持續探測擁塞窗口的方法來控制進入「敏捷探測」，使鏈接盡可能地使用更多的帶寬。Westwood+使用更長的帶寬估計間隔和優化的濾波器來修正Westwood對ACK壓縮場景對帶寬估計過高的問題。通過以上改良，TCP Westwood系列演算法在有線網路和無線網路的擁塞控制上獲取平衡，尤其研究中針對於無線通信網路上
Compound TCP
復合TCP（Compound TCP）是微軟自己實現的TCP擁塞控制演算法，通過同時維護兩個擁塞窗口，來實現在長肥網路有較好的性能而又不損失公平性。該演算法在Windows Vista和Windows Server 2008開始廣泛部署，並通過補丁的方式回溯支持到Windows XP和Windows Server 2003。在Linux上也有一個舊版本的移植實現
TCP PRR
TCP PRR（TCP Proportional Rate Rection ）是旨在恢復期間提高發送數據的准確性。該演算法確保恢復後的擁塞窗口大小盡可能接近慢啟動閾值。在Google進行的測試中，能將平均延遲降低3~10%，恢復的超時減少5%。PRR演算法之後作為Linux內核3.2版本的默認擁塞演算法
TCP BBR
TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）是由Google設計，於2016年發布的擁塞演算法。以往大部分擁塞演算法是基於丟包來作為降低傳輸速率的信號，而BBR則基於模型主動探測。該演算法使用網路最近出站數據分組當時的最大帶寬和往返時間來創建網路的顯式模型。數據包傳輸的每個累積或選擇性確認用於生成記錄在數據包傳輸過程和確認返回期間的時間內所傳送數據量的采樣率。該演算法認為隨著網路介面控制器逐漸進入千兆速度時，與緩沖膨脹相關的延遲相比丟包更應該被認為是識別擁塞的主要決定因素，所以基於延遲模型的擁塞控制演算法（如BBR）會有更高的吞吐量和更低的延遲，可以用BBR來替代其他流行的擁塞演算法，例如CUBIC
QUIC Quick UDP Internet Connections
QUIC旨在提供幾乎等同於TCP連接的可靠性，但延遲大大減少。它主要通過兩個理解HTTP流量的行為來實現這一點：
第一個變化是在連接創建期間大大減少開銷。由於大多數HTTP連接都需要TLS，因此QUIC使協商密鑰和支持的協議成為初始握手過程的一部分。 當客戶端打開連接時，伺服器響應的數據包包括將來的數據包加密所需的數據。
QUIC使用UDP協議作為其基礎，不包括丟失恢復。相反，每個QUIC流是單獨控制的，並且在QUIC級別而不是UDP級別重傳丟失的數據。這意味著如果在一個流中發生錯誤，協議棧仍然可以獨立地繼續為其他流提供服務
QUIC包括許多其他更普通的更改，這些更改也可以優化整體延遲和吞吐量
每個數據包是單獨加密的，因此加密數據時不需要等待部分數據包。 在TCP下通常不可能這樣做，其中加密記錄在位元組流中，並且協議棧不知道該流中的更高層邊界。這些可以由運行在更上層的協議進行協商，但QUIC旨在通過單個握手過程完成這些
QUIC的另一個目標是提高網路切換期間的性能，例如當移動設備的用戶從WiFi熱點切換到移動網路時發生的情況。 當這發生在TCP上時，一個冗長的過程開始了：每個現有連接一個接一個地超時，然後根據需要重新創建。期間存在較高延遲，因為新連接需要等待舊連接超時後才會創建。 為解決此問題，QUIC包含一個連接標識符，該標識符唯一地標識客戶端與伺服器之間的連接，而無論源IP地址是什麼。這樣只需發送一個包含此ID的數據包即可重新創建連接，因為即使用戶的IP地址發生變化，原始連接ID仍然有效
QUIC在應用程序空間中實現，而不是在操作系統內核中實現。當數據在應用程序之間移動時，這通常會由於上下文切換而調用額外的開銷。 但是在QUIC下協議棧旨在由單個應用程序使用，每個應用程序使用QUIC在UDP上託管自己的連接
Chromium的網路堆棧同時打開QUIC和傳統TCP連接，並在QUIC連接失敗時以零延遲回退到TCP連接