网络协议梳理这件事，很多人第一反应是"这有什么好梳理的，四层模型、七层模型，书上写得明明白白"。我早年也这么想，直到某次线上接口成片超时，前端说请求没到，后端说没收到包，网络组说链路是通的，三方各自拿着自己的日志都说自己没问题。最后抓到包才发现，是中间一段隧道的 MTU 比预想的小，大包被丢了，小请求正常、大请求超时，症状看起来像"偶发",其实是"必然"。那次之后我养成了一个习惯：不管接手什么系统，先做一遍网络协议梳理，把这条链路上每一层跑的什么协议、谁在改包、谁在丢包，用一张表说清楚。这篇就把我这套梳理办法摊开讲讲，包括分层怎么切、参数怎么算、抓包怎么看、坑都在哪儿。
1. 先把协议栈的骨架立起来
1.1 按数据流向梳理，别按协议名背清单
我见过不少人的"协议梳理"是一张名词表：以太网、ARP、IP、ICMP、TCP、UDP、DNS、HTTP、TLS，一列排下来，看着挺全，真出事一个都用不上。原因很简单，协议名是静态名词，排障需要的是动态路径——你得知道一个字节从应用缓冲区出来之后，先被谁套了一层头，再被谁改了一次，最后在哪个环节可能被扔掉。
所以我做梳理的第一个动作，永远不是列协议，而是画一条数据流：客户端应用 → 本机协议栈 → 网卡 → 交换机 → 路由器/网关 → 中间设备 → 服务端网关 → 反向代理 → 应用进程。这条线上的每一跳，我都会问三个问题：这一跳处理的是哪一层？这一跳会不会改写报文？这一跳出问题时的表现长什么样？三问答完，协议自然就挂上去了，而且挂上去的是"有用的协议"，不是"词典里的协议"。
顺着这条思路，我把整个协议栈拆成三条主线，后面所有细节都往这三条线上挂：
- 寻址线：我从哪来、到哪去。以太网 MAC、ARP、IP 地址、子网掩码、路由表、NAT 转换，全归这条线。这条线断了，表现是"根本不通"。
- 连接线：两端能不能对上话。TCP 握手、端口、监听队列、TLS 握手、DNS 解析，全归这条线。这条线断了，表现是"连不上"或"连得慢"。
- 可靠性线：话有没有说完整。序列号、确认号、重传、窗口、拥塞控制、分片重组，全归这条线。这条线断了，表现最恶心——"通，但慢，或者偶尔失败"。
这三条线的好处是，你拿到任何一个故障现象，都能先落到某条线上，再往下钻具体协议，而不是从协议清单的第一行开始一个个排除。下面这张表是我自己常用的对照表，故障现象和层级的映射基本都在里面：
| 现象 | 大概率所在层 | 首先怀疑的协议/机制 | 第一手工具 |
|---|---|---|---|
| 完全 ping 不通 | 链路层 / 网络层 | ARP、VLAN、路由、安全组 | ip neigh、ip route |
| 能 ping 通但端口连不上 | 传输层 | 监听未起、防火墙、连接队列满 | ss -lntp、telnet |
| 连得上但很慢 | 传输层 / 应用层 | 窗口过小、重传、DNS 慢 | ss -ti、抓包 |
| 小请求正常大请求超时 | 网络层 | MTU / 分片 / PMTUD | ping -M do -s |
| 偶发 502 / 连接被重置 | 传输层 / 代理层 | TIME_WAIT、keepalive、空闲超时 | ss -s、代理日志 |
| 首字节慢但传输快 | 应用层 | DNS、TLS 握手、慢查询 | curl -w分段计时 |
1.2 一次请求到底被套了几层壳
光说分层还是抽象，我更愿意用"套娃"这个说法。你在应用层写下一个GET /api/user，它出门的时候是这样的：应用层先给它加上 HTTP 头，变成一段文本；TLS 层再给这段文本加上 5 字节记录头和加密后的负载；TCP 层加 20 字节头（不含选项），带上源端口、目的端口、序列号；IP 层加 20 字节头，带上源 IP、目的 IP、TTL；以太网层加 14 字节头，带上源 MAC、目的 MAC，尾部再加 4 字节 FCS 校验。
每一层的开销我都建议你亲手算一遍，因为很多"带宽不够"的错觉，其实是头部开销吃掉的。以一个典型的 HTTPS 小请求为例：HTTP 头假设 300 字节，TLS 记录头 5 字节加 MAC/AEAD 标签 16 字节，TCP 头 20 字节，IP 头 20 字节，以太网头 14 字节加 FCS 4 字节，合计额外开销 79 字节。如果业务负载只有 200 字节，那有效载荷占比不到 60%。这也解释了一个常见现象：同一套服务，改成 HTTPS 之后 QPS 掉了几个点，不是加密算不动，是每个包都变胖了，包数量没变但总字节数涨了。
反过来，大文件传输时头部开销可以忽略，真正卡脖子的是别的东西——窗口够不够大、有没有丢包触发拥塞控制降速、路径 MTU 是不是被某个隧道压小了。所以我在梳理时会按"小包场景"和"大包场景"分开看，这两类问题的排查路径几乎不重叠，混在一起想只会越想越乱。
提示：算头部开销的时候别忘了 TCP 选项。带上时间戳选项（很多系统默认开）TCP 头就是 32 字节而不是 20 字节，MSS 也会跟着少 12 字节。抓包看到的
tcp.len和你以为的不一样，八成就是这个原因。
1.3 梳理最终要产出三张能用的表
我做一次完整的网络协议梳理，最后会沉淀三样东西，缺一样都算没做完。
第一张是链路协议清单：从客户端到服务端，每一跳跑的什么协议、什么端口、谁维护、有没有加密。这张表看着朴素，但新人接手时的价值极高，很多"这个端口为什么开着"的疑问，查表就有答案。
第二张是关键参数表：MTU、MSS、TCP 窗口、keepalive 时间、各类超时时间、DNS TTL、TLS 版本与套件。参数这东西最容易被忽略，因为平时它们不出声，一出事就是按秒计算的损失。我习惯把每一跳的 MTU 和超时都写进去，后来救过我好几次。
第三张是故障映射表：就是上面那张现象对照表，但要落成本系统的实际值。比如"连不上"对应到本系统，是安全组没放行还是连接队列满了，判断依据是什么、命令是什么。这张表是排障时的第一反应来源，写一次能用很久。
2. 链路层与网络层：那些决定上限的细节
2.1 MTU 1500 从哪来，MSS 又该怎么算
以太网默认 MTU 是 1500 字节，这个数字不是什么物理定律，是当年以太网规范定下的一个折中值——大到能摊薄头部开销，小到冲突检测的时隙还能算得过来。它被沿用至今，成了事实标准，也成了无数"大包不通"故障的源头。
MSS（最大报文段长度）是 TCP 层面的概念，它等于 MTU 减去 IP 头和 TCP 头：1500 - 20 - 20 = 1460。如果开了 TCP 时间戳选项，就是1500 - 20 - 32 = 1448。这个 1460 就是你在抓包里正常情况下能看到的最大单个 TCP 段负载。一旦链路中间有一段 MTU 比 1500 小，比如某些隧道封装会吃掉 20 到 60 字节，或者 PPPoE 吃掉 8 字节，那么一个 1460 字节的段到了那里就装不下，要么分片，要么被丢弃。
分片这件事很坑。IPv4 允许中间路由器分片，但很多设备出于性能考虑直接丢弃并回一个 ICMP "需要分片"消息，这就是路径 MTU 发现（PMTUD）机制。问题在于，如果这个 ICMP 消息在中间被拦掉了（现实里非常常见），发送方永远收不到通知，就会一直重传那个大包，表现就是"握手成功、小请求成功、一传大数据就卡死"。这个现象有个专门的名字叫 PMTU 黑洞。
我排查这类问题的标准动作是这样：
# 逐步加大包大小并禁止分片，找到能通过的最大值 ping -M do -s 1472 <目标IP> # 1472 + 8(ICMP头) + 20(IP头) = 1500 ping -M do -s 1400 <目标IP> ping -M do -s 1200 <目标IP>能通的最大-s值加上 28 就是这条路径的实际 MTU。如果 1472 不通但 1400 通，说明中间有东西把 MTU 压到了 1428 左右，这时候要么在隧道的两端把 MSS 钳制下来（iptables -t mangle -A FORWARD -p tcp --syn -j TCPMSS --clamp-mss-to-pmtu），要么直接在应用层把单次写入的数据块控制在安全范围内。
注意：MSS 钳制只对 TCP 有效，UDP 大包照样会碎。如果你的服务里有基于 UDP 的协议（视频、DNS over UDP、自研的实时通信），必须自己在应用层做分片，别指望网络层帮你兜底。
2.2 ARP 与邻居表：同网段通信的隐形前置条件
同一个网段内的两台机器通信，光有 IP 是不够的，报文最终得靠 MAC 地址在链路上送达。ARP 干的就是"我知道你的 IP，你的 MAC 是多少"这件事。流程很简单：广播问一句"谁是 192.168.1.10"，对方单播回"我是，我的 MAC 是这个"，问的一方把结果缓存进邻居表。
这个机制本身没什么好讲的，但它在实际环境里制造的故障一点不少。容器化环境里尤其明显——如果容器网络的实现方式让 ARP 广播到不了该到的地方，或者邻居表项老化得太快，就会出现"间歇性不通"。表现是每隔一段时间有几秒钟的失败，然后自己恢复，日志里看不出任何异常。
我常用的两个检查命令：
ip neigh show # 查邻居表状态，看有没有 FAILED / INCOMPLETE arping -I eth0 192.168.1.10 # 主动探测，看响应延迟和丢包邻居表里出现INCOMPLETE说明发了 ARP 请求但没收到回应，这通常是二层隔离或者广播被限速。出现大量STALE是正常的，内核会惰性刷新，但如果一台机器上邻居表项数暴涨到几万条，那就要检查是不是有扫描行为或者网段划分不合理。
还有一个容易踩的坑：多网卡机器上 ARP 响应的源地址选择。默认行为下，内核可能用 A 网卡的地址去回应本该走 B 网卡的 ARP 请求，导致对端学到的 MAC 和预期不符，报文就跑到错误的网卡上去了。这个可以用arp_ignore和arp_announce两个参数来约束，但改之前一定要在测试环境验证，因为它们影响的是整机所有网卡的行为，改错了会让原本正常的链路也出问题。
2.3 IP 寻址、路由查找与 NAT 的副作用
IP 层最核心的两个动作是"查路由"和"改 TTL"。查路由用的是最长前缀匹配——路由表里有10.0.0.0/8和10.1.0.0/16两条时，去往10.1.2.3的包会走后者，因为前缀更长更具体。这个规则听起来理所当然，但实际出故障时经常有人搞混，尤其是在有多条默认路由或者策略路由的环境里。
我在梳理时会重点确认三件事：默认路由指向哪里、有没有策略路由规则（ip rule show）、有没有多路径负载均衡。策略路由是最容易被遗忘的一块，因为它不体现在常规的ip route输出里，但一旦存在，报文可能完全不走你预期的路径。有次排查一个"部分请求走到了错误后端"的问题，最后发现就是一条遗留的策略路由规则，按源端口取模分流，把一小部分流量引到了老集群。
NAT 则是另一类麻烦。SNAT 让内网机器共享出口地址，代价是连接跟踪表（conntrack）成为有状态资源。表满了之后新连接直接建不起来，报错是"cannot allocate memory"或者干脆静默丢包。检查方式：
sysctl net.netfilter.nf_conntrack_count sysctl net.netfilter.nf_conntrack_max conntrack -S # 看各状态的统计和插入失败计数conntrack -S里的insert_failed如果持续增长，基本可以确定表满了或者有冲突。调大上限只是治标，更该做的是看看到底是谁在制造大量短连接，很多时候根源是某个服务的连接池配置不当，或者有个定时任务在不停地建连断连。
2.4 ICMP 不只是 ping 工具
很多人把 ICMP 当成"ping 用的"，实际上它是 IP 层的信使，承载了大量诊断信息。目的不可达、TTL 超时、需要分片、参数错误，这些消息都是 ICMP 送回来的。你把 ICMP 全禁掉，换来的是网络变得"哑"——出问题没有任何反馈，只能靠猜。
TTL 超时消息是traceroute的实现基础，它靠逐跳递增 TTL 来探测路径。如果中间设备不回 ICMP，traceroute就会显示一堆星号，路径就断了线索。这种情况下可以换用基于 TCP 或 UDP 的探测方式，很多现代实现都支持指定协议和端口，绕过纯 ICMP 的限制。
在梳理时我会特别记录一条：这条链路上 ICMP 是被放行、限速还是丢弃。放行最好；限速要记下限速阈值，因为高并发探测时可能触发限速导致误判；丢弃就得准备好替代方案，比如提前在两端部署主动探测，靠业务层面的心跳来判断连通性。
3. 传输层：参数、状态与那些算得出来的上限
3.1 握手挥手状态机与实际观测
TCP 建连三次握手、断连四次挥手，这个流程谁都能背。但排障时真正有用的是状态机——每个状态代表什么、卡在哪个状态说明什么问题。我把常打交道的状态整理成下面这张表，配的是我在实际环境里最常看到的成因：
| 状态 | 含义 | 卡在这里通常说明 |
|---|---|---|
| LISTEN | 服务端在监听 | 正常 |
| SYN_SENT | 客户端已发 SYN，等回应 | 对端没收到，或被防火墙丢弃 |
| SYN_RECV | 服务端收到 SYN 并回了 SYN-ACK | 半连接队列压力大，或 SYN 被泛洪 |
| ESTABLISHED | 连接已建立 | 正常 |
| FIN_WAIT_1 | 主动关闭方发了 FIN | 对方迟迟不回 ACK，可能应用卡住 |
| FIN_WAIT_2 | 收到对方 ACK，等对方 FIN | 对方应用没关连接，典型资源泄漏 |
| CLOSE_WAIT | 被动关闭方收到 FIN，尚未 close | 应用层没有正确关闭，代码问题 |
| LAST_ACK | 被动方发了 FIN，等最后 ACK | 短暂状态，长期存在不正常 |
| TIME_WAIT | 主动关闭方等待 2MSL | 正常，量大需关注端口 |
CLOSE_WAIT是我最关注的一个。它长期大量存在，几乎百分之百是应用代码的问题——收到了对方的关闭请求，但没有调用 close 释放。这个状态不受任何内核参数影响，调参数是白费力气，只能改代码。而TIME_WAIT完全相反，它是主动关闭方的正常状态，量大是结果不是原因，去"消灭"它往往会把问题变复杂。
关于队列，还有两个参数值得记：半连接队列（tcp_max_syn_backlog）和全连接队列（somaxconn与 listen 的 backlog 取小值）。全连接队列溢出时，内核默认行为是静默丢弃第三次握手的 ACK，客户端会以为连接建立成功然后发数据收不到回应，表现极其诡异。检查方式是看ss -lnt输出里的Send-Q列，以及netstat -s | grep -i listen里的溢出计数。
3.2 窗口、带宽延迟积与吞吐上限的算法
传输层的性能上限是可以算出来的，这一点很多人不知道，导致优化时全凭感觉。核心公式只有一个：
吞吐上限 = 窗口大小 / RTT
反过来，要打满某条链路需要的窗口是：
窗口 = 带宽 × RTT，这个乘积叫带宽延迟积（BDP）。
举个具体例子。假设链路带宽 1Gbps，往返时延 40ms。BDP = 1Gbps × 0.04s = 40Mbit = 5MB。也就是说，接收窗口至少要 5MB，这条链路才可能跑满。而很多系统的默认接收缓冲区只有几百 KB，实际能达到的吞吐就被死死压在几十 Mbps，你怎么优化应用代码都没用。
# 看当前连接的窗口和重传情况 ss -ti dst <目标IP> # 相关内核参数 sysctl net.ipv4.tcp_rmem # 接收缓冲区 最小/默认/最大 sysctl net.ipv4.tcp_wmem # 发送缓冲区 sysctl net.core.rmem_max输出里的cwnd（拥塞窗口）和rtt是最关键的两个值，用cwnd / rtt就能估算出这条连接当前的实时吞吐上限。如果发现cwnd一直上不去，说明要么在丢包触发了拥塞控制降窗，要么受限于接收方通告的窗口。
提示：调大缓冲区不是无脑越大越好。缓冲区过大会让"缓冲区膨胀"问题更严重——排队的数据变多，延迟升高，实时业务的体验反而变差。对延迟敏感的服务，宁可窗口小一点、丢包少一点，也不要为了吞吐把缓冲堆到几十 MB。
3.3 重传、RTO 与拥塞控制的实际影响
丢包之后的重传策略直接决定了应用的体感。TCP 有两套重传触发机制：超时重传（RTO）和快速重传。RTO 是基于 RTT 估算出来的，有最小值限制，Linux 上一般是 200ms 起，初始值 1 秒。快速重传靠的是重复 ACK，收到三个重复 ACK 就立刻重传，不用等 RTO 到期。
这两者的差别在抓包里非常明显：一次超时重传至少带来几百毫秒的停顿，而快速重传通常只带来一个 RTT 的额外延迟。所以当你看到某个接口的 P99 延迟总是集中在几百毫秒这个档位，第一反应就该去看有没有超时重传。
# 统计重传情况 netstat -s | grep -i retrans ss -ti | grep -E "retrans|rto"retrans计数持续增长说明链路在丢包，rto值突然变大说明 RTT 估算被打乱了。如果重传率超过 1%，任何应用层优化都是徒劳，得先解决链路问题。
拥塞控制算法这块，现在主流的两个选择是 CUBIC 和 BBR。CUBIC 基于丢包判断拥塞，在有随机丢包的链路上会过度降速；BBR 基于带宽和 RTT 建模，对随机丢包不敏感，在高延迟长肥管道上优势明显。切换方式：
sysctl net.ipv4.tcp_congestion_control # 查看当前 sysctl -w net.ipv4.tcp_congestion_control=bbr但 BBR 不是万金油。它在有深缓冲的网络里可能挤占其他流的带宽，在多租户环境下要慎重。我自己的经验是：内网同机房用默认的 CUBIC 就够了，跨地域长链路再考虑 BBR，而且一定要做 A/B 对比，别一上线就全量切。
3.4 TIME_WAIT 与端口耗尽的定量分析
这是传输层被误解最深的一块。先把结论摆出来：TIME_WAIT是主动关闭方的正常状态，作用是保证最后一个 ACK 能到达、让旧连接的残余报文在网络中消散，防止它们污染新连接。它存在是有道理的，不是"系统的毛病"。
问题出在量上。假设一台机器作为客户端，每条连接都是它主动关闭，那么每条连接都会占用一个本地端口进入TIME_WAIT，持续 60 秒（Linux 的 2MSL 默认值）。可用端口范围默认是 32768 到 60999，大约 28000 个。那么理论上每秒能建立的新连接上限是：
28000 / 60 ≈ 466 次/秒
超过这个量，就会出现"无法分配请求的地址"报错。注意这个上限还受四元组限制——同一个目标 IP 加目标端口下，能用的源端口就只有这些。
应对思路有几条，我按推荐程度排：
- 改成长连接。这是治本的办法，尤其是内部服务之间，用连接池复用，别每次请求都新建连接。
- 让服务端主动关闭。谁主动关闭谁承担 TIME_WAIT，把这个负担转移到连接数更少的服务端，通常更合理。
- 扩大端口范围。
net.ipv4.ip_local_port_range调大到 1024-65535，能提升三四倍上限，成本极低。 - 开
tcp_tw_reuse。注意这个参数只对出站连接有效，而且需要开启时间戳选项配合，本质是复用那些"安全"的 TIME_WAIT 端口。它对服务端的入站连接毫无帮助。 - 绝对不要动
tcp_tw_recycle。这个参数在新版本内核里已经被移除，老版本上开启它会在 NAT 环境下造成大量连接失败，属于典型的"优化出故障"。
注意：很多人把
tcp_fin_timeout当成缩短 TIME_WAIT 的参数，这是错的。它控制的是 FIN_WAIT_2 状态的持续时间，跟 TIME_WAIT 没有关系。改它不但解决不了端口耗尽，还可能让半关闭的连接更快被回收，引发别的问题。
3.5 UDP 与 QUIC：什么时候该换车
UDP 本身极简：无连接、不保证顺序、不重传、不做拥塞控制，头部只有 8 字节。它的价值就在于"什么都不管"，把控制权完全交给应用层。DNS 查询、实时音视频、游戏状态同步、监控数据上报，这些场景要么数据小到不值得建连，要么丢了也无所谓，要么应用自己有更好的补偿策略，用 UDP 是合适的。
真正值得单独说的是 QUIC。它跑在 UDP 之上，但在用户态实现了可靠传输、拥塞控制、加密握手，把 TCP 那套机制重新做了一遍，还顺带解决了几个历史包袱：建连只需 0 到 1 个 RTT、连接迁移不受 IP 变化影响、没有 TCP 层的队头阻塞。对于移动端和弱网场景，收益是实打实的。
但换协议的成本别低估。QUIC 走 UDP，意味着中间设备对 UDP 的处理策略会直接影响它——有些环境对 UDP 限速甚至直接封禁，有些负载均衡器不支持 UDP 转发。我的建议是：先在灰度环境验证整条链路对 UDP 的友好度，再决定要不要切；同时保留 TCP 回退能力，别把鸡蛋放一个篮子里。
4. 应用层协议：差异、选型与那些默认值陷阱
4.1 DNS 解析链路与缓存层级
DNS 是整个请求链路的第一步，也是最容易被忽略的一步。一次完整的解析要经过：浏览器缓存 → 操作系统缓存 → 本地 DNS 服务器 → 根服务器 → 顶级域服务器 → 权威服务器。每一层都有自己的 TTL，实际生效的缓存时间取最短的那个。
我梳理 DNS 时重点关注三件事。第一是解析耗时，首次解析可能要几十到上百毫秒，如果每次请求都触发解析，累积起来很可观。第二是缓存行为，很多运行时环境有自己的 DNS 缓存，比如某些语言的虚拟机会缓存解析结果，改了 DNS 记录之后不重启进程就是不生效，这个坑我踩过不止一次。第三是多记录与故障转移，一个域名配多条 A 记录时，客户端拿到的是全部还是部分、失败后会不会换一条，不同实现差别很大。
dig +trace example.internal # 从根开始追溯解析路径 dig @8.8.8.8 example.internal # 指定 DNS 服务器查询 dig +short example.internal # 只看结果容器环境里还要多看一层/etc/resolv.conf，里面的search域和ndots设置会让某些域名多解析好几次。默认ndots:5意味着域名里的点数少于 5 个时，会先尝试拼接 search 域，失败后再试绝对域名——一个简单的服务名可能触发四五次查询，每次几十毫秒，加起来就是明显的延迟。
4.2 HTTP 三个版本的差异与选择
HTTP/1.1 的核心问题是队头阻塞：同一个连接上，前一个请求没响应完，后一个就得等着。浏览器靠开多个连接缓解，但连接数有限，且每个连接都要独立握手。
HTTP/2 引入了多路复用，一个连接上并行跑多个流，还做了头部压缩（HPACK）和服务器推送（推送后来基本被弃用了）。但它的多路复用建立在 TCP 之上，一旦底层丢包，所有流都被阻塞，这叫 TCP 层队头阻塞。丢包率高的链路上，HTTP/2 的表现可能还不如 HTTP/1.1 开多个连接。
HTTP/3 把传输层换成了 QUIC，彻底绕开了这个问题，还支持 0-RTT 恢复和连接迁移。代价是 UDP 链路的兼容性风险和一部分中间设备的支持度。
| 维度 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 传输层 | TCP | TCP | QUIC(UDP) |
| 多路复用 | 无（靠多连接） | 有 | 有 |
| 队头阻塞 | 应用层有 | TCP 层有 | 基本消除 |
| 头部压缩 | 无 | HPACK | QPACK |
| 建连开销 | 1 RTT + TLS | 1 RTT + TLS | 0-1 RTT |
| 中间设备兼容 | 最好 | 好 | 需验证 |
我的实践结论是：内部服务之间 HTTP/1.1 加连接池完全够用，别为了"先进"去上 HTTP/2，多路复用带来的复杂度在低延迟内网里收益有限。对外的移动端接口、跨地域调用，HTTP/2 或 HTTP/3 的收益才明显。切换之前一定要确认负载均衡、网关、WAF 这些中间环节的支持情况。
4.3 TLS 握手、证书链与常见配置错误
TLS 握手是 HTTPS 请求里除 DNS 之外最容易被忽视的耗时点。TLS 1.2 完整握手需要两次往返，TLS 1.3 压到一次，会话复用时甚至可以做到 0-RTT。对于高频短连接，握手成本占比很高，所以会话复用（session ticket 或 session ID）必须开。
# 查看握手过程和耗时 openssl s_client -connect example.internal:443 -servername example.internal -tls1_3 # 只看证书链和有效期 echo | openssl s_client -connect example.internal:443 2>/dev/null | openssl x509 -noout -dates -subject常见的配置问题有这么几类。证书链不全是最高频的，服务端只配了站点证书没配中间证书，浏览器能自动补全所以看不出问题，但很多客户端和 SDK 不会补，直接握手失败。时间不同步导致证书校验失败的案例也不少，机器时钟漂移几分钟就可能让有效期校验挂掉。SNI 未配置则会在多域名共用同一 IP 的架构下返回错误证书。
提示：验证证书链完整性最靠谱的办法是关掉本地根证书缓存去连，或者用一个干净的客户端环境测。本地能通不代表线上能通，这类问题在测试环境极难复现。
4.4 长连接与推送协议怎么选
需要服务端主动推数据时，可选方案有 WebSocket、SSE、MQTT、gRPC 流这么几种，选型不能只看"哪个火"，要看场景的约束。
| 方案 | 底层 | 方向 | 适合场景 | 主要限制 |
|---|---|---|---|---|
| WebSocket | TCP（HTTP 升级） | 双向 | 交互式应用、协同编辑 | 需处理断线重连、心跳 |
| SSE | HTTP | 服务端到客户端 | 通知、日志流、进度推送 | 单向，HTTP/1.1 下占连接 |
| MQTT | TCP | 双向（发布订阅） | 物联网、弱网设备 | 需要 Broker，协议栈较重 |
| gRPC 流 | HTTP/2 | 双向 | 服务间流式调用 | 依赖 HTTP/2，浏览器支持有限 |
选了长连接就绕不开三个问题：心跳间隔怎么定、断线怎么重连、连接数怎么控制。心跳太频繁浪费资源，太稀疏则发现不了中间设备的空闲超时。我的经验值是心跳间隔要比链路上最短的空闲超时小一截，比如负载均衡 60 秒断空闲连接，心跳就设 30 秒，留出一倍余量。重连要做指数退避，不然服务端重启的瞬间会被所有客户端的重连请求打垮。
5. 抓包与排障实操：把梳理落到现场
5.1 工具分工与常用参数
工具不在多，在于知道什么时候用哪个。下面这张表是我日常的主力配置：
| 工具 | 主要用途 | 典型命令 |
|---|---|---|
ss | 看本机连接状态、窗口、队列 | ss -lntp、ss -ti dst x.x.x.x |
tcpdump | 抓包，适合服务器端 | tcpdump -i eth0 -nn port 80 -w a.pcap |
| Wireshark | 分析包，看时序和重传 | 图形化，配合 IO 图看吞吐 |
dig | DNS 解析排查 | dig +trace、dig +short |
curl | 端到端耗时分析 | curl -w分段计时 |
mtr | 逐跳丢包与延迟 | mtr -rwzbc 100 <目标> |
openssl s_client | TLS 握手细节 | 见上文 |
curl的分段计时特别值得单独讲，因为它能一次性把 DNS、TCP、TLS、首字节、总耗时都拆开，定位速度快得惊人：
curl -o /dev/null -s -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.internal/health各项之间做差就能知道瓶颈在哪：tcp - dns是 TCP 握手耗时，tls - tcp是 TLS 握手耗时，ttfb - tls是服务端处理耗时，total - ttfb是传输耗时。哪一段异常，就往哪一层深挖。
5.2 一次"大包必超时"的完整排障记录
说个我印象最深的案例，整个过程能体现梳理的价值。
现象：某项目的文件上传接口，小文件（几十 KB）100% 成功，超过 200KB 的文件 100% 超时，报错是读取超时，不是连接失败。服务端日志里能看到请求进来，但没有完整接收记录。
第一轮假设：应用层的读取超时设得太短。检查配置，读取超时 30 秒，200KB 的文件正常几百毫秒就该传完，排除。
第二轮假设：服务端接收缓冲区太小。查了tcp_rmem，默认值和最大值都不算小，而且连接建立后窗口能涨上去，排除。
第三轮：抓包。在服务端抓包，看到一个非常清晰的特征——客户端发到 1448 字节的包之后，后续的包服务端一个都没收到，客户端在不停重传同一个序列号，重传间隔从 200ms 一路涨到几秒，最后客户端放弃。
这个特征指向两个可能：丢包，或者路径 MTU 不匹配。接着做验证：在客户端往服务端发带 DF 标志的大包，发现 1472 字节不通，1400 字节通，1300 字节通。到这里基本确定了——链路上有一段 MTU 小于 1500，大包被丢弃，而 ICMP 的"需要分片"消息没有回传，客户端不知道要减小 MSS，陷入死循环。
根因：客户端和服务端之间加了一层隧道封装，隧道头占用了额外字节，实际 MTU 降到 1400 左右。但客户端和服务端的网卡 MTU 还是 1500，双方协商出来的 MSS 是 1460，超出实际路径能力。
解决：在网关的出方向做 MSS 钳制，把 SYN 包里的 MSS 选项改写成 1360，给隧道留足余量。改完之后大文件上传立刻恢复正常，重传计数归零。
沉淀：这件事之后我把"路径 MTU 探测"加进了上线前检查清单，凡是跨网段、跨云、加了隧道封装的链路，一律先测一遍实际 MTU。
5.3 常见问题速查表
下面这些是我这些年反复遇到的，按现象整理，配上判断依据和处理方向，能覆盖大部分日常场景：
| 现象 | 判断依据 | 处理方向 |
|---|---|---|
| 大量 CLOSE_WAIT | ss -s里该状态计数持续增长 | 查应用代码，确认是否漏了 close |
| 端口耗尽报错 | ss -s显示 TIME_WAIT 占满端口范围 | 上连接池、扩端口范围、改主动关闭方 |
| 连接建立但无响应 | 全连接队列溢出计数增长 | 调大 backlog，优化慢处理逻辑 |
| 偶发几百毫秒延迟 | ss -ti里 retrans 增长 | 查丢包，看是不是拥塞控制过度降速 |
| 首字节慢、传输快 | curl -w里 ttfb 占比大 | 查服务端处理、DNS、TLS 握手 |
| 解析偶发失败 | dig多次查询结果不一致 | 查多记录、TTL、本地缓存 |
| 长连接被莫名断开 | 空闲超时时间与心跳间隔对比 | 心跳间隔缩到超时的一半 |
| 证书校验失败 | openssl s_client报链不完整 | 补中间证书、校时 |
| 同网段不通 | ip neigh出现 INCOMPLETE | 查二层隔离、ARP 限速、VLAN 配置 |
| 隧道后吞吐骤降 | BDP 计算 vs 实际窗口 | 调缓冲区、确认窗口缩放已开启 |
5.4 我自己的梳理清单
最后把我每次接手新系统都会过一遍的清单放出来，都是踩过坑之后加进去的，顺序就是排查时的优先级：
- 确认实际 MTU：跨网段、有隧道的链路必测，记下安全值，写进配置。
- 确认 DNS 解析路径和 TTL：含容器内
resolv.conf的ndots和search。 - 确认连接建立方式：长连接还是短连接，连接池大小，有没有 keepalive。
- 确认各层超时时间：客户端、负载均衡、网关、应用，取最短的那个作为实际约束。
- 确认窗口和缓冲区：按 BDP 算一遍，看默认值够不够。
- 确认拥塞控制算法：跨地域长链路重点看，必要时做 A/B。
- 确认 TLS 版本与证书链：用干净客户端验证，别信本地。
- 确认中间设备对 ICMP 和 UDP 的策略：影响 PMTUD 和 QUIC 可用性。
- 确认重传率和丢包率基线：有个基线，异常时才能对比出来。
- 把上面九项写进文档：不写下来，三个月后自己都忘了。
我个人在实际操作中的体会是，网络协议梳理最大的价值不在于"懂多少协议"，而在于遇到问题时知道先看哪一层、用什么命令验证、看到什么现象对应什么原因。协议细节可以现查，但这套"从现象到层级到命令"的映射关系，只能靠自己一遍遍排障积累。上面那些表和清单，就是我这些年积累下来的东西，你可以直接拿去改成自己系统的版本，比从头摸索要省不少时间。
