Linux --DNS与ICMP

发布时间:2026/10/22 7:32:49

Linux --DNS与ICMP DNS互联网的“电话簿”是怎么进化来的没有 DNS 的年代hosts 文件的痛TCP/IP 通信靠的是IP 地址 端口号。但 IP 地址是一串数字人记不住。于是早期人们用hosts 文件来维护“主机名 → IP”的映射。用户输入host-a计算机查 hosts 文件发现它对应172.20.2.1然后才去通信。问题在哪最初这个 hosts 文件由SRI-NIC统一管理。每台新计算机入网、每个 IP 变更都得去信息中心申请更新其他计算机还要定期下载新版 hosts 文件。这就像全公司共用一本电话簿每来一个新同事所有人都得重新打印一本——根本不可持续。DNS 的诞生就是为了解决这个“集中管理”的瓶颈把域名解析的权力下放由各个组织自己维护自己域内的映射关系用户查询时自动去问 DNS 服务器。但 hosts 文件并没有消失。你的电脑上至今仍然保留着它而且在域名解析时hosts 文件的优先级高于 DNS 查询。域名的层级结构从右往左读以www.baidu.com为例部分名称含义com一级域名顶级域表示企业类域名同级的还有net、org、cn等baidu二级域名公司名通常由企业自己管理和注册www三级域名/主机名习惯用法早期用来表示“这个主机提供 Web 服务”域名的层级是从右向左逐级细化的。根服务器在最右边通常省略不写表现为末尾的点往下依次是顶级域、二级域、三级域……越往右管理权限越高越往左越接近具体的某台机器。域名解析的完整过程拆成两条主线来理解主线一客户端 → 本地 DNS 服务器递归查询你电脑上的“DNS 客户端”并不直接去问根服务器。它只做一件事向本地 DNS 服务器通常是运营商提供的比如电信/移动的 DNS或者你手动设的 8.8.8.8发出请求然后等着最终答案。这叫递归查询——我托你办这件事你负责给我最终结果中间你跑了哪些地方我不管。主线二本地 DNS 服务器 → 各级 DNS 服务器迭代查询本地 DNS 服务器拿到www.baidu.com的查询后如果自己的缓存里没有就开始“层层问路”问根服务器“.com谁管” 根服务器不直接给百度 IP而是回答“.com顶级域服务器地址是 xxx你去问它。”问.com服务器“baidu.com谁管”.com服务器同样不直接给答案而是说“baidu.com的权威服务器地址是 xxx你去问它。”问baidu.com权威服务器“www.baidu.com的 IP 是多少” 这次终于拿到了最终答案。这个过程叫迭代查询——每次问一个人他要么给你答案要么告诉你“下一个该问谁”你自己接着跑。拿到答案后本地 DNS 服务器把 IP 返回给你的电脑同时把这条记录缓存起来。下次再有人问www.baidu.com只要缓存没过期直接返回不用再跑一遍全程。用 dig 看 DNS 到底返回了什么;; 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注意这里有两步www.baidu.com先被解析成一个别名CNAMEwww.a.shifen.com然后www.a.shifen.com才被解析成两个 IP 地址。这是百度用 CDN 的常见做法——同一个域名背后可能对应多个 IP就近分配。status: NOERROR表示查询成功。SERVER: 100.100.2.136#53告诉你这次是谁回答的阿里云的公共 DNS。如果你看到status不是NOERROR那就要排查是不是域名不存在、DNS 服务器拒绝响应等问题了。浏览器输入 URL 后DNS 只是第一步“浏览器输入 URL 后发生了什么”。DNS 解析只是整个链条的前置环节。简单串一下浏览器查自己的 DNS 缓存有没有刚访问过这个域名查操作系统缓存 / hosts 文件发起 DNS 查询就是上面讲的递归 迭代拿到 IP 后建立 TCP 连接三次握手如果是 HTTPS还要 TLS 握手发送 HTTP 请求服务器处理并返回响应浏览器解析 HTML、加载资源、渲染页面DNS 之所以重要是因为如果第一步卡住了后面所有事都无从谈起。这也是为什么 DNS 故障往往表现为“网页打不开但 QQ 能上”——QQ 可能已经缓存了服务器 IP而浏览器需要重新解析域名。ICMPIP 协议的“通讯员”为什么需要 ICMPIP 协议的设计哲学是“尽力而为”它只管把数据包往目的地扔不保证送到也不保证按顺序到达。如果中途路由器发现“下一跳网络不可达”或者目标主机电源关了IP 协议本身不会通知发送方。这就像你寄了一封信邮局发现地址写错了直接把信销毁不会退回来告诉你哪里错了。ICMP 就是那个退信通知单当 IP 包出问题时路由器或目标主机用 ICMP 报文告诉发送方“包没送到原因是 XXX”。关键理解ICMP 虽然是网络层协议和 IP 一起工作但它不是传输层协议。TCP/UDP 才有端口号的概念ICMP 根本不关心端口。所以那个面试陷阱——“ping 走哪个端口”——答案是ping 不走端口它基于 ICMP在网络层。ICMP 报文的分类ICMP 报文分成两大类差错报告类通知出了什么问题类型值名称典型场景3目标不可达Destination Unreachable网络/主机/协议/端口不可达11超时Time ExceededTTL 减到 0包被丢弃5重定向Redirect告诉发送方“下次走另一个路由器更快”4源点抑制Source Quench拥塞控制已废弃现代网络很少用查询/诊断类主动探测网络状态类型值名称用途8 / 0回送请求 / 回送应答Echo Request / Replyping 的核心13 / 14时间戳请求 / 应答测量时间同步17 / 18地址掩码请求 / 应答获取子网掩码早期使用ping最熟悉的 ICMP 工具ping www.baidu.com做的事情极其简单先通过 DNS 把www.baidu.com解析成 IPping 的是域名不是 URL。向目标 IP 发送ICMP Echo Request类型 8。目标主机收到后返回ICMP Echo Reply类型 0。ping 统计往返时间RTT和丢包率。ping 能通说明什么说明你的机器到目标 IP 的网络层路径是通的目标主机也开机并响应 ICMP。但 ping 通不代表服务可用——比如目标主机的 Web 服务挂了但机器还活着ping 照样通。traceroute利用 TTL 的“路痴导航”tracerouteWindows 下叫tracert是一个网络诊断工具用来追踪你的电脑到目标主机之间数据包经过了哪些路由器以及每一跳的延迟是多少。你可以把它理解成给数据包装了一个“行程记录仪”看它从你家到目标服务器中途经过了哪些“驿站”。它解决什么问题假设你访问某个网站很慢ping显示延迟很高但你不知道是你家路由器的问题、运营商骨干网的问题还是目标服务器机房的问题。traceroute能帮你把路径一段一段拆开定位到底是哪一跳开始变慢或丢包。你的电脑 → 家用路由器 → 运营商网关 → 城域网 → 骨干网 → 目标机房 → 目标服务器 跳1 跳2 跳3 跳4 跳5 跳6traceroute就是把上面这条链路上的每一个节点 IP 和响应时间列出来。它是怎么做到的核心原理利用 TTLtraceroute的巧妙之处在于利用了 IP 包头里的 TTL 字段。TTLTime To Live生存时间的规则是数据包每经过一个路由器TTL 减 1当 TTL 减到 0 时路由器丢弃这个包并返回一个 ICMP 超时报文Type 11Time Exceeded给发送方。traceroute就是故意利用这个“报错”来探测路径步骤发送的包发生了什么traceroute 学到什么第1步TTL 1 的探测包到达第1个路由器TTL 减为 0路由器丢弃并返回 ICMP 超时第1跳的 IP 和往返时间第2步TTL 2 的探测包经过第1个路由器TTL→1到达第2个路由器TTL→0第2个路由器返回 ICMP 超时第2跳的 IP 和往返时间第3步TTL 3 的探测包依次类推到达第3个路由器时 TTL 归零返回超时第3跳的 IP…………最后一步TTL 足够大包到达目标主机目标主机不会返回“超时”而是返回ICMP Port Unreachable传统 UDP 模式或Echo ReplyICMP 模式到达终点停止探测一句话总结traceroute通过逐步增大 TTL让路径上的每一跳依次“暴露”自己——每一跳都以为自己是因为 TTL 耗尽才丢包的于是老老实实把 ICMP 超时报文发回来traceroute就记录下这一跳的 IP。原理讲的是“怎么找出每一跳的 IP”可我要的是“哪一跳开始变慢/丢包”这俩是怎么挂上钩的答案就在traceroute的输出格式里它不只是记录 IP它给每一跳都发了多个探测包并记录每个包的往返时间RTT和有没有收到回复。这两个数据就是判断“慢”和“丢”的依据。怎么判断“哪一跳开始变慢”核心方法沿着跳数从上往下看找延迟“台阶式跃升”的那个位置。比如1 192.168.1.1 1 ms 1 ms 1 ms 2 10.0.0.1 3 ms 2 ms 3 ms 3 202.97.1.1 15 ms 14 ms 16 ms 4 202.97.2.1 16 ms 15 ms 17 ms 5 61.135.1.1 180 ms 182 ms 179 ms ← 延迟突然从 16ms 跳到 180ms 6 61.135.2.1 181 ms 180 ms 183 ms 7 61.135.169.121 182 ms 181 ms 180 ms ← 目标解读第 4 跳还是 16ms第 5 跳突然变成 180ms并且后面每一跳都维持在高位。这说明瓶颈出现在第 4 跳到第 5 跳之间的链路很可能是第 5 跳路由器所在的网络或它上游的链路拥塞/绕路。注意两个坑不能只看单独一跳的延迟。如果第 5 跳显示 180ms但第 6 跳又回到 20ms那第 5 跳的高延迟很可能只是它自己回 ICMP 报文的 CPU 处理慢路由器处理“报错信”是低优先级任务不代表数据转发慢。要看从哪一跳开始“持续”高。延迟要结合地理距离看。国内到美国 150ms 是正常的国内城际 10ms 才是正常。单纯一个数字没意义要看跳变。怎么判断“哪一跳开始丢包”看*出现的位置以及后续跳是否恢复。情况 A中间某跳* * *但后面跳正常3 202.97.1.1 15 ms 14 ms 16 ms 4 * * * 5 61.135.1.1 18 ms 17 ms 19 ms 6 61.135.169.121 20 ms 19 ms 18 ms解读第 4 跳不回复但第 5、6 跳都正常回复。这说明路径是通的只是第 4 跳那台路由器不响应 ICMP 超时报文安全策略/限速。这不叫丢包叫“沉默的路由器”。数据包实际上顺利穿过了它否则后面的跳不可能有回复。情况 B从某一跳开始后面全部* * *3 202.97.1.1 15 ms 14 ms 16 ms 4 202.97.2.1 16 ms 15 ms * 5 * * * 6 * * * 7 * * *解读第 4 跳开始出现*之后再也没有任何一跳回复连目标都没到达。这说明问题出在第 4 跳之后——要么第 4 跳到第 5 跳的链路断了要么第 5 跳及之后的路由器全部静默概率低要么目标主机不可达。结合 ping 一起看如果 ping 目标也不通那基本可以断定从第 4 跳往后就断了。情况 C目标跳* * *但前面都正常5 61.135.1.1 18 ms 17 ms 19 ms 6 * * *解读能到达第 5 跳但目标主机不回复。常见原因目标主机关了/防火墙禁止 ICMP/目标主机只响应 TCP。这时候 traceroute 看不到终点不代表网络不通可能只是目标不搭理 ICMP。用tcptraceroute或直接telnet 目标IP 端口验证更准。关键注意事项避免误判延迟高 ≠ 这一跳有问题路由器处理 ICMP 超时报文本身是低优先级的CPU 忙的时候回复慢所以某一跳显示 200ms 可能只是它“回信慢”实际转发数据包并不慢。要看从哪一跳开始“持续”变慢而不是单看某一跳的数值。* * *后恢复正常是常见现象很多骨干路由器不响应 ICMP但后续跳正常返回说明路径没问题只是中间有“沉默的路由器”。路径可能不对称去程和回程走的路由器可能完全不同。traceroute只测去程以及回程的 ICMP 报文路径所以看到的是单向路径。不同系统的默认探测方式不同Linuxtraceroute默认用UDP 高端口探测目标返回 Port Unreachable 作为终点标志Windowstracert默认用ICMP Echo Request和 ping 一样还有TCP traceroute如tcptraceroute用 TCP SYN 探测能绕过 ICMP 被禁用的防火墙穿透性更好。和 ping 的关系pingtraceroute目的测试到目标是否通、延迟多少测试路径上每一跳的情况协议ICMP Echo Request/ReplyICMP 超时报文 UDP/ICMP/TCP 探测回答的问题“能不能到多快”“经过了谁在哪一跳出问题”典型用法先 ping 确认通不通ping 不通或延迟高时用 traceroute 定位断在哪实战顺序通常是先ping目标 → 不通或很慢 → 再traceroute看卡在哪一跳 → 判断是本地网络、运营商还是目标机房的问题。
延伸阅读

更多相关文章

2026/10/22 7:32:49

在markdown编辑器中所见即所得修改表格【概念】

在markdown编辑器中所见即所得修改表格【概念】——这是我最初使用markdown编辑器的时候的一种设想,一直不明白为什么没有人来实现这个概念。 直到今天,以AI写代码、通过外挂方式实现的时候,才明白,如果不是商业软件开发&#xff…

2026/10/22 8:38:00

从CC Switch到Magpie:Claude Code配置管理迁移实战

几个月前我写过一篇关于 Claude Code 日常工作流的分享,那时候我还在用 CC Switch 管理多套配置。半年下来,配置从一个文件膨胀到一整个目录,不同项目的模型偏好、MCP 服务、工具权限全都混在一起。CC Switch 在最开始确实帮我解决了“来回改…

2026/10/22 8:38:00

Agentic AI与提示工程实战:构建智慧消防智能救援系统

凌晨两点,指挥中心大屏的告警音骤然响起,某物流仓库的烟感探测器触发联动。值班员需要在几十秒内判断火势规模、确定最近的可用消防水源、规划出警路线,同时还要协调物业确认内部是否有人被困——信息分散在不同的系统里,人脑切换…

2026/10/22 8:38:00

HDFS分布式文件系统入门:核心架构、读写流程与集群搭建实战

1. 为什么我要从HDFS开始聊大数据 很多人第一次接触大数据,脑子里冒出来的第一个问题往往是:这东西到底怎么存?毕竟数据量一旦从GB级别跳到TB甚至PB级别,传统那套“一台服务器加几个硬盘”的思路就彻底不够用了。你可能会想&#…

2026/10/22 8:38:00

LTE下行SISO仿真:MATLAB代码全链路解析与PDSCH收发实现

简介:压缩包内含一套基于MATLAB编写、面向LTE下行链路的SISO系统级仿真代码,共40个.m文件,体积约35KB,属于轻量级教学型脚本集。代码围绕LTE物理层与无线资源管理关键环节展开,覆盖PDSCH/PDCCH信道处理、OFDM收发、信道…

2026/10/22 8:32:58

veg200数据集科学划分:面向农业AI落地的鲁棒性分层策略

1. 项目概述:为什么 veg200 数据集划分不是“复制粘贴”就能搞定的事 你拿到 veg200 蔬菜分类数据集,第一反应是不是直接 train_test_split 一跑,再手动挪几个文件夹完事?我试过——三次模型在验证集上准确率波动超过12%&#x…

2026/10/21 4:53:08

金融AI落地指南:从调研报告到技术选型与工程实践

简介:这份PDF报告聚焦2025年金融服务业中国AI现状与趋势,面向金融科技从业者、AI战略规划人员及关注行业数字化转型的研究者,帮助读者把握生成式AI在银行、支付、交易等场景中的落地路径与投资方向。资源包内含1个PDF文件,大小约1…

2026/10/22 0:01:49

电商智能运营体系从0到1:架构设计、落地步骤与避坑指南

前两年我们团队接了一个电商平台的运营中台项目,目标很直白:把过去靠运营拍脑袋做的选品、定价、发券、推活动这些事,逐步用数据算法和自动化流程代替。项目名字内部就叫“电商智能运营体系”。最近有不少朋友问我当时是怎么设计的、踩过哪些…

2026/10/22 0:01:49

若依框架AI代码生成不稳定?用Agent Skill三层结构+五步法搞定

最近一段时间,我一直想把后台管理系统里那些机械重复的增删改查代码交给AI去写。框架用的是若依,按理说这类业务代码模式非常固定,应该是AI最擅长的事情。可真试下来却不是那么回事——你让AI生成一个用户管理模块,它给出的Contro…

还想了解更多?直接咨询顾问

免费诊断 + 免费方案 + 透明报价。

全国咨询热线400-8866-253
免费获取方案
☎咨询二维码 ☎ ↑