1、网络调试基础：网络调试的概念、常见网络调试工具介绍、网络调试的重要性
1.1 到底什么是网络调试？
网络调试，说白了就是给网络系统「看病」。
你想想看，网络不通、丢包、延迟高、断连……这些问题天天都在发生。网络调试就是一套方法论，帮我们定位问题根源，然后解决它。
我个人习惯把网络调试分成三个层次：
- 连通性调试——能不能通？
- 性能调试——通得怎么样？
- 稳定性调试——会不会断？
嗯，这三个层次是递进的。很多新手只做到第一层，觉得能 ping 通就完事了。我在项目中遇到过不少这样的案例——明明能 ping 通，业务却跑不起来。为什么？因为连通不代表可用。
核心观点：网络调试不是「试错」，而是「验证假设」。每次操作前，先问自己一句：我怀疑是什么问题？然后去证明或证伪它。
1.2 常见网络调试工具介绍
工具不在多，在于会用。我这些年用下来，真正高频使用的也就那么几个。咱们一个一个说。
1.2.1 ping —— 最基础的「心跳检测」
ping 用的是 ICMP 协议。它能告诉你两件事：目标是否可达，以及往返时延大概多少。
ping 8.8.8.8 -c 10
# 输出示例
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=11.8 ms
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 11.5/12.1/13.2/0.5 ms我的小技巧：不要只看「通不通」，要看「丢包率」和「时延抖动」。丢包率超过 1% 就要警惕了。我曾经排查过一个视频卡顿问题，ping 了 1000 个包，发现丢包率 0.3%，但时延抖动高达 50ms——问题就出在这里。
1.2.2 traceroute —— 看数据包走了哪条路
ping 只能告诉你终点的情况。但网络问题往往出在中间节点。traceroute 就是干这个的。
traceroute www.baidu.com
traceroute to www.baidu.com (183.232.231.172), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 1.234 ms 1.198 ms 1.165 ms
2 10.0.0.1 (10.0.0.1) 3.456 ms 3.421 ms 3.389 ms
3 61.148.3.1 (61.148.3.1) 8.901 ms 8.876 ms 8.845 ms
4 * * *
5 183.232.231.172 (183.232.231.172) 15.234 ms 15.198 ms 15.165 ms看到第 4 跳的星号了吗？那可能是节点不响应 ICMP，也可能是真的丢包。怎么判断？多跑几次。如果每次都卡在同一个节点，那大概率是那里有问题。
注意：有些运营商节点会主动丢弃 ICMP 包，这不代表网络不通。我曾经被这个坑过——查了半天，结果是正常的。所以 traceroute 的结果要结合其他工具一起看。
1.2.3 netstat / ss —— 查看本机网络状态
这两个工具能告诉你：本机开了哪些端口、建立了哪些连接、处于什么状态。
# 查看所有监听端口
ss -tlnp
# 输出示例
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))
LISTEN 0 128 [::]:80 [::]:* users:(("nginx",pid=5678,fd=6))嗯，这里要注意：Recv-Q 和 Send-Q 这两个字段很多人不看。如果 Recv-Q 一直不为零，说明应用层没来得及收数据——可能是程序卡住了。
1.2.4 tcpdump —— 网络抓包利器
前面几个工具都是「看表象」。tcpdump 能让你「看本质」——直接看网络包的内容。
# 抓取 80 端口的 HTTP 请求
tcpdump -i eth0 -nn 'tcp port 80' -c 100
# 抓取特定 IP 的通信
tcpdump -i eth0 -nn 'host 192.168.1.100'我的经验：tcpdump 是网络调试的「终极武器」。很多 ping 和 traceroute 看不出来的问题，一抓包就原形毕露。比如 TCP 重传、窗口满、三次握手失败……这些在包级别一目了然。
1.2.5 其他常用工具一览
| 工具 | 用途 | 一句话总结 |
|---|---|---|
| nslookup / dig | DNS 解析排查 | 域名能不能解析成 IP？ |
| curl / wget | HTTP 请求测试 | 服务端能不能正常响应？ |
| iperf | 带宽测试 | 链路到底能跑多快？ |
| mtr | traceroute + ping 合体 | 一路看过去，哪跳有问题？ |
| Wireshark | 图形化抓包分析 | tcpdump 的 GUI 版，更直观 |
1.3 网络调试的重要性
说实话，很多人觉得网络调试是「出了问题才做的事」。这个想法很危险。
我举个例子。有一次上线一个新系统，上线前没做网络压测。结果上线当天，用户一多，服务端大量 TIME_WAIT 连接堆积，端口被占满，新连接进不来。整个系统瘫痪了 40 分钟。
事后复盘，其实用 netstat 看一眼就能发现端倪。但当时没人做这个「调试」动作。
网络调试的重要性，我总结为三点：
- 缩短故障恢复时间——会调试的人，10 分钟定位问题；不会的人，可能折腾半天。
- 预防潜在风险——很多问题在爆发前是有征兆的。比如丢包率缓慢上升、连接数持续增长……调试能帮你提前发现这些信号。
- 提升系统性能——调试不只是修 bug，还能优化。比如调整 TCP 参数、优化路由策略，这些都能让系统跑得更快。
我的建议：把网络调试当成日常习惯，而不是应急手段。每天花 5 分钟看看关键链路的延迟和丢包率，比出问题后再熬夜排查要划算得多。
1.4 本章小结
这一章咱们聊了网络调试的基本概念，认识了几个核心工具：ping、traceroute、netstat、tcpdump。也聊了为什么网络调试这么重要。
说白了，网络调试就是网络工程师的「听诊器」。你不会用，就只能在表面打转；你会用了，就能看到网络内部的真实状态。
下一章，咱们会深入讲抓包分析。到时候我会拿一个真实的故障案例，一步步带你走一遍完整的调试流程。嗯，那个案例挺有意思的，到时候细说。
一句话记住本章：网络调试不是玄学，是科学。工具是死的，思路是活的。先怀疑，再验证，最后下结论。