1. 先搞懂“分层”它更像一张用来看清问题边界的排障图普通表格的意义有限“计算机网络入门基础知识详解”这个题目乍一看像教材目录真啃下去才发现它是一堆缩写的集合OSI 七层、TCP 三次握手、子网掩码、ARP、DNS、MTU、TTL。我带过几个刚入行的新人几乎每个人的第一反应都是“这些背下来到底有什么用”然后考试背完就忘。问题不在人笨在于大部分入门材料先把名词堆到你面前再让你自己去猜这些名词之间的因果关系。这篇东西是我自己带人、以及自己踩坑之后重新梳理的版本。它不追求把每个协议讲全而是围绕一条主线一次网络请求从你的设备出发到对方服务响应回来中间经过了哪些环节每个环节可能在哪里出问题。这条线理顺了OSI 七层就不再是需要死记的表而是一张排障地图。适合谁看刚接触后端、运维、嵌入式但网络底子薄的同学准备面试想真懂而不是背八股的朋友以及被“能 ping 通但网页打不开”这类问题折磨过的人。零基础能读有基础的可以挑着看。1.1 拿一次网页访问把七层串起来你在浏览器里敲下一个网址回车接下来发生的事情大致是这样浏览器先判断这是不是一个 IP不是的话就交给 DNS 去问——这是应用层的活拿到 IP 后传输层负责建立一条可靠的、带序号和确认的连接通常是 TCP网络层给数据加上源 IP 和目的 IP交给路由器一跳一跳地转发链路层再把它包成帧写上本跳的源 MAC 和下一跳的 MAC物理层最后把这堆 0 和 1 变成电信号、光信号或者无线电波送出去。对方收到之后反过来一层层拆拆到应用层交给服务程序。用寄快递来类比会好理解很多。应用层是你写的那封信的内容传输层是信封上写的“第 3 封共 5 封”保证对方收到的顺序不乱、缺了能补网络层是收件地址和寄件地址决定了包裹大致往哪个方向走链路层是各个中转站之间的运输单每一站的单子都只写“从这一站到下一站”物理层就是卡车、飞机和公路本身。写信的人不需要知道卡车走哪条高速卡车司机也不需要看懂信里写了什么——这就是分层的意义。1.2 分层真正的价值把故障范围一次性砍掉一半分层最实用的地方在排障。任何一个网络问题你都可以用“逐层收敛”的方式快速缩小范围。先看物理层网线插了没、光模块亮不亮、无线信号强度多少。再看链路层同一网段内能否 ARP 到对方、交换机端口有没有报错。再看网络层ping通不通、路由表里有没有到目的网段的路由。再看传输层目标端口通不通、有没有被拒绝。最后看应用层服务进程是否在监听、返回的状态码是什么。这里有个我反复跟新人强调的点每验证一层就等于把可能的故障点砍掉一部分。比如ping不通基本可以把应用层和传输层的问题排除掉直接往下三层找ping通但curl超时说明链路和路由没问题重点看端口、防火墙策略和服务本身。这套方法比“凭感觉猜”快十倍。层级典型故障表现常用验证手段物理层网卡灯不亮、丢包严重看指示灯、换线换口、查看接口错误计数链路层同网段不通、ARP 解析失败arp -a、查看交换机 MAC 表、VLAN 配置网络层跨网段不通、路由环路ping、tracert、查看路由表传输层端口拒绝、连接超时ss -tunlp、telnet目标端口应用层状态码异常、返回内容不对curl -v、查看服务日志2. 协议栈逐层拆解每一层到底在处理什么问题2.1 物理层与数据链路层帧、MAC 和交换机的世界物理层最容易被人跳过因为它“没有协议可背”。但实际上大量玄学问题都出在这里网线水晶头氧化导致千兆协商成千兆半双工、光模块和光纤类型不匹配、机房里强电和网线捆在一起造成干扰。我遇到过一次线上服务周期性地每隔几分钟卡一下查了三天应用代码最后发现是网线被机柜门压出了内伤误码率高到触发重传。链路层解决的是“同一个广播域内怎么把帧送到对的设备”。以太网帧靠 48 位的 MAC 地址寻址交换机维护一张 MAC 地址和端口的对应表收到帧就查表从对应端口转发出去查不到就向所有端口泛洪。ARP 协议负责把 IP 地址翻译成 MAC 地址——你问“谁是这个 IP”对方回“我是我的 MAC 是这个”。这里有个经典现象ping一个同网段的地址不通先看 ARP 表里有没有对方的 MAC如果没有说明二层就没通问题根本不在 IP 层。交换机每个端口是独立的冲突域但默认所有端口属于同一个广播域广播包会泛洪到所有端口。设备一多广播风暴就能把网络拖垮所以要把端口划分到不同的 VLAN 里逻辑上切成多个广播域。这部分知识在云环境里被隐藏了但一旦你接触物理机、专线或者虚拟化平台就绕不开。2.2 网络层IP 是一套“尽力而为”的分拣系统IP 协议最大的特点写在教科书上也很少有人真正消化它是无连接、不可靠、尽力而为的。它不保证送达、不保证顺序、不保证不重复出了事只负责把包丢掉然后通过 ICMP 告诉你一声。真正的可靠性是上层 TCP 扛的。理解这一点你就能明白为什么 UDP 不是“残缺的 TCP”而是一种刻意的设计取舍。IP 报文头里有个字段叫 TTL每经过一台路由器减 1减到 0 就丢弃并回一个 ICMP 超时报文。这个设计的初衷是防止路由环路把包永远转下去但它顺便变成了排障神器tracert就是靠逐渐增大 TTL 值让路径上的每一跳依次出来“报到”。另一组容易忽视的字段是分片相关的——链路层有 MTU 限制常见以太网是 1500 字节超过这个大小的 IP 包要么在源端分片要么由中间设备分片要么直接丢弃并回一个“需要分片”的 ICMP。如果这个 ICMP 被防火墙拦掉了就会出现“小的请求正常、大的请求卡死”这种非常典型的症状后面排查部分我会细说。路由器的转发依据是路由表查表规则是最长前缀匹配。同一台路由器上同时存在0.0.0.0/0默认路由、10.0.0.0/8、10.1.0.0/16三条时目标是10.1.2.3的包会走/16那条因为前缀最长、最具体。默认网关本质上就是一条0.0.0.0/0的路由意思是“我不知道去哪儿的都丢给这个地址”。2.3 传输层TCP 和 UDP 的取舍远不只是“可靠与非可靠”TCP 提供的可靠性由几个机制叠加而成序号和确认号负责知道“哪些收到了”超时重传和快速重传负责“没收到就再发”滑动窗口负责流量控制、别把接收方撑爆拥塞控制负责在网络本身扛不住时主动退让。慢启动阶段窗口指数增长到了阈值转为线性增长丢包时根据不同算法收缩窗口——这段逻辑决定了同一条宽带下为什么大文件传输和实时通话的体验会互相影响。三次握手常被问“为什么不是两次”。核心原因有两个一是防止历史连接。如果网络上飘着一个很久以前发出的、已经失效的连接请求两次握手的话服务端会直接建立连接并占用资源而客户端根本不认三次握手时客户端会回一个 RST 拒绝掉。二是同步双方初始序号——TCP 的可靠性建立在序号之上双方都必须确认“我发的第一个字节编号是 X你收到了你发的第一个字节编号是 Y我收到了”。这两件事加起来两次不够四次多余。四次挥手常被问“为什么比握手多一次”。因为 TCP 是全双工的两个方向要各自关闭一方说“我没有数据要发了”之后另一方可能还有数据没发完所以 ACK 和 FIN 不能合并成一个包。主动关闭方最后会进入 TIME_WAIT 状态等待 2 倍报文最大生存时间目的是保证最后一个 ACK 能到达对方以及让这条连接遗留的旧报文在网络中彻底消亡不会串到后面复用同一组四元组的新连接里。特性TCPUDP连接方式面向连接需握手无连接直接发可靠性确认、重传、保序不保证送达与顺序头部开销20 字节起8 字节拥塞控制有无典型用途网页、文件传输、数据库连接域名解析、音视频、游戏、实时遥测2.4 应用层DNS 和 HTTP 才是你日常打交道最多的DNS 的本质是一个分布式的、带缓存的电话簿。查询过程分递归和迭代两种角色你本机配置的 DNS 服务器替你递归查它在根、顶级域、权威服务器之间迭代问路。这个链条上任何一环的缓存都可能让你改了记录却“不生效”所以排查解析问题第一件事是确认 TTL 和是否命中缓存而不是急着怀疑服务商。HTTP 这几年变化很大。1.1 时代靠长连接复用 TCP但同一连接上的请求是串行的队头阻塞严重2.0 引入了多路复用把消息拆成帧在一条连接上交错传输但底层还是 TCPTCP 层的丢包依然会阻塞所有流基于 UDP 的新一代协议把可靠传输做到了用户态才真正绕开了这个问题。日常排障里最实用的命令是curl -v它会把 DNS 解析、连接建立、TLS 握手、请求头、响应头、状态码全打印出来比看日志快得多。3. IP 地址与子网划分最容易劝退、也最值得死磕的部分3.1 私有地址、掩码与“同网段”的真正含义要判断两台机器在不在同一个网段关键在于把 IP 和掩码做按位与看结果是否相同不能只看 IP 前缀像不像。192.168.1.10/24和192.168.2.10/24看着像邻居实际是两个网段必须经过网关。反过来10.0.1.5/16和10.0.2.5/16看着差很远其实是同一个网段直接二层就能通。私有地址段是三块10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。这些地址不会在公网上被路由家里和公司内部随便用靠 NAT 转换出去。还有两个特殊地址值得记住127.0.0.0/8是本机回环169.254.0.0/16是链路本地地址——如果你看到设备拿到 169.254 开头的地址基本可以断定 DHCP 没拿到租约这是新手最容易忽视的线索。3.2 手算子网块大小法比二进制换算快十倍教材喜欢教你转二进制数 1 的个数这个方法不容易错但慢。实际工作里我用的是块大小法块大小 256 - 掩码最后一段的数值。比如掩码255.255.255.192块大小就是 64那么子网就是 0、64、128、192 这几个起点每个子网 64 个地址去掉网络地址和广播地址剩 62 个可用。举个真实场景某团队分到192.168.10.0/24有 5 个部门每个部门约 25 台设备要求每部门独立网段。倒推主机位需要至少 25 个可用地址2⁵ - 2 30 ≥ 252⁴ - 2 14 25所以主机位取 5 位前缀变成/27掩码255.255.255.224块大小 32一共切出 8 个子网5 个部门够用还留 3 个扩展。子网网络地址可用范围广播地址1192.168.10.0/27.1 - .30.312192.168.10.32/27.33 - .62.633192.168.10.64/27.65 - .94.954192.168.10.96/27.97 - .126.1275192.168.10.128/27.129 - .158.159手算容易出错可以写几行脚本验证。Python 的ipaddress模块就是干这个的import ipaddress net ipaddress.ip_network(192.168.10.0/24) for sub in net.subnets(new_prefix27): hosts list(sub.hosts()) print(f{sub} 掩码{sub.netmask} 首{hosts[0]} 末{hosts[-1]} 可用{len(hosts)})跑出来的结果和上表一致心里就有底了。网关地址通常取每个子网的第一个或最后一个可用地址这个习惯要统一否则接手的同事会骂人。还有一个细节网关必须和主机在同一网段如果网关配成了别的网段主机会认为网关不可达直接表现为“内网通、外网不通”。3.3 NAT 与端口复用一个公网地址承担一整间屋子的上网需求家庭和企业出口普遍用 NAT更准确地说是带端口复用的 NAPT路由器把内网地址加源端口翻译成公网地址加一个新的源端口维护一张映射表。正因为这张表是内部主动建立的外部主动发起的连接找不到映射所以内网服务默认对外不可见需要手动配置端口映射才能被访问。这带来一个副作用两端都在 NAT 后面的设备想直连会非常困难因为谁也不知道对方的公网映射是什么。这也是为什么大量实时通信场景需要借助中继服务器来打通或者干脆全部走服务端转发。理解 NAT 的行为模型对设计分布式系统、排查“服务本地好好的、外部调用不通”这类问题非常关键。4. 抓包与排障把黑盒变成透明玻璃4.1 从下往上的排查顺序与命令清单我的习惯是从下往上每一步都记录下来。先确认本机地址和路由ip addr show # 看地址、掩码、网卡状态 ip route show # 看默认网关和明细路由 cat /etc/resolv.conf # 看 DNS 配置然后确认连通性和路径ping -c 4 192.0.2.10 # 三层通不通看丢包和延迟 traceroute 198.51.100.20 # 路径上哪一跳开始断 dig example.internal short # 域名解析结果 ss -tunlp | grep 8080 # 本机有没有进程在监听这个端口 curl -v http://198.51.100.20:8080/health # 应用层握手和响应再往下就是抓包了。带过滤条件的命令行抓包工具非常适合在服务器上直接跑图形化工具适合在本地慢慢分析。常用的过滤表达式是host 192.0.2.10 and port 8080先抓住可疑流量再逐个包看标志位和序号。4.2 一次完整的排障实录某开发者反馈调用一个内部接口大部分时候正常偶尔超时而且超时的请求都是带较大请求体的。听到“大请求体偶尔超时”这几个字我的第一反应就是 MTU 和分片而不是应用代码。第一步ping目标地址正常延迟 1 毫秒以内说明三层通。第二步ping -s 1400加大包直接不通症状复现。第三步判断是不是分片被丢链路上有一台设备做了隧道封装实际可用 MTU 比 1500 小请求体一大就触发分片而中间设备不允许分片又发不出“需要分片”的 ICMP 通知于是包被静默丢弃表现就是超时。第四步验证把客户端的 MSS 调小请求立刻稳定。第五步定方案在两端设备上把接口 MTU 和 TCP MSS 都往下调同时放行必要的 ICMP 类型因为路径 MTU 发现依赖它。整件事从复现到解决不到一小时但如果一开始就奔着应用日志去查很可能耗上一整天。这件事之后我总结了一句话“小时通、大不通”几乎必定是 MTU 问题“一直通突然断”先看有没有人改了配置“间歇性抖动”看丢包和重传“特定域名不行”看 DNS。4.3 三次握手的抓包表现抓到的报文长这样地址用文档保留段便于对照No. Source Destination Flags Seq Ack Len 1 192.0.2.10 198.51.100.20 [SYN] 1000 0 0 2 198.51.100.20 192.0.2.10 [SYN, ACK] 5000 1001 0 3 192.0.2.10 198.51.100.20 [ACK] 1001 5001 0 4 192.0.2.10 198.51.100.20 [PSH, ACK] 1001 5001 512 5 198.51.100.20 192.0.2.10 [ACK] 5001 1513 0第 1 个包客户端发起带上自己的初始序号 1000。第 2 个包服务端同时把 SYN 和自己的 ACK 合在一起确认号是 1001 表示“1000 我收到了下一个我要 1001”。第 3 个包客户端确认服务端的 5000。第 4 个包就是真正的数据了。断开时的四次挥手会看到两个方向的 FIN 和 ACK 分别出现如果只有一边发 FIN 而另一边迟迟不回就要怀疑对端进程卡死或者被中间设备拦了。我踩过的坑是只看抓包不看时间戳。有一次握手明显慢一个 SYN 到 SYN-ACK 之间隔了 3 秒这个数字太整了不像是网络抖动最后查出来是服务端的连接队列满了在重试。看到整数秒的延迟先怀疑超时重试机制不要先怀疑带宽。5. 常见问题速查与踩坑记录5.1 高频故障速查表现象最可能的原因优先验证的动作拿到 169.254 开头地址DHCP 未获取到租约检查 DHCP 服务与链路能 ping 通 IP 但域名打不开DNS 配置或解析异常dig对比不同 DNS 服务器内网通、外网不通网关或 NAT 配置错误ip route查看默认路由端口 telnet 不通服务未监听或被策略拦截ss -tunlp确认监听地址服务本地访问正常、外部不通监听在 127.0.0.1 或仅内网地址改为监听 0.0.0.0 并核对策略小请求正常、大请求超时MTU 与分片问题ping -s逐步加大包验证间歇性超时丢包、重传或连接队列满抓包看重传率和握手耗时偶尔提示证书或时间相关错误设备时间偏差过大校准系统时间5.2 我踩过的坑比教材有用得多第一个坑是掩码写错。有次给一批机器批量配地址脚本里掩码少写了一位结果同一批机器互相 ping 不通怎么查路由都正常最后发现两台机器认为彼此不在同一网段包全丢给网关了。批量配置前先拿一台验证再去铺开这个习惯能省下大量返工。第二个坑是 DNS 缓存。改了解析记录本地一直在验证失败其实只是缓存还没过期。后来我养成习惯排查解析问题先用权威服务器直接查绕开所有缓存确认记录本身是对的再去纠结缓存。第三个坑是双网卡的路由冲突。一台机器同时接了内网和外网默认路由被后配的那块网卡抢走结果访问内网服务时包从外网口出去了。这类问题在服务器上很常见处理办法是给内网网段配明细路由明确指定从哪块网卡出去。第四个坑是时间不同步。安全握手对时间敏感设备时间差了几分钟握手就会失败报错信息还特别含糊。现在我的巡检脚本里固定有一项是比对设备时间。第五个坑是防火墙只放行了入站。应用需要主动访问外部服务时被拦了日志上看起来像“对方没响应”实际是出站就被挡了。排查时永远要双向看。最后分享一个我自己的体会。网络这东西最怕的是把它当玄学。它确实有复杂度但每一层的行为都是有确定规则的问题也一定能通过某种可观测的手段暴露出来。工具不用多ping、traceroute、dig、ss、curl这五个命令加上一个抓包工具就足以解决绝大多数日常问题。真正拉开差距的不是记住了多少协议字段而是遇到问题时能不能有条理地分层排除以及排完之后有没有把过程记下来。我自己的排查笔记里最有价值的从来不是那些成功的案例而是走了弯路的那几次——它们才真正塑造了排查时的直觉。