时延抖动的根源与应对
网络技术一直在演进，带宽一直在增加，可是在互联网边缘和数据中心却有一种反方向的奇怪趋势。
曾经在互联网的边缘，主机均以有线方式接入，有线接入方式的传输可以建模成标准的星型交换式网络。但是到了后来，越来越多的移动终端通过 Wi-Fi 接入，互联网边缘开始由交换式网络 “退化” 到共享介质网络，碰撞冲突，隐藏节点冲突，多径等带来了时延的严重抖动。
另一方面，前云计算时代，数据中心通常只做内容存储，只做少量计算，但到了云计算时代，数据中心将机器看作一个资源池，大量短消息在机器间频繁交互，网络有效载荷率和利用率均开始降低，大量突发造成传输时延严重抖动。
互联网边缘和数据中心面对的问题其实是同一个问题，原因也是同一个，即不可预测的冲突。Wi-Fi 传输冲突在时间域被分布式处理，二进制指数退避造成抖动，微突发在 buffer 空间域被集中处理，队列长度造成抖动，其实是一回事。不管是冲突还是微突发，都不可预测，这是抖动的根源。
这个时空倒置关系非常有趣。常人见，数据中心微突发造成的抖动与 Wi-Fi 的时延抖动相比简直微不足道，因为抖动本身正是一个时间指标，人们对时间比对空间敏感很多。从根本上讲，共享介质网络碰撞冲突浪费了时间，而 buffer 排队浪费的是空间而不是时间。对于时间，它无限延展，但某一刻浪费了就没了，但对于 buffer，它有界有限，空间是对称的，队列清空的时候，对应的 “浪费” 就还回来了。
当网络流量捆绑在一起时，在核心传输网可以获得极高的带宽利用率，但对单流，目前没什么端到端协议可以在高抖动场景依然保持稳定。而单流全链路是一个漏桶，最糟糕的那段决定了整体上限。
为应对抖动，在无线转有线的节点终结端到端协议是高尚的，比如无线 AP 处做一个 TCP 代理，分割无线链路和有线链路，让小且高抖动的无线 RTT 部分不至于影响大且稳定的有线 RTT 部分。但除了端到端，中间节点几乎无法触碰，不然就不是互联网了，因此总是趋势总是偏向认为 “这种做法不够技术” 的价值观。
TCP 自身的行为特征加重了共享介质网络冲突。TCP 需要 ACK 提供自时钟来驱动 sender 的行为，但 ACK 越多，共享介质冲突就越严重。这就产生了矛盾，ACK 太少不行，太多也不是。
BBR 采集以及使用 RTT 以及 Delivery rate 的方式过于粗糙，因此无法在共享介质网络中兑现其高带宽利用率的承诺，偶然窥视便知 Wi-Fi 场景下即时 RTT 不可信任，于是我也草写了一个同样粗糙但稍微合理的方案：当 BBR 面对时延抖动，本文由这个方案再引申一下。
RTT 在横向上可分为处理时延，传播时延，排队时延，这已是老生常谈，另外，在纵向上，RTT 可分为稳定部分和抖动部分。
为此，在一段足够长又不太长的滑动时间窗口内，冒泡采集 minrtt 作为 RTT 稳定部门上界，即时 RTT(记为 iRTT) 与 minrtt 之差作为抖动部分(记为 jRTT)求算术平均或者移指平均(但不建议)，二者相加即可用 RTT(记为 uRTT)：
jRTT = beta * jRTT + (1 - beta) * (iRTT - minrtt) （算术平均更好，但不太好计算移动算术平均）
uRTT = (iRTT - minrtt) + jRTT
简单来讲就是说，RTT 的稳定部分和抖动部分要用不同的方式汇总，比如稳定部分采用移指平均，抖动部分采用算术平均。
说一下为什么抖动部分用算术平均优于移指平均。
既然是抖动，就没什么趋势可遵循，两个抖动样本之间 “几乎” 毫无关联，全凭随机和运气，而移指平均描述的过滤噪声后的趋势，这种情况下，算术平均会更加独立对待每一个样本。
其实将抖动部分隔离后(我承认我的算法很简陋，但我这么并非在描述一种算法，而是一个思路)，再回到 RTT 横向组分：
RTT = 主机处理时延 + 存储转发时延 + 抖动传输部分平均时延(共享介质无线网络传播时延) + 稳定传输部分时延(有线网络传播时延) + 排队时延
【注：存储转发时延是固有的，意思是转发节点必须收完整个报文才能转发，比如 25Gbps 带宽网卡收完一个 1500B 报
文需要 420ns 的固有时延，这段时间内，首先被接收的第一个 bit 必须等着】
基于上述想法采集和使用 RTT，可过滤掉更多的抖动带来的影响。
OK，看一个有趣的怪异结论，互联网的一个最重要的特征就是对时间的合理浪费。如果信息精确到足够控制所有，没人希望时间被浪费，用可接受的时间浪费换简单的控制，代价便是抖动，这也是所有统计复用系统的特征对于 Wi-Fi 或总线以太网，碰撞浪费了时间，对于交换式网络，一边 buffer 排队，一边链路空置同样浪费了时间。
日常开车出行就是一个统计复用的例子，说走就走，但说堵就堵，浪费的时间依然来自冲突，比如插队失败相当于浪费了时间，插队成功浪费了别人时间，而这种浪费的时间在全局上会统计积累，反噬自身。
这种交换是划算的，它点燃了互联网之火。下面的摘录来自 RFC 1：
As with any new facility, there will be a period of very light usage until the community of users experiments with the network and begins to depend upon it. One of our goals must be to stimulate the immediate and easy use by a wide class of users. With this goal, it seems natural to provide the ability to use any remote HOST as if it had been dialed up from a TTY (teletype) terminal. Additionally, we would like some ability to transmit a file in a somewhat different manner perhaps than simulating a teletype.
为了让互联网门槛极低而易用，几乎就是 “接上来就行”，势必造成端网解耦，如果一开始就没有控制信息的共享，统计复用的时间浪费就不可避免，这注定互联网本身就是一个抖动网络，只是这种抖动在 Wi-Fi 接入侧表现的尤其明显。Wi-Fi 自身复制了这划算的交易，Wi-Fi 足够简单，因此才方便使用和推广，抖动算这种便利性的代价之一吧。
本周只休一天，讨论两个传输领域的难题，一个是 buffer 的大小，一个是时延的抖动，本文说第二个。其实这两个问题关联非常紧密。如果你希望不丢包，必须拿东西来换，大 buffer 只是一个措施，而你要承担它的后果。大 buffer 的后果之一，甚至可以说最核心的，就是抖动。在有限网络，大 buffer 没什么好讨论的，假设一个 25Gbps 的链路有 25Gbps 的 buffer，你就要接受最大 1s 的时延等待，你能吗？你是接受等待呢，还是接受小 buffer 丢包感知后重传，重传时延可能不会到 1s。对于无线 Wi-Fi，大 buffer 需要更详细说明，二进制指数退避的最久时间相当于 Wi-Fi 的 buffer，这个时间如果能到 1s，那么你的数据包可能在 1s 内都会被重试传输，你要承担的是等待这段最长可达 1s 的时间，当然，你还有另一个选择，等待一个更短的 deadline，然后重传。
浙江温州皮鞋湿，下雨进水不会胖。