【Linux网络#15】：DNS 协议 & ICMP 协议

一、DNS 协议

DNS 是一整套从域名映射到 IP 的系统

1. DNS 背景

TCP/IP 中使用 IP 地址和端口号来确定网络上的一台主机的一个程序，但是 IP 地址不方便记忆，于是人们发明了一种叫主机名的东西, 是一个字符串, 并且使用 hosts 文件来描述主机 名和 IP 地址的关系.

最初，通过互连网信息中心（SRI-NIC）来管理这个 hosts 文件的.

• 如果一个新计算机要接入网络, 或者某个计算机 IP 变更, 都需要到信息中心申 请变更 hosts 文件.
• 其他计算机也需要定期下载更新新版本的 hosts 文件才能正确上网.

这样就太麻烦了, 于是产生了 DNS 系统.

• 一个组织的系统管理机构，维护系统内的每个主机的 IP 和主机名的对应关系.
• 如果新计算机接入网络，将这个信息注册到数据库中;
• 用户输入域名的时候，会自动查询 DNS 服务器，由 DNS 服务器检索数据库，得到对应的 IP 地址

至今, 我们的计算机上仍然保留了 hosts 文件. 在域名解析的过程中仍然会优先查找 hosts 文件的内容.

lighthouse@VM-8-10-ubuntu:~$ cat /etc/hosts
#
127.0.1.1 localhost.localdomain VM-8-10-ubuntu
127.0.0.1 localhost

2. 域名

主域名是用来识别主机名称和主机所属的组织机构的一种分层结构的名称。

比如：www.baidu.com

关于域名补充：提问 AI 的问题列表，非技术问题，但是有助于理解域名解析

3. 域名解析流程

浏览器首先看一下自己的缓存里有没有，如果没有就向操作系统的缓存要，还没有就检查本机域名解析文件 hosts，如果还是没有，就会 DNS 服务器进行查询，查询的过程如下：

• 客户机 向其本地域名服务器发出 DNS 请求报文，问 www.baidu.com 的IP 是啥，并发给本地 DNS 服务器
• 本地域名 服务器收到请求后，查询本地缓存.
  • 如果缓存里的表格能找到 www.baidu.com，则它直接返回 IP 地址。
  • 如果没有，本地 DNS 会去问它的根域名服务器：“老大，能告诉我 www.baidu.com 的 IP 地址吗?"根域名服务器是最高层次的，它不直接用于域名解析，但能指明一条道路。
• 根域名 服务器收到请求后，发现后置是.com，说：“www.baidu.com 这个域名归 .com 区域管理”。将对应的顶级域名服务器 .com 的IP地址返回给本地域名服务器。
• 本地域名 服务器向顶级域名服务器 .com 发出解析请求报文。
• 顶级域名 服务器 .com 收到请求后，判断该域名属于 baidu.com 域，然后将对应域名返回。
• 本地域名 服务器向二级域（baidu.com ） 发起解析请求报文，然后二级域将对应的授权域名服务器 dns.baidu.com 的IP地址返回给本地域名服务器。
• 本地域名 服务器向授权域名服务器 dns.badiu.com 发起解析请求报文。
• **授权域名 **服务器 dns.baidu.com 收到请求后，将查询结果返回给本地域名服务器。
• 本地域名 服务器将查询结果保存到本地缓存，同时返回给客户机。

注意：上面的整个过程用的是 UDP 协议，简单不需要建立连接 如果是 TCP 的话，本地 DNS 是将 IP 地址返回客户端，客户端和目标建立连接。

那是不是每次解析域名都要经过那么多的步骤呢?

• 当然不是了，还有缓存这个东西的嘛。

🐟 浏览器会先看自身有没有对这个域名的缓存，如果有，就直接返回，如果没有，就去问操作系统，操统也会去看自己的缓存，如果有，就直接返回，如果没有，再去 hosts 文件看，也没有，才会去问「DNS 服务器」。 👎 数据包表示：“DNS 老大哥厉害呀，找到了目的地了!我还是很迷茫呀，我要发出去，接下来我需要谁的帮助呢?”

【案例】

注意：上面的整个过程

举个例子，🌐 域名解析的"城市导航系统"（场景化案例）

假设小明在浏览器输入www.abc.com，就像游客要去"数字城市"中的某栋大楼：

1. 浏览器自查缓存 → � “小明先翻自己的口袋（浏览器缓存），看有没有这栋大楼的坐标（IP地址）。很不巧，上周清理过缓存，口袋空空如也。” 案例：Chrome浏览器通过chrome://net-internals/#dns可查看缓存
2. 操作系统缓存查询 → 🖥️ “小明跑去问小区保安（操作系统缓存）。保安翻了近3天的访客记录，发现最近没人查询过这个地址，无奈摇头。” 技术细节：Windows通过ipconfig /displaydns可查看系统DNS缓存
3. Hosts文件检索 → 📂 “小明不甘心，又翻开自己随身携带的私人通讯录（hosts文件）。这个本子上记着127.0.0.1 localhost和一些公司测试地址，但就是没有www.abc.com。” 典型路径：Windows→C:\Windows\System32\drivers\etc\hosts
4. 本地DNS服务器登场 → 📡 “小明终于拨通了城市导航中心电话（本地DNS服务器，通常是运营商提供的114.114.114.114或8.8.8.8）。导航员小蓝开始工作： ❓ 小蓝先查本地缓存记录：‘三天前有人查过这个地址，IP是1.1.1.1…但缓存有效期只剩10秒了，必须重新确认！’”
5. 根域名服务器指引 → 🗺️ “导航员小蓝来到城市中心广场（根域名服务器），这里有13个巨型导航牌。 🗣️ 小蓝问：‘请问.com区的导航站怎么走？’ 👮 根导航员秒答：‘去东区198.41.0.4，那里有管理所有.com地址的顶级导航站！’”
6. 顶级域名服务器接力 → 🏢 “小蓝火速赶到.com区导航大厦（顶级域名服务器）： 🗣️ ‘我要找abc.com区域的详细导航处’ 👔 工作人员查册后回应：‘请前往203.0.113.1，那是abc.com专属的导航分站’”
7. 权威域名服务器终查 → 🏭 “在abc.com专属导航分站（权威域名服务器），小蓝终于得到明确答案： 📍 ‘www.abc.com的精确坐标是1.1.1.1，有效期24小时（TTL=86400秒）’”
8. 结果传递与缓存 → 🔄 “小蓝立刻做两件事： ✅ 把新坐标1.1.1.1记在本子（本地DNS缓存）上，标注24小时后失效 📞 回电小明：‘目标地址已确认，请保存好这个坐标！’ 小明拿到IP后，终于成功访问网站！”

🎯 关键机制强化

1. 缓存时效策略
   • 浏览器缓存：Chrome默认缓存1分钟
   • 系统缓存：Windows默认缓存1天
   • DNS层级缓存：按TTL值动态调整
2. 现实中的异常处理 #mermaid-svg-5xYrGAHjh5etu1jh {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-5xYrGAHjh5etu1jh .error-icon{fill:#552222;}#mermaid-svg-5xYrGAHjh5etu1jh .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-5xYrGAHjh5etu1jh .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-5xYrGAHjh5etu1jh .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-5xYrGAHjh5etu1jh .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-5xYrGAHjh5etu1jh .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-5xYrGAHjh5etu1jh .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-5xYrGAHjh5etu1jh .marker{fill:#333333;stroke:#333333;}#mermaid-svg-5xYrGAHjh5etu1jh .marker.cross{stroke:#333333;}#mermaid-svg-5xYrGAHjh5etu1jh svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-5xYrGAHjh5etu1jh .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-5xYrGAHjh5etu1jh .cluster-label text{fill:#333;}#mermaid-svg-5xYrGAHjh5etu1jh .cluster-label span{color:#333;}#mermaid-svg-5xYrGAHjh5etu1jh .label text,#mermaid-svg-5xYrGAHjh5etu1jh span{fill:#333;color:#333;}#mermaid-svg-5xYrGAHjh5etu1jh .node rect,#mermaid-svg-5xYrGAHjh5etu1jh .node circle,#mermaid-svg-5xYrGAHjh5etu1jh .node ellipse,#mermaid-svg-5xYrGAHjh5etu1jh .node polygon,#mermaid-svg-5xYrGAHjh5etu1jh .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-5xYrGAHjh5etu1jh .node .label{text-align:center;}#mermaid-svg-5xYrGAHjh5etu1jh .node.clickable{cursor:pointer;}#mermaid-svg-5xYrGAHjh5etu1jh .arrowheadPath{fill:#333333;}#mermaid-svg-5xYrGAHjh5etu1jh .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-5xYrGAHjh5etu1jh .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-5xYrGAHjh5etu1jh .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-5xYrGAHjh5etu1jh .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-5xYrGAHjh5etu1jh .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-5xYrGAHjh5etu1jh .cluster text{fill:#333;}#mermaid-svg-5xYrGAHjh5etu1jh .cluster span{color:#333;}#mermaid-svg-5xYrGAHjh5etu1jh div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-5xYrGAHjh5etu1jh :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 是 否 查询失败? 尝试备用DNS 成功? TCP/IP栈检查 hosts文件冲突检测 浏览器安全模式测试
3. DNS特殊案例 当访问www.taobao.com时：
   • 根DNS返回.com服务器
   • 顶级DNS返回taobao.com权威服务器
   • 权威服务器根据用户IP定位最近的CDN节点（如上海用户得到140.205.220.96）

域名的层级关系

在域名中，越靠右的位置表示其层级越高。

毕竟域名是外国人发明，所以思维和中国人相反，比如说一个城市地点的时候，外国喜欢从小到大的方式顺序说起(如 XX 街道 XX 区 XX市 XX 省)，而中国则喜欢从大到小的顺序(如 XX省 XX市 XX 区 XX街道)。

实际上域名最后还有一个点，比如 www.server.com. ，这个最后的一个点代表根域名。 也就是说：.根域 是在最顶层，它的下一层就是 .com 顶级域，再下面是 server.com。 所以域名的层级关系类似一个树状结构:

image-20250301151706477

树的最顶端代表根服务器，根的下一层就是由我 们所熟知的 .com、.net、.cn 等通用域和 .cn、.uk 等国家域组成，称为顶级域。

• 网上注册的域名基本都是二级域名，比如 http://baidu.com、http://taobao.com 等等二级域名，它们基本上是归企业和运维人员管理。接下来是三级或者四级域名

为什么是这样的结构呢？

• 根域的 DNS 服务器信息保存在互联网中所有的 DNS 服务器中。
• 这样一来，任何 DNS 服务器就都可以找到并访问根域 DNS 服务器了。
• 因此，客户端只要能够找到任意一台 DNS 服务器，就可以通过它找到根域 DNS 服务器，然后再一路顺藤摸瓜找到位于下层的某台目标 DNS 服务器。

4. 使用 dig 工具分析 DNS 过程

安装 dig 工具，如下：

yum install bind-utils # Centous
sudo apt install dnsutils # Ubuntu

现在我们就可以使用 dig 指令来查看域名的解析过程了，如下：

lighthouse@VM-8-10-ubuntu:~$ dig www.baidu.com

; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> www.baidu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27056
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.baidu.com. IN A

;; ANSWER SECTION:
www.baidu.com. 1057 IN CNAME www.a.shifen.com.
www.a.shifen.com. 40 IN A 115.239.210.27
www.a.shifen.com. 40 IN A 115.239.211.112

;; Query time: 0 msec
;; SERVER: 100.100.2.136#53(100.100.2.136)
;; WHEN: Wed Sep 26 00:05:25 CST 2018
;; MSG SIZE rcvd: 90

结果解释：

1. 开头位置是 dig 指令的版本号
2. 第二部分是服务器返回的详情, 重要的是 status 参数，NOERROR 表示查询成功
3. QUESTION SECTION：表示要查询的域名是什么
4. ANSWER SECTION 表示查询结果是什么。这个结果先将 www.baidu.com 查询 成了 www.a.shifen.com, 再将 www.a.shifen.com 查询成了两个 ip 地址.
5. 然后最下面是一些结果统计，包含查询时间和 DNS 服务器的地址等。更多 dig 的使用方法参见：linux dig 命令使用方法

补充 – 关于 DNS 缓存：

• 在 Windows 系统中，可以使用 ipconfig /displaydns 命令来查看系统级别的 DNS 缓存
• 而且浏览器也是有缓存，可以自行搜索一下，看看能不能找到

5. 输入 URL 的事情

这是一个经典的面试题，能牵扯到所有网络知识点，没有固定答案越细越好，可以参考：

1. 当你在浏览器地址栏输入一个URL后回车，将会发生的事情？
2. 键入网址到网页显示，期间发生了什么

下面我把整个过程比作成 “数字世界的快递系统”，来方便理解，如下：

🌐 第一阶段：地址翻译与导航（DNS解析）

场景：“快递员要找到收件地址”

1. 浏览器缓存检查 → 📦 “浏览器像熟练的快递员，先翻自己的’近期送货单’（缓存），看看是否最近送过这个地址。如果是Chrome，可以通过chrome://net-internals/#dns查记录。”
2. 操作系统缓存接力 → 💻 “没找到？快递员跑去问’社区管家’（操作系统）。Windows管家会敲命令ipconfig /displaydns查看系统级缓存。”
3. Hosts文件寻宝 → 🗺️ “还不死心！快递员翻开一本神秘的’上古地址簿’（hosts文件），这里可能有开发者手动添加的地址，比如把127.0.0.1强行指向localhost。”
4. DNS层级探险 → 🚀
   • 本地DNS服务器（如8.8.8.8）：“快递中心接线员开始打电话：‘根域名服务器吗？请问.com区怎么走？’”
   • 根域名服务器：“去198.41.0.4找.com管理局！”
   • 顶级域名服务器：“example.com的权威服务器在199.254.0.1！”
   • 权威域名服务器：“最终地址是93.184.216.34，有效期2小时！”

🔗 第二阶段：建立传输通道（TCP连接）

场景：“修建高速公路”

1. TCP三次握手 → 🤝 “浏览器（客户端）挥动信号旗：‘我要修路！’（SYN） 服务器回应：‘同意修路！’（SYN-ACK） 浏览器最后确认：‘路修好了！’（ACK） 就像两个工程师在峡谷两岸架桥，通过三次确认保证桥梁稳固。”
2. TLS安全隧道（HTTPS场景）→ 🔒
   • “客户端亮出支持的密码套件：‘我有AES-256和SHA-256！’”
   • 服务器返回数字证书：“这是CA颁发的身份证！”
   • 双方生成会话密钥：“现在用椭圆曲线加密生成临时密钥！” 如同在高速路上加装防弹玻璃，全程加密运输。

📦 第三阶段：请求与响应（HTTP交互）

场景：“发送订单与接收货物”

// 浏览器发送的"订单清单"（HTTP请求头示例）
GET /index.html HTTP/1.1
Host: www.example.com
Accept: text/html,application/xhtml+xml
Cookie: session_id=abc123
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

// 服务器返回的"快递包裹"（HTTP响应示例）
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=3600
Content-Length: 1256

<!DOCTYPE html>
<html>...</html>

🎨 第四阶段：货物拆箱与组装（浏览器渲染）

场景：“建筑工地施工”

1. 解析流水线 → 🏗️
   • HTML解析器：“我是钢筋工，正在搭建DOM骨架！”
   • CSS解析器：“我是泥瓦匠，正在创建CSSOM样式墙！”
   • JavaScript引擎：“我是电工，随时可能让工地停工（阻塞解析）！”
2. 渲染树构建 → 🌳 “监理工程师（渲染引擎）把DOM树和CSSOM树合并，生成渲染树，排除所有display:none的隐形建材。”
3. 布局与绘制 → 🖌️
   • 布局阶段：“测绘组计算每个砖块（元素）的精确位置，突然发现某个<div>的width:50%需要重新测量！”
   • 绘制阶段：“油漆工根据图层顺序刷漆，注意！z-index:999的弹窗要最后喷涂！”
4. 交互动画阶段 → 🎬 “交互动画师（合成线程）把页面分成多个图块，用GPU加速处理transform动画，像播放电影一样流畅展示。”

⚡️ 关键性能优化点

DNS预读取

<!-- 提前解析其他域名的DNS -->
<link rel="dns-prefetch" href="//cdn.example.com">

TCP快速打开（TFO） “在第二次访问时，TCP握手可减少1个RTT时间，就像快递员记住常用路线后可以抄近道。”

HTTP/2多路复用 “所有资源通过一个TCP连接并行传输，告别HTTP/1.1的’车队拥堵’问题。”

关键渲染路径优化

• CSS放在头部：“先让泥瓦匠准备好样式，避免钢筋工返工”
• JS异步加载：“让电工（JS）在后台工作，不影响主体施工”
• 字体预加载：“特殊装饰材料提前到位，避免文字显示延迟”

🔧 异常处理流程图

结论：整个过程就像一场精密的交响乐演奏：DNS解析是乐谱准备，TCP连接是乐器调音，HTTP请求是乐章演奏，浏览器渲染是指挥家的最终呈现。每个环节的优化都能让这场"音乐会"更加流畅动听！

二、ICMP 协议

1. 概述

ICMP 协议是一个 网络层协议，全称是 Internet Control Message Protocol，也就是互联网控制报文协议

所谓控制，就是通过下发指令来感知和控制网络环境，所以它一定是配合一个 无法感知网络环境 的协议来工作的，这个协议就是IP协议(包括IPv4和IPv6)

• ICMP的作用可以确认IP数据包是否成功到达目标主机（ 传递控制消息），或者 通知在发送过程中数据包被丢弃的原因（错误报告）

所以，ICMP通常被认为是IP协议的一部分，它封装在IP层中，使用IP协议进行传输。因此，严格来说，ICMP既不是一个网络层协议，也不是一个传输层协议，而是介于两者之间的一个协议。

它的主要功能是传输网络诊断信息，信息主要包括两类：

1. 「查询报文类型」：主要用于信息的查询和采集，比如：采集传输路径上的每个路由器都是谁，本次传输的报文是否到达目的主机等等。
2. 「差错报文类型」：主要用于诊断网络故障，比如：通知传输报文被丢弃的原因是什么等等

2. ICMP 背景

一个新搭建好的网络，往往需要先进行一个简单的测试，来验证网络是否畅通；

• 但是 IP协议是一个不可靠协议，不提供可靠传输，如果IP数据包在传输过程中出现错误，如检验和错误，拥塞，超时等，IP数据包是会被直接丢弃的（丢包），然后就没有后续了（IP 协议不能通知传输层是否丢包以及丢包的原因）

这是 IP协议 的一个设计准则决定的，也就是 best effort（尽力而为），这样的好处是让IP协议尽量保持简单的形态，只负责有效率的数据传输，而更多的可靠性保证交给上层协议实现（如 TCP）

但并不是所有上层协议都保证可靠性，所以需要有协议辅助IP完成必要的网络质量管理。ICMP协议 的缘由就是这样来的

⏰ 当IP数据包出现错误时，上层发送IP数据包的主机或路由器并不知下层发生了错误，这个时候下层的主机或路由器就可以通过发送ICMP数据包，将错误信息汇报给上层，从而让上层的主机或路由器进行调整。

• ICMP 仅只能提供某些特定类型的错误信息汇报，并不能帮助IP协议成为可靠的协议，不过虽然错误信息有限，但用于基本的网络质量管理足够了

3. ICMP 功能

ICMP本质就相当于IP层的“调试接口”，可从应用层直接访问IP层的功能，测试IP层代码的准确性。主要功能包括：

• 确认 IP包 是否成功到达目标主机。
• 返回 IP包 被丢弃的原因。
• ICMP 也是基于IP协议工作的，但是它并不是传输层的功能，因此仍然把它归为网络层。
• ICMP 只能搭配 IPv4 使用，IPv6需要用 ICMPv6

在 IP 通信中如果某个 IP 包因为某种原因未能达到目标地址，那么这个具体的原因将由 ICMP 负责通知。

image-20250301164656657

如上图例子，主机 A 向主机 B 发送了数据包，由于某种原因，途中的路由器 2 未能发现主机 B 的存在，这时，路由器 2 就会向主机 A 发送一个 ICMP 目标不可达数据包，说明发往主机 B 的包未能成功。

• ICMP 的这种通知消息会使用 IP 进行发送 。

因此，从路由器 2 返回的 ICMP 包会按照往常的路由控制先经过路由器 1 再转发给主机 A 。收到该 ICMP 包的主机 A 则分解 ICMP 的首部和数据域以后得知具体发生问题的原因。

4. 基于 ICMP 命令

① ping命令

$ ping localhost
PING localhost (127.0.0.1):56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 tt1=64 time=0.086 ms 
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.183 ms 
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.143 ms 
--- Localhost ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss 
round-trip min/avg/max/stddev = 0.086/0.150/0.187/0.041 ms

• 注意：此处 ping 的是域名，而不是 URL，一个域名可以通过 DNS解析成 IP 地址
• ping命令不光能验证网络的连通性，同时也会统计响应时间 和 TTL。
• ping 命令会先发送一个ICMP Echo Request 给对端，对端接收到之后会返回一个 ICMP Echo Reply。

image-20250301171254459

telnet 是23端口，ssh 是22端口, 那么 ping 是什么端口？

ping 命令基于网络层的ICMP，而端口号是传输层的概念，在网络层中根本就没有端口号 ！！！

① traceroute 命令

安装 traceroute，如下：

sudo apt install -y traceroute # Ubuntu

也是基于 ICMP 协议实现，能够打印出可执行程序主机，一直到目标主机之前经历多少路由器.

【案例】

lighthouse@VM-8-10-ubuntu:~$ traceroute www.baidu.com
traceroute to www.baidu.com (183.2.172.177), 30 hops max, 60 byte packets
 1  11.72.201.193 (11.72.201.193)  3.389 ms *  3.572 ms
 2  * * *
 3  * * 10.162.69.169 (10.162.69.169)  0.644 ms
 4  10.196.2.101 (10.196.2.101)  0.652 ms 10.162.32.253 (10.162.32.253)  0.989 ms 10.196.93.230 (10
 5  * * *
 6  * * 121.14.206.169 (121.14.206.169)  4.097 ms
 7  * 58.63.249.213 (58.63.249.213)  6.025 ms 121.14.50.5 (121.14.50.5)  8.911 ms
 8  * 14.29.117.178 (14.29.117.178)  24.591 ms 14.29.117.170 (14.29.117.170)  5.078 ms
 9  * * 14.29.117.170 (14.29.117.170)  4.974 ms
10  * * *

① 命令全局参数

• traceroute to www.baidu.com (183.2.172.177), 30 hops max, 60 byte packets
  • 目标地址：www.baidu.com（解析为IP 183.2.172.177），这是百度服务器的IP地址
  • 最大跳数：30 hops max，表示最多探测30个中间节点，若未达目标则终止
  • 探测包大小：60 byte packets，包含IP头（20字节）和UDP头（8字节），有效载荷约32字节

② 逐跳输出解析，格式说明如下

每行输出代表一个中间节点（路由器或网关），格式为： 跳数 [节点IP（反向解析域名）] 探测包1延迟 探测包2延迟 探测包3延迟 例如： 3 * * 10.162.69.169 (10.162.69.169) 0.644 ms

③输出中的特殊现象

(1) 星号（*）的成因

• 中间节点过滤：运营商核心路由器可能丢弃ICMP/UDP探测包（如第2、5、10跳）
• 路径动态调整：负载均衡导致部分探测包路径不同（如第4跳显示多个IP）
• 网络拥塞：高延迟后丢包（如第7跳58.63.249.213响应，其他探测包超时）。

(2) 多IP地址的跳数

• 负载均衡：同一跳显示多个IP（如第4跳的 10.196.2.101和 10.162.32.253），表明流量通过不同路径传输（ECMP技术）
• 多路径路由：不同探测包经过不同网关（如第8跳的 14.29.117.178和 14.29.117.170）

(3) 延迟波动

• 跨运营商传输：第8跳的24.591 ms显著高于其他节点，可能经过城际骨干网互联点。
• QoS策略：运营商对探测包优先级较低，优先保障业务流量。

【★,°:.☆(￣▽￣)/$:.°★ 】那么本篇到此就结束啦，如果有不懂 和 发现问题的小伙伴可以在评论区说出来哦，同时我还会继续更新关于【Linux】的内容，请持续关注我 ！！