浙江温州皮鞋湿，下雨进水不会胖！9月份错过了深圳的超猛台风，12月8号又错过了杭州的超猛大雪，当天却在深圳迎来了赵正则，马上2019年了，又一次错过了杭州的大雪，回到了深圳过元旦…
无奈啊无奈，去年夏天我为如题展示的问题折腾的寝食难安，然而并无解，可能那是一个工作任务吧，什么事情只要成了工作任务，就索然无味了…
现如今，工作重点已经远离了 判定无线网络对TCP的影响 ，偶然的机会，我反倒又重新想起了往事，不得不探究一番LTE网络对TCP的影响到底是什么。
我就长话短说，不使用太多的术语，简单描述一下。
网络结构
要想移动就必须无线，不然拖着线缆走来走去，迟早得把自己缠进去。
为了支持移动终端无线上网，必须有很多固定的基站，每个基站释放的信号辐射一定的区域，所有的基站构成一个像马蜂窝一样的 移动通信信号网络（图片百度得之，盗图所得）
每一个小孔都由一个基站负责，当然在无线空域。小孔之间是会有重叠的，而这种重叠区域，正是移动网络中关键行为，移交行为的执行区域，但是在移动网络中，任何行为都是 但不经常，也不绝对 的！即便你不用去推敲多普勒效应，也能从自己频繁掉线的经历中可见一斑！
每一个基站都有 转发所有到达其辐射区域的移动终端所收发的数据 的任务，与此同时，它还必须负责实时监控 有哪些移动终端属于自己信号所能辐射的区域 以及 哪些移动终端正在进入或者离开自己信号所能辐射的区域， 后者被称为 移交任务。
基站移交过程
移交，这是无线移动网络中最最关键的过程，可以说无线移动网络绝大多数和固网有所区别的行为都是由这个所谓的移交过程造成的。
由于移动终端随时随地在移动过程中，而其所在的空间的每一个点都由一个或者多个基站辐射的信号所覆盖，随着终端的移动，每一个基站的信号强度会有所变化：
基站会根据和移动终端协商的结果，来决定要不要把该移动终端 转交 给其它 更适合服务它 的基站，比如该基站比当前基站的信号更好，诸如此类。
所有的行为都发生在时空当中，那么移交过程的时序图，大致就是下面的样子：
以此为基础，我们就知道在无线移动网络中TCP怪异行为的成因为何了。
为什么RTT抖动
无线网络的介质不像固网那么可靠，这是一定的。
无线网络的介质无非就是一些电磁波，这玩意儿非常脆弱，非常容易受到各类干扰，除了你的移动终端距离基站的距离不同会导致信号强弱差异之外，还会有其它因素影响：
- 天气因素，比如大风，闪电
- 有人提着一台无线设备从你身边走过
- 地形因素，包括身边开过一辆汽车
- 设备天线的方向
- …
是不是很复杂？！
如果移交过程一如既往的顺利，那么RTT几乎不会发生变化，然而在无线网络情况下，基于上述的原因，移交行为往往并不仅仅由于距离变化而发生，此外，由于电磁波信号的脆弱性质，在移交的过程中，消息也不是能保证顺利到达，任何一个消息都可能会丢失。
这导致，如果信令丢失，唯一能让移动终端能重新接入网络的机制就是其主动探测机制，其中为了避免信令延迟到达，其权衡就是使用定时器机制，而这个定时器便是RTT抖动的根源！
而TCP的RTO计算依赖于RTT，如果RTT是不准的，那么RTO将会是随意的，这极大影响着TCP的丢包判断。
如果这个移动终端重新扫描基站的定时器延时数量级达到了TCP连接的RTO数量级，极有可能还会触发TCP的重传，这显然是丢包误判，因为此时只是ACK在基站已经找不到移动终端而被丢弃，所以让移动终端误以为数据包的丢失，或者是反向路径上发生同样的事情。
总之，移交过程让TCP对丢包的判断变得复杂！
为什么乱序多
信令的传输和数据的传输总是分开的，它们二者之间应该是解耦合的，这是优秀的设计，但是这种设计也会对特有的协议带来一些问题，比如要求顺序传输的TCP。
其实TCP的规范并不要求顺序传输，它只是要求顺序接收而已，然而在实现上，如果你没有让接收端觉得你在顺序传输，那么发送端将会重传已经传过的数据，这意味着，实际上，TCP 要求 发送端 必须按照顺序传输数据。
然而正是由于移动网络中移交过程的存在，导致在移交的期间，可能会有多个基站在独立帮忙传输移动终端的数据，它们之间并没有做基于数据流序列号的同步机制，这导致了乱序的发生！
越是将缓存当带宽的发送行为，比如CUBIC这种，就越是会收到乱序的影响，而BBR这种算法，本来就保持不排队政策，所以数据乱序的可能性相对少很多。
本质上的原因，就在于， 信令和数据是分别发送和接收的， 信令只负责控制的部分，有可能信令已经判断无线连接失效了，可是数据依然保留在缓存中继续被发送，而此时移动终端已经连接上其它的基站在发送数据了。
TIPs：移动场景下，千万不要填充缓存！
ACK聚合
综上，TCP的ACK聚合能在一定程度上避免RTT抖动和乱序，然而这会减慢ACK时钟报时频率，影响CCA来做决策。
成也萧何，败也萧何！
可见，传统的TCP遇到如今当下的无线移动网络时，损的一逼啊，我们不希望底层的行为会影响到TCP层面的丢包判定以及重传，显然，基站移交导致的RTO并不是真的丢包所导致，但是 网络协议栈的分层设计 法则让我们没法大动干戈…在适应无线移动网络这方面，BBR是不是比CUBIC更好呢？
这却是不一定的。
我们不能仅仅关注丢包判定这方面，我们还要关注收敛速度。BBR对移动网络的底层移交行为是 无感知 的，它能意识到的仅仅就是 丢包 而已！这种策略导致的结果到底是好还是坏，我觉得是坏！
首先，我觉得BBR统计最小RTT的方式在移动网络要有所改变，这是最必要的，其次，计算cwnd的算法必须要有所改变，不能仅仅是乘以2，因为ACK聚合会导致空窗期，这个已经在BBRv2里解决了，甚好。
接下来，我也不知道会发生什么。
疯子说了，待明年，我们就终于又回到魔都的地界里去了，所有的事情都已经过去，摧毁了当初南下的原因，如今回去便是自然而然。虽然不是回到嘉定，但杭州至少也是我们经常去的地方，也是满满的回忆。
开车两个小时多就能到嘉定，吃个洲桥的羊肉串外加一顿火锅，也不错。
浙江温州皮鞋湿，下雨进水不会胖！
原文链接: https://blog.csdn.net/dog250/article/details/85416381
欢迎关注
微信关注下方公众号，第一时间获取干货硬货；公众号内回复【pdf】免费获取数百本计算机经典书籍;
也有高质量的技术群，里面有嵌入式、搜广推等BAT大佬
原创文章受到原创版权保护。转载请注明出处：https://www.ccppcoding.com/archives/406677
非原创文章文中已经注明原地址，如有侵权，联系删除
关注公众号【高性能架构探索】，第一时间获取最新文章
转载文章受原作者版权保护。转载请注明原作者出处！
