企业官网建设流程全解析

1. 先把账算清楚：这套模型为什么长成四层

1.1 从一次线上卡顿说起，分层不是课本概念

几年前我处理过一次很典型的故障：某个内部服务响应时间从 80ms 突然涨到 2 秒，运维第一反应是应用代码有问题，开发说是数据库慢，DBA 说数据库指标一切正常，三方互相甩锅甩了两天。最后我用mtr跑了一遍，发现中间某一跳丢包率 3%，重传把延迟拖上去了，跟代码一行关系都没有。这件事让我彻底改变了对TCP/IP 网络模型的看法——它从来不是拿来应付面试的背诵材料，而是一套责任划分坐标系。有了它，你才能在故障现场快速判断"这件事该由谁负责查"，而不是几十号人一起瞎猜。

这篇文章我想把 TCP/IP 网络模型彻底拆开讲：四层各自负责什么、边界在哪里、封装解封装过程中哪些细节会咬人、怎么用抓包和内核状态把抽象模型"看见"、以及真出问题时按什么顺序排查。不管你是刚学网络的在校生，还是已经写过几年业务代码但对底下这层始终一知半解的开发者，或者是被线上超时折磨过的运维，我都尽量给到能直接上手复现的东西。

一个前置说明：下面所有实验环境、IP、端口、抓包记录都是我在本地虚拟环境里搭出来的模拟场景，数据为演示方便做过调整，你复现时数值不会完全一样，但结构和现象是一致的。

1.2 OSI 七层与 TCP/IP 四层的真实关系

教科书上先讲 OSI 七层——物理、数据链路、网络、传输、会话、表示、应用。这套模型是国际标准化组织在 1980 年代推的，理论上很漂亮，但它输掉了市场。原因不复杂：会话层和表示层在工程实现里根本划不清界限。你告诉我 TLS 属于哪一层？它做加密，像表示层；它管连接建立和会话恢复，像会话层；但它又实打实是一个应用层协议，跑在 TCP 之上。再比如 JSON 序列化，算表示层还是应用层？没人说得清。

TCP/IP 模型干脆不纠结，只分四层：网络接口层、网络层、传输层、应用层。教学时为了讲清楚物理介质和链路协议的区别，通常把最底下拆成物理层和数据链路层，凑成五层。我个人的习惯是讲原理用五层、做排障用四层，因为排障时你根本不需要区分"这是网线的问题还是网卡驱动的问题"，统一归到"链路层以下"就行，反正查的手段差不多。

记住一句话：模型是用来划责任的，不是用来分类的。当你纠结某个协议该算哪一层时，说明你已经在钻牛角尖了，实际工程里只要知道"它跑在哪一层的协议之上"就够了。

1.3 分层真正带来的两个价值：变更隔离与坐标定位

分层最核心的收益是变更隔离。你换一块万兆网卡，不需要改 HTTP 服务器的一行配置；你把 HTTP/1.1 升级到 HTTP/2，不需要动路由表；你把内网从 IPv4 双栈切到 IPv6 单栈，Web 框架代码基本不用改。每一层只暴露稳定的接口给上层，内部怎么实现随便换，这是整个互联网能持续演进的根本原因。如果没有这套抽象，每换一次底层技术就要重写全部上层应用，谁都受不了。

第二个价值是坐标定位。任何一个网络问题，你都可以先问："它属于哪一层？" ping 不通 = 网络层及以下；ping 通但端口连不上 = 传输层或对端没监听；端口通但返回 500 = 应用层。这个判断能直接把排查范围砍掉 70%。我在带新人的时候，第一课永远是让他们把这句话背下来，因为绝大多数人出问题时的第一反应是"重启一下试试"，而不是"先确定问题在哪一层"。

2. 逐层拆开看：每一层到底在解决什么问题

2.1 网络接口层：帧、MTU 和那些被忽略的物理约束

最底下这层负责把一串二进制变成一个能在物理介质上传输的信号，再把相邻两台设备之间的数据搬运过去。这一层的关键词是帧和MTU。以太网的标准 MTU 是 1500 字节，意思是单个以太网帧能承载的载荷上限。这个数字不是随便定的，是当年以太网和硬件成本妥协的结果，几十年过去了一直没变，成了整个互联网的隐形地基。

一个完整的以太网帧结构是：目的 MAC 6 字节 + 源 MAC 6 字节 + 类型 2 字节 + 载荷（46 到 1500 字节）+ FCS 校验 4 字节。头部固定开销 14 字节，尾部 4 字节，再加上帧间间隔和前导码，实际在物理介质上传输的开销比这个还多一点。这意味着你传输 1500 字节的 IP 包，实际在线上跑的是 1518 字节甚至更多。做带宽估算时必须把这块开销算进去，否则算出来的理论值和实测值永远对不上。

这一层还有两个绕不开的机制：ARP和MAC 地址表。IP 包要发出去，必须知道下一跳的 MAC 地址，ARP 就是干这个的——广播问"谁是这个 IP"，对应设备单播回"我是，我的 MAC 是 xxx"。这个机制简单有效，但也带来了广播风暴和 ARP 欺骗的问题。交换机内部维护 MAC 地址表，记录哪个 MAC 在哪个端口上，收到帧就按表转发，不知道就往所有端口泛洪。整个局域网的转发逻辑就建立在这张表上。

注意：MTU 不一致是极其常见的隐形杀手。链路中间有一台设备 MTU 是 1400，两端都是 1500，大包过不去又没有任何提示，表现为"能 ping 通、能建立连接、一传大文件就卡死"。这种问题不看抓包根本发现不了。

2.2 网络层：IP 的无状态与"尽力而为"的代价

网络层的主角是 IP 协议，它的设计哲学可以用八个字概括：无连接、尽力而为。它不保证送达、不保证顺序、不保证不重复，只负责一件事——把包从源地址送到目的地址，中间经过哪些路由器它不管。这个设计在当时看是激进的，因为同时期的其他网络方案（比如虚电路）都在追求可靠性。但历史证明这个选择是对的：把可靠性做进网络层，意味着每个中间节点都要维护状态，成本极高且脆弱；把可靠性推到端点，网络核心就能保持简单、可扩展。

IP 包头部固定 20 字节（不含选项），关键字段包括：版本号（4 位）、首部长度（4 位）、总长度（16 位）、标识/标志/片偏移（用于分片）、TTL（8 位，每经过一个路由器减 1，减到 0 就丢弃并回 ICMP 超时）、协议号（8 位，标识上层是 TCP=6 还是 UDP=17）、首部校验和、源 IP、目的 IP。TTL 这个字段顺便成就了traceroute这个工具——它靠逐步递增 TTL 让沿途路由器依次返回 ICMP 超时消息，从而画出路径。

分片是这一层最容易被忽视的细节。当一个 IP 包超过链路 MTU 时，路由器要么分片、要么丢弃。IPv4 允许中途路由器分片，IPv6 则强制要求端到端做路径 MTU 发现（PMTUD），中途路由器一律不分片。这个差异导致 IPv6 环境下 PMTUD 失败会直接表现为黑洞——包被静默丢弃，没有任何反馈。实际运维中，防火墙把 ICMP 全禁掉是 PMTUD 失效的头号原因，因为 PMTUD 依赖 ICMP "需要分片"消息回传。

2.3 传输层：TCP 和 UDP 的分工不是"可靠 vs 不可靠"

传输层是整个模型里最复杂的一层，因为它要在不可靠的 IP 之上变出各种花样。核心是两个协议：TCP和UDP。很多人把它们的区别简化成"可靠 vs 不可靠"，这个说法对但不完整，容易误导。真正的区别在于控制权在谁手里：TCP 把流控、重传、拥塞控制全包了，应用只需往里写字节；UDP 什么都不管，应用自己决定怎么处理丢包和乱序。

TCP 提供的是字节流抽象，注意不是"消息流"。这意味着你write()两次 100 字节，对方可能一次read()到 200 字节，也可能分三次读到。所有"TCP 粘包"的问题本质上都是应用层设计错误——TCP 根本没有包的概念。想划分消息边界，要么在应用层加长度前缀，要么用分隔符，要么直接上现成的协议框架。

UDP 提供的是数据报抽象，保留消息边界，但可能丢、可能乱序、可能重复。它适合的场景比很多人想的要多：DNS 查询（一问一答，自己重试）、实时音视频（丢一帧无所谓，卡顿才要命）、游戏同步状态（新状态覆盖旧状态，重传旧数据毫无意义）、QUIC（在 UDP 上重新实现一套可靠传输，绕开内核协议栈的僵化）。

2.4 应用层：协议设计者的自留地

应用层是模型里最自由的一层，因为它没有统一标准，每个协议自己定规矩。HTTP、DNS、SSH、SMTP、MQTT、Redis 协议，统统在这层。这层的关键能力是定义语义：请求是什么、响应是什么、错误怎么表达、状态怎么保持、版本怎么协商。

这一层最容易被轻视，因为看起来"就是个文本协议"。但恰恰是这里的设计决定了系统的可扩展性。举个具体的例子：HTTP/1.1 的队头阻塞问题，本质是应用层协议设计导致的——同一个连接上请求必须串行，前一个响应没回来后一个就得排队。HTTP/2 用二进制分帧和多路复用解决了连接级队头阻塞，但 TCP 层的丢包仍然会阻塞整个连接的所有流，于是才有了基于 UDP 的 QUIC。你看，一次应用层的性能优化，最终逼着传输层都换了实现。

应用层还有一个常被忽略的责任：超时和重试策略。TCP 有自己的重传超时，但那是针对单个报文的，应用层的"整个请求多久没响应就放弃"完全是应用自己定的。这两个超时如果不协调，会出现很尴尬的情况：应用层 3 秒超时放弃了，但 TCP 连接还在那儿重传，连接池里的槽位被占着，最终导致连接耗尽。这类问题我在生产环境里见过不止一次。

3. 封装与解封装：一个请求的完整旅程

3.1 头部开销的精确计算与 MSS 的由来

理解封装最直观的方式是算一遍头部开销。假设你在浏览器里发一个 HTTPS 请求，数据往下走的过程是这样的：

应用层产生 HTTP 报文，假设 500 字节。到传输层，加上 TCP 头 20 字节（不带选项），变成 520 字节。到网络层，加上 IP 头 20 字节，变成 540 字节。到链路层，加上以太网头 14 字节和 FCS 4 字节，变成 558 字节。如果算上帧间间隔 12 字节和前导码 8 字节，物理线路上实际传输 578 字节。为了提高 500 字节的有效载荷，你付出了 78 字节的开销，占比 13.5%。这个比例在小包场景下更夸张：一个 1 字节的 telnet 按键，实际在线路上跑 1 + 20 + 20 + 18 + 20 = 79 字节，有效载荷率 1.3%。这就是为什么高频小包场景（比如某些游戏协议、金融行情推送）要拼命做批量合并。

更关键的是MSS（最大报文段长度）的计算。MSS 是 TCP 载荷的最大值，等于 MTU 减去 IP 头和 TCP 头的长度：

MSS = MTU - IP头(20) - TCP头(20) = 1500 - 40 = 1460 字节

如果是 IPv6 环境：

MSS = 1500 - 40(IPv6固定头) - 20(TCP头) = 1440 字节

这个 1460 不是配置出来的，是算出来的，而且只在三次握手时通过 MSS 选项协商一次。双方各自宣告自己期望接收的 MSS，实际发送时取较小值。如果链路中间有 MTU 更小的设备，理论上应该通过 ICMP 通知发送方，但现实中这个通知经常被防火墙拦掉，于是就有了 MTU 黑洞问题。

提示：如果你遇到"SSH 能连上、命令能敲、但scp传大文件卡住"这种诡异现象，八成就是 MTU 不匹配。用ping -M do -s 1472 目标IP逐步缩小包长，能快速定位实际可用 MTU。1472 + 20(IP) + 8(ICMP) = 1500，这是以太网 MTU 下能 ping 的最大载荷。

3.2 从curl到网卡：一次请求的逐层还原

我在实验环境里做了一次完整追踪，用curl请求一个 HTTPS 地址，同时在客户端抓包。整个过程可以分成几个阶段：

第一阶段是域名解析。浏览器或 curl 先查本地缓存和 hosts 文件，没有就发 DNS 查询。DNS 默认走 UDP 53 端口，一次问答就完事，响应超过 512 字节（或者启用了 EDNS0 更大）时会切到 TCP。这一步发生在应用层，但用的传输层协议是 UDP。

第二阶段是TCP 三次握手。拿到 IP 之后，客户端选一个临时端口（Linux 默认范围 32768 到 60999）发起连接。这里有个细节：临时端口的选择是内核随机挑的，不是顺序分配，目的是降低被猜测的风险。握手完成后连接进入 ESTABLISHED 状态。

第三阶段是TLS 握手（HTTPS 才有）。这一步在 TCP 之上完成证书验证、密钥协商，通常需要 1 到 2 个 RTT。TLS 1.3 把这一步压缩到 1-RTT，还支持 0-RTT 恢复，这是它相比 1.2 最实际的收益。

第四阶段才是真正的 HTTP 请求。请求报文被 TCP 切成不超过 MSS 的段，加上序号，交给 IP 层；IP 层查路由表决定下一跳，加上 IP 头；链路层查 ARP 缓存拿到下一跳 MAC，封装成帧发给网卡；网卡做 DMA 传输，把帧变成电信号或光信号发出去。

整个下行的过程是封装，上行的过程是解封装。每一层剥掉自己的头，把载荷交给上层。这个过程中任何一层的头部损坏或校验失败，都会被丢弃，且大多数情况下不会通知上层——这就是"沉默丢包"的来源。

4. 动手实操：把抽象的模型抓到眼前

4.1 最小实验环境搭建

我用的环境是两台虚拟机加一台做路由的机器，模拟客户端、服务端和中间链路。客户端 10.20.30.11，服务端 10.20.30.80，都用 Linux，装好tcpdump、ss、curl。为了能看清握手过程，服务端起一个最简单的监听：

# 服务端：监听 8443 端口，打印收到的内容 nc -l -p 8443 -k # 客户端：发起连接并发送一段文本 printf 'hello tcp model\n' | nc 10.20.30.80 8443

这个环境足够验证从链路层到应用层的完整路径。如果要做 MTU 相关的实验，把中间路由那一台的出口 MTU 调小：

# 在中间路由上把出口 MTU 改成 1400 ip link set dev eth1 mtu 1400 ip link show eth1 | grep mtu

改完之后用ping -M do -s 1400去测，你会发现 1400 载荷的包过不去（因为加上 28 字节 ICMP/IP 头超过 1428），但 1372 载荷的能过。这个实验做一遍，比看十篇文章都记得牢。

4.2 三次握手抓包：字段的每一个数字都有含义

在客户端执行抓包：

tcpdump -i eth0 -nn -vv -c 20 'tcp port 8443'

抓到的前三个包大致是这样：

14:22:31.102931 IP 10.20.30.11.51234 > 10.20.30.80.8443: Flags [S], seq 3141592653, win 64240, options [mss 1460,sackOK,TS val 88213 ecr 0,nop,wscale 7], length 0 14:22:31.103512 IP 10.20.30.80.8443 > 10.20.30.11.51234: Flags [S.], seq 2718281828, ack 3141592654, win 65160, options [mss 1460,sackOK,TS val 99312 ecr 88213,nop,wscale 7], length 0 14:22:31.103588 IP 10.20.30.11.51234 > 10.20.30.80.8443: Flags [.], ack 1, win 502, options [nop,nop,TS val 88213 ecr 99312], length 0

逐字段解读一下。第一行Flags [S]是 SYN 标志位，表示请求建连。seq 3141592653是初始序列号 ISN，这个值是随机生成的，不是从 0 开始，目的是防止连接被伪造。win 64240是接收窗口，表示"我最多能接收这么多字节"，注意这个值是内核根据接收缓冲区自动算出来的。options里的信息量最大：mss 1460是告诉对方"我期望你发的单个 TCP 载荷最大 1460 字节"；sackOK表示支持选择性确认；TS val是时间戳选项；wscale 7是窗口缩放因子，表示实际窗口 = 头部窗口值 × 2^7 = 64240 × 128，约 8MB。

第二行Flags [S.]是 SYN + ACK，服务端同意建连。它的ack是客户端的 seq + 1，表示"我收到了你的 SYN，下一个期望的序号是 xxx + 1"。同时服务端也提供自己的 ISN。双方都宣告了自己的 MSS、SACK、窗口缩放参数。第三行Flags [.]是纯 ACK，握手完成。

这里有一个新手最常困惑的点：为什么第三个包的ack显示是 1，而不是一个巨大的数字？因为 tcpdump 默认对序号做了相对化处理，把每个方向的第一个序号记作 0，后续显示相对值。想看绝对序号要加-S参数。我第一次看抓包时在这个问题上卡了半小时，一直以为自己的包被改了。

握手的本质是三件事的交换：确认双方收发能力（网通）、同步初始序列号（数据流标定起点）、协商参数（MSS、窗口缩放、SACK、时间戳）。少一次都不行。两次不够，因为无法确认客户端的接收能力和服务端的发送能力；四次多余，中间两步可以合并。

4.3 用ss和内核统计对照状态机

抓包看的是线上的物理事实，ss看的是内核里维护的连接状态，两者对照才能形成完整认知。常用命令：

# 查看所有已建立的 TCP 连接，显示进程 ss -tanp state established # 按状态计数，快速判断有没有异常堆积 ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn # 查看 TCP 重传统计 nstat -az | grep -i retrans

ss -tan输出的第一列是状态：ESTABLISHED、SYN-SENT、SYN-RECV、FIN-WAIT-1、FIN-WAIT-2、TIME-WAIT、CLOSE-WAIT、LAST-ACK、CLOSING。这十一个状态构成 TCP 状态机，每个状态对应一个特定阶段。运维排查时最常看的是几个：

• 大量 SYN-RECV：三次握手没走到第三步，典型是 SYN Flood 攻击或者服务端积压队列满了。
• 大量 TIME-WAIT：主动关闭方进入的状态，等 2MSL（Linux 默认 60 秒）后释放。高并发短连接服务上这很常见，一般不是问题，除非把临时端口耗尽了。
• 大量 CLOSE-WAIT：被动关闭方没调close()，这是应用层 bug，不是网络问题。看到这个先查代码。
• 大量 FIN-WAIT-2：对端不响应 FIN，可能是对端进程僵死。

配合内核统计看更准：

# 系统级 TCP 统计 netstat -s | grep -iE 'retrans|reset|overflow|drop'

输出里的segments retransmitted是全局重传次数，listen queue of a socket overflowed是 accept 队列溢出的次数。后面这个数字特别值得盯，非零说明应用 accept 太慢，新连接被内核丢了，表现就是客户端偶发连接超时，但服务端看着很闲。

5. TCP 可靠传输的三个核心机制与关键参数

5.1 序号、确认和窗口：可靠性的三根支柱

TCP 的可靠性建立在三个机制上：序号、确认、重传。序号给每个字节编号，让接收方知道有没有收全、有没有重复；确认号告诉发送方"这个位置之前的我都收到了"；超时没收到确认就重传。

但光有这三个会掉进一个陷阱：发送方发一个包等一个确认，吞吐量被 RTT 死死限制。所以要有滑动窗口。接收方在确认包里带上自己的接收窗口大小，意思是"你最多还能发这么多字节，不确认也能发"。发送方维护一个发送窗口，窗口内的数据可以连续发出，收到确认后窗口向右滑动。

窗口字段只有 16 位，最大 65535 字节。在早期网络里够用，但在高带宽长延迟链路（BDP 很大）上就不行了。于是有了窗口缩放选项，在握手时协商一个缩放因子，最大 14，实际窗口可达 65535 × 2^14 ≈ 1GB。

算一笔实际的账。假设带宽 1Gbps，RTT 40ms，那么：

BDP（带宽时延积）= 1 × 10^9 bit/s × 0.04 s = 4 × 10^7 bit = 5 × 10^6 字节 ≈ 4.77 MB

要让这条链路的吞吐跑满，接收窗口至少要 4.77MB，也就是 65535 × 2^7 = 8.4MB 才够。缩放因子至少要到 7。这就是为什么现代 Linux 默认开启窗口缩放，且wscale常常是 7 到 10。

注意：如果中间有老旧的中间设备改写了窗口字段却不懂缩放选项，会出现窗口协商错乱，表现为吞吐量被人为限制在很小值。这类问题极难排查，因为两端的ss都显示正常。只能靠抓包对比握手时的 wscale 和后续通信的实际窗口值。

5.2 拥塞控制与重传超时：那些"看起来慢"的现象

滑动窗口管的是接收方能力，拥塞控制管的是网络能力，两者是不同的东西。发送方能发多少 = min(接收窗口, 拥塞窗口)。拥塞窗口由拥塞控制算法动态调整，经历慢启动、拥塞避免、快重传、快恢复几个阶段。

Linux 的默认算法这些年换过：早期是 Reno，后来是 CUBIC（2.6.19 起），现在很多发行版提供 BBR 但默认仍是 CUBIC。CUBIC 的核心思路是用三次函数曲线控制窗口增长，在高带宽长延迟链路上比 Reno 收敛快得多。BBR 则完全换了思路，不靠丢包判断拥塞，而是估算瓶颈带宽和最小 RTT，主动把发送速率控制在估计值附近。在有随机丢包的链路上（比如跨国链路），BBR 优势明显，因为 CUBIC 会把随机丢包误判成拥塞从而保守降速。

重传超时（RTO）的计算也有讲究。不是简单的"RTT 加个固定值"，而是走 Jacobson/Karels 算法：

SRTT = (1 - 1/8) × SRTT + (1/8) × RTT RTTVAR = (1 - 1/4) × RTTVAR + (1/4) × |SRTT - RTT| RTO = SRTT + 4 × RTTVAR

这个公式的意思是：平滑 RTT 加权平均，再乘上抖动幅度的四倍作为安全边界。RTO 还有指数退避机制，超时一次翻倍，最多到 120 秒。所以你抓包看到的"第一次重传等 200ms，第二次 400ms，第三次 800ms"就是这个机制。

快速重传是另一个重要机制：收到三个重复 ACK 就立即重传，不用等 RTO 到期。这能大幅缩短恢复时间，因为丢一个包后面还有包到达，接收方会不停发重复 ACK 提示"我缺了中间那个"。

查看和调整这些参数：

# 查看当前拥塞控制算法 sysctl net.ipv4.tcp_congestion_control # 查看可用的算法 sysctl net.ipv4.tcp_available_congestion_control # 查看重传相关计数 nstat -az | grep -E 'TcpRetransSegs|TcpExtTCPTimeouts|TcpExtTCPSlowStartRetrans' # 查看接收/发送缓冲区范围（最小/默认/最大） cat /proc/sys/net/ipv4/tcp_rmem cat /proc/sys/net/ipv4/tcp_wmem

tcp_rmem和tcp_wmem这三个值很重要，中间那个是默认值，第三个是自动调整的上限。如果上限设得不够大，窗口缩放再大也没用，因为内核不会把缓冲区开到那么大。跨机房传输优化时，这两个参数是必调项。

5.3 四次挥手：为什么比握手多一次

关闭连接需要四次，根本原因是TCP 是全双工的。A 说"我没数据要发了"（FIN），B 回"知道了"（ACK），但此时 B 可能还有数据没发完，所以不能立刻关。等 B 也发完数据了，再发自己的 FIN，A 回 ACK，连接才算真正关闭。

主动关闭方在发完最后一个 ACK 之后会进入TIME-WAIT状态，等待 2MSL（Linux 上是 60 秒，MSL 定义为 30 秒）。这个状态不是为了"等对方收完数据"这么玄乎，而是两个非常实际的原因：一是保证最后一个 ACK 能到达，如果丢了对方会重发 FIN，此时还能响应；二是让本连接残留的旧报文在网络中彻底消失，避免影响下一个使用相同四元组的连接。

TIME-WAIT 堆积是高并发短连接服务的经典问题。粗算一下：如果ip_local_port_range是 32768 到 60999，可用端口约 28000 个，假设服务器主动关闭连接且维持 60 秒 TIME-WAIT，那么理论上的短连接上限就是 28000 / 60 ≈ 466 QPS。超过这个值就会遇到Cannot assign requested address报错。

解决思路有三条，各有代价：

我个人的建议是首选长连接。绝大多数高并发场景下，TIME-WAIT 堆积都是因为连接池没做好，而不是内核参数没调对。

6. 常见问题与排查技巧实录

6.1 分层排查法：一套能直接抄的顺序

出了问题不要慌，按层往下问，每一层用一个命令验证。这套流程我用了很多年，基本能做到 5 分钟内定位到大致范围。

第一步，确认本机网络配置。ip addr看 IP 有没有配上，ip route看默认路由在不在。这一步排除掉 30% 的低级问题——虚拟机没拿到 IP、路由被改、网卡没起来。

第二步，测网络层通不通。ping目标 IP。注意ping域名和pingIP 要分开测，前者顺带验证了 DNS，后者纯测网络。如果 IP 通域名不通，问题在 DNS；如果都不通，问题在网络路径。

第三步，测传输层端口通不通。nc -zv 目标IP 端口或者curl -v telnet://目标IP:端口。注意端口不通可能是三种情况：对端没监听、中间防火墙拦了、或者监听在 127.0.0.1 而不是 0.0.0.0。这三种表现一样，但排查方向完全不同，需要登录对端用ss -tlnp确认监听地址。

第四步，测应用层响应。curl -v -w '@curl-format.txt'看各阶段耗时。用-w输出time_namelookup、time_connect、time_appconnect、time_starttransfer这几个指标，能精确定位慢在哪一段。

第五步，抓包确认线上的真实情况。前面四步都是基于本机视角，抓包才能看到实际收发的每个字节。抓包时优先用过滤表达式减少数据量，比如tcp port 443 and host 10.20.30.80。

我把这套流程整理成了速查表：

6.2 四个我踩过的坑，每个都花了不少时间

坑一：抓包看不到握手，只有数据传输。有一次我抓包分析一个慢请求，只看到数据包，看不到三次握手。折腾半天才意识到是抓包开始得太晚，连接在抓包启动前就已经建立了。要抓握手必须先在客户端启动抓包，再发起连接。如果连接已经建立，想看数据就抓数据，想看握手只能杀掉连接重来。

坑二：netstat统计的重传次数很低，但实际感受很慢。这个问题的关键在于统计口径。netstat -s里的segments retransmitted是全局累计值，如果只重传了一两个包，在总量里完全看不出来，但这一两个包触发了 RTO 退避，延迟直接翻倍。判断方法是用ss -tin看单条连接的详情，它会把retrans、rtt、rttvar、cwnd、ssthresh都列出来，逐条看比看全局统计有用得多。

坑三：服务端一切指标正常，客户端却大量超时。排查到最后发现是中间设备的连接表满了。中间有状态设备（负载均衡、防火墙、NAT 网关）都维护连接表，表满了就丢新连接。表现是客户端超时，服务端日志里连个请求都没有。判断方法是看客户端抓包里有没有 SYN 发出、有没有 SYN+ACK 回来。如果 SYN 发出去了但没有回包，且服务端ss看不到 SYN-RECV，那就是中间设备丢了。

坑四：改了 MTU 参数，重启后失效。ip link set mtu是临时修改，重启就没了。持久化要写进网络配置文件（不同发行版位置不同），或者用 systemd-networkd / NetworkManager 的配置。我在这上面栽过，当时调完 MTU 测试一切正常，第二天重启完问题重现，查了半天以为是别人的改动。

6.3 几条不带技术含量但很省时间的经验

第一条，先确认时间戳对齐。跨机器排查时，各机器时间不一致会让你把因果搞反。我见过一次"服务端日志显示响应发出去了，客户端日志显示没收到"，最后发现客户端时间快了 3 秒，日志顺序全是乱的。动手前先date对一遍，或者干脆用同一台机器抓两端的包。

第二条，抓包文件先存下来再分析。很多人喜欢一边抓一边看，抓到关键信息时手忙脚乱。正确做法是-w存成 pcap 文件，然后用图形化工具慢慢分析。文件也别删，一个问题可能要看三四遍，每遍关注点不一样。

第三条，不要迷信"看起来正常"的指标。CPU 不高、内存充足、连接数不多，不代表没问题。有次一个服务平均延迟 5ms 但 P99 是 3 秒，平均值被大量快请求稀释了，看平均值永远发现不了。任何性能指标都要看分位数，至少看 P95 和 P99。

第四条，给每个现象准备一个可证伪的假设。排查最怕的是"我觉得应该是 xxx"。正确做法是先提出假设，再设计一个能证明假设错误的方法。比如怀疑是 MTU 问题，就构造大包去测，如果大包能过，假设就错了，别继续在这条路上耗。这个方法听着简单，但在真有压力的时候能救命，因为它强制你把猜测变成实验。

这套模型我用了很多年，最大的体会是：它真正的价值不在于你知道四层各叫什么，而在于出问题的时候你脑子里有一张图，知道数据从哪来、到哪去、在哪一层可能被卡住。这张图建立起来之后，看任何网络问题都会变得有条理。至于那些参数和命令，用的时候查一下就行，真正需要内化的是分层的思维方式和"先定位再动手"的习惯。