第4章 网络协议与故障排查：TCP/IP、HTTP、DNS、tcpdump、抓包分析
本章聚焦网络协议排查核心技能，覆盖TCP/IP状态机、HTTP请求链、DNS递归解析及tcpdump实战。面试中通常要求你从现象反推原因、展示抓包分析路径和协议细节理解。以下内容帮助你建立结构化回答框架，应对故障排查类问题。
面试问答卡片
| 面试问题1：tcpdump抓到一个TCP重传，你怎么排查根因？ |
| 面试官考察点 | 是否理解重传触发条件、能区分丢包与延迟、会查看重传序列号和RTO计算。 |
| 回答框架 | 1.确认重传发起方（客户端VS服务端）→ 2.观察重传间隔（RTO是否指数退避）→ 3.检查对端是否回复了DupACK → 4.结合网络层判断是丢包还是网络拥堵 |
| 简短示例回答 | 先看tcpdump显示[TCP Retransmission]，检查序列号一致。若对端无DupACK则为发送方定时器超时，常见于链路丢包或服务端负载高；若收到3个DupACK则触发快速重传，需排查中间设备丢包或TCP窗口收缩。 |
| 可能追问 | RTO怎么计算的？怎样区分重传是丢包还是延迟？快速重传和超时重传的触发条件差别？ |
| 避坑提醒 | 不要只回答“看丢包”，要具体说明重传类型、序列号模式、对端ACK行为。避免只说抓包命令参数而忽略分析逻辑。 |
| 面试问题2：描述一次HTTP请求从输入URL到页面显示的完整DNS解析过程，并说明可能出现的故障。 |
| 面试官考察点 | 是否完整理解递归/迭代、缓存层、CNAME、TTL、DNS劫持等，并能结合故障案例。 |
| 回答框架 | 1.浏览器 → 本地DNS缓存 → 2.递归DNS解析根/HOSTS → 3.迭代查询权威服务器 → 4.返回A/AAAA记录 → 5.故障点：缓存污染、上游超时、递归被劫持 |
| 简短示例回答 | 先查本地hosts和浏览器DNS缓存，未命中则向递归DNS请求。递归DNS从根→.com → example.com权威获取A记录。常见故障是递归服务器缓存了过期或错误记录（如DNS劫持），导致指向错误IP，可用dig +trace逐级验证。 |
| 可能追问 | 怎么看DNS响应被篡改？TTL设置过小有什么影响？如何做DNS压测？ |
| 避坑提醒 | 不要只背诵流程，要指出实际故障场景（比如递归查询超时导致解析缓慢）。举例时描述具体抓包过滤条件（dns.port==53）。 |
| 面试问题3：服务端出现大量TIME_WAIT或CLOSE_WAIT，如何用tcpdump定位并解决？ |
| 面试官考察点 | 是否理解TCP状态机、主动/被动关闭区别、netstat与tcpdump结合手段、内核参数优化。 |
| 回答框架 | 1.用netstat统计状态分布 → 2.抓包过滤src/dst特定连接 → 3.检查FIN/ACK序列 → 4.判断哪端主动关闭 → 5.调整内核参数（TIME_WAIT复用、CLOSE_WAIT检查应用未关闭连接） |
| 简短示例回答 | 若服务端大量TIME_WAIT，tcpdump显示服务端先发FIN，常见于压测短连接场景，可开启net.ipv4.tcp_tw_reuse和tcp_tw_recycle(内核4.12前)。CLOSE_WAIT则被动方未调用close，tcpdump显示接收到FIN后无后续，需检查应用层连接泄漏。 |
| 可能追问 | tcp_tw_recycle为何被废弃？如何区分正常TIME_WAIT和异常？大量CLOSE_WAIT如何定位具体进程？ |
| 避坑提醒 | 避免直接给优化参数而不解释原理。要强调先确认状态根源再改参数，否则可能引入连接复用导致数据错乱。 |
项目案例实战：电商大促连接池耗尽故障排查
| 项目名称 | 大促期间Redis连接池耗尽导致接口超时10倍增长 |
| 业务背景 | 电商秒杀场景，应用层通过JedisPool读写Redis，高峰时接口P99从30ms飙升至300ms，部分连接被拒绝。 |
| 规模指标 | 每日峰值QPS 8万，Redis连接池最大200，并发线程500+，机器8C16G * 10台 |
| 技术栈 | Java (Spring Boot) + Jedis + Redis Cluster + tcpdump + Wireshark + 阿里云SLB |
| 核心难点 | 1. 表面现象是超时，但无法区分是网络丢包、Redis慢查询还是连接池等待；2. 连接池耗尽后新建连接会被拒绝，但机器资源未打满。 |
| 面试高频追问 | ① 你怎么判断连接池耗尽而非Redis本身慢？② tcpdump抓包时看到大量SYN_SENT和RST，能说明什么？③ Jedis连接池maxTotal与maxWaitMillis如何关联优化？ |
| 可迁移回答话术 | “先看应用日志连接池等待超时异常，配合tcpdump过滤目标Redis端口，发现客户端发出SYN后收到RST——说明服务端拒绝连接，证明连接池已满。然后调整maxTotal根据QPS*RT计算，同时开启连接保活避免被动断开。这种路径适用于一切连接池耗尽场景，包括数据库连接池和HTTP连接池。” |
💡 备考提示： 面试官常让你“手写”一条tcpdump过滤命令。务必掌握tcpdump -i eth0 host 10.0.0.1 and port 6379 -w dump.pcap，并配合tshark或wireshark分析。项目案例中的“连接池耗尽+SYN收到RST”为高频考题，建议作为STAR素材反复演练。