Shunix's Weblog

Telegram网络层源码分析

Shunix -

最近看了一下Telegram网络层的源码，本来想网上找一下现成的结论，降低一点学习成本，但是并没有发现相关的资料。于是自己梳理了一下telegram是如何发送网络请求和响应回包的，这里做个总结。

连接的建立

先上一张图：

这张图描述了telegram客户端和server的连接时如何建立的。Java层的ConnectionsManager是一个线程安全的单例，其实只是个wrapper，真正的逻辑都是转交给C++层的ConnectionsManager类处理的。 C++层的ConnectionsManager对象，在TgNetWrapper.cpp中初始化，也同样是个单例。这里贴一下C++层ConnectionsManager类的init方法:

这里有两个关键的方法调用，一个是loadConfig()，一个是pthread_create()。顺着时间线往下看，loadConfig()调用了initDataCenter()方法，这个方法实现如下:

可以看到，主要是一些hardcode的IP和端口，其实在连接上第一个数据中心之后，客户端就会被分发到最优的数据中心接入，这里写这么多，可以看作一种fallback逻辑。
接下来使用了一个pthread_create的调用，新的线程中会执行ThreadProc()方法，这个方法会先调用sendPing()，实现如下：

这里调用了DataCenter的getPushConnection()和getGenericConnection()方法，这里把connection类型区分开的本意是下载，推送等使用不同的连接，这样可以防止一些耗时任务一直占用连接，同一个数据中心，可以给不同类型的连接分配不同的IP和端口，来提高网络连接的效率。
接下来是一个循环，循环中不断调用select()方法，来处理请求，这个方法的实现如下：

这里有一个epoll_wait()的调用，直觉上来说，这就是处理网络请求的核心，所以我们也从这里开始分析，先看一下这个epolFd上注册的fd:

这里分析一下，epolFd上注册的fd一共有两类：

  1. socket。这里可以看到，socket连接在创建时，会向epoll注册自己，在关闭时会把自己从epoll的监视列表移除。而adjustWriteOp()方法是在socket发送数据时调用，我们知道，对于socket的send，只是把数据发送到了缓冲区，如果缓冲区满会触发EAGAIN，这个时候就要监听EPOLLOUT，表示缓冲区可写，adjustWriteOp()方法完成的就是这个操作。
  2. 用于事件通知的fd，这里有eventFd和pipeFd。这两个用于事件通知的fd不会同时使用，先初始化eventFd，pipeFd仅仅是在eventFd无法成功初始化时的备选方案。这两个fd具体用在哪里可以看下面的代码段。

wakeup()方法调用的地方在这里：

这个scheduleTask()方法是写得最耐人寻味的地方。我本来以为，这只是个网络请求的任务队列，后来查了一下这个方法的调用，发现这个队列的东西真是包罗万象，什么加载文件，加载配置，设置dns，设置语言等任务都放到了这个队列里，感觉上是一个jni层全局的调度器。而对于网络请求，都是放在requestQueue中，查看sendRequest()方法不难看出来，处理网络请求是在processRequestQueue()方法中进行的。
现在再来看select()方法，流程就清楚多了，epoll_wait会在以下几种情况下被唤醒：

  1. socket连接有数据需要接收
  2. socket缓冲区可写，上一次发送的数据没有完成
  3. 有任务在pendingTasks队列中

当线程被唤醒，不再阻塞之后，会首先去处理pendingTasks队列中的请求。然后调用epoll返回的EventObject对象的onEvent()方法依次处理，这个EventObject方法其实可以看作一个wrapper，会根据EventObjectType把逻辑分发到各个对象上，代码如下：

对于epoll，会用到的类型是EventObjectTypeConnection, EventObjectTypePipe, EventObjectTypeEvent.
完成EventObject的处理之后，接下来会关闭超时连接，这里的超时时间是12秒，然后要处理长连接的心跳。这里对于长连接心跳的处理如下：

  1. 关闭超时的长连接。这里对于超时的判定有两个条件，一是发送心跳包没有收到回包，已经过去了30s，二是距离上次发送心跳包时间已经过了190s。
  2. 判断当前时间距离上一次发送心跳包是否已经超过了180s，如果是的话，则发送长连接心跳包。这里可以得出结论，Telegram的长连接心跳周期是3分钟。
    接下的处理非常良心，Telegram在检测到当前队列没有上传下载任务和向server请求盐值的任务时，会关闭和数据中心的socket连接。这里有一个阈值是10s，可以认为，如果把应用切到后台，在完成当前队列里的上传和下载请求10s后，Telegram就会关闭长连接，停止发心跳。这个操作非常省电，反观国内大把app，各种黑科技保活。
    那么有一个问题，Telegram是如何保证休眠后还能接收到消息呢？答案是GCM，从AndroidManifest.xml里很容易找到GCM对应service的实现类：

这里的ConnectionsManager.getInstance().resumeNetworkMaybe()就是尝试重新恢复长连接的操作，逻辑很简单，就不再赘述。
最后一步，对于和DataCenter的普通连接，也发送心跳保活，这里的心跳周期是19s，然后每小时更新一次DataCenter的配置。再调用processRequestQueue()方法开始处理请求队列中的任务。
这里整理了一个比较直观的流程图，说明了发起请求的过程。

Telegram网络模块的分析就到这里了。