1. 寄一封信看懂 IP 协议存在的全部理由我当年学网络的时候第一个绕不过去的东西就是 IP 协议。教材翻来覆去讲格式、讲字段我背得滚瓜烂熟但心里始终悬着一个问题这玩意到底在干嘛后来真正上手抓包、配路由器、排故障才对 IP 协议的理解产生了质变——它做的事情其实非常简单简单到可以用寄信来类比。1.1 网络通信的第一性问题数据该交给谁我们先从最原始的问题出发。两台电脑之间要通信最朴素的想法就是拉一根线连起来A 发数据 B 收物理上能通数据就能到。但现实中的网络不是两两台台直连而是几百台、几万台、甚至几十亿台设备交错连接。这时候出现了一个任何人都绕不开的第一性问题一份数据发出来之后网络凭什么知道它该往哪走这就好比你在北京写好一封信想寄给上海的朋友。你不可能亲自跑一趟也不认识沿途每一个邮递员你只能把信丢进邮筒。剩下的路程里每一站的邮局都得自己判断这封信下一步往哪个方向送才能最终送到收件人手里。IP 协议干的就是这件事。它不负责帮你写信不负责内容是否完整它只负责一件事给每台设备编一个门牌号并且在信封上写明从哪来、到哪去让沿途的每个邮局只看这一行字就能决定下一步把信转给谁。这听起来简单但正是这个看似简单的设计让全世界几十亿台设备不需要彼此认识也能完成通信。没有 IP 协议整个网络世界就退化成了一张没有导航的交通图数据包发出去之后能不能到全凭运气。1.2 邮政系统与 IP 网络的逐跳转发IP 协议和邮政系统还有一个惊人的相似点都是逐跳转发。邮局的邮递员不认识收件人他只知道下一站该把信送到哪个邮局。全球的路由器也是这样工作的。一台路由器收到数据包它并不需要知道包最终要到哪一台电脑它只需要查一下自己的邮局分单表路由表然后把包转发给下一跳Next Hop就完事了。下一跳再继续查自己的表再往下一跳送直到最后到达目的网段。这种设计有一个巨大的好处不需要任何一台路由器掌握全局地图。你家里的路由器只需要知道外网一律交给运营商设备运营商的路由器需要知道发往美国的流量走哪条骨干链路仅此而已。每一跳只做一点判断合起来就完成了全球范围的寻址。我在 GNS3 里做实验的时候三台路由器串起来PC1 ping PC3在两台中间的路由器上开启 debug ip icmp就能清清楚楚看到这个逐跳过程。数据包先到 R1R1 看一眼目的地址发现不是本地网段就从出接口扔给 R2R2 做同样的事扔给 R3R3 发现目标就在自己挂着的网段里直接送达。整个过程没有任何一台设备知道完整路径但数据就是能到。1.3 尽力而为——IP 协议不承诺任何可靠性如果你刚开始学 IP还有一个概念必须在脑子里扎根IP 协议是尽力而为Best Effort的它本身不承诺可靠性。这个表述经常让人困惑——既然叫协议怎么连可靠都不保证但恰恰是这一点才让 IP 协议足够轻轻到可以跑在任何介质上。它提供的是最底层的转发服务我尽力把数据包往目的方向转但丢包、乱序、重复、损坏统统不管。丢了就丢了网络不会重传不会自动修复。这就好比你寄平信邮局只保证我按流程送不保证不丢、不保证按顺序到达。真正的内容安全、顺序正确、丢了重发那是 TCP 的事和 IP 无关。明白了这一点再去理解网络排障会顺畅很多。很多脑壳疼的问题——网页加载一半卡住、视频流出现花屏——都不是 IP 层面的问题而是传输层和应用层的纠错机制在工作。IP 本身只不过丢掉了几个包它并不会告诉你。2. 一帧报文里的大学问IP 头的核心字段到底在表达什么理解了 IP 的定位之后就可以撕开报文本身看看它长什么样了。用 Wireshark 抓任何一个 IP 包看到的头部信息其实就十几二十个字节但每个字段的存在都不是没理由的。挑几个真正影响理解的字段说剩下的你就当成是登记信息不用过度焦虑。2.1 版本号、首部长度与服务类型头部最前面 4 个 bit 是版本号。IPv4 就是 4IPv6 就是 6。这玩意很短但是路由器拿到包后的第一个判断就是它——因为 v4 和 v6 的头部格式完全不同连解析方式都不一样。做网关设备的时候一定要注意很多家用路由器默认双栈打开但某些老旧固件对 v6 的支持有 bug会导致表现为能上微信但网页打不开特别坑。首部长度IHL和总长度配合使用。IPv4 头部并不总是 20 字节有选项字段时可以长到 60 字节所以必须明确告知头部到底多长。数据包的总长度最多 65535 字节但是底层链路一般不支持这么大的包这就需要分片。这里先埋个坑后面单说。服务类型ToS字段现在的发展史很有意思。老说法叫优先级现在更通用的称呼是 DSCP差分服务代码点。园区网里搞 QoS就是在这些 bit 上做文章给语音、视频流量打高优先级标记让路由器在拥塞时优先转发它们。我做过一个实验给 VoIP 流量打上 EF 标记在链路拥塞时延迟直接从几百毫秒降到了十几毫秒效果立竿见影。2.2 分片字段超过 MTU 之后会发生什么分片字段目前对小白来说是 IPv4 头部最让人犯迷糊但也最值得搞懂的一块。以太网链路标准帧的承载上限是 1500 字节我们管这个叫 MTU最大传输单元。你的应用层要发送一个 4000 字节的数据包IP 层收到之后发现这玩意超过 1500 了怎么办答案只有一个字切。IP 会把一个大数据包切分成好几个不超过 1500 字节的小片段每个片段打上同样的识别号Identification同时标注这是原包的第几个碎片。接收端再根据这些碎片拼回原始数据。这里就引出两个字段MFMore Fragments和Fragment Offset分片偏移。MF 用来告诉接收端后面还有片子Fragment Offset 用来告诉接收端这一段应该拼在原数据的位置上。实际使用中最常见的坑是 PMTUD路径 MTU 发现。默认情况下两台主机之间通信要经过的链路 MTU 可能比 1500 小比如常见的 1492PPPoE 拨号、1400 甚至更低。如果发送端不知道该改小包就直接发 1500 的包中间路由器可能会丢弃而不是分片。表现为某些网站打不开、视频能加载图片但刷不出来。懂的都懂验证手段就是 ping 大包测 MTU# Linux 下测 MTU从大往小试看你不带分片标志能不能通 ping -M do -s 1472 -c 3 192.168.1.1 ping -M do -s 1400 -c 3 192.168.1.1这里的 -s 1472 因为要加上 28 字节的 IPICMP 头才是完整的 1500。测到哪个值能通基本就是实际 MTU 了。2.3 TTL、源地址、目的地址——三个容易被忽略的细节TTL生存时间大概是 IP 头部里最有故事性的字段。它每经过一台路由器就减 1减到 0 就被丢弃并向源地址回一个 ICMP 超时消息。为什么要设计 TTL防环。如果没有这个字段一个数据包在路由环路里就会永远转下去把链路塞瘫痪。有了 TTL最多跳 255 次就会自动销毁。日常用它来查路由环路特别方便traceroute的原理就是故意把 TTL 从 1 开始递增发包然后通过沿途设备返回的 ICMP 超时报文重建整条路径。源 IP 和目的 IP是唯一不变的字段。逐跳转发中MAC 地址每一跳都在变但 IP 地址从头到尾不变。这是 IP 地址和 MAC 地址职责分工的集中体现后面讲 ARP 时会更清楚。一个冷知识ICMP 重定向Redirect经常被人忽略。当路由器发现你发给我的数据其实应该直接发给另一台路由器它会告诉你下回直接发给它这就是一个 ICMP 重定向消息。安全上经常要禁用这玩意别让它随便改主机的路由观不然容易被恶意引导流量。3. 路由器的角色IP 协议靠逐跳转发跑遍全球知道了 IP 头上写了什么下一个话题必然是沿途的路由器到底怎么决定往哪转发这就牵扯到了路由表和路由协议。但先说一个容易误解的点路由器和 IP 的关系不是路由器实现了 IP 协议这么简单路由器是整个 IP 网络的执行者。3.1 路由表是地图下一跳是路标每一台路由器都维护着一张路由表表里写的是我认识哪些网段每个网段该往哪个接口/哪台下一跳设备送。当路由器收到一个数据包它只看目的 IP然后查路由表找最长匹配的路由条目把包从对应接口转发出去。关键点在最长匹配这四个字上。路由表里可能同时有 192.168.1.0/24 和 192.168.0.0/16 两条条目目的 IP 是 192.168.1.100那它会优先选择 /24 那条因为 /24 是更精确的匹配。原理嘛前缀越长代表网段划分越细走细分的路更接近目标。我在真实项目里踩过一个坑设备配置了两个 Loopback 地址一个在 A 网段一个在 B 网段默认路由设了指向 A 网关结果跟 B 网段的邻居互通时发现来回路径不一致。查了半天原因就是 B 网段出去的回包默认选了 A 网段的出口路由表里没有给 B 单独指一条出口链路。这就是典型的路由表设计不细默认路由一把梭的教训。3.2 默认路由和直接路由的区别你敲ip route add default via 192.168.1.1的时候等价于告诉路由器所有我认识的路由都匹配不上的流量统统扔给 192.168.1.1。这就是默认路由也叫最后手段的转发。和它对应的是直连路由。直连路由不用配只要接口开了 IP路由器就知道我这个网段直连着哪个接口此时转发行为非常直接查 ARP把数据帧直接丢给目标主机。这俩的区别经常有人混淆。直连路由是我可直接到达的邻居默认路由是我不认识但可以找人带路。最能说明问题的是如果你配置的默认路由是 192.168.1.1但你的出接口根本不在这个网段里那路由永远不通。因为默认路由也得通过出接口转发而那个网段你根本没有直连ARP 都不知道问谁。3.3 子网掩码IP 分类之外更重要的一件事很多人对标准 IP 分类倒背如流A 类是 0 开头B 类是 10 开头C 类是 110 开头。但现行 CIDR无类域间路由体系下那些分类早就不重要了真正重要的是子网掩码。子网掩码不是 IP 的附属品它就是路由的灵魂。子网掩码决定了同一广播域的范围。两个 IP 在不在同一个二层网络里不是看 IP 像不像而是看掩码一算准不准。掩码剥离的方法很简单把 IP 和掩码做按位与运算结果相同就是同一网段。举一个最常碰到的例子设备 A 是 192.168.1.2/24设备 B 是 192.168.2.3/16。看起来 A 和 B 的 IP 不在一个段里但因为 B 的掩码是 16它的实际网段是 192.168.0.0/16也就是整个 192.168.x.x 都在它的广播域里。那 A 认为 B 不在本地网段会走网关而 B 认为 A 就在本地直连不走网关直接发 ARP。结果就是单向通反方向不通——这种问题以前在线下网络里碰到过排查起来一度很崩溃。排掉它不难把你的掩码算清楚同时把设备 A、B 两边的真实网段判断都对齐。别想当然IP 分类那套老黄历早该翻篇了。4. ARPIP 地址和 MAC 地址之间差一张翻译表聊完 IP不得不提 ARP。虽然题目是 IP 协议但你没 ARP 就永远觉得 IP 和现实世界隔着一层纱。因为 IP 地址是逻辑层面的门牌而二层网络真正认的地址是 MAC 地址。从门牌到实体的映射靠的就是 ARP。4.1 为什么不能直接拿 MAC 地址通信一个特别好的问题既然 MAC 地址是网卡出厂就烧好的全球唯一那人类直接用 MAC 地址通信算了干嘛还要搞 IP这里面的逻辑和现实完全吻合MAC 地址是物理地址它没有层次。就像全世界每个人的身份证号都唯一但你不认识对方的身份证号也不知道对方人在哪怎么把信寄过去IP 地址是逻辑地址它按区域层次划分路由器只看 IP 就能确定大致方向。MAC 地址只能在同一个网段内直接使用。所以互联网的整体寻址必须靠 IP只有到了最后一段才用 MAC 精准定位主机。用大白话讲IP 地址是全球邮政系统的邮政编码门牌号MAC 地址是小区物业登记的房间钥匙号。你说寄信该写邮编还是钥匙号4.2 ARP 请求/应答以及 GNS3 里能看到的实际交互ARP 的运作逻辑在 GNS3 里非常清晰。就我们开头提到的实验场景PC1 连 R1PC2 连 R2R1 和 R2 之间再接一条链路。你从 PC1 ping PC2抓 PC1 和 R1 之间那条链路的包能看到完整的 ARP 交互过程。PC1 首先发现 PC2 不在自己的网段于是要把包先发给网关——但 PC1 怎么知道网关的 MAC 地址它就发一个 ARP 广播谁是 192.168.1.1网关 IP请把你的 MAC 告诉我。R1 收到广播一看自己就是 192.168.1.1于是回一条 ARP 应答我就是我的 MAC 是 xx:xx:xx:xx:xx:xx。PC1 把这条映射写进自己的 ARP 缓存表然后把数据帧封装好交给 R1。R1 从接口收到这个帧剥掉二层头看目的 IP 是 192.168.2.2PC2查路由表发现出接口连的是 R2 的某个 IP。于是 R1 又得对 R2 发起 ARP 查询。这一跳一跳过去的模式和前面讲的 IP 逐跳转发完全串起来了。我在实验时特别喜欢开着debug arp看这个过程比 Wireshark 的界面更有实时感*Nov 27 14:03:22.823: ARP: arp_send_request 192.168.1.1 *Nov 27 14:03:22.827: ARP: arp_reply received 192.168.1.1 is at xxxx.xxxx.xxxx看到这段日志说明你的主机和网关之间的二层通信是健康的。如果 ARP 一直 request 没人 reply那么问题基本锁定在二层链路、接口 UP 状态、VLAN 划分这些方面——跟 IP 半毛钱关系没有别死磕 IP。4.3 ARP 的坑缓存中毒、重复地址ARP 很好用但也是个容易出幺蛾子的协议。最常见的问题是ARP 缓存中毒。因为 ARP 应答没有认证机制谁都能发一条我是某某 IP其他设备就把这条信了。攻击者发一条网关 IP 是我的 MAC全网的流量就都被它截走了。解决方案是网络中配置动态 ARP 检测DAI或者干脆绑定静态 ARP 表。我在园区网改造项目里就是靠 DAI DHCP Snooping 联合把这种问题压下去的效果相当直接。还有一个经典问题IP 地址冲突。两台设备配了同一个 IP其中一个发 ARP另一个也抢着回整个网络乱套。判断办法看交换机上不停变化的 MAC 地址表或者直接抓一个网段的 ARP 包看有没有多个 MAC 应答同一个 IP。顺带一提ARP 缓存是有老化时间的。Windows 默认 ARP 超时是 2 到 10 分钟Cisco 交换机上一般默认 4 小时。老设备换 IP 之后你先清一下 ARP 缓存再测试不然会碰到新 IP 配置了却一直连不通的诡异现象。5. 把 IP、TCP、UDP 拼起来看一次完整通信的完整视图单独学 IP 协议的时候总觉得它只是报头里的字段但只有把它跟 TCP/UDP 拼在一起才会看到整个网络协议栈是怎么协作的。这也是从会背到会排障之间的关键一步。5.1 端口号补充了 IP 表达的缺失IP 头里的目的 IP 只是把数据包送到了正确的电脑。但一台电脑上跑着微信、浏览器、邮箱客户端数据到了之后该交给谁这个问题 IP 回答不了需要传输层来回答。答案就是端口号。TCP/UDP 头里的源端口和目的端口把给哪台电脑细化成了给这台电脑上的哪个应用。用一个更生活的比如IP 是送外卖送到小区门口端口是送到几栋几零几交给具体哪个人。缺了端口数据到了 PC 上就成了无头公案操作系统不知道该交给哪个进程。所以抓包时看 IP 层解决到达谁的问题看传输层解决交给谁的问题。这俩的配合关系可以用 Wireshark 打开任意一次浏览器访问网页的抓包文件一眼就能看明白。5.2 TCP 为什么比 UDP 可靠——和 IP 的关系再回到可靠性这个话题。前面我说 IP 是尽力而为、不保证可靠的那可靠传输这三个字落在谁头上落在 TCP 头上。TCP 干的事包括建立连接三次握手、按序号排列数据、确认收到、超时重传、流量控制。每一项工作都是在弥补 IP 层可能丢包、可能乱序、可能重复的缺陷。你可以把 TCP 想象成一个称职的秘书老板应用层把文件交给秘书发出去秘书记录发了多少条、收到了多少条回执发现没回执就重新发发现回执乱序就重新整理。UDP 则什么都不要封装完直接扔给 IP。所以 UDP 非常轻、延迟低适合实时通话、视频、游戏这类能容忍小部分丢失的场景。这也就解释了一个现象为什么同一条网线里视频会议偶尔花屏但不会像网页一样转圈卡死——花屏是 UDP 丢了包直接不处理转圈是 TCP 一直等确认然后重传。理解了这一点后排障思维就升级了。看到一个网络慢的问题别再笼统地说网络不好。你可以先判断是 TCP 层在重传还是在 IP 层丢包。如果是 UDP 场景的延迟抖动大概率是链路拥塞或 QoS 没做如果是 TCP 场景的卡顿那要优先看丢包率、重传率、窗口值这些传输层的指标。5.3 从浏览器输入网址到看到页面一次完整的网络旅程现在把上面讲的串成一条线模拟一次完整的网页访问浏览器输入example.com先做 DNS 查询。DNS 的请求是一个 UDP 包偶尔用 TCP这个包同样要经过 IP 封装。操作系统协议栈判断目标 IP 不在本地网段于是把数据帧的目标 MAC 填成网关的 MAC通过 ARP 获取扔给路由器。路由器逐跳转发每一跳都改 MAC但 IP 不变直到到达最终服务器所在网段的路由器。服务器收到 IP 包剥掉 IP 头看到 TCP 目的端口是 443把数据交给 HTTPS 服务进程。浏览器拿到 HTML、CSS、JavaScript 资源渲染出页面。每一步出问题现象都不一样。DNS 挂了是直接输 IP 能打开输域名打不开网关 MAC 获取失败是同网段能通跨网段全断中间有一跳丢包则是时快时慢丢包率一上来就卡。这个判断链路就是我给团队新人教的网络排障的坐标轴。有了这个坐标轴报个网络不通到你手里起码能快速定位到是哪个环节出了问题再谈解决。6. 从协议理解到排障实战这些坑我替你踩过了讲完理论还是得落到实战。下面这几个场景是我这些年处理过或者带人处理过的高频问题每一个只要理解透上面讨论的内容就能快速拆解。6.1 ping 通但网页打不开问题到底在哪这个是我带新人时最常考的一个场景。PC 能 ping 通百度或者任意外网 IP但浏览器无论如何打不开网页。新手第一反应是网络是通的啊怎么还打不开从上面的完整视图去拆ping 通说明 IP 层面的来回路径是通的。打不开网页可能在哪DNS。浏览器第一步要解析域名DNS 走的是 UDP 53 端口。如果防火墙只放了 ICMP 而没放 UDP 53就是这种诡异的现象。还有更隐蔽的DNS 解析正常但 TCP 443 的握手包被中间设备丢掉。nslookup能解析出 IP但浏览器还是转圈尝试telnet 目标IP 443你就知道了根本连不上。这时候问题在 TCP 层不在 IP 层。6.2 抓包看 IP 分片你看到的丢包可能不是真的丢抓包时你可能会遇到一个非常迷惑的场景Wireshark 里看到很多TCP Previous segment not captured或者IP Fragment红色标记看起来网络好差。但真实原因是抓包点放得不对。尤其是跨路由器抓包时MTU 不一致会导致数据包被分片之后再重组你在中间链路抓到的已经不是一个完整的原始流而是分片片段的集合。这时候看起来丢了其实什么都没丢只是抓包工具把分片后的片段和原始流的顺序重建得不够完美。我的经验是要分析 IP 层分片问题最好在端到端的两台设备上分别抓对比看两端收到的片段。如果源端发出的是 1500 的整包目的端收到了几个更小的分片那基本可以确定是中间有路由器的 MTU 设置比 1500 小。沿着路径逐一 ping 大包测 MTU很快就能定位到是哪一跳在切。6.3 IP 冲突、子网错位与最后一公里的排查顺序最后总结一套我自己在实际运维里用的排查顺序给看到这里的朋友一条捷径先确认连通性范围同网段通不通跨网段通不通明确故障影响面。再查 IP 参数两边的 IP、掩码、网关是否配置正确ARP 缓存是否需要清理。然后看路由设备上有没有正确配置默认路由或者路由表里是否缺少目标网段。最后抓包定责把抓包分两步先在源端抓看发出后有没有出网再到目的端抓看有没有到达。从源头到目的一段一段收缩范围。这套顺序看着简单但它很稳。IP 协议本身的逻辑就是远方的路由靠路由表本地的送达靠二层你用同样的逻辑去排障总能把问题一点一点逼近到真正出问题的那一跳。如果问我个人最深的体会那就是IP 协议学了这么多年真正让我开窍的并不是它有多少字段、多少规则而是明白了它只是整个通信链条里的一环。它的职责边界那么清晰却能和上下层协议配合得天衣无缝。搞懂它不是为了应付考试而是让你在网络出问题时能在心里精确地画出一条这单到哪一步了的路线图然后顺着它一步步走到真相那里。