0x80070035找不到网络路径_网络入门 认识网络探测命令

网络联通性问题的排查过程中，常用命令如 ping，traceroute，mtr ，看懂这些命令的结果容易，但知其所以然却考验基本功，所以顺手给自己梳理了一下其中常被忽视的工作原理，不会写的太详尽，但希望都是有价值的知识点，温故知新～   Traceroute 测试环境：macOS 在终端输入traceroute  xxxx并解析到对端服务IP后，将发起本地到对端服务IP的链路探测，探测过程会先发送一个TTL为1的UDP数据包，如截图中红框内容所示，该数据包中包含允许到达的最大hop(跳数)。由于每经过一台路由器，经过的hop计数加1，也就是说，第1个UDP包会在到达第1台路由器时结束它的生命周期，并返回一个ICMP的差错报文(在指定TTL内，无法到达目标地址)，本地收到差错报文后把TTL值加1，允许到达上次阵亡所在地的下一跳路由器。 我们在探测结果中可以看到每一跳的耗时，这里耗时计算的方法是，在探测包发出时标记时间戳，收到ICMP响应时打上时间戳，根据两个时间戳计算往返时间，所以耗时是指往返耗时RTT，而同TTL可以发多个探测报文，图中是会默认发3个，所以会有三个RTT结果。 在未到达目标IP前，所有的差错报文都会以Time-to-live exceeded的形式返回，当TTL数能够达到目标主机IP后，如何把这个到达信息返回给本地呢？因为UDP是面向无连接，如果一直未收到对端的返回包，本地无法获知数据包是在路上丢了还是对方确实未响应，所以traceroute借助了一个方法判断，即通过指定一个非常大且几乎不会被占用(>30000)的目标端口号，使目标主机返回差错报文「目标端口不可达」。本地获取到这个包后判断本次链路探测结束。 在我们使用traceroute的过程中会出现，持续一段时间的丢包后开始正常，或者发到一半开始就再无响应的情况(如traceroute www.baidu.com的结果)，这时不能直接判断对端是否可达，因为常常是防火墙或者服务端配置了不响应ICMP报文或者不处理UDP数据包导致。 除了traceroute常见的「目标(端口)不可达」和「超时(TTL)不可达」两种差错报文外，常见的差错报文还有：

1. 源站抑制：线路中某个位置出现网络拥堵，建议降低IP包发送频率。(使用较少)
2. 重定向：发送端使用了非最优路径，引导发送端下次向更优路径上的下一跳路由器发送请求。

其中，「目标不可达」又包含以下几种不可达类型：

1. 网络不可达：找不到去往对应网段的路径。
2. 主机不可达：已经到达目标网段内，但找不到目标主机。
3. 协议不可达：请求的协议不被服务端支持，如对端限制了TCP协议请求(四层)，可能就会返回一个ICMP包(三层)通知你协议不可达。
4. 端口不可达：已经找到目标主机，但是目标端口不提供服务。

  Ping

Ping的工作机制是基于ICMP协议的主动探测。

在请求时，对每一个数据包做标记，如seq=1/256，含义为256个请求包中序号为1的包，对应的，针对序号为1的响应包中也会含有标记1/256，用序号来区分数据包是否达到以及到达的先后顺序，计算单个探测请求的RTT时间，最后也可以统计出发送了多少包，最终回来了多少个数据包。 Type:8 (Echo(ping) request) 代表该ICMP包的具体类型为一个探测请求包。 Type:0 (Echo(ping) reply)代表该ICMP包的具体类型为一个探测响应包。 1.request请求包 2.reply响应包 如下图所示，这个request包的TTL限制为64，主要是为了防止网络环路造成数据包回不来的情况，超出64跳以后，认为这是一个不可达的地址。每经过一跳路由器，TTL值减1。 traceroute的不同探测包TTL从0开始逐渐加1，ping的每一个探测包TTL从64(默认)开始逐渐减1。 两者的另一个区别是，traceroute利用ICMP的差错报文在工作，而ping利用了ICMP的主动探测报文(type8)在工作。 对端服务器Ping不通的情况，大部分是由于对端限制了ICMP协议的数据包，根据服务端的不同处理行为，请求端显示的结果也不相同。(这里的大部分特指非底层网络搭建过程的实际业务中)

1. Refused ICMP，表现为对端拒绝了访问。
2. Drop ICMP，表现为request timeout。

     Mtr 当 网络出现问题时，也常会用mtr去探测，这个工具需要额外进行安装，集成了tracer oute和ping包的优点和特性，所以原理方面不再赘述，主要聊下对探测结果的分析。 这里我们以mtr 1.1.1.1为例，如下图所示，结果中包含每一跳的探测信息，包括在每一跳的丢包率和耗时。 针对网络联通性较差的情况，首先需要关注的是，最后一跳有没有丢包。比如这里第12跳的时候，有21.4%的包没有返回预期的响应，但是所有的数据包都能在13跳到达目标IP时返回响应，即，每一个数据包都可以到达目标IP，这就是一个没有丢包正常网络，所以并不用纠结为什么12跳丢包(12跳丢包的原因结合上面所说的traceroute就很容易理解)。 显而易见，如果最后一跳有丢包的现象，那么需要以最后一跳为基准，逐渐向前一跳追溯，上一个丢包的位置在哪里。当我们去探测云服务器的联通性时，可能会在集群入口/防火墙处丢包，也可能在运营商处丢包，通过mtr可以方便的获取到丢包的位置。 双向mtr是指，本地执行mtr服务端IP，同时在服务端机器上mtr本地的公网IP，可以更好的了解往返路径的丢包情况，定位更精准。 mtr结果各列的含义：

• Host：探测的IP地址或域名
• Loss%：对应IP的丢包率
• Snt：每秒发送数据包的数量，默认值是10，可以通过参数 -c来指定发送包的数量
• Last：最近一次的返回时延
• Avg：平均时延
• Best：时延最短耗时
• Wrst：时延最久耗时
• StDev：标准偏差，时延数据的波动性高低