DHCP 和 ICMP：IP 怎么自动分配，网络问题怎么报告

前面几篇把 IP、CIDR、ARP、MAC 和路由转发讲完后，网络包已经有了比较完整的出门路线。但实际使用时还有两个很常见的问题：一台新电脑刚接入网络，IP 地址、网关、DNS 从哪里来？网络包在路上出错了，发送方怎么知道具体出了什么问题？

资料 在 ARP 后面接着讲 DHCP，原因很自然。我们的电脑通常不是手动填写 IP 地址，而是通过 DHCP 动态获取 IP，这能省掉大量人工配置。再往后讲 ICMP，是因为 IP 通信过程中可能遇到目标不可达、路由异常、包被丢弃等情况，总要有一种方式把问题原因通知回来。

所以这篇不用把 DHCP 和 ICMP 当作两个孤立名词。DHCP 解决“怎么加入网络”，ICMP 解决“网络通信出问题时怎么知道”。一个发生在入网配置阶段，一个常出现在连通性诊断和错误反馈里。

很多人把 DHCP 理解成“自动分配 IP”，这没错，但不完整。真正入网需要的不只是 IP 地址，还包括子网掩码、默认网关、DNS 服务器、租约时间等信息。没有默认网关，跨网段通信不知道交给谁；没有 DNS，浏览器输入域名时就很难解析到目标 IP。

文中说，DHCP 是 Dynamic Host Configuration Protocol，动态主机配置协议。这个名字里的 configuration 很重要，它说明 DHCP 分配的是一组网络配置，而不是只给你一串地址。

这也是为什么在公司、校园、家庭网络里，设备一连上 Wi-Fi 或网线，几秒钟内就能上网。背后不是操作系统猜到了配置，而是客户端和 DHCP 服务端完成了一轮协商，拿到了能在当前网络里正常通信的参数。

DHCP 获取地址通常可以概括为四步：Discover、Offer、Request、ACK。新接入的客户端一开始还没有可用 IP，也不知道 DHCP 服务器在哪，所以第一步只能广播 Discover，大意是：我需要网络配置，谁能提供？

服务器收到后，如果有可分配地址，会返回 Offer，告诉客户端可以使用哪个 IP，以及相关的掩码、网关、DNS、租约时间。客户端可能收到多个 Offer，随后通过 Request 表示自己选择某个地址。最后服务器回复 ACK，确认这份租约正式生效。

资料 第 73 页明确提到，DHCP 客户端进程监听 68 端口，DHCP 服务端进程监听 67 端口，并且 DHCP 交互全程使用 UDP 广播通信。理解这点很有用：设备还没拿到地址时，很多通信条件还不具备，所以它需要用广播方式先把服务器找出来。

DHCP 分配的 IP 通常有租约时间。客户端不是拿到地址后就永远占着，而是在租约快到期时向服务器发送 DHCP Request，请求继续使用这份地址。文中写到，如果服务器同意继续租用，就用 DHCP ACK 应答，客户端延长租期。

如果服务器不同意继续租用，就会返回 DHCP NACK，客户端需要停止使用当前租约的 IP 地址。这个机制让地址池可以被回收，也能适应设备上下线频繁的网络环境。

排查“为什么我的 IP 变了”时，租约是一个很实际的入口。设备长时间离线、地址池紧张、网络策略调整、DHCP 服务器重启或拒绝续租，都可能导致客户端重新获取地址。它不是网络乱分配，而是租约机制在工作。

DHCP 依赖广播，这会带来一个问题：路由器通常不会转发广播包。如果每个网段都必须放一台 DHCP 服务器，管理会很麻烦。文中正好提出了这个疑问，并给出解决办法：DHCP 中继代理。

有了 DHCP 中继后，客户端仍然向本地链路发送 DHCP 请求。中继代理收到广播包后，把它改成单播形式发给远端 DHCP 服务器。服务器返回应答后，再由中继代理把结果广播给客户端。

这样一来，DHCP 服务器即使不在同一链路上，也可以统一分配和管理多个网段的 IP 地址。企业网络里常见的集中 DHCP 管理，靠的就是这类中继机制，而不是每层楼、每个 VLAN 都单独维护一台服务器。

如果设备拿不到 IP，先看它有没有发出 DHCP Discover，本地网络里有没有 DHCP 服务器或中继代理响应。客户端如果一直停在自分配地址，通常说明它没能从 DHCP 服务端拿到有效租约。

如果设备拿到了 IP 但不能上网，不要只看 IP 本身。还要看子网掩码、默认网关、DNS 是否正确。IP 地址能让你进入本地网络，但默认网关决定你能不能跨网段，DNS 决定域名能不能解析。

如果只有某个网段拿不到地址，就要检查 DHCP 中继配置、VLAN、网关接口和服务器地址池。因为 DHCP 使用 UDP 和广播/中继转发，链路中任何一个环节不通，客户端看到的结果都可能只是“获取地址失败”。

IP 网络不是每个包都能顺利到达。路由器可能找不到下一跳，目标网络可能不可达，包的 TTL 可能耗尽，包太大又不能分片。没有反馈时，发送方只知道“没回应”，不知道问题卡在哪里。

文中讲 ICMP 时说，网络包在复杂传输环境里常会遇到各种问题，需要传出消息，报告遇到了什么问题，这样才能调整传输策略。ICMP 的主要功能包括确认 IP 包是否成功送达目标地址、报告发送过程中 IP 包被废弃的原因，以及改善网络设置。

ICMP 的通知消息也会使用 IP 发送。比如某个路由器发现包无法继续转发，它会返回一个 ICMP 包，发送方收到后解析 ICMP 头部和数据域，就能知道大致原因。

资料 把 ICMP 大致分成两类：一类是用于诊断的查询消息，也就是查询报文类型；一类是通知出错原因的错误消息，也就是差错报文类型。这个分类比硬背一堆 Type/Code 更适合入门。

查询报文用于主动探测。最常见的是 Echo Request 和 Echo Reply，也就是 ping 背后的核心。主机向目标发送 Echo Request，目标如果能收到并允许回应，就返回 Echo Reply。你看到的延迟时间，本质上是请求和响应往返的时间。

差错报文用于告诉发送方哪里出了问题。比如目标不可达、TTL 超时、需要分片但又不能分片，这类信息都能帮助发送方或运维人员判断问题位置。它不是修复问题的协议，但能让问题不再完全沉默。

ping 常用于判断目标是否可达。它发送 ICMP Echo Request，等待 Echo Reply。如果能收到回复，说明从当前主机到目标之间至少存在一条可返回的路径，目标也愿意响应这类 ICMP 请求。

但 ping 不通不等于业务一定不通。很多服务器、防火墙、云安全组会禁用或限制 ICMP Echo，但 HTTP、SSH、数据库端口仍可能正常开放。反过来，ping 通也不代表业务端口可用，因为 ICMP 通了，不等于 TCP 端口监听正常、应用进程正常。

所以 ping 更适合作为第一层连通性检查。它能告诉你“网络层面有没有基本回应”，但不能替代端口探测、应用日志、DNS 检查和链路路由分析。

traceroute 的思路和 ICMP 差错报文有关。它会逐步增加 IP 包的 TTL。TTL 到 0 时，中间路由器会丢弃这个包，并返回 ICMP Time Exceeded，也就是超时消息。发送方根据这些返回消息，就能知道路径上有哪些路由器经过。

第一轮 TTL 设为 1，第一跳路由器返回超时；第二轮 TTL 设为 2，第二跳返回超时；依次增加，直到到达目标或探测结束。这样就把原本隐藏在网络里的路径一跳一跳摸出来。

不过 traceroute 的结果也要谨慎看。有些路由器不返回 ICMP，有些链路会负载均衡，有些网络会对探测包限速。看到星号不一定就是断了，可能只是中间设备不愿意回答。

当一台电脑完全上不了网时，先看 DHCP：有没有拿到 IP、掩码、网关、DNS。如果连地址都没拿到，就还没真正进入网络，后面查 DNS、HTTP、TCP 意义都不大。

拿到地址以后，再看本地网关能不能通。网关不通，可能是链路、VLAN、ARP、网关配置问题；网关通但外网不通，再看路由、NAT、运营商或上游防火墙。这个阶段，ping 和 traceroute 这类基于 ICMP 的工具就很有用。

如果业务访问失败，但 ping 和 traceroute 看起来正常，就要往传输层和应用层继续查：端口是否开放，TLS 是否握手成功，HTTP 状态码是否异常，服务端有没有返回错误。DHCP 和 ICMP 解决的是网络基础层面的线索，不负责解释所有应用问题。

如果被问 DHCP，可以这样答：DHCP 用于动态分配主机网络配置，客户端监听 UDP 68，服务端监听 UDP 67。常见获取过程是 Discover、Offer、Request、ACK，拿到的不只是 IP，还包括掩码、网关、DNS 和租约时间。租约快到期时客户端会请求续租，服务器同意则 ACK，不同意则 NACK。

如果被问 DHCP 中继，就说 DHCP 交互依赖广播，而广播通常不能跨路由器。DHCP 中继代理收到客户端广播请求后，会以单播形式转发给 DHCP 服务器，再把服务器应答转回客户端，从而让一个 DHCP 服务器管理多个网段。

如果被问 ICMP，就说它是互联网控制报文协议，用来报告 IP 包传输中的错误原因，也可用于网络诊断。ICMP 大致分查询报文和差错报文，ping 用 Echo Request/Reply 判断连通性，traceroute 利用 TTL 超时返回信息观察路径。