RTT 发散思维写点随笔录

随心录，随笔录

聊聊RTT

RTT，往返时延这小玩意在计算机早已家喻户晓。

工人熟练得用他搭建城墙，用他打造云梯，做着和网络关系的花样武器。

即便别人对他有多熟悉，我还是想着围绕他写点东西，发散神经的跟他说句你好，RTT。

网络的度量维度从来没有太多，包数、时延和速率。RTT在网络系统上扮演了重要角色，这个缘由，在于人对时间很敏感。

我并不想照本宣科的解读RTT，但我还是想对RTT拆解下，这样也方便我下面想写的话。

实际上，Net这里也有很多细节，以后再补充。

RTT有处理时延、本地排队时延、传输时延和传播时延四个部分。
传输时延：
transmission=packsize/NICsendtransmission = pack_{size}/NIC_{send}transmission=packsize/NICsend
传播时延：
propagation=distance/mediumpropagation = distance/mediumpropagation=distance/medium

还依稀记得这是书本上的东西。

结合实际，再想想，RTT是什么。如果想计算RTT，RTT还可以这么分，“拥塞时延”，拥塞路径的传播时延、端的传输时延和阻塞排队时延之和；最小RTT，这是我们常见的RmR_mRm，包括非拥塞路径的传播时延、端传输时延；最后是端上（每个终端）的初始时延，也可以叫做“非拥塞时延”，涵盖端的处理时延和排队时延。

它们就是RTT，这样区分可以明显的看出RTT的好和坏。痛点在哪呢？拥塞时延和非拥塞时延，拥塞时延的问题自然是阻塞，阻塞意味着时间的拉大，想象在一直堵的高速上，你可以直观感受到这种差感；非拥塞时延，可能这么说不太受众，换句话说，“网络抖动”。网络抖动是端上一系列导致RTT大的问题，原因就在于端处理数据包的时延变长了，直接影响了RTT。

端也囊括交换机、路由器等中间设备。

网络抖动

两个数据包时延不一致，就叫网络抖动了，往往说网络抖动时会扯掉网络拥塞，因为拥塞引发的时间上的差很难叫做抖动，拥塞触发的RTT升高动但不抖，妙极妙极。

抖动的原因很多，需要逐步排查。对于时间要求高的应用，网络抖动是个大问题，而RTT一般是保证应用网络质量的标准，维持在一个收敛的区间是重要的。

再回RTT

理想的RTT是这样的，拥塞算法的目的之一是尽可能在复杂的网络上靠近这个理想折线。

所以，以时延为度量的CCA可以更准确的达到这个目标，RTT也是重要的标准。

说说Delay-based拥塞

忽而想到了拥塞算法，于是乎趁机会有写下点什么。

基于丢包的拥塞算法已经渐渐失去了地位，关键在于共网上的噪音太大了，不具备抗噪的拥塞注定会被替代。当然Cubic仍然在被使用，一在于保守，二在于只管自己，三就是简单干净，符合数学探测模型规律。

但现在的互联网已经开始脱离这类算法，基于时延的拥塞算法开始更具有竞争力。两个点，一是抗噪，二是不会以牺牲bloating delay为代价，提高资源的利用率。

基于时延的拥塞算法渐渐又衍生出基于速率的拥控，这与基于窗口的类型相区分，使得降低网络里可能的突发流量。（网络对于突发实际上很敏感，因为突发打破了平衡，会导致很多的意外）并且，基于速率的拥塞实际上和时延关系紧密，当发送速率（受系统、网络的影响）收敛到一个平衡的区间时，时延也会达到理想的收敛，两者持负相关的关系。

至于基于时延的拥控不公平问题，需要更多的洞察力，“拥控不能让传播的信道饥饿”，怎么解决端到端的饥饿问题，是拥控领域公平性的重要课题。

今天就到底为止吧，笔停文终。