现实世界中的网络是由无数的计算机和路由器组成的一张的大网，应用的数据包在发送到服务器之前都要经过层层的路由转发。而Traceroute是一种常规的网络分析工具，用来定位到目标主机之间的所有路由器

在介绍Traceroute的原理之前，需要了解几个技术名词：

• IP协议是TCP/IP协议族中最核心的部分，它的作用是在两台主机之间传输数据，所有上层协议的数据（HTTP、TCP、UDP等）都会被封装在一个个的IP数据包中被发送到网络上。

• ICMP全称为互联网控制报文协议，它常用于传递错误信息，ICMP协议是IP层的一部分，它的报文也是通过IP数据包来传输的。

• TTL（time-to-live）是IP数据包中的一个字段，它指定了数据包最多能经过几次路由器。从我们源主机发出去的数据包在到达目的主机的路上要经过许多个路由器的转发，在发送数据包的时候源主机会设置一个TTL的值，每经过一个路由器TTL就会被减去一，当TTL为0的时候该数据包会被直接丢弃（不再继续转发），并发送一个超时ICMP报文给源主机。

具体到traceroute的实现细节上，有两种不同的方案：

在基于UDP的实现中，客户端发送的数据包是通过UDP协议来传输的，使用了一个大于30000的端口号，服务器在收到这个数据包的时候会返回一个端口不可达的ICMP错误信息，客户端通过判断收到的错误信息是TTL超时还是端口不可达来判断数据包是否到达目标主机，具体的流程如图：

1. 客户端发送一个TTL为1，端口号大于30000的UDP数据包，到达第一站路由器之后TTL被减去1，返回了一个超时的ICMP数据包，客户端得到第一跳路由器的地址。
2. 客户端发送一个TTL为2的数据包，在第二跳的路由器节点处超时，得到第二跳路由器的地址。
3. 客户端发送一个TTL为3的数据包，数据包成功到达目标主机，返回一个端口不可达错误，traceroute结束。

Linux和macOS系统自带了一个traceroute指令，可以结合Wireshark抓包来看看它的实现原理。首先对百度的域名进行traceroute：traceroute ，每一跳默认发送三个数据包，我们会看到下面这样的输出：

注意看红框处的内容，跟第一张图对比，可以看到traceroute程序首先通过UDP协议向目标地址115.239.210.27发送了一个TTL为1的数据包，然后在第一个路由器中TTL超时，返回一个错误类型为Time-to-live exceeded的ICMP数据包，此时我们通过该数据包的源地址可知第一站路由器的地址为10.242.0.1。之后只需要不停增加TTL的值就能得到每一跳的地址了。

然而一直跑下去会发现，traceroute并不能到达目的地，当TTL增加到一定大小之后就一直拿不到返回的数据包了：

其实这个时候数据包已经到达目标服务器了，但是因为安全问题大部分的应用服务器都不提供UDP服务（或者被防火墙挡掉），所以我们拿不到服务器的任何返回，程序就理所当然的认为还没有结束，一直尝试增加数据包的TTL。

目前在网上找到许多开源iOS traceroute实现大多都是基于UDP的方案，实际用起来并不能达到想要的效果，所以我们需要采用另一种方案来实现。

上述方案失败的原因是由于服务器对于UDP数据包的处理，所以在这一种实现中我们不使用UDP协议，而是直接发送一个ICMP回显请求（echo request）数据包，服务器在收到回显请求的时候会向客户端发送一个ICMP回显应答（echo reply）数据包，在这之后的流程还是跟第一种方案一样。这样就避免了我们的traceroute数据包被服务器的防火墙策略墙掉。

采用这种方案的实现流程如下：

1. 客户端发送一个TTL为1的ICMP请求回显数据包，在第一跳的时候超时并返回一个ICMP超时数据包，得到第一跳的地址。
2. 客户端发送一个TTL为2的ICMP请求回显数据包，得到第二跳的地址。
3. 客户端发送一个TTL为3的ICMP请求回显数据包，到达目标主机，目标主机返回一个ICMP回显应答，traceroute结束。

可以看出与第一种实现相比，区别主要在发送的数据包类型以及对于结束的判断上，大体的流程还是一致的。

值得一提的是在Windows系统中也有traceroute程序，它的名字叫做tracert，tracert就是用采用这种方法来实现的，感兴趣的话可以自行尝试一下，这里就不再演示了。

这里我们主要讨论基于ICMP的实现，相关的Demo已经上传至github：

采用这种方案时，ICMP数据包的创建、解析、校验都需要我们自己进行，ICMP是封装在IP数据包的数据段中传输的，所以关键在于如何创建和发送ICMP数据，以及接收到返回的数据时如何从IP数据包中将ICMP解析出来：

ICMP数据包头部的格式如下：

其中的类型字段用来表示消息的类型，在上可以看到所有类型代表的含义。报文中的标识符和序列号由发送端指定，如果这个ICMP报文是一个请求回显的报文（类型为8，代码为0），这两个字段会被原封不动的返回。

根据上图中各个字段的大小可以定义如下类型：

其中的type字段指定了这个ICMP数据包的类型，是需要重点关注的对象，为此定义一个报文类型的枚举：

比较麻烦的是校验的计算，这一部分直接使用了苹果官方示例中的代码，所涉及到的几个工具方法封装在类型TracerouteCommon中。

在发送数据的时系统会自动加上IP头部不需要自己处理，如此一来我们只需要创建一个ICMPPacket数据包并通过socket发送到目标服务器就可以了。

接下来就是要接收服务器向我们返回的ICMP数据了，我们接收到的是带有IP头部的原始数据，所以必须先进行一些处理将ICMP从IP数据包中提取出来，IP数据包由两部分组成：数据包头部信息部分以及实际的数据部分。下图是IPv4数据包的结构：

一眼看上去是不是感觉很混乱，其实这里面只有用红框圈出来的这这三个字段需要我们关心：版本表示该数据包是IPv4还是IPv6；之前说过ICMP协议是通过IP协议来传输的，如果该数据包传输的是ICMP协议则协议字段会被设置为1；由于IPv4数据包带有可选的选项字段，所以其头部的长度是可变的，此时需要根据首部长度字段来获取具体的数据。

根据上面的结构可以定义类型：

提取ICMP数据包的方法如下：

其中出现的如ipPtr->versionAndHeaderLength & 0xF0的判断是因为版本号和首部长度各自只占4个bit，在结构中直接定义了一个1字节的uint8_t类型来表示，所以只能通过位运算符&来获取各自的值。

有了上面的两步，剩下的事情就很简单了，下面是整体流程的伪代码：

// 1. 创建一个套接字
 // 4. 发送并等待返回的数据包
 
 // 5. 解析数据包，记录数据，成功条件判断

socket的类型采用了SOCK_DGRAM，有些小伙伴可能会感到疑惑：用SOCK_DGRAM创建套接字不还是发送UDP数据么？

确实在许多系统的实现中要直接发送ICMP的话需要使用原始套接字（类型为SOCK_RAW），这在iOS系统中是不被允许使用的，但是查阅资料中了解到macOS支持一种使用参数SOCK_DGRAM和IPPROTO_ICMP来直接创建ICMP套接字方式，尝试之下果然iOS也支持这种用法。不过在使用中发现了一个问题：使用IPv4套接字的时候接收到的数据包是带有原始IP头部的，而使用IPv6套接字的时候收到的数据包却没有IP头部，这个问题让我比较疑惑，各位大佬如果有对这一块了解的话还望赐教。

中的示例程序已经在模拟器和真机环境经过测试，可以看到，现在Traceroute已经能够正常的工作了：

有些路由器会隐藏的自己的位置，不让ICMP Timeout的消息通过，结果就是在那一跳上始终会显示星号，此外服务器也可以伪造traceroute路径的，不过一般应用服务器也没有理由这么做，所以Traceroute的结果还是能够为网络分析提供一些参考的。

FD（File Descriptor）文件描述符在形式上是非负整数，它是一个索引值，指向内核为每个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在Linux系统中，一切设备都视作文件，文件描述符为Linux平台设备相关的编程提供了一个统一的方法。

在stability测试的过程中，经常会出现许多FD泄漏导致的莫名其妙的FC，而crash的堆栈也是千奇百怪， 可能出现在应用层、framework层、Native层，其中以framework层居多。 所以当出现这个问题以后往往认为是framework出现问题了， 实际上从后面Debug的结果来看许多都是应用出现了问题。 同一个问题也会经常出现不同的堆栈。这就是FD泄漏的一个重要的特性，问题出现的不确定性。

FD作为文件句柄的实例，可以用来表示一个打开的文件，一个打开的网络流(socket)，管道或者资源（如内存块），输入输出(in/out/error)。 在Linux系统中，每个进程可以使用的FD数量是有上限的，在Android中这个上限为1024，表示每个进程可以创建的file descriptors 不能超多1024个。可以通过下面两种方式查看：

相比较传统的内存泄漏，FD泄漏在大部分情况下不会出现内存不足的情况，所以出现问题的时候会更加隐晦。由于发生FD泄漏的时候内存可能不会出现不足，所以不会出发系统的GC操作，导致只有通过crash进程的方式去自我恢复。事实上在很多情况下，就算触发系统GC，也不一定能够回收已经创建的句柄文件。

Android应用可能会需要很多资源，像输入输出流，数据库资源Cursor， Binder设备。如果没能够很好的处理这些资源，不仅可能造成内存的泄漏，也可能会出现FD泄漏。

用来指向这个打开的文件，而如果反复执行下面的代码，FD文件会持续不断地增加，直至超过1024出现FC。

在/proc/${进程id}/fd/ 目录下执行ls –l查看到增加的FD指向创建的文件，这里创建了不同的file，即使是对同一个文件，也会创建多个FD来指向这个打开的文件流。

最终导致应用进程出现FC，并打出如下的Log， 表示这个进程FD数量已经到达了上限，无法再创建新的FD，只有终止进程。

正确的做法是能够在final中将流进行关闭,这样无论中途是否出现异常导致程序中断，都会将流顺利关闭。

与输入输出相似，数据库查询的Cursor如果没有及时进行Close，也会出现FD泄漏的情况。 如下面这段异常的Log:

这个问题是在Stability测试环境下出现的，由于未能够在Cursor使用后及时进行关闭，最终出现了FD的溢出。 从上面FC的Log可以看到，异常出现在ContentProvider跨进程传递传递的时候，出现了异常，显示无法打开database文件。看到unable to open database file，大胆地猜测是否是出现了FD的泄漏。然后在Log中找到了下面这段，确定了是FD泄漏造成了这次的FC。

而对于Cursor没有及时关闭这个问题，下面这种情况很容易造成开发者的疏忽，导致出现问题：

下面这段异常Log是在Monkey测试中出现的，所以没有明确的操作步骤，测试脚本提取的crash堆栈如下，显示的是无法分配JNI资源，看上去是一个典型了内存泄漏问题。

但是在查看Log以后，在前面找到了下面的Log，发现原来是FD发生了泄漏。具体表现为打开FMRadio后，点击Recent按键500～600次， /proc//fd/目录下fd文件数量不断增长，直到超过1024阀值发生FC.

在Android中使用线程，尤其是HandlerThread要尤其的谨慎，必须要确保创建HandlerThread的函数不会被反复的调用导致线程反复的被创建。 如果循环调用下面这段代码几百次，就会出现FD泄漏。

HandlerThread实际上是带有Loop的thread，而对于传统的Java Thread，需要声明Loop以后才会出现FD的增加。因为声明Loop相当于增加了一块缓冲区，需要有一个FD来标识。如果反复调用下面这段代码也会出现FD泄漏。

公司的同一个手机项目的的stability测试中，出现了两个crash的log，堆栈几乎完全不一样，但是后面发现原来都是没有及时调用WindowManager.removeView造成的。 第一份log如下：

所以两个问题确实是属于同一个问题，都属于FD泄漏。我们在两份Log中到找到了如下的Log：

一台手机在跑Monkey的时候出现的这个问题，错误的堆栈信息如下，看着堆栈，挂在了native层， abort message 发现原来是FD文件超了

我们发现问题出在如下的代码上：

写一封新邮件,startactivity 使用的flag是multiTask，也就是说，每点击创建新的邮件，都会创建task。而Monkey在跑的时候创建了n个邮件的task， 而对应打开的ComposeActivityEmail.java 的 “插入快速语” 会创建很多个fd , 最终导致FD超过1024， 进程崩溃。 实际上，通过反复如下代码就会出现这个问题：

FD会发生泄漏的根本原因是没有对资源进行有效的管理。无论是文件资源，设备资源，Socket资源，输入输出流还是线程等，如果被频繁的调用而没有即使释放，甚至根本就没有释放，将会使得FD越积越多，最终导致了泄漏的发生。

这类问题比较容易在Stabiliy、Monkey、JrdLog中出现，当在这些测试中遇到挂在不可思议的地方的时候就可以看看是否可能是FD泄漏引起的问题。

并不是说有上面的关键字，就一定是FD泄漏，JNI对象泄漏也会出现too many的字段；也并不是说没有上面的关键字就一定不是FD泄漏问题，具体到问题还是需要具体分析。

每个进程创建的FD文件都在/proc/${问题应用所在进程}/fd/这个目录下,在这个目录下执行ls |wc –l 或者在任意adb shell目录下使用lsof ${问题应用所在进程} |wc –l, 都可以查看进程的FD文件数量，如果能够找到某个或者某些操作能够让FD数量稳定的增长，那么就容易解决。

一般可以尝试反复点击Recent， 反复打开应用或者Activity，然后按back返回等操作，反复横竖切换等。

由于存在1024这个阈值，普通用户在使用过程中一般不会出现这个问题，出现这个问题一般都是Stability测试或者Monkey出现的。

如果stability这样的测试中，可以通过编写脚本每1 min 抓取一次FD的数量，观察在什么时间段FD数量出现了稳定的增长过程，然后再对比期间所做的测试操作，通过分析尝试去找到手动的复现路径。

而Monkey测试就没有什么规律了，因为测试本身就是乱序的操作过程，要知道复现只能够通过联系Log上下文，查看操作了哪些Activity，做了哪些操作，哪些Log是反复打印的，哪些Log出现不正常的现象，然后一个个去尝试排除。

一旦有了复现路径以后，要找到相应出问题的代码段的返回就会小了很多。

如果能定位到具体的文件，可以先查看一下最近的提交记录。如果这个问题之前没有后来才出现，一般都是改出来的问题，按照之前debug经验来看，这种情况还是占了大多数。但是有些问题之前没出现，可能只是没有被测试来而已，很多原生的代码也是会出现问题的。

如果运气不好遇到这些原生问题，可以重点查看哪些可能会被反复调用的代码段，在Java层面比如说onResume，onConfigurationchanged 之类函数，查看在这些代码段中是否由创建什么线程、资源，而在onPause或者onDestroy没有被释放掉的。