微信终端跨平台组件 mars 系列 —— 信令传输网络模块之信令超时

正文

请到「今天看啥」查看全文

传统 Unix 实现中，定时器的间隔取决于数据的往返时间（即 RTT），根据 RTT 进行一定的计算得到重传超时间隔（即 RTO）。由于网络路由、流量等的变化，RTT 是经常发生变化的，RTT 的测量也极为复杂（平滑算法、Karn 算法、Jacbson 算法等）。在《TCP/IP详解》中，实际测量的重传机制如图3所示，重传的时间间隔，取整后分别为1、3、6、12、24、48和多个64秒。这个倍乘的关系被称为“指数退避”。

图3 实际测量的重传机制

在移动终端中，RTO 的设计以及重试频率的设计是否与传统实现一致呢？对此我们进行了实测，实测数据如下：

图4所示为OPPO手机TCP超时重传的间隔，依次为[ 0.25s，0.5s，1s，2s，4s，8s，16s，32s，64s，64s，64s …]：

图4 OPPO 手机 TCP 超时重传间隔

而 SamSung 中 TCP 超时重传的间隔依次为[0.42s, 0.9s, 1.8s, 3.7s, 7.5s, 15s, 30s, 60s, 120s, 120s …]，见图5。

图5 三星手机 TCP 超时重传间隔

经过多次实际测试我们可以看出虽然由于不同厂商的 Android 系统实现，RTO 的值可能会有不同的设定，但都基本符合“指数退避”原则。

接下来再看 iOS 系统中，TCP RTO 的实验数据，图6所示为实验中第一次的数据[ 1s，1s，1s，2s，4.5s，9s，13.5s，26s，26s … ]。

图6 iOS 系统 TCP RTO 第一次实验数据

上面的数据看起来并不完全符合指数退避，开始阶段的重试会较为频繁且 RTO 最终固定在 26s 这一较小的值上。

进行第二次测试后发现数据有了新的变化[1s，1s，1s，2s，3.5s，8.5s，12.5s，24s，24s …]，如图7所示。

图7 iOS 系统 TCP RTO 第二次实验数据

RTO 终值由26秒缩减至24秒，最终经过多次测试并未发现 iOS 中 TCP RTO 的规律，但可以看出 iOS 确实采用了较为激进的超时时间设定，对重试更为积极。

➤ 读写超时的目标

通过上述的调研与实验，可以发现在 TCP/IP 中，协议栈已经帮助我们进行了超时与重传的控制。并且在 Android、iOS 的移动操作系统中进行了优化，使用了更为积极的策略，以适应移动网络不稳定的特征。

那是否意味着我们的应用层已经不需要超时与重传的控制了呢？其实不然。在链路层，HARQ 提供的是节点之间每一数据帧的可靠传输；在传输层，TCP 超时重传机制提供的是端与端之间每个 TCP 数据包的可靠传输；同理，在微信所处的应用层中，我们仍然需要提供以“请求”为粒度的可靠传输。

请到「今天看啥」查看全文