网络高压追问与抓包实战#

一、TCP 连接管理深追

SYN 队列与 Accept 队列：

Client SYN → [SYN Queue (半连接队列)] → Server SYN+ACK → Client ACK
  → [Accept Queue (全连接队列)] → accept() 取出

SYN Flood 防护：

• 攻击原理：大量伪造源 IP 的 SYN 包填满 SYN 队列
• 防护1：tcp_syncookies=1（不分配 SYN 队列资源，用 cookie 验证）
• 防护2：调大 SYN 队列 + 加快 SYN 超时淘汰
• 防护3：网络层防火墙/IDS 过滤

TIME_WAIT 堆积：

• 原因：主动关闭方进入 TIME_WAIT，持续 2MSL（通常60s）
• 影响：端口耗尽导致无法建新连接
• 排查：ss -s | grep TIME-WAIT 或 netstat -an | grep TIME_WAIT | wc -l
• 解决：tcp_tw_reuse=1（重用 TIME_WAIT 连接）+ 连接池复用 + 长连接

二、TLS 握手与证书链排查

TLS 1.2 握手（2-RTT）：
  Client Hello (支持的密码套件) →
  ← Server Hello + Certificate + Server Key Exchange + Server Hello Done
  Client Key Exchange + Change Cipher Spec + Finished →
  ← Change Cipher Spec + Finished

TLS 1.3 握手（1-RTT）：
  Client Hello (密钥共享参数) →
  ← Server Hello + Certificate + Finished
  Finished →

证书链验证失败排查：

# 查看证书链
openssl s_client -connect example.com:443 -showcerts

# 常见错误：
# 1. 证书过期 → 检查 Not After 字段
# 2. 中间证书缺失 → 服务端没下发完整链
# 3. 域名不匹配 → SAN/CN 不包含请求域名
# 4. 自签证书 → 客户端信任库没有 CA 证书

三、HTTP/2 深追

HTTP/2 的 TCP 队头阻塞：

• HTTP/1.1：多个 TCP 连接(6个)，一个阻塞不影响其他
• HTTP/2：一个 TCP 连接，TCP 层丢包重传→所有 Stream 等待
• HTTP/3 解决方案：基于 QUIC(UDP)，每个 Stream 独立丢包重传

四、抓包实战

tcpdump 常用命令：

# 抓指定端口
tcpdump -i eth0 port 8080 -w capture.pcap

# 抓指定主机
tcpdump -i eth0 host 10.0.0.1 -nn

# 只看 SYN 包（排查连接建立问题）
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

# 只看 RST 包（排查连接异常断开）
tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'

Wireshark 分析技巧：

五、网络排障决策树

连接不上？
  ├─ ping 不通 → 检查网络/防火墙/路由
  ├─ ping 通但端口不通 → telnet/nc 测端口 → 服务没启动/防火墙
  └─ 端口通但连接超时 → 抓包看 SYN 是否有 SYN+ACK
       ├─ 无 SYN+ACK → 服务端 backlog 满 / SYN flood
       └─ 有 SYN+ACK → 客户端问题 / 中间设备

连接上但请求慢？
  ├─ DNS 解析慢 → dig/nslookup 测 DNS 响应时间
  ├─ TLS 握手慢 → curl -w "%{time_appconnect}" 看 TLS 耗时
  ├─ 首字节慢(TTFB) → 服务端处理慢
  └─ 传输慢 → 带宽/MTU/拥塞控制

网络排查我常用 tcpdump 抓包+Wireshark 分析。TCP 连接问题重点看两个队列：SYN 队列（半连接）和 Accept 队列（全连接），它们的大小由 tcp_max_syn_backlog 和 somaxconn 控制，高并发场景默认 128 太小必须调大。SYN Flood 攻击就是打满 SYN 队列，防护用 tcp_syncookies 避免分配资源。TIME_WAIT 堆积导致端口耗尽用 tcp_tw_reuse 复用连接加上长连接池。TLS 方面 1.2 是 2-RTT，1.3 优化到 1-RTT，证书验证失败常见原因是中间证书缺失或证书过期，openssl s_client 可以查看完整证书链。HTTP/2 最大的改进是多路复用，但引入了 TCP 层队头阻塞——一个 TCP 连接丢包重传时所有 Stream 都阻塞，HTTP/3 通过 QUIC 基于 UDP 每个 Stream 独立重传解决了这个问题。抓包实战上 tcpdump 抓 SYN/RST 标志位的包最常用，Wireshark 里 tcp.analysis.retransmission 过滤重传包能快速定位网络质量问题。

追问方向：

• “TCP 拥塞控制算法有哪些？”→ 四阶段：慢启动（指数增长）→ 拥塞避免（线性增长）→ 快重传（3 重复 ACK 立即重传）→ 快恢复（减半继续）；现代算法有 CUBIC（默认）和 BBR（Google）
• “Nagle 算法和延迟 ACK 的冲突？”→ Nagle 等凑大包才发、延迟 ACK 等数据一起确认，两者叠加导致小包场景延迟飙升；解决方案设置 TCP_NODELAY 关闭 Nagle
• “四层负载和七层负载区别？”→ L4 基于 IP:Port 转发不解析内容（LVS/F5，性能高），L7 基于 HTTP header/URL 路由能做更细粒度分流（Nginx/HAProxy）
• “Keep-Alive 和连接池区别？”→ Keep-Alive 复用单个 TCP 连接但请求仍是串行的，连接池管理多个 TCP 连接可并行处理多个请求

易错点：

• ❌ “HTTP/2 没有队头阻塞”——HTTP 层没有了，但 TCP 层引入了新的
• ❌ “TLS 1.3 是 0-RTT”——首次连接 1-RTT，只有恢复连接（PSK）才是 0-RTT
• ❌ “TIME_WAIT 用 tcp_tw_recycle 解决”——该选项在 NAT 场景有严重问题，Linux 4.12 已移除
• ✅ 排查口诀：先 ping 测连通、再 telnet 测端口、再 curl 测应用、最后 tcpdump 抓包