昨天突然被问到traceroute的原理，一时竟也说不出来，有些命令平时虽然经常在用，但实际原理确并不了解，趁这次机会就来梳理一下。
traceroute：是网络诊断中，用来分析IP包经过那些路由的命令。
学前知识：
IP包中有个字段TTL，这个是最大跳转次数的字段，每经过一个路由器，值会-1，当值为0的时候，这个包就会被路由器丢弃，并返回ICMP-超时包给请求主机。
实现原理：
1、traceroute首先发出三个UDP包（发出三个主要是为了统计，这里可以不用太在意），其TTL的字段为1，目的地为目标主机的IP，该UDP包在经过路由器-1时，TTL值会被设置为0该包会被丢弃，并返回ICMP-超时给请求主机；
2、在收到路由器1发来的"ICMP-超时"包时，traceroute会继续发出三个UDP包，其TTL的字段被设置为2，该UDP包顺利的经过了路由器-1，在到达路由器-2时，TTL值被值为0，随之丢弃，返回ICMP-超时包给请求主机；
…………继续重复，每收到一个返回ICMP-超时的包，则继续发出TTL值+1的UDP包；
3、就这样，在经历了4个路由器后，TTL=5的UDP包，历经千山万水，终于来到了目的主机，大家可能会觉得目的主机会欣然接受这个UDP包，但实际不是，目的主机做了如下的处理：
- 丢弃（不认识你，狗带）
- 返回ICMP-目标不可达包给请求主机
大家可能觉得很奇怪，为什么会被丢弃呢？简单的说一下，就是主机没有监听该UDP端口的进程。
4、请求主机的traceroute程序，在收到ICMP-目标不可达包后，终于心满意足的结束工作了。
下面为了加深一下印象，结合tcpdump命令，对traceroute过程进行一些验证
主要观察过程中[发出的UDP包] [路由器返回的ICMP-超时包] [目的主机返回的ICMP-目标不可达包]
1、使用命令，监听目的主机相关的包
tcpdump -i eno33554984 -vvnn host 119.146.184.98
2、使用traceroute命令对目的主机发起请求
[root@www ~]#traceroute 119.146.184.98
traceroute to 119.146.184.98 (119.146.184.98), hops max, byte packets
192.168.0.1 (192.168.0.1) 2.217 ms 1.741 ms 1.509 ms
116.24.132.1 (116.24.132.1) 11.348 ms 11.117 ms 11.287 ms
113.106.47.93 (113.106.47.93) 7.111 ms 6.848 ms 7.123 ms
5.107.38.59.broad.fs.gd.dynamic.163data.com.cn (59.38.107.5) 6.921 ms 6.712 ms 6.434 ms
183.59.12.153 (183.59.12.153) 8.635 ms 7.664 ms 7.593 ms
183.61.222.102 (183.61.222.102) 11.923 ms 10.220 ms 9.423 ms
119.146.184.198 (119.146.184.198) 15.779 ms 119.146.184.94 (119.146.184.94) 47.902 ms 119.146.184.62 (119.146.184.62) 16.571 ms
####################################
#返回结果解释：
#列1：[] 经过的路由器序号；
#列2：[192.168.0.1 ] 路由器IP（也叫网关）；
#列3：[(113.106.47.93) ] 即括号内的内容，具体用途不明，有懂的可以解释一下哈；
#列4：[7.111 ms] 返回的时间，这里也可以发现，一共有3个时间，还想起来吗？traceroute每次发出的UDP包都是3个一起发的；
需要注意的是，大家可以看到最后一列，是有3个地址的，其实也不难理解，路由器是会根据实际情况寻找合适的路径；
3、现在来看看tcpdump采集的结果，观察由请求主机发出的UDP包
::27.892318 IP (tos 0x0, ttl , id , offset , flags [none], proto UDP (), length )
192.168.0.200. > 119.146.184.98.: [bad udp cksum 0xf19e -> 0xfaae!] UDP, length
::27.892798 IP (tos 0x0, ttl , id , offset , flags [none], proto UDP (), length )
192.168.0.200. > 119.146.184.98.: [bad udp cksum 0xf19e -> 0x000b!] UDP, length
::27.893869 IP (tos 0x0, ttl , id , offset , flags [none], proto UDP (), length )
####################################
#返回结果解释：
#可以看到我们的主机，往119.146.184.98发出TTL=1的UDP包，而且是三个；这里大家可以奇怪，不是说经过的网关会返回ICMP-超时的包吗？为啥没看到呢？
#为什么呢？
#因为ICMP-超时这个包，不是119.146.184.98返回的，那是谁返回的呢？回忆一下上文！是路由器！所以这里我们需要使用tcpdump指定路由器的ip来抓包。
4、观察路由器返回的ICMP-超时包
tcpdump -i eno33554984 -vvnn host 116.24.132.1
#温馨提示：执行完这个命令后，你需要重新执行traceroute 119.146..98命令才能进一步观察116.24.132.1返回的包哦
::26.210530 IP (tos 0xc0, ttl , id , offset , flags [none], proto ICMP (), length )
116.24.132.1 > 192.168.0.200: ICMP time exceeded in-transit, length
IP (tos 0x0, ttl , id , offset , flags [none], proto UDP (), length )
192.168.0.200. > 119.146.184.98.: UDP, length
####################################
#返回结果解释：
#这里我们选择了采集第二跳的路由器地址116.24.132.1的数据包（为什么不用第一跳呢？因为第一跳往往是自己家里的路由器地址，这个地址的包会非常多，不容易观察到实验#结果）
#从返回的结果中，我们可以看到第二跳路由器确实返回ICMP time exceeded包，实际上会有3个，就不一一列举了。
5、观察目的主机返回的ICMP-目标不可达包
#在 [root@www ~/test_traceroute]#tcpdump -i eno33554984 -vvnn host 119.146.184.98 命令返回的结果中查看
::27.972224 IP (tos 0x0, ttl , id , offset , flags [none], proto ICMP (), length )
119.146.184.98 > 192.168.0.200: ICMP 119.146.184.98 udp port unreachable, length
IP (tos 0x0, ttl , id , offset , flags [none], proto UDP (), length )
192.168.0.200. > 119.146.184.98.: UDP, length
####################################
#返回结果解释：
#在返回结果中最后的地方可以看到ICMP 119.146.184.98 udp port unreachable的字样。
最后再总结一下traceroute常见返回结果的分析:
1、大家在练习的时候，可能第一个想到的就是拿一些知名网站来测试，下面我们就拿百度的一个ip地址来测试
[root@www ~]#traceroute -m 14.215.177.38
traceroute to 14.215.177.38 (14.215.177.38), hops max, byte packets
192.168.0.1 (192.168.0.1) 2.395 ms 2.063 ms 1.583 ms
116.24.132.1 (116.24.132.1) 36.296 ms 36.939 ms 36.706 ms
183.56.71.225 (183.56.71.225) 6.550 ms 6.304 ms 6.396 ms
183.56.66.93 (183.56.66.93) 5.716 ms 5.491 ms 5.713 ms
183.56.64.50 (183.56.64.50) 8.059 ms 7.733 ms 7.513 ms
* * *
14.29.121.194 (14.29.121.194) 9.082 ms 14.29.121.198 (14.29.121.198) 8.977 ms 14.29.121.206 (14.29.121.206) 9.700 ms
* * *
* * *
* * *
####################################
返回结果解释：
*号代表发出去的UDP没有收到相应的ICMP-超时包，这个主要是因为某些路由器安全原因，拒绝返回ICMP-超时包。
所以大家可以看到第六跳的记录都是*号，说明，第六跳的路由器没有返回ICMP-超时包。
同时存在如下一点疑问：
为什么traceroute没有结束，一直不断的检测呢？（我们在命令中指定检测10跳的参数），如果你有耐心，可以指定-m 128参数，会发现traceroute始终无法自动结束，每次都需要耗尽所有的检测次数。
2、那么，为什么8 9 10跳返回的也是*呢？这里合理推测一下：
- 我所在的网络，访问百度这个网站，至少需要7跳才能到达，在第七条以后，TTL=8的UDP包可能已经到达百度的主机，那么为什么traceroute没有结束呢？
- 一个合理的推测，就是百度14.215.177.38这个主机直接丢弃了我们的UDP包，拒绝返回ICMP-目标不可达包；
- 由于traceroute一直没有收到ICMP-目标不可达包，所以他会一直生成UDP包，并增加TTL的值发出，直到达到我们指定的检测跳数（本例中，我们指定的跳数=10）。
- 大家也可以使用如下命令
[root@www ~/test_traceroute]#tcpdump -i eno33554984 -vvnn host 14.215.177.38
这个命令可以采集到14.215.177.38的相关包，可以看到只有发出去的包，没有返回的包，也基本可以验证我们的推测。