原标题：IPv4互联网的下半场，难说再见；IPv6互联网的上半场，顺势加速！
一、引言
2020年随着华为NewIP技术研究的发布，触及互联网体系、架构等层面的演进，使得下一代互联网再一次成为业界讨论的热点。IPv6还在路上，新一轮互联网革命性变化又要拉开帷幕了?
本文暂且不探讨这个前沿研究的技术以及对未来的影响，先看看在路上的IPv6互联网发展状况。记得若干年前有业内资深人士就曾说过IPv4向IPv6的演进犹如“为飞行中的飞机更换引擎”，IPv6升级改造更多是在做地址/协议层面相应软硬件相关IPv6特性的改造，满足终端、网络、内容应用等方面IPv6支持的要求，整体并没有触及更多下一代互联网体系、架构等层面的变革或调优。
若将2003年基于IPv6的Cernet2建设作为国内IPv6起端，17年时光荏苒;而从国内运营商2009年启动大规模IPv6试点改造为起点，如今已然10年;这么多年过去了，究竟国内IPv6发展如何?
本文简单分析了基于IPv4互联网的现状，对于国内IPv6发展情况进行多维度的观察和分析，希望能为大家带来一些新视角的看法。
二、基于IPv4互联网的下半场，难说再见
1. 互联网快速发展，IPv4地址资源已然成为发展瓶颈
现阶段全球互联网呈现以下几个特点：
其中很重要的一点就是宽带用户及终端数量将呈现爆炸性增长态势，据咨询机构预测，到2020年全球网民数量将达到26亿，物联网联网终端数量将达到500亿个的规模量级。
各类互联网应用需要海量的IP地址资源来标识和实现互联网数据通信，而目前全球IPv4地址资源基本耗尽，如非特殊情况，各区域RIR新IP地址申请均分配IPv6地址。(少量IPv4地址如/23等申请则视各RIR储备池及回收地址情况进行分配)
Source by：https://www.potaroo.net/tools/ipv4/index.html
现阶段私有地址转换(NAT)方案尽管能够一定程度上解决IPv4公有地址枯竭的问题，但已不能很好满足各类新兴互联网应用，同时也给用户溯源、网络可管可控等方面带来极大的复杂度;IPv4互联网发展面临最大瓶颈实质上是“万物互联”背景下IP地址匮乏，从而导致网络连通性无法扩展。
2. IPv4地址资源仍有挖掘空间，开源节流将大行其道
尽管各区域RIR储备池中基本耗尽，但早前分配出去的IPv4地址中仍有相当比例处于闲置状态(尤其是ARIN所分配的地址段，如美国若干大学及科研机构就手握大段地址。
Source by：https://www.potaroo.net/tools/ipv4/index.html
注：/8地址段约有1678万个IPv4地址。
受到市场需求及经济利益驱动，很多公司及机构(早期免费或低廉价格获得大段地址)开始对外交易其拥有的IPv4地址资源，存量闲置地址资源(据不完全统计至少约有5000+万个IP地址)的上市及交易将极大缓解部分地域及企业IPv4地址紧缺状况，某种程度上也使得IPv6显得并不是迫在眉睫。
但需要指出的是，各国IPv4地址数量及分布严重不均衡，美国约11.5亿(占所有可分配地址数的1/4，其中三大云计算提供商存量IPv4地址就达到1.2亿)，而部分国家面临IPv4地址资源严重不足、地址回收及交易难度较大等困难。
3. 基于IPv4的传统及新兴互联网应用依然发展强劲
尽管很多国家在战略层面都鼓励向IPv6互联网演进，但受到存量IPv4互联网基础设施投资保护、使用习惯、各类内容及应用对IPv6支持度等因素制约，IPv4互联网作为关键网络基础设施在5-10年内将继续获得大量Capex投入来优化承载各类传统及新兴的互联网应用。
对于IPv4应用发展中对于互联网的承载需求，业界各方除了千方百计挖掘IPv4公有地址资源、引入和完善各类NAT技术以求节约IPv4公有地址外，还根据VR/AR、全息通信、云游戏等新兴实时应用对于互联网在低延时、安全性、可靠性等方面的要求，不断引入定向HTTP、传输层安全(TLS)、QUIC、确定性网络(DetNet)等技术对互联网架构及功能模块进行创新完善。
简言之，基于IPv4的传统及新兴互联网应用依然发展强劲。
三、中国IPv6互联网刚进入上半场
1. 国内IPv6发展：起个大早、赶个晚集
国内在IPv6领域起步较早，基本与国际同步，早在1994年就建设了采用IPv6技术的中国教育科研网CERNET，并在2003年开始逐步升级为IPv6 only的Cernet2示范骨干网;2011年国家层面明确提出中国下一代互联网商用示范路线，在国家发改委等相关部委IPv6专项推动下国内运营商、内容提供商、软硬件设备厂商等产业链各方进行了各领域IPv6改造工作，初步实现了从用户侧-网络-应用侧全程IPv6业务的打通，产业链层面逐步向全面支持IPv6演进;从2013年开始国家发改委分批选择了北京、杭州等代表性城市建设下一代互联网示范城市，希望调动基础电信运营企业、广电企业、商业网站、设备制造企业等多方力量，推动下一代互联网与新一代移动通信、移动互联网、物联网、云计算、大数据等新兴信息技术融合应用。
如上，尽管国家层面在IPv6商用部署及推动上做了大量工作，但于2003年Cernet2建设起端的国内IPv6改造历经起落，直至2017年底国内IPv6发展状态仍然不甚理想：
2. 国内IPv6发展：2018年起进入加速模式
(1) 政府强势主导推动IPv6升级改造
为了扭转国内IPv6商用停滞不前的局面，2017年11月，中共中央办公厅、国务院办公厅印发了《推进互联网协议第六版(IPv6)规模部署行动计划》，在此背景下工信部于2018年开始全力推动IPv6规模部署各项工作，并在2019安排了网络就绪专项行动计划，以行政力量牵引IPv6产业链各方按照政府制定的目标加速IPv6发展。
截至2019年底国内IPv6终端/网络/应用基础设施等基本就绪((以下章节部分图表数据直接来源于www.china-ipv6.cn或在其基础上进行了数据分析，在此致谢，后续不再逐一说明)，推动了国内IPv6商用产业链初步形成，但还没有真正进入“市场化、自驱动”的商用生态阶段。
(2) 国内IPv6网络基础设施改造基本完成
作为承载着国内绝大多数通信网络及互联网应用流量的基础电信运营商，经过近10年持续投入，基本完成对终端、网关、固定网络(接入网、城域网、骨干网)、移动网络等IPv6化改造，截至2019年底国内IPv6网络基础设施已基本就绪。
(3) 国内IPv6内容(APP应用、网站、云服务)支持度明显提高
综上，互联网应用侧的IPv6改造已有明显进展，但仍有相当数量的公司及机构仍停留在表面的IPv6改造阶段，并未触及需要“真金白银”大量资源投入的底层IPv6改造。
(4) 国内IPv6地址申请、分配及IPv6用户渗透等加速推进
目前国内IPv6地址多从APNIC处直接申请获得(即从2400::/12地址段中分配，如中国电信申请的地址段为240e::/18，中国联通申请的地址段为2408:8000::/20)
截至2020年3月，根据APNIC数据，中国已获得47859块(/32)IPv6地址，位居世界第二(占全球已分配地址的比例已从4.92%上升至7.95%)。
而按照国内IPv6监测平台数据，截至2020年2月，中国大陆IPv6已分配地址用户数为13.4亿，IPv6活跃用户达到2亿(占比已达到23.55%)，IPv6活跃连接数达到了11.19亿(占比已达到65.78%)。
注1：已分配IPv6地址用户数指基础电信企业在近30天内为用户分配IPv6地址的数量
注2：IPv6活跃用户数是指具备IPv6网络接入环境，已获得IPv6地址，且在近30天内有使用IPv6协议访问网站或移动互联网应用(APP)的互联网用户数量.
注3：IPv6活跃连接数是基础电信企业统计得出的、已获得IPv6地址且在一个月内有访问记录或者流量记录的用户数，包括移动网IPv6活跃连接数和固定宽带IPv6活跃连接数。
此外，APNIC数据也从一个侧面印证了上述变化，截至2020年3月，中国IPv6用户占互联网用户占比已达15.42%(02 Aug 2018数据为0.49%)。
Source：https://labs.apnic.net/dists/v6dcc.html update Date: 25 Mar 2020
(5) 国内IPv6网络流量逐步加载，网络质量与IPv4网络基本相当
IPv6网络流量已逐步加载：
注：以上数据截至2020年2月，均为基础电信企业统计得出，取一天内平均流量。
根据国际IPv6发展经验，流量占比突破5%后将迎来一个快速发展的时间窗口，基于上述数据，LTE移动网络IPv6流量极有可能在丰富IPv6应用等举措激发下快速增长;国际出入口IPv6流入流出的数量级及占比充分说明境外IPv6内容丰富度较国内要高。
此外，上述数据表明中国电信在IPv6流量加载方面相对领先于其它两家运营商。
IPv6网络质量与IPv4基本趋同：截至2020年2月，国内IPv6网络平均网间时延39.73ms，平均网内时延46.9ms，在轻载流量负荷下IPv6网络质量与IPv4基本趋同。
(6) 国内IPv6软硬件、终端等趋向成熟，商用产业链初步形成
经过十多年的打磨，从2018年起主流软硬件厂商各类产品及终端等对于IPv6已经实现默认支持。
截至2020年3月，在LTE移动终端方面，苹果系统在iOS 12.1版本后，安卓系统在Android 8.0版本后，已全面支持IPv6，国内主流LTE移动终端基本支持在IPv4/IPv6双栈下运行;智能家庭网关方面，基础电信企业2018年以来集采的机型已全面支持IPv6;家庭无线路由器方面，市场占有量较大的普联、腾达、华硕、小米及友讯等五家厂商新出厂型号设备均默认支持IPv6(但IPv6性能及功能方面相对较弱)。
此外，随着国内各项IPv6政策落地及行政力量强力推动下，IPv6内容供给侧也有较大突破，用户使用IPv6意愿有所增强，初步建立了从用户-终端-网络-业务(内容)各方积极参与的IPv6商用产业链。
3. 国内IPv6发展存在的问题及挑战
3.1 国内市场IPv6发展内生动力不足
(1) 运营商网络基础设施IPv6承载能力初步具备，但离支持全面商用尚有较大差距
目前运营商IPv6网络改造基石仍然是IPv4/IPv6双栈，尽管已经实现IPv6用户的网络接入及流量承载，但规模IPv6用户及流量上线后实际承载及应用服务能力有待进一步验证;某种程度上IPv6规模商用场景下意味着现网双栈运行的关键网元设备性能将可能大幅下降甚至不堪重负，对运营商而言意味着追加大量额外投资重构基础设施或者需要考虑作出是否关闭IPv4协议栈的艰难决策。
如上原因，若面临IPv6规模流量增长带来Capex及Opex需要额外追加大量支出时，预计运营商在推动分配IPv6地址的用户使用IPv6网络的积极性将相对有限。
(2) 云服务关键基础设施及云产品IPv6全面支持尚需时日
云服务提供商云产品对IPv6的全面支持依赖于数据中心内外部网络设备层面的IPv6替换/升级，各类应用服务器集群、存储、中间件等相应代码层面的IPv6化修改等，但现阶段很多云产品还停留在内容应用的IPv6转换服务：如Web页面的IPv6化使得官网可以提供IPv6访问、提供IPv6与IPv4的转换服务使得IPv6用户能访问其IPv4服务器应用资源，尚处在IPv6基本支持阶段。
主流云商如阿里云、腾讯云等也都发布了各自的IPv6支持路线，乐观预计至少在2022年后才能全面支持IPv6。
(3) 用户特别是家庭用户使用IPv6意愿远不如使用IPv4
国内运营商在国家“提速降费”背景下运营压力巨大，在鼓励IPv6地址用户使用IPv6网络方面难以提供更具吸引力的优惠资费套餐，同时IPv6用户在有效获得IPv6应用资源方面仍旧面临瓶颈，很多APP及网站只是提供首屏/首页或一级连接的IPv6访问，并不能全面支持IPv6，使得IPv6访问体验一致性欠佳;受限于国家安全管控政策，IPv6国际互联互通带宽较小，尽管国内互联互通已支持IPv6，但相对有限的国内IPv6应用资源难以充分满足用户体验和需求，从而制约了用户使用IPv6的积极性。
如上，IPv6全程端到端的体验(包括但不限于网络质量、应用稳定性、主观体验等)较IPv4整体上还是有相当距离，影响了IPv6用户使用IPv6业务的积极性。
(4) 存量网关及家庭路由器大多不支持IPv6，新网关或家庭路由器设备有限支持IPv6
尽管运营商2018年起新采购并提供给客户的网关等设备能够基本支持IPv6(如IPv6地址分配获取等)，但家庭侧仍有大量存量网关及家庭路由器(据不完全统计，这部分比例约40%甚至更高)不支持IPv6，这部分存量资产还需要较长时间才能逐步被更新替代为全面支持IPv6，从一个侧面说明IPv6端到端打通仍面临最后一米的挑战。
(5) 国内IPv6内容侧供给严重不足
尽管Top互联网应用APP，国家及省级层面的政府类、大型央企、金融、教育等领域重点网站的IPv6支持度已有较明显提升，但在监测过程中也发现部分应用及网站还处在“应付”阶段，多为门户页面的IPv6改造，并未涉及深度的业务逻辑及功能IPv6化改造，并没有实质上实现对IPv6的全面支持(即网站对以IPv6地址访问的用户并未全面优先提供IPv6相应内容资源，更多分配得到IPv6地址的双栈用户实质上仍旧继续使用IPv4地址访问IPv4相应内容)，未能起到很好的示范引领作用。
上述IPv6内容侧供给严重不足背后的原因涉及到内容提供商大量的IPv6改造成本投入，市场化环境下各类内容提供商更多会从自身经济利益出发选择成本最低的IPv6支持方案满足国家政策要求，一方面等待IPv6用户和网络规模快速增长(市场驱动力)，一方面也在等待政府更多的支持政策(行政驱动力)。
基于成本考量及现阶段IPv6用户规模的实际，内容提供商缺乏足够的动力去做更佳体验、更深层次的IPv6应用和内容。
3.2 国内IPv6监测指标体系需要进一步完善
尽管国家层面制定了多个维度的IPv6专项推进考核指标及目标，但仔细分析下来还是会发现部分指标并不能很好体现实际的IPv6发展状态。
以IPv6活跃连接数为例，该指标定义为基础电信企业统计得出的、已获得IPv6地址且在一个月内有访问记录或者流量记录的用户数，也就意味着获得IPv6地址的用户只要在一个月内至少访问一次IPv6应用就会被计入，看到这是否觉得有些“放水”，个人认为这类数据对于IPv6商业运营而言参考价值并不高。
衡量IPv6商用化程度需要更多关注对标IPv4使用状况的指标，以下几个指标后续如果能纳入国家IPv6发展监测平台的话或许对IPv6商用态势研判更有参考价值：
3.3 IPv4向IPv6迁移，行政推动还是市场选择?
从经济学的角度，市场总是会寻求约束条件下的最优化配置，在IPv4互联网的下半场尚未散场之前，目前来看IPv4向IPv6迁移的市场驱动力仍旧不足，业界各方预计还是不会主动拥抱IPv6互联网。
为此顶层设计的战略层面若将IPv6互联网视作拉动新基建、提升数字化水平的关键领域，则需要国家层面出手，投入更多的资源和政策来加速IPv6规模商用并形成具备自生长能力的良好生态。
以上措施的落地将进一步激发和形成IPv6产业链良好的发展态势，在政府资源及政策推动下IPv6商用若能顺利到达加速发展的临界点，则可以考虑政府行政力量的逐步退出，让IPv6商用市场自由生长发展，相信届时挥别IPv4互联网也是自然而然的结果。
四、小结及展望
在国内发展基于IPv6的下一代互联网成为国家意志的背景下，工信部在2020年3月份下发了通信函〔2020〕57号《关于2020年开展IPv6端到端贯通能力提升专项行动的通知》，要求加快提升IPv6端到端贯通能力，持续提升IPv6活跃用户和网络流量规模，明确了七大重点任务和三大目标。
对于该通知提及的七项重点任务中，前四项(优化提升IPv6网络接入能力、加快提升内容分发网络(CDN)IPv6应用加速能力、大幅提升云服务平台IPv6业务承载能力、全面扩大数据中心(IDC)IPv6覆盖范围)及第七项(着力强化IPv6网络安全保障能力)仍然属于IPv6基础设施及支持能力的完善和提升，第五项(着力提升终端设备IPv6支持能力，即要求终端设备出厂默认支持IPv6、主要电商平台优先向用户推荐支持IPv6的终端设备、加速运营商存量家庭网关的更新替换)和第六项(稳步提升行业网站及互联网应用IPv6浓度，如已经穿透要求三级链接支持IPv6的占比要求超过85%)则是关注到了IPv6商用层面的真正短板所在。
而从三大目标来看，喜的是这一次工信部关注到了流量占比(尤其是尽快推动移动网络IPv6流量越过临界点进入快速增长阶段)对于IPv6商用的重要意义，忧的是仍然把IPv6活跃连接数看得很重，并没有把行业网站及互联网应用IPv6浓度等与IPv6商用运营紧耦合的指标纳入目标体系，同时还未看到更多措施落地相关的财政及税收政策细节披露，希望不要出现业界相关方只是以应付任务的方式来完成通知相应的要求。
IPv6风一直在吹，希望政府及各方已经或将要投入的大量资源能够真正转换为IPv6产业链加速发展的基石，同时建立更为科学合理的IPv6监测评价指标体系，及时调整完善和推动业界各项IPv6举措及相关政策落地，从而为国内民众及各行各业带来符合用户预期、具有更佳体验的IPv6互联网，早日实现IPv4向IPv6互联网的平滑演进和真正的规模商用。
多云管理与安全架构迁移
一、多云业务需求
根据Gartner的定义，多云是指企业同时拥有两个或多个云计算平台，在部署的时候可能会使用公有云、私有云或两者的某种组合。
用户的业务需求主要集中在以下几个方面：
1. 多云接入
2. 异构资源纳管
3. 计量计费
4. 运维监控
5. 安全管理
二、多云业务安全架构
首先给大家分享一下多云安全架构全景图
我们先从多云基础架构说起：
有了标准的多云基础架构，那么我们的安全基础架构就容易规划了。个人认为每家的多云管理系统差异化主要体现基础安全部分，应用安全部分可以使用多家产品。
1. 如果我们把底层架构都统一使用Kubernetes与Pod，那么，我们的多云基础架构安全其实是以容器安全为基矗那么基于容器的安全生态需要建立起来。
(1) 针对基础能力模型中的镜像仓库，我们需要有镜像仓库扫描，保证进入到整个安全平台的镜像是安全的。
(2) 针对Kubernetes与Pod需要做基线检查，当然部分基线配置需要在多云管理平台侧设置。这部分其实用过CIS_Kubernetes_benchmark 标准检测即可。
(3) 容器运行时安全，针对容器运行非授信进程、文件、网络连接需要限制。同时联动停止或者删除容器，控制网络连接。形成闭环容器安全治理。
2. 多云基础架构容器安全，需要寄生在宿主机上(例如：云主机、裸金属服务器、物理服务器)。所以主机安全需要支持安装在任何上述环境中。
3. 为了更好的了解整个多云集群操作状态，Kubernetes日志审计系统也是多云基础安全必备的功能之一。
4. 最后，能上多云管理系统的公司，肯定是组织架构复杂的，需要多方人员协调才能把安全运营闭环做好。
多云的应用安全部分
1. 多云抗D与多云WAF
很多游戏公司都很早就集成多云抗D解决方案了。前几年棋牌类游戏。公有云A的解决方案不行，马上通过调度系统切换，或者通过HTTPDNS，DNS自动切换。保证游戏业务的可用性。云WAF也是一个道理。
2. 自动化漏扫服务与安全众测
在多云场景中，可以选择购买多个自动化漏洞扫描工具，获取差异化漏洞扫描报告，同时目前国内公有云大部分都可以按次计费，方便在特定场景中实施(例如：重保、业务系统上线、例行安全巡检等)。
再谈谈安全众测的事，其实安全众测在安全圈也不是什么新鲜概念，但是伴随着多云安全的概念重新粉饰，将会得到极大的应用。毕竟多云的核心理念是获得各家厂商的安全能力。
三、多云安全的未来
虽然现在阶段多云管理安全解决方案是一个比较新的概念，在商业落地方面还比较薄弱，但是绝对是一个大的趋势，赶不上这个风口的公有云厂商未来的2~3年发展空间不会很大。google在这个浪潮中应该是最大的赢家，通过开源的容器编排系统Kubernetes，让企业级消费者接受并且可免费使用自己管控的系统，获得很大收益，其次通过Anthos架设多云管理平台，最终商业落地使用谷歌云变现。大厂就是有资源，玩颠覆，对抗AWS。针对国内后进公有云厂商，快速落地其多云管理产品，快速推向用户是当务之急。
浅谈TCP/IP传输层TCP BBR算法
0x00.前言
这是TCP/IP协议栈系列的第三篇文章，之前的一篇面试热点|理解TCP/IP传输层拥塞控制算法讲述了传统的拥塞控制算法基本原理，今天一起来学习下最新Linux内核中增加的拥塞控制算法：TCP BBR算法。
鉴于TCP拥塞控制算法背后有一套复杂的数学理论和控制策略，因此本文也只能是浅谈，通过本文你将了解到以下内容(温馨提示：文章较长需要一些耐心，也可以先收藏再阅读)：
0x01. 拥塞控制简史
大约在1988年之前TCP/IP是没有拥塞控制的，但是随着网络接入规模的发展之前仅有的端到端窗口控制已经无法满足要求，在1986年引发大规模网络瘫痪，此时就要提到一个重量级人物：Van Jacobson范雅各布森。
这位力挽狂澜的人物入选了计算机名人堂Internet Hall of Fame，Van Jacobson大神提出并设计实施了TCP/IP拥塞控制，解决了当时最大的问题，来简单看下Van Jacobson的维基百科简介(笔者做了部分删减)：
范雅各布森Van Jacobson是目前作为互联网技术基础的TCP/IP协议栈的主要起草者，他以其在网络性能的提升和优化的开创性成就而闻名。
2006年8月，他加入了帕洛阿尔托研究中心担任研究员，并在位于相邻的施乐建筑群的Packet Design公司担任首席科学家。在此之前，他曾是思科系统公司首席科学家，并在位于劳伦斯伯克利国家实验室的网络研究小组任领导者。
范雅各布森因为在提高IP网络性能提升和优化所作的工作而为人们所知，1988到1989年间，他重新设计了TCP/IP的流控制算法(Jacobson算法)，他因设计了RFC 1144中的TCP/IP头压缩协议即范雅各布森TCP/IP头压缩协议而广为人知。此外他也曾与他人合作设计了一些被广泛使用的网络诊断工具，如traceroute，pathchar以及tcpdump 。
范雅各布森于2012年4月入选第一批计算机名人堂，计算机名人堂简介：https://www.internethalloffame.org/inductees/van-jacobson
如图为Van Jacobson计算机名人堂的简介：
笔者找了Van Jacobson和Michael J. Karels在1988年11月发布的关于拥塞避免和控制的论文，总计25页，感兴趣的读者可以查阅：
我们常用的tracetoute和tcpdump也是van-jacobson大神的杰作，作为互联网时代的受益者不由得对这些互联网发展早期做出巨大贡献的开拓者、创新者、变革者心生赞叹和敬意。
0x02.传统拥塞控制算法回顾
2.1 算法目的
看到一篇文章说到TCP 传输层拥塞控制算法并不是简单的计算机网络的概念，也属于控制论范畴，感觉这个观点很道理。
TCP拥塞控制算法的目的可以简单概括为：公平竞争、充分利用网络带宽、降低网络延时、优化用户体验，然而就目前而言要实现这些目标就难免有权衡和取舍。
但是现在的网络通信基础设施水平一直在飞速提高，相信在未来的某个时间点这些目标都可以达到，小孩子才选择，我们大人全都要!
2.2 算法分类
在理解拥塞控制算法之前我们需要明确一个核心的思想：闻道有先后 术业有专攻，笔者觉得这是一个非常重要的共识问题，把A踩在泥土里，把B吹捧到天上去，都不是很好的做法。
实际的网络环境十分复杂并且变化很快，并没有哪个拥塞控制算法可以全部搞定，每一种算法都有自己的特定和适用领域，每种算法都是对几个关键点的权衡，在无法兼得的条件下有的算法选择带宽利用率，有的算法选择通信延时等等。
在明确这个共识问题之后，我们对待各个拥塞控制算法的态度要平和一些，不要偏激地认为谁就是最好，几十年前的网络状况和现在是截然不同的，我们永远都是站在巨人的肩膀之上的，这也是科学和文明进步的推动力。
传统拥塞控制算法并不是一蹴而就的，复杂的网络环境和用户的高要求推动着拥塞控制算法的优化和迭代，我们看下基于丢包策略的传统拥塞控制算法的几个迭代版本，如图所示：
与此同时还有一类算法是基于RTT延时策略来进行控制的，但是这类算法在发包速率上可能不够激进，竞争性能不如其他算法，因此在共享网络带宽时有失公平性，但是算法速率曲线却是很平滑，我们暂且把这类算法当做君子吧!
其中比较有名的Vegas算法是大约在1995年由亚利桑那大学的研究人员拉里彼得森和劳伦斯布拉科夫提出，这个新的TCP拥塞算法以内华达州最大的城市拉斯维加斯命名，后成为TCP Vegas算法。
关于基于RTT的TCP Vegas算法的详细介绍可以查阅文档：
http://www.cs.cmu.edu/~srini/15-744/F02/readings/BP95.pdf
文档对Vegas算法和New Reno做了一些对比，我们从直观图形上可以看到Vegas算法更加平滑，相反New Reno则表现除了较大的波动呈锯齿状，如图所示：
实际上还有更细粒度的分类，由于不是今天的重点，就不再深入展开了，当前使用的拥塞控制算法还是基于丢包Loss-Based作为主流。
2.3 算法原则
我们知道在网络链路中连接的数量是动态变化且数量巨大的，每一条连接都面临着一个黑盒子式的网络环境，这并不像我们平时出行时看看地图就知道哪里堵了，为了维护一个好的网络环境，每一条连接都需要遵守一些约定。
如果连接端都无所顾忌地发生数据包，那么网络链路很快就到了瓶颈了，数据通信完全无法保障，所以要到达一个稳定高效的网络环境还是需要费很大心思的，这其中有两个重要的概念：公平性和收敛性。
说来惭愧笔者在网络上找了很多资料去理解TCP拥塞控制的公平性和收敛性，但是仍然没有获得一个很好的权威解释，所以只能结合一些资料和自身的理解去阐述所谓的公平性和收敛性。
笔者认为公平性是相对于网络链路中的所有连接而言的，这些共享链路的连接启动和结束的时间不同，在实际的交互过程中每条连接占有带宽的机会是均等的，并且由于带宽限制连接双方通信的数据量是动态调整并且近似收敛于某个值，也就是呈现一个锯齿状或者更加平滑的波动曲线，对于基于丢包的拥塞控制算法而言AIMD线性增乘性减策略起了关键控制作用。
接下来我们来重点看下AIMD特性，先来贴一张经典的图，直观看AIMD的过程：
看看维基百科对于AIMD的定义：
The additive-increase/multiplicative-decrease(AIMD) algorithm is a feedback control algorithm best known for its use in TCP congestion control.
AIMD combines linear growth of the congestion window with an exponential reduction when congestion is detected.
Multiple flows using AIMD congestion control will eventually converge to use equal amounts of a shared link.
The related schemes of multiplicative-increase/multiplicative-decrease (MIMD) and additive-increase/additive-decrease (AIAD) do not reach stability.
简单翻译一下：线性增加乘性减少算法是一个反馈控制算法，因其在TCP拥塞控制中的使用而广为人知，AIMD将线性增加拥塞窗口和拥塞时乘性减少窗口相结合，基于AIMD的多个连接理想状态下会达到最终收敛，共享相同数量的网络带宽，与其相关的乘性增乘性减MIMD策略和增性加增性减少AIAD都无法保证稳定性。
AIMD相比MIMD和AIAD在连接进入拥塞避免阶段使用试探线性加策略而不是乘性加策略更加安全，在探测丢包时则大幅度乘性减少到1/2这样对于缓解拥塞会有比较好的效果更加快速，相反如果探测到丢包时采用线性减少AD可能拥塞持续的时间会更长，总体来说AIMD算是一个比较简单实用的工程版本的反馈控制，也具备可工程收敛性，因而被广泛实用。
2.4 弱网络环境下的AIMD
时间拉回20多年前，在互联网早期几乎所有的设备都是通过有线网络进行连接通信的，这也是拥塞控制在设计之后一直都起到不错作用的重要因素，有线连接的网络稳定性比较好，因此把丢包作为网络拥堵的一个特征也很正常。
再拉回到现在，从2010年之后移动互联网蓬勃发展，移动终端的持有量已经可以称为海量，无线网络的引入让网络环境变得更加复杂，因此不稳定丢包变得更加频繁，但是这时的丢包就不一定是网络拥堵造成的了，因为整个数据包经过多重路由、交换机、基站等基础通信设备每个环节都可能发生异常。
在弱网环境下，尤其是移动互联网中之前的基于AIMD的拥塞控制策略可能会由于丢包的出现而大幅降低网络吞吐量，从而对网络带宽的利用率也大大下降，这时我们采用更加激进的控制策略，或许可以获得更好的效果和用户体验。
恶意丢包的情况下，基于AIMD的拥塞控制确实就相当于被限速了，因为AIMD确实有些保守谨慎了，这个其实也很好理解的哈。
我们都知道在移动网络环境下是由终端以无线形式和附近的基站交互数据，之后数据传输至核心网，最后落到具体的服务器所在的有线网络，其中最后一公里的区域属于高延时场景，有线网络属于低延时高带宽场景。
在国外有相关实验证明弱网环境下RTT的变化对于使用传统拥塞控制算法下网络吞吐量的影响，数据和曲线如图所示：
实验含义：RTT的增大影响了比如CUBIC这类拥塞控制算法的慢启动等阶段，我们知道慢启动阶段每经过1个RTT周期拥塞窗口cwnd将加倍，但是更大的RTT就意味着发送方以很低的速率发送数据，更多的时间是空闲的，发包的加速度极大将低了，所以整个吞吐量就下降很明显。
看下实验者的原文表述：
The delay before acknowledgment packets are received (= latency) will have an impact on how fast the TCP congestion window increases (hence the throughput).
When latency is high, it means that the sender spends more time idle (not sending any new packets), which reduces how fast throughput grows.
0x03 TCP BBR算法简介
BBR算法是个主动的闭环反馈系统，通俗来说就是根据带宽和RTT延时来不断动态探索寻找合适的发送速率和发送量。
看下维基百科对BBR算法的说明和资料：
相关文献：https://queue.acm.org/detail.cfm?id=3022184
TCP BBR(Bottleneck Bandwidth and Round-trip propagation time)是由Google设计，并于2016年发布的拥塞算法，以往大部分拥塞算法是基于丢包来作为降低传输速率的信号，而BBR基于模型主动探测。
该算法使用网络最近出站数据分组当时的最大带宽和往返时间来创建网络的显式模型。数据包传输的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率。
该算法认为随着网络接口控制器逐渐进入千兆速度时，分组丢失不应该被认为是识别拥塞的主要决定因素，所以基于模型的拥塞控制算法能有更高的吞吐量和更低的延迟，可以用BBR来替代其他流行的拥塞算法例如CUBIC。Google在YouTube上应用该算法，将全球平均的YouTube网络吞吐量提高了4%，在一些国家超过了14%。BBR之后移植入Linux内核4.9版本，并且对于QUIC可用。
3.1 基于丢包反馈策略可能在的问题
基于丢包反馈属于被动式机制，根源在于这些拥塞控制算法依据是否出现丢包事件来判断网络拥塞做减窗调整，这样就可能会出现一些问题：
丢包即拥塞
现实中网络环境很复杂会存在错误丢包，很多算法无法很好区分拥塞丢包和错误丢包，因此在存在一定错误丢包的前提下在某些网络场景中并不能充分利用带宽。
缓冲区膨胀问题BufferBloat
网络连接中路由器、交换机、核心网设备等等为了平滑网络波动而存在缓冲区，这些缓存区就像输液管的膨胀部分让数据更加平稳，但是Loss-Based策略在最初就像网络中发生数据类似于灌水，此时是将Buffer全部算在内的，一旦buffer满了，就可能出现RTT增加丢包等问题，就相当于有的容量本不该算在其中，但是策略是基于包含Buffer进行预测的，特别地在深缓冲区网络就会出现一些问题。
网络负载高但无丢包事件
假设网络中的负载已经很高了，只要没有丢包事件出现，算法就不会主动减窗降低发送速率，这种情况下虽然充分利用了网络带宽，同时由于一直没有丢包事件出现发送方仍然在加窗，表现出了较强的网络带宽侵略性，加重了网络负载压力。
高负载丢包
高负载无丢包情况下算法一直加窗，这样可以预测丢包事件可能很快就出现了，一旦丢包出现窗口将呈现乘性减少，由高位发送速率迅速降低会造成整个网络的瞬时抖动性，总体呈现较大的锯齿状波动。
低负载高延时丢包
在某些弱网环境下RTT会增加甚至出现非拥塞引起丢包，此时基于丢包反馈的拥塞算法的窗口会比较小，对带宽的利用率很低，吞吐量下降很明显，但是实际上网络负载并不高，所以在弱网环境下效果并不是非常理想。
3.2 TCP BBR算法基本原理
前面我们提到了一些Loss-Based算法存在的问题，TCP BBR算法是一种主动式机制，简单来说BBR算法不再基于丢包判断并且也不再使用AIMD线性增乘性减策略来维护拥塞窗口，而是分别采样估计极大带宽和极小延时，并用二者乘积作为发送窗口，并且BBR引入了Pacing Rate限制数据发送速率，配合cwnd使用来降低冲击。
3.2.1 一些术语
BDP
BDP是Bandwidth-Delay Product的缩写，可以翻译为带宽延时积，我们知道带宽的单位是bps(bit per second)，延时的单位是s，这样BDP的量纲单位就是bit，从而我们知道BDP就是衡量一段时间内链路的数据量的指标。这个可以形象理解为水管灌水问题，带宽就是水管的水流速度立方米/s，延时就是灌水时间单位s，二者乘积我们就可以知道当前水管内存储的水量了，这是BBR算法的一个关键指标，来看一张陶辉大神文章中的图以及一些网络场景中的BDP计算：
长肥网络
我们把具有长RTT往返时间和高带宽的网络成为长肥网络或者长肥管道，它的带宽延时积BDP很大大，这种网络理论上吞吐量很大也是研究的重点。
TCP Pacing机制
可以简单地理解TCP Pacing机制就是将拥塞控制中数据包的做平滑发送处理，避免数据的突发降低网络抖动。
3.2.2 带宽和延时的测量
BBR算法的一些思想在之前的基于延时的拥塞控制算法中也有出现，其中必有有名的是TCP WestWood算法。
TCP Westwood改良自New Reno，不同于以往其他拥塞控制算法使用丢失来测量，其通过对确认包测量来确定一个合适的发送速度，并以此调整拥塞窗口和慢启动阈值。其改良了慢启动阶段算法为敏捷探测和设计了一种持续探测拥塞窗口的方法来控制进入敏捷探测，使链接尽可能地使用更多的带宽。
TCP WestWood算法也是基于带宽和延时乘积进行设计的，但是带宽和延时两个指标无法同时测量，因为这两个值是有些矛盾的极值，要测量最大带宽就要发送最大的数据量但是此时的RTT可能会很大，如果要测量最小的RTT那么久意味着数据量非常少最大带宽就无法获得。
TCP BBR算法采用交替采样测量两个指标，取一段时间内的带宽极大值和延时极小值作为估计值，具体的实现本文就不展开了。
3.2.3 发送速率和RTT曲线
前面提到了BBR算法核心是寻找BDP最优工作点，在相关论文中给出了一张组合的曲线图，我们一起来看下：
1.曲线图示说明：
这张图是由两个图组合而成，目前是展示[数据发送速率vs网络数据]和[RTTvs网络数据]的关系，横轴是网络数据数量。
两个纵轴从上到下分别为RTT和发送速率，并且整个过程分为了3个阶段：应用限制阶段、带宽限制阶段、缓冲区限制阶段。
2.曲线过程说明：
app limit应用限制阶段
在这个阶段是应用程序开始发送数据，目前网络通畅RTT基本保持固定且很小，发送速率与RTT成反比，因此发送速率也是线性增加的，可以简单认为这个阶段有效带宽并没有达到上限，RTT是几乎固定的没有明显增长。
band limit带宽限制阶段
随着发送速率提高，网络中的数据包越来越多开始占用链路Buffer，此时RTT开始增加发送速率不再上升，有效带宽开始出现瓶颈，但是此时链路中的缓存区并没有占满，因此数据还在增加，RTT也开始增加。
buffer limit缓冲区限制阶段
随着链路中的Buffer被占满，开始出现丢包，这也是探测到的最大带宽，这个节点BDP+BufferSize也是基于丢包的控制策略的作用点。
3.一些看法
网上有一些资料都提及到了这张图，其中的一些解释也并不算非常清晰，结合这些资料和自己的认识，笔者认为在网络链路的缓存区没有被使用时RTT为最小延时MinRTT，在网络链路缓冲区被占满时出现最大带宽MaxBW(链路带宽+链路缓存)，但是此时的MaxBW和MinRTT并不是最优的而是水位比较高的水平，有数据表明按照2ln2的增益计算此时为3BDP，整个过程中MinRTT和MaxBW是分开探测的，因为这二者是不能同时被测量的。
3.2.4 BBR算法的主要过程
BBR算法和CUBIC算法类似，也同样有几个过程：StartUp、Drain、Probe_BW、Probe_RTT，来看下这几个状态的迁移情况：
StartUp慢启动阶段
BBR的慢启动阶段类似于CUBIC的慢启动，同样是进行探测式加速区别在于BBR的慢启动使用2ln2的增益加速，过程中即使发生丢包也不会引起速率的降低，而是依据返回的确认数据包来判断带宽增长，直到带宽不再增长时就停止慢启动而进入下一个阶段，需要注意的是在寻找最大带宽的过程中产生了多余的2BDP的数据量，关于这块可以看下英文原文的解释：
To handle Internet link bandwidths spanning 12 orders of magnitude, Startup implements a binary search for BtlBw by using a gain of 2/ln2 to double the sending rate while delivery rate is increasing. This discovers BtlBw in log2BDP RTTs but creates up to 2BDP excess queue in the process.
Drain排空阶段
排空阶段是为了把慢启动结束时多余的2BDP的数据量清空，此阶段发送速率开始下降，也就是单位时间发送的数据包数量在下降，直到未确认的数据包数量
ProbeBW带宽探测阶段
经过慢启动和排空之后，目前发送方进入稳定状态进行数据的发送，由于网络带宽的变化要比RTT更为频繁，因此ProbeBW阶段也是BBR的主要阶段，在探测期中增加发包速率如果数据包ACK并没有受影响那么就继续增加，探测到带宽降低时也进行发包速率下降。
ProbeRTT延时探测阶段
前面三个过程在运行时都可能进入ProbeRTT阶段，当某个设定时间内都没有更新最小延时状态下开始降低数据包发送量，试图探测到更小的MinRTT，探测完成之后再根据最新数据来确定进入慢启动还是ProbeBW阶段。
我们来看一下这四个过程的示意图：
曲线说明：这两个坐标给出了10Mbps和40msRTT的网络环境下CUBIC和BBR的一个对比过程，在上面的图中蓝色表示接收者，红色表示CUBIC，绿色表示BBR，在下面的图中给出了对应上图过程中的RTT波动情况，红色代表CUBIC，绿色代表BBR。
0x04.TCP BBR算法的一些效果
有一些文章认为BBR有鲜明的特点，把拥塞控制算法分为BBR之前和BBR之后，可见BBR还是有一定影响，但是BBR算法也不是银弹，不过可以先看看BBR算法在谷歌推动下的一些应用效果，其中包括吞吐量、RTT、丢包率影响：
从图中我们可以看到在YouTube应用BBR算法之后，就吞吐量普遍有4%左右的提升，特别地在日本的提升达到14%，RTT的下降更为明显平均降低33%，其中IN(猜测是印度地区)达到50%以上，在丢包率测试中BBR并不想CUBIC那么敏感，在丢包率达到5%是吞吐量才开始明显下降。
0x05.总结
本文先回顾了以CUBIC为代表传统的拥塞控制算法，之后展开了对BBR算法的一些介绍。
网络上关于BBR的文章很多，笔者也尝试结合很多文章和外文资料进行理解和归纳，但是由于笔者工作经验和水平所致上述文字中可能存在一些问题，对此表达歉意，并且很多细节也并未展开，所以只能当做是一次浅谈了。
0x06.巨人的肩膀
https://queue.acm.org/detail.cfm?id=3022184
