㈠ 手机怎么设置提高网速
不管是在家或者出门，相信大家都会遇倒网速突然变慢的问题，可能有些小伙伴会以为是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连接