什么是微信的Mars

Mars是微信在2017年开源的一套跨平台跨业务的基础组件。在这里可以给出github上的官方架构图

Mars基础架构
从上面的架构图中我们可以看到，Mars主要包含了一下几个部分：
STN：STN是微信的网络传输信令模块，是mars组件中终端和服务端进行通讯的小数据信令通道。STN模块包含了微信在海量用户使用上作出的一系列优化和尝试，特别是在弱网络情况下有非常不错的效果
SDT：Mars的网络诊断工具，这里包含了Mars对当前网络状态的定义，包括：优质网、正常网和弱网络等的界定。这对于下面我们要进行分析的智能心跳和STN超时机制有非常密切的关系。
XLOG：基于mmap读写的一套日志框架，具体的分析可以看我之前的一篇文章
腾讯Xlog接入指南与踩过的坑
Comm:主要包含了消息队列，锁，时钟还有线程管理等，基础Comm不在本次的分析介绍之内

为什么要使用Mars

通过研究和学习，为什么要使用Mars我这里做了几点小结
1 如果你的应用只是一个普通的APP，并不涉及到即时通讯，或者你们的APP对于消息的即时性没有很强的要求，那么我比较推荐你只单独使用Mars的Xlog组件就可以了。这对你们app的日志管理，线上问题追踪和定位具有非常好的帮助。在接入了Xlog后，出现线上问题我们上家公司几乎可以做到5分钟内定位问题，10分钟给出解决方案。
2 STN组件的设计逻辑非常的贴合移动互联网的网络使用环境，是一套非常成功的解决方案，尤其是弱网环境和平台特性具有非常多的优化策略
3 Mars 是基于socket的解决方案，在网络调优方面具有跟强的主动性和可控性。

Mars 的超时机制

TCP的超时重传

熟悉TCP传输协议的同学都知道，TCP在建立连接的情况下，如果当前的请求方没有在规定的时间内得到接收方的相应，那么就会发生重传的机制，这个也是TCP保证可靠性传输的一个重要的原则。我们在了解超时和重传是需要了解的两个指标
RTT：数据往返的时间；
RTO：超时重传的时间间隔
这里盗一张mars的官方图，我们来看下Android手机的tcp超时重传的时间间隔表现

从途中我们可以看到，超时重传的间隔，依次为[ 0.25s，0.5s，1s，2s，4s，8s，16s，32s，64s，64s，64s …]
我们可以看到，前面的重传时间还有一定的时间间隔，但后面是几个连续的64s。这个算法其实就是指数退避的算法。

Mars的超时重传机制

是不是传输层已经有了超时重传机制，应用层就不需要了呢？其实不是的，我们可以知道tcp在经过一定的超时重传后才会确定当前的tcp不可用，返回timeout标示。但是这个时间非常的就，一般来说Android手机大概要6min才会确定当前的TCP连接不可用。但是对于移动端来说6min的时间是非常影响用户体验的，因此应用层的超时重传机制需要更加的敏捷。
但是需要注意，敏捷并不等于密集。在很多的场景下，密集的心跳机制并不能取到重新建连的效果，反而会是网络通道更加的恶劣。因此在经过多个尝试后，Mars采用了一下的几个超时方案

总读写超时

总读写时间这个比较好理解，就是一次完成的RTT所需要的时间，这里总结起来包括：
请求发送耗时 - 类比TCP包传输耗时；
响应信令接收耗时 - 类比ACK传输耗时；
服务器处理请求耗时 - TCP接收端接收和处理数据包的时间相对固定，而服务器由于信令所属业务的不同，逻辑处理的耗时会差异明显，所以无法类比；
等待耗时 - 受应用中请求并发数影响。
因此，我们提出了应用层的总读写超时如右图所示，最低网速根据不同的网络取不同的值。

总读写超时

首包超时

总读写超时有一个弊端是无法确定服务端的处理请求时间，最致命的一点是相应信令的时间处理较长，这导致了在网络状态很差的情况下，同样需要较长的时间才可以进行重试。首包超时是指在tcp的第一次回包的情况就去确定这个信令的接受耗时。调整后的首包超时方案如下

首包超时

包包超时

首包超时有一个弊端，就是在网络堵塞的情况下，由于tcp的拥塞窗口和流量控制，一个tcp包会被切割成几个部分进行传输，也就是发生了tcp的拆包和粘包的现象。加入后续的包又丢失了，仍然需要整个完整的读写超时才能发生问题。这就引入了包包超时的机制：两个数据段之间的超时时间。因为包包超时在首包超时之后，这个阶段已经确认服务器收到了请求，且完成了请求的处理，因此不需要计算等待耗时、请求传输耗时、服务器处理耗时，只需要估算网络的 RTT。

动态超时

动态读写超时

动态读写超级更多的是依赖于当前的网络状况，这个网络状态评估就跟之前提到的SDT模块有着莫大的关系。Mars在动态超时的设计中，把当前的网络分为excellent和evaluate两种状态，分别在这两种状态中不停的调整当前的动态耗时。

网络情况诊断

Mars 的连接方案-复合连接

我们先总结一下串行连接和并行的优缺点
串行连接：
1 资源占用小，服务端没有负载的压力
2 超时选择困难，连接最慢可用
并行连接
1 资源占用较大，服务端负债压力大
2 连接最快可用
复合连接
先看一下官方给的图

复合连接
初始阶段，应用发起对 IP1 &Port1 的 connect 调用。在第4秒的时候，如果第一个 connect 还没有返回，则发起对 IP2 &Port2 的 connect 调用。以此类推，直至发起了5组 IP&Port 的 connect 调用。
对比串行连接与并行连接，复合连接有以下特点：
常规情况下，服务器负载与串行连接策略相同，实现了低负载的目标；
异常情况下，每4s发起新（IP，Port）组合的 connect 调用，使得应用可以快速的查找可用 IP&Port，实现高性能的目标；
在超时时间的选择上，复合方式的“并发”已经实现了高性能、低负载的目标，因此在超时时间的选择上可以相对宽松，以保障高可用为重。
综合对比，复合连接能够维持低资源消耗的情况下，能同时实现低负载、高性能、高可用的目标。

Mars的智能心跳

智能心跳指的是长连接过程中，应用层维护的自己和服务端的心跳连接。客户端在适当的时间周期内，向服务端发送一个心跳请求，判断当前的连接是否可用。一般的app处理是用一个定时的任务（45s）连续的向服务端发送ping请求，等待服务端的返回。如果心痛不同，则认为当前的长连接不可用，需要重新进行长连接的建联。
微信的智能心跳如下
心跳时间区间：最小4分30秒，最大9分50秒；
心跳增加步长：60秒；心跳稳定后，探测步长：20秒；
当前APP为活跃状态，长连刚连接前3个成功心跳，和没有网络，这3种情况使用固定最小心跳：4分30秒；其他情况使用自适应智能心跳，基本算法如下；
连续3个心跳成功后，每心跳增加60秒心跳步长，一直到最大9分50秒，设为固定状态；
连续3个心跳失败后，减少60+20秒，第4个心跳失败，直接设最小心跳4分30秒；

微信心跳机制.png