作为一名运维工程师，日常工作中最令人头疼的莫过于各种网络故障。在过去一年半的运维生涯中，我积累了丰富的网络故障排查经验，今天就来和大家分享一下如何运用抓包工具（Wireshark、tcpdump）和网络排查工具（nc、lotop、telnet、ping、ss、nslookup）来解决实际问题。
一、项目背景：那些年，我们一起追过的网络故障
在运维的日常任务中，网络故障可谓五花八门：应用层报错、链路延迟、丢包，甚至部分服务不可达。记得有一次，用户反馈网站访问异常，我通过抓包工具发现数据包在防火墙出口处被丢弃，而另一边的 TCP 握手数据包显示连接一直处于半开状态。经过一番排查，最终确定问题出在防火墙策略更新后端口映射配置遗漏。从那以后，我便开始深入研究各类抓包和网络诊断工具，并在实际工作中不断总结经验。
二、抓包工具的应用：Wireshark 与 tcpdump 的实战
2.1 案例一：tcpdump 捕捉异常连接，揪出网络丢包元凶
在一次故障排查中，某个业务服务器无法与后端数据库建立稳定连接，我怀疑是网络层丢包导致。于是，我在服务器上使用 tcpdump 进行抓包，命令如下：
[root@server ~]# tcpdump -i eth0 -nn -s 0 -w capture.pcap其中，-i eth0 指定网卡接口，-nn 禁止将 IP 地址和端口号解析成域名和服务名，-s 0 抓取整个数据包，-w capture.pcap 将抓包结果保存到文件。
抓包完成后，我在 Wireshark 中打开 capture.pcap 文件，利用过滤器 tcp.port==3306（假设数据库使用 3306 端口），发现明显的 TCP 重传和连接中断情况。进一步检查防火墙日志，果然有部分数据包被丢弃。
小结：利用 tcpdump 抓包后再结合 Wireshark 进行详细分析，是定位网络问题的高效方法。tcpdump 命令简单灵活，可以快速捕获网络数据，而 Wireshark 的图形化界面则能让故障原因一目了然。
2.2 案例二：Wireshark 剖析 HTTP 异常，解决负载均衡配置问题
公司某业务接口返回异常，初步怀疑是中间网络设备引起的数据包重组问题。我在业务服务器上直接抓包，用 Wireshark 分析 HTTP 协议报文，发现有少量 HTTP 请求重复发送，且响应时间异常高。经过深入分析，原来是上游负载均衡配置不当，导致部分请求重复转发。调整配置后，问题顺利解决。
小结：Wireshark 提供了强大的协议解析能力，能帮助我们直观定位问题，并给出修改建议。
三、网络排查工具的应用：多工具协同作战，精准定位故障
在抓包之外，我们常用一些网络排查工具来进一步确认问题，下面分别介绍 nc、lotop、telnet、ping、ss、nslookup 的基本用法和真实案例。
3.1 Netcat (nc)：万能网络工具，测试端口连通性的利器
基本用法： Netcat 是一个万能的网络工具，可以用于测试端口连通性、传输文件等。常用参数：
-
-z：仅扫描指定端口，无数据传输 -
-v：显示详细输出
案例：测试服务端口是否开放 有次排查中怀疑某服务端口不通，我使用如下命令：
[root@server ~]# nc -zv 192.168.1.100 8080
Connection to 192.168.1.100 8080 port [tcp/*] succeeded!成功的提示让我确认该服务端口是开放的，再进一步排查应用层问题。
3.2 Lotop：实时监控网络流量，揪出异常流量元凶
基本用法： Lotop 是一款实时监控网络流量的工具（类似 iftop、nethogs），可以直观显示各进程的流量情况。启动后可实时监控网络带宽占用。
案例：排查异常流量 有次服务器突然网络带宽异常占满，我使用 lotop 后发现某个进程持续占用大量流量，经调查是异常日志采集脚本循环上传错误数据。及时停止进程后，网络恢复正常。
[root@server ~]# lotop
-- 实时流量监控启动 --
PID Process TX(KB/s) RX(KB/s)
1234 log_uploader 1200 300
5678 nginx 50 80
...3.3 Telnet：简单直接的 TCP 连接测试工具
基本用法： Telnet 常用于测试 TCP 连接，简单直接：
telnet 192.168.1.100 22如果能成功连接，则端口开放。
案例：验证远程 SSH 可用性 在一次远程维护中，我需要确认目标服务器 SSH 服务是否正常。执行如下命令：
[root@server ~]# telnet 192.168.1.105 22
Trying 192.168.1.105...
Connected to 192.168.1.105.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.4显示 SSH 协议版本后，说明服务正常。
3.4 Ping：检测目标主机连通性，观察延迟情况
基本用法： Ping 用于检测目标主机是否连通，同时可观察延迟情况：
ping -c 4 8.8.8.8-c 指定发送次数。
案例：判断网络延迟 某次用户反馈访问外部服务延迟较高，我通过 ping 命令发现丢包率达 30%，经排查发现上游链路存在问题。此时我及时通知了网络供应商。
[root@server ~]# ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=25.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=30.1 ms
...3.5 SS：高效显示网络连接信息，检查异常连接状态
基本用法： ss 工具用于显示网络连接信息，比 netstat 更高效。常用参数：
-
-t：显示 TCP 连接 -
-u：显示 UDP 连接 -
-l：仅显示监听状态 -
-n：不解析服务名
案例：检查异常的连接状态 一次出现 TCP 连接堆积问题时，我使用如下命令查看当前连接状态：
[root@server ~]# ss -tunl
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:*
tcp LISTEN 0 100 0.0.0.0:22 0.0.0.0:*
...通过查看，我发现有大量异常连接堆积在某个端口上，经进一步确认是应用层没有及时关闭连接，调整后问题解决。
3.6 Nslookup：DNS 查询，测试域名解析是否正常
基本用法： Nslookup 用于 DNS 查询，可以测试域名解析是否正常：
nslookup www.example.com案例：域名解析错误 有次内部服务无法通过域名访问，我通过 nslookup 检查后发现 DNS 服务器返回的 IP 地址不正确。经过检查 DNS 配置后，更正后问题得到解决。
[root@server ~]# nslookup www.example.com
Server: 192.168.1.2
Address: 192.168.1.2#53Non-authoritative answer:
Name: www.example.com
Address: 93.184.216.34四、故障排查中的问题与思考：经验总结，让运维更高效
在一年半的运维实践中，最常遇到的难题往往是故障定位不准确。通过使用上述工具，我总结了几点经验：
-
多工具互补：抓包工具适合数据层细查，而 telnet、ping 等工具则快速验证网络连通性；ss 和 nc 可以进一步验证端口和进程状态。结合使用能更快定位问题。
-
日志与数据包同步：在排查过程中，总要和系统日志、应用日志相结合，确认是否存在策略更新、应用异常等因素。
-
学习与积累：每次故障处理后，我都会总结经验，建立一份常见故障及处理方案的文档，以便快速响应类似问题。这不仅提高了解决问题的效率，也让我对网络协议和各工具的使用有了更深的理解。
五、总结：掌握工具，提升团队响应速度与解决能力
本文结合真实案例，从抓包工具（Wireshark、tcpdump）和网络排查工具（nc、lotop、telnet、ping、ss、nslookup）的角度，分享了如何在日常运维工作中排查网络问题。作为一名一年半经验的运维工程师，亲身经历的案例让我深刻体会到，熟练掌握这些工具不仅能帮助我们快速定位问题，还能提升整个团队的响应速度和解决能力。
希望这篇文章能对大家在遇到网络问题时提供一些思路和帮助，也欢迎大家留言讨论更多实际案例和心得体会。
)
