学网络这些年，我见过太多人卡在同一个地方：书翻了三章，OSI 七层背得滚瓜烂熟，一到真机上ping不通就完全没了方向。计算机网络入门基础知识这东西，难点从来不在概念本身，而在于大部分人学的时候是"悬空"的——脑子里有一堆名词，手上没有一个能跑起来的场景，名词之间也没有连成一条线。这篇东西我想干的事很具体：把"一台机器怎么找到另一台机器、数据怎么过去、出问题怎么定位"这条主线从头到尾走一遍，中间该算的参数算给你看，该敲的命令贴给你抄。适合刚接触网络的新手，也适合做了几年业务开发、但对底层一直是黑盒状态的朋友。看完至少能做到两件事：拿到一个 IP 和掩码能自己算出网段，遇到"连不上"能按顺序往下排而不是瞎猜。
1. 先把"网络"这件事拆开看：分层到底解决了什么麻烦
1.1 为什么一定要分层，而不是写一个大程序
很多人对分层的理解停留在"考试要考"，觉得是人为制造的复杂度。我换个说法你就明白了：假设不分层，你要写一个程序，负责把一段文字从 A 机器送到 B 机器，那这个程序得同时处理网线插没插、电信号怎么编、对端在哪个位置、中间丢包了要不要重发、两台机器字符编码是不是一致——只要其中任何一环出问题，整个程序都得改。这不是工程，这是灾难。
分层的本质是把"会变的部分"和"不变的部分"隔开。物理介质从双绞线换成光纤，只需要换最底下一层，上面的 IP、TCP 完全不用动；应用层从网页换成视频流，底下四层照样干活。每一层只对上一层负责、只用下一层提供的能力，层与层之间靠约定好的接口通信。这个设计思想在软件工程里到处都是，网络只是把它用得最彻底的一个领域。
我第一次真正理解分层，是在一次排查里：应用层报"连接超时"，我一直以为是服务端代码问题，折腾了半天，最后发现是中间某一跳设备把某个端口的包丢了。如果没有分层，我根本没法判断"是应用没响应"还是"包压根没到"。分层给了你一个逐层排除的坐标系，这才是它最实用的价值。
1.2 OSI 七层和 TCP/IP 四层，别背模型，背职责
教科书上的 OSI 七层模型是个"理论参考模型"，实际工程里跑的是 TCP/IP 四层（或者说五层）。两套东西对照着看就够了，别在这上面耗时间。
| OSI 七层 | TCP/IP 四层 | 这一层实际管什么 | 典型代表 |
|---|---|---|---|
| 应用层 / 表示层 / 会话层 | 应用层 | 业务语义，数据长什么样 | HTTP、DNS、SSH |
| 传输层 | 传输层 | 端到端，进程到进程 | TCP、UDP |
| 网络层 | 网络层 | 主机到主机，跨网段寻址 | IP、ICMP |
| 数据链路层 | 网络接口层 | 同一段链路上的相邻设备 | 以太网、ARP |
| 物理层 | 网络接口层 | 比特怎么变成电/光信号 | 网线、光模块 |
记的时候别记"七"这个数字，记职责边界。我自己的记法是四个问题：数据给谁用（应用层）、给哪个进程（传输层）、送到哪台机器（网络层）、下一跳交给谁（链路层）。四个问题回答完，一整套流程就通了。
有个特别容易混淆的点：MAC 地址管"下一跳"，IP 地址管"最终目的地"。很多人以为发一个包出去，源 MAC 和目标 MAC 是一路不变的，完全不是。每经过一个路由器，MAC 头都会被重写，但 IP 头里的源和目的地址基本不变（NAT 场景除外）。这个认知差异直接决定你能不能看懂抓包结果——抓包看到 MAC 地址跟自己预期不一样，新手第一反应是"被抓错了"，老手第一反应是"这里有个网关在改写"。
1.3 新手最容易搞混的边界：帧、包、段、报文
这几个词在日常聊天里混着用没问题，但在排查问题时混用会直接导致判断错误。按封装层级，从上往下依次是：
- 报文（message）：应用层的数据单位。比如一次 HTTP 请求的完整内容。
- 段（segment）：TCP 把报文切开后加上 TCP 头，叫 TCP 段。UDP 的叫数据报。
- 包（packet）：加上 IP 头之后叫 IP 包。这是网络层的单位。
- 帧（frame）：加上以太网头尾之后叫帧。这是链路层的单位，也是抓包工具真正抓到的东西。
为什么要较真这个？因为不同层的问题，排查手段完全不一样。丢包发生在链路层（比如网线接触不良、交换机端口错误），你抓包只能看到帧缺失；丢包发生在传输层（比如对端缓冲区满了），你能看到包到了但没被确认。分不清层级，你就会用错工具。
提示：说"丢包"的时候，尽量说清楚是哪一层丢的。这个词太笼统，很多次沟通扯皮都是因为它。
2. IP地址、掩码与网关：入门路上第一道真正会卡人的坎
2.1 网络号、主机号、广播地址，怎么算
这是整个入门阶段唯一需要动笔算的东西，也是最值得花时间的地方。一个 IPv4 地址是 32 位，写成四段十进制只是为了人看着舒服。掩码的作用就是把 32 位切成两半：左边是网络部分，右边是主机部分。
判断两台机器能不能直接通信，只看一件事：网络号是否相同。相同就能直接通（走 ARP 找对方 MAC），不同就必须经过网关。
算法很简单，但必须练熟：把 IP 和掩码都转成二进制，做按位与运算，结果就是网络号。举个具体的：
IP : 192.168.10.130 掩码 : 255.255.255.192转成二进制：
IP : 11000000.10101000.00001010.10000010 掩码 : 11111111.11111111.11111111.11000000 与运算: 11000000.10101000.00001010.10000000结果是192.168.10.128，这就是网络号。主机位是最后 6 位，全 0（网络号本身）和全 1（广播地址192.168.10.191）不能用，所以可用地址范围是192.168.10.129到192.168.10.190，一共 62 个。
192.168.10.130落在这个范围内，说明它是一个合法主机地址，属于192.168.10.128/26这个子网。这几个数字（网络号、广播地址、可用范围）必须能一口气算出来，后面配错地址、划错网段，全是这里出的问题。
顺带提一句私有地址段，家里、公司内网基本都是这三段，看到它们就知道不会直接出现在公网上：
| 地址段 | 前缀范围 | 可用地址数量（约） | 常见用途 |
|---|---|---|---|
| 10.0.0.0 – 10.255.255.255 | /8 | 1600 万 | 大型内网 |
| 172.16.0.0 – 172.31.255.255 | /12 | 100 万 | 中型内网 |
| 192.168.0.0 – 192.168.255.255 | /16 | 6.5 万 | 家庭、小型办公 |
172.16到172.31这个范围特别容易记错，很多人以为172.16到172.32，多了个 32，实际是到172.31为止，因为第二段只有 16 个可用值。
2.2 子网划分动手算一遍（含参数计算过程）
划分子网这件事，考试里是做题，工程里是规划。我按一个真实会遇到的场景走一遍：拿到192.168.10.0/24，需要分给四个部门，每个部门不超过 50 台设备，要求每个部门一个独立网段。
第一步，确定每个子网需要多少主机位。公式是2^n - 2 ≥ 需求主机数，减 2 是去掉网络号和广播地址。需求 50：
2^5 - 2 = 30 < 50 不够 2^6 - 2 = 62 ≥ 50 够用所以主机位需要 6 位。总长度 32 位，网络位就是32 - 6 = 26，也就是/26，掩码是255.255.255.192（因为掩码的最后一段是11000000，十进制 192）。
第二步，算出能有几个子网。原来/24有 8 位主机位，现在变成 6 位，借走了 2 位：2^2 = 4个子网，正好四个部门。
第三步，列出四段范围。步长是2^6 = 64：
| 子网 | 网络号 | 可用范围 | 广播地址 | 可用数 |
|---|---|---|---|---|
| 子网 1 | 192.168.10.0/26 | .1 – .62 | .63 | 62 |
| 子网 2 | 192.168.10.64/26 | .65 – .126 | .127 | 62 |
| 子网 3 | 192.168.10.128/26 | .129 – .190 | .191 | 62 |
| 子网 4 | 192.168.10.192/26 | .193 – .254 | .255 | 62 |
网关一般取每个子网的第一个可用地址（.1、.65、.129、.193），也有人习惯取最后一个，无所谓，但同一个内网里要保持一致，否则后期维护会很痛苦。
再反过来算一次，这类题也很常见：现有一个地址10.20.30.200/27，求网络号和可用范围。/27意味着最后一段掩码是11100000，即 224，步长2^5 = 32。200 落在192到223之间（192, 224, 256 是边界），所以网络号是10.20.30.192，广播地址10.20.30.223，可用范围.193到.222，共 30 个。
注意：划分方案一旦上线，再改成本很高——所有设备的静态 IP、防火墙策略、ACL、监控配置全要跟着变。所以规划阶段多做一步：按未来三年的设备增长量预留。我见过一个团队 62 个可用地址用掉 58 个，加一台打印机就得整个网段重来。
2.3 网关和 ARP：为什么同网段不通网关也能通
网关（默认网关）这个概念的准确定义是：当目的地址不在本网段时，把包交给谁。所以如果两台机器在同一网段，它们之间的通信压根不需要网关参与——这一点很多人没意识到，配错了网关但同网段通信仍然正常，等到跨网段才发现问题。
同一网段内的通信靠 ARP 完成。A 要给 B 发包，A 只知道 B 的 IP，不知道 MAC，于是发一个 ARP 广播："谁是 192.168.10.130？"整个二层广播域里所有设备都能收到，只有 B 会回应自己的 MAC。A 拿到后写进 ARP 缓存，再发数据。
ARP 缓存是有生命周期的，一般几分钟到几十分钟。这解释了一个常见现象：换了网卡或者虚拟机迁移后，短时间内别人访问不到你，因为旧 MAC 还在别人的缓存里。清一下就好：
# Windows arp -a arp -d * # Linux ip neigh show ip neigh flush all # macOS arp -a -d跨网段时流程变成：A 判断目的 IP 不在本网段，于是查路由表找到默认网关，然后对网关的 IP做 ARP，拿到网关 MAC，把包发给网关。包里的目的 IP 仍然是最终的 B，但目的 MAC 是网关的。这就是 1.3 里说的"MAC 每跳改写、IP 基本不变"。
还有一个特殊情况值得知道：同网段内如果配了不同掩码，就会出现"A 认为同网段、B 认为不同网段"的诡异状态。A 直接 ARP 找 B，能通；B 回包时认为不同网段，发给网关，网关如果没有对应的路由就丢了。表现出来就是"能 ping 通一半"或者"单向通"。这类问题极难靠猜，必须核对双方的掩码。
3. 一次网页打开背后发生了什么：完整链路走一遍
3.1 DNS解析：从域名到IP
你在地址栏敲一个域名回车，第一件事不是发 HTTP 请求，而是把这个名字翻译成 IP。这个过程是 DNS 干的，走 UDP 53 端口，绝大多数情况下。
完整的解析路径是自下而上的：先查本地 hosts 文件（很多"改了不生效"的问题就出在这），再查本机 DNS 缓存，然后问配置的首选 DNS 服务器。如果那台服务器没有缓存，它会代为逐级询问：根 → 顶级域 → 权威服务器，拿到结果后层层返回并缓存。
这个链路有几个实操上的含义：
- 改 hosts 是不需要重启的（部分系统有缓存，浏览器也有自己的缓存），但改 DNS 记录需要等 TTL 过期。
- 解析结果可能每次不一样，因为一个域名可以配多条 A 记录做轮询，这在排查"为什么这次连到另一台机器"时很关键。
- 内网域名解析失败，八成是 DNS 服务器指错了，或者内网 DNS 和公网 DNS 混配。这种情况下
nslookup指定服务器试一下就能定位：
# 用默认 DNS 查 nslookup example.internal # 指定某台 DNS 查，用来对比 nslookup example.internal 10.20.30.2 # Linux 上更推荐 dig，信息更全 dig example.internal +short dig @10.20.30.2 example.internaldig的输出里重点看status和ANSWER SECTION。status: NXDOMAIN是记录不存在（可能是拼错了或者没配），SERVFAIL往往是 DNS 服务器本身有问题或者上游不通。这两个状态含义完全不同，别混着排查。
3.2 建连接、发请求、收响应
拿到 IP 之后，如果是 HTTPS，还要先做 TLS 握手（这里不展开），然后才是 TCP 三次握手。整个过程可以粗略拆成几段时间：
- DNS 解析耗时
- TCP 建连耗时（一个 RTT）
- TLS 握手耗时（一到两个 RTT，和协议版本有关）
- 首字节时间（服务端处理）
- 内容传输时间
这五段在浏览器的开发者工具 Network 面板里都有对应字段，能直接看：Queueing、DNS Lookup、Initial connection、SSL、TTFB、Content Download。哪一段长，问题就在哪一段，这是前端同学排查"页面打开慢"最有效的方法，比猜有用得多。
我自己遇到过一回：页面加载要三秒多，所有人第一反应是"后端接口慢"。打开面板一看，TTFB 只有 80ms，但Initial connection花了将近两秒。后来发现是那一批机器的 TCP 建连有问题，跟业务代码一点关系没有。如果不去看分段耗时，这个方向能偏一周。
3.3 封装与解封装：数据在每一层被套了几层壳
从发送方看，数据是一层层往下套壳的：
[以太网头][IP头][TCP头][HTTP数据][以太网尾]每往下一层，就在前面加一个本层的头。接收方反过来，从下往上逐层剥开，每一层看自己的头、做自己的判断，然后把剩下的部分交给上一层。
这里有个必须算清楚的参数：MSS。以太网的标准 MTU 是 1500 字节，这是一个帧里数据部分的最大长度。IP 头最小 20 字节，TCP 头最小 20 字节，所以：
MSS = MTU - IP头 - TCP头 = 1500 - 20 - 20 = 1460 字节这就是为什么很多 TCP 连接的 MSS 是 1460。如果中间有隧道封装（比如 IPsec、GRE），MTU 会被吃掉一部分，MSS 要相应减小，否则就会出现"小请求正常、大请求卡死"的经典现象——包太大被丢弃，但 ICMP 的"需要分片"消息被防火墙拦了，发送方永远等不到通知，这就是所谓的 PMTU 黑洞。
排查这个现象最直接的办法是带DF（不分片）标志去 ping，逐步加大包长：
# Linux，-M do 表示禁止分片，-s 指定数据长度 ping -M do -s 1472 10.20.30.10 # 1472 + 8(ICMP头) + 20(IP头) = 1500，正好是 MTU # 如果 1472 不通但 1400 通，说明路径 MTU 小于 1500Windows 上对应的是ping -f -l 1472 目标IP。这个技巧在排查跨专线、跨隧道的应用卡顿时非常好用，很多"应用只传小文件正常"的怪问题都是 MTU 引起的。
4. 动手实验：在自家机器上把网络"看见"
4.1 环境准备与最简单的连通性验证
不需要买设备，一台能上网的电脑就够了，再加两个免费工具：抓包工具（Wireshark 是开源的，够用）和命令行。想在更接近真实的环境里练，可以装个虚拟机，两台虚拟机放同一个虚拟网络里，随便折腾。
第一步永远是看自己的配置：
# Windows ipconfig /all # Linux（推荐，输出更规整） ip addr show ip route show # macOS ifconfig netstat -rn重点看四项：本机 IP、掩码、默认网关、DNS 服务器。这四项缺一个，网络就不完整。配置完成之后按顺序验证：
# 1. 先看本机协议栈是否正常（ping 回环） ping 127.0.0.1 # 2. 再看同网段是否能通（换成网关地址） ping 192.168.10.1 # 3. 再看跨网段（用公网地址，比如公共 DNS） ping 8.8.8.8 # 4. 最后看域名解析 ping www.example.com这个四步顺序是有讲究的，它对应一个由近及远的排查逻辑：回环通说明协议栈没问题，网关通说明二层和本地配置没问题，公网 IP 通说明路由和出口没问题，域名通说明 DNS 没问题。四步里哪一步断了，问题范围就锁定在那一段。这个顺序我用了很多年，比"重启试试"高效太多。
注意：很多网络禁 ping（ICMP 被拦），所以 ping 不通不等于不通。这时候要换端口探测，比如
telnet 目标 端口或者nc -zv 目标 端口。
4.2 抓包：把看不见的东西变成看得见的
抓包是分水岭。会抓包的人排查网络问题，和不会的人，效率差一个数量级。
先选网卡。多网卡机器上抓错网卡是最常见的失误——你抓的是无线网卡，流量走的却是有线。选好之后加过滤条件，否则流量一大根本看不清：
# 只看某个 IP 相关的 ip.addr == 192.168.10.130 # 只看某个端口 tcp.port == 443 # 只看 TCP 的 SYN 包（看建连） tcp.flags.syn == 1 and tcp.flags.ack == 0 # 组合：某台机器和 80 端口的交互 ip.addr == 192.168.10.130 and tcp.port == 80命令行环境下用tcpdump，适合在没有图形界面的服务器上操作：
# 抓某块网卡上 80 端口的包，-nn 不做名称解析，-A 显示内容 sudo tcpdump -i eth0 -nn port 80 -A -c 50 # 抓某个主机之间的包，存成文件拿回来分析 sudo tcpdump -i eth0 -nn host 10.20.30.10 -w /tmp/cap.pcap看抓包结果，先看三次握手是否完成。如果只看到 SYN 没有 SYN-ACK，说明包到了对端但没回，可能是对端没监听、或者中间被拦了。如果看到 SYN 之后回了 RST，那是明确拒绝，说明端口没开或者被策略拒绝，这两种情况的处理方向完全不同——前者要查服务，后者要查策略。
再看有没有重传。同一个序号的数据包出现多次，说明丢包了。重传集中出现在某个方向，多半是那一段链路有问题。这个比"感觉卡"要精确得多。
4.3 端口与连接状态：netstat/ss 怎么读
服务器上排查，"服务到底起没起"这件事必须能一眼看出来。
# Linux 推荐 ss，比 netstat 快 ss -lntp # 监听中的 TCP 端口，带进程名 ss -antp # 所有 TCP 连接 ss -s # 汇总统计 # 传统写法 netstat -an | grep LISTEN netstat -tunlp # Windows netstat -ano | findstr LISTENING几个高频状态要能读懂：
| 状态 | 含义 | 常见场景 |
|---|---|---|
| LISTEN | 正在监听 | 服务正常启动 |
| ESTABLISHED | 连接已建立 | 正常通信中 |
| SYN_SENT | 已发 SYN 等回应 | 建连中，卡住说明对端不回 |
| SYN_RECV | 收到 SYN 已回 SYN-ACK | 半连接，大量出现要警惕 |
| TIME_WAIT | 主动关闭方等待 | 大量堆积通常是短连接太多 |
| CLOSE_WAIT | 收到对端 FIN 但自己没关 | 大量堆积是代码没 close，必查 |
| FIN_WAIT2 | 自己发了 FIN 等对端 FIN | 长时间停留说明对端不关 |
CLOSE_WAIT这个状态我要单独说。它的意思是"对方要关了，我这边还没关"，责任在本地应用代码——没有正确释放连接。如果你在服务器上看到成百上千个CLOSE_WAIT，不用怀疑，去查代码里的连接释放逻辑，别去调内核参数，调了也没用。
而TIME_WAIT的责任在协议设计本身，主动关闭方必须等 2MSL（一般是 60 秒）才能复用这个四元组，目的是保证最后一个 ACK 能被对方收到、以及让旧连接的残留包在网络里消失。所以TIME_WAIT多不一定是坏事，短连接密集型服务上出现几千个是正常的。要缓解就上连接池，或者调整net.ipv4.tcp_tw_reuse（只在客户端侧生效，服务端意义不大）。
5. TCP和UDP：什么时候该用哪个，以及握手挥手里的坑
5.1 三次握手四次挥手的实际意义
面试题里背"三次握手是为了确认双方收发能力"，这话没错但太干。我换个角度讲：握手的存在是为了在传数据之前，让双方就"初始序号"达成一致。
TCP 保证可靠传输的基础是序号。每个字节都有编号，接收方按序号确认，缺了就要求重传。但双方一开始并不知道对方从哪个号开始，所以要交换初始序号（ISN）。A 发 SYN 带自己的 ISN，B 回 SYN-ACK 带自己的 ISN 并确认 A 的，A 再回 ACK 确认 B 的。三次，刚好双方都确认了自己和对方的初始序号。
为什么不能两次？因为 B 的 ISN 发出去了，但 B 不知道 A 收到没有。A 如果没收到，B 后面发的数据 A 会认为序号不对。第三次 ACK 就是让 B 确认"我的序号对方拿到了"。
四次挥手是因为 TCP 是全双工的，两个方向要各自关闭。A 发 FIN 表示"我没数据要发了"，B 回 ACK，但此时 B 可能还有数据要发，所以不能立刻关，等 B 也发完了再发自己的 FIN，A 回 ACK。中间那个"半关闭"状态是很多问题的来源——比如服务端收到 FIN 之后进入CLOSE_WAIT，如果应用不主动 close，这个连接就一直挂着。
5.2 TIME_WAIT、RST、半连接这些现场问题
除了上面说的CLOSE_WAIT和TIME_WAIT，还有两类现场问题值得展开。
RST 的产生原因。RST 是"我不认这个连接，立刻断"。常见场景有：连一个没监听的端口（对端内核直接回 RST）、连接已经关闭但还有包发过来、中间设备（负载均衡、防火墙）认为连接不合法主动发 RST、应用主动调用了带SO_LINGER 0的 close。
排查"连接莫名被断"，如果抓到 RST，先确定 RST 是谁发的——看源 IP。是服务端发的还是中间设备发的，方向完全不同。这一步不看，后面全是在猜。
SYN Flood 和半连接队列。SYN_RECV状态大量堆积，说明收到了 SYN、回了 SYN-ACK，但没等到最后的 ACK。正常情况下这个状态只存在极短时间，堆积说明有人在大量伪造源 IP 发 SYN，或者链路有问题导致 ACK 回不来。与之相关的两个参数：
# 查看当前半连接队列和全连接队列的使用情况 ss -lnt # 输出中的 Send-Q 是全连接队列上限，Recv-Q 是当前排队数 # 相关内核参数 net.core.somaxconn # 全连接队列上限 net.ipv4.tcp_max_syn_backlog # 半连接队列上限 net.ipv4.tcp_syncookies # 开启 SYN Cookie 防御这里有个实操经验：应用层监听时传的 backlog 如果小于内核的somaxconn，实际生效的是应用传的那个值。所以你会看到"我把内核参数调到 65535 了还是不生效"——去检查应用配置里的 backlog 参数，很多框架默认只有 128 甚至更小。
5.3 UDP不是"不可靠"的代名词
新手常有的误解是"UDP 不可靠所以不能用"。UDP 只是不提供可靠传输、不保证顺序、不做拥塞控制，这些能力可以自己在应用层实现。选择 UDP 的理由通常不是"我想偷懒"，而是这几种：
- 延迟比完整性重要：音视频通话，丢一两帧没人听出来，但重传导致的延迟是致命的。
- 需要广播/组播：UDP 天然支持，TCP 不支持。
- 短事务、无状态：DNS 查询就一个包一来一回，建 TCP 连接的开销比查询本身还大。
- 需要自己控制重传策略：有些实时协议自己实现 FEC 和前向纠错，比 TCP 的重传更合适。
反过来，什么时候坚决别用 UDP？任何"数据丢了会导致业务错误"的场景，比如转账、下单、文件传输。自己实现一套可靠传输的成本远超想象，除非你是做协议栈的。
顺带纠正一个常见说法："UDP 比 TCP 快"。准确的说法是UDP 的头部开销小、没有建连和拥塞控制的额外延迟。在链路质量好、包不大的情况下确实更快；但在有丢包的链路上，TCP 有拥塞控制会主动降速，而一个不加控制的 UDP 流会把整条链路打满，害人害己。这个区别在写实时应用时非常关键。
6. 常见故障排查实录与速查表
6.1 排查的固定顺序：从物理层往上推
我从无数次现场里总结出一个原则：别跳步，从下往上。新手最喜欢从应用层往下猜（"是不是代码 bug"），老手习惯从底层往上排，因为底层问题影响面大、验证成本低。
固定顺序是这样：
- 物理/链路：网线、光模块、交换机端口指示灯、
ip link看接口是不是 UP。这一步 30 秒能完成，却能解决相当比例的问题。 - 本机配置：IP、掩码、网关、DNS 是否正确，有没有地址冲突（
arping能查）。 - 同网段连通：ping 网关。不通说明二层或本地配置有问题，跟外网无关。
- 跨网段路由：ping 一个公网 IP。不通说明路由或出口有问题。
- DNS：ping 域名。IP 通但域名不通，就是 DNS。
- 端口与服务：
nc -zv或telnet探端口。通不通决定是网络问题还是服务问题。 - 应用层：前面全通还不行，才轮到看日志、看代码。
这个顺序的价值在于每一步都能把问题范围砍掉一半。我见过有人跳过前五步直接去翻服务日志翻了两小时，最后发现是网线没插紧。
6.2 十类高频问题速查表
| 现象 | 最可能的原因 | 快速验证 | 处理方向 |
|---|---|---|---|
| ping 网关不通 | 网线/IP 冲突/掩码错 | ip link看接口状态，arping查冲突 | 检查物理连接和地址配置 |
| ping IP 通但域名不通 | DNS 配错或解析失败 | nslookup 域名 指定DNS | 修正 DNS 或改 hosts |
| 能 ping 通但端口连不上 | 服务没起或被策略拦 | nc -zv IP 端口 | 查服务监听状态和访问策略 |
| 间歇性超时 | 丢包、MTU 问题、连接数满 | 抓包看重传，ping -M do试 MTU | 分段排查链路质量 |
| 大文件传不了小请求正常 | MTU/MSS 不匹配 | 逐步加大不分片包长 | 调整 MSS 或启用 MSS 钳制 |
| 大量 CLOSE_WAIT | 应用没关连接 | ss -antp数状态 | 改代码，别调内核 |
| 大量 TIME_WAIT | 短连接过多 | ss -ant统计 | 上连接池，客户端开 tw_reuse |
| 访问偶发连到旧机器 | DNS 缓存 / 负载均衡会话 | dig多次看结果 | 检查 TTL 和会话保持配置 |
| 抓包看不到包 | 抓错网卡 / 过滤条件错 | 清空过滤看全量 | 确认流量出口网卡 |
| 换网卡后别人连不上 | ARP 缓存未更新 | arp -a查旧 MAC | 清 ARP 缓存 |
6.3 几个反直觉的经验
第一，"重启好了"往往不是玄学，是缓存。ARP 缓存、DNS 缓存、连接池里的死连接、负载均衡的会话表，任何一处过期数据都会造成"重启就好"。知道这个原理之后，你可以不重启，精准清对应的缓存，影响面小得多。
第二，"网络慢"这三个字几乎没有信息量。到底是延迟高（RTT 大）、带宽小（吞吐低）、还是抖动大（时延不稳定）？这三种的排查方向完全不同。延迟高看路由跳数和链路质量，带宽小看瓶颈在哪一跳，抖动看是不是有拥塞或者队列配置问题。我现在的习惯是要求对方给出具体数字：ping 的平均延迟、丢包率、传输速率，有数字才好判断。
第三，不要迷信"对端没问题"。排查最忌讳的是过早排除嫌疑。我踩过最深的坑就是笃定"服务端肯定没问题"，结果绕了一大圈回到原点。正确做法是每一层都留一个可验证的判据，而不是靠"我觉得"。
第四，抓包文件要保存。现场问题往往转瞬即逝，抓下来的 pcap 文件是唯一能复盘的证据。我习惯是排查一开始就开着抓包，存到临时目录，问题解决后保留几天再删。有好几次都是事后回看才找到真正原因。
7. 学习路径与资料取舍（个人经验）
学网络最容易走的两条弯路，一条是死磕理论不看实际，一条是只会敲命令不懂原理。前者的典型表现是能画出完整的七层模型但配不好一个网关，后者的典型表现是命令背了一堆，一旦现象不在"经验库"里就完全卡住。
我建议的节奏是这样：先用两三天把 IP、掩码、网关、ARP 这几件事彻底弄明白，能做到"给一个地址和掩码，手算出网段和可用范围"，这一步没有任何捷径，必须动笔。然后立刻上手抓包，抓一次自己打开网页的全过程，对照着看每一层加了什么头，把抽象概念落到具体字节上。这一步做完，前面的理论会突然变得"实"起来。
再往后是 TCP 的细节。这一块不建议一上来就啃拥塞控制的公式，先搞清楚序号、确认、重传、窗口这四个概念，能把一次抓包里的重传和窗口变化读出来，就已经超过大多数人了。拥塞控制可以等到实际遇到性能问题时再深入。
工具方面，命令行三件套（ping、traceroute/tracert、dig/nslookup）加一个抓包工具，覆盖了日常八成以上的场景。剩下的mtr（结合 ping 和 traceroute，看每一跳的丢包率）、curl -v（看 HTTP 层细节）、ss（看连接状态）三个也值得花时间熟悉，都是排查时的主力。
最后说个我自己的体会：网络这东西，看十遍不如抓一次包。很多概念在文字上绕来绕去讲不清，但只要你在抓包结果里亲眼看到 SYN、SYN-ACK、ACK 三个包的时间戳差了 200 毫秒，你就永远记住 RTT 是什么了。所以别怕折腾，找台虚拟机，随便改改掩码、拔拔网线、抓抓包，把网络弄"坏"几次，比顺顺利利用十次学到的多得多。
