共计 1583 个字符，预计需要花费 4 分钟才能阅读完成。
前言
以前看 <<TCP/IP 详解卷一 >> 的时候，发现可以根据 IP 报文中的 TTL 字段追踪数据包的路由详情，觉得很有意思。后来知道别人早就把它实现出来了，就是 linux 下的 traceroute 命令 (windows 的 tracert), 学了 golang 后也想实现一个 go 版本的，但中间都给种种事情耽搁了，最近把工作辞了，刚好有点时间，就想着把它做出来，顺便当作个人项目去面试。
应用场景
在分析 traceroute 之前，先介绍一下它的应用场景。不知道你们有没有遇到过这样情况，就是买了个国外的服务器，用 ssh 连接的时候发现很慢，然后你就会忍不住 ping 一下看延迟多少，如果出来 300 的延迟你会忍不住吐槽一句：什么破服务器，延迟这么高。然后你肯定想知道原因，为什么这破服务器这么卡。
而这时候 traceroute 就可以派上用场了，你用 traceroute 测一下就知道，它会可以追踪数据包的路由详情，可以知道从你的电脑到服务器之间经过了多少跳的路由，如果是数据包经过很多跳路由最终才到服务器，自然就很卡。
下面我用 vultr.com 域名测试，先 ping 一下
Pinging vultr.com [108.61.13.174] with 32 bytes of data:
Reply from 108.61.13.174: bytes=32 time=234ms TTL=50
Reply from 108.61.13.174: bytes=32 time=233ms TTL=49
Reply from 108.61.13.174: bytes=32 time=247ms TTL=49
Reply from 108.61.13.174: bytes=32 time=233ms TTL=49
Ping statistics for 108.61.13.174:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 233ms, Maximum = 247ms, Average = 236ms200 多的延迟，然后我们再用 tracert(windows 下的 traceroute) 测一下：
Tracing route to vultr.com [108.61.13.174]
over a maximum of 30 hops:
1 1 ms 2 ms 2 ms 192.168.0.1 [192.168.0.1]
2 2 ms 1 ms 1 ms 192.168.1.1 [192.168.1.1]
3 4 ms 3 ms 3 ms 183.17.228.1
4 15 ms 40 ms 4 ms 153.106.38.59.broad.fs.gd.dynamic.163data.com.cn [59.38.106.153]
5 8 ms 17 ms 18 ms 183.56.65.14
6 9 ms 7 ms 7 ms 202.97.90.162 深圳
7 17 ms 17 ms 16 ms 202.97.38.166 昆明
8 185 ms 192 ms 184 ms 202.97.51.94 上海
9 164 ms 167 ms 165 ms 202.97.90.118
10 191 ms 170 ms 183 ms 9-1-9.ear1.LosAngeles1.Level3.net [4.78.200.1]
11 * * * Request timed out.
12 235 ms 239 ms 247 ms 214.213.15.4.in-addr.arpa [4.15.213.214]
13 * * * Request timed out.
14 * * * Request timed out.
15 246 ms 248 ms 237 ms 174.13.61.108.in-addr.arpa [108.61.13.174]可以看到经过了 15 跳的路由，如果你分别查一下这些 ip 对应地方，会发现它从深圳绕到昆明，再绕到上海最后才去了美国，绕了中国大半圈，延迟不高才怪呢。
原理分析
具体实现
正文完
