Wireshark网络分析与安全实战 第 5 篇：网络故障排查实战
摘要
本文将带你系统学习网络故障排查的方法论和实践技巧，帮助你建立结构化的故障排查思路。你将学习连接问题、性能问题、应用问题的诊断流程，掌握使用Wireshark快速定位问题根源的技巧。通过真实案例分析，你将能够将理论知识应用到实际工作中，高效解决各种网络问题。
学习目标
阅读完本文后，你将能够：
- 能力1：建立系统化的网络故障排查思路，从问题现象到根本原因
- 能力2：熟练诊断网络连接问题，快速定位 unreachable 网络的故障点
- 能力3：分析网络性能问题，识别延迟、丢包、吞吐量瓶颈
- 能力4：排查应用层问题，结合协议分析解决 Web、DNS 等应用故障
一、故障排查方法论
1.1 结构化排查流程
网络故障排查需要系统化的方法，避免盲目尝试。以下是一个通用的问题解决框架：
flowchart TD Problem[发现网络问题] --> Define[明确定义问题] Define --> Questions[回答关键问题] Questions --> Q1[谁受影响?] Questions --> Q2[什么时候开始?] Questions --> Q3[有什么症状?] Questions --> Q4[最近有变化吗?] Q1 --> Scope[确定问题范围<br>单个用户/多个用户/全网] Q2 --> Timeline[确定时间范围<br>突然发生/逐渐恶化/间歇性] Q3 --> Symptom[确定症状类型<br>完全不可达/性能下降/功能异常] Q4 --> Change[确定变更因素<br>配置更改/设备更换/软件更新] Scope --> Gather[收集数据] Timeline --> Gather Symptom --> Gather Change --> Gather Gather --> Hypothesis[提出假设] Hypothesis --> Test{测试假设} Test -->|是| Verify[验证修复] Test -->|否| Revise[修改假设] Revise --> Test Verify --> Document[文档化<br>问题和解决方案]
图表讲解：
这个故障排查流程图展示了系统化的问题解决方法。结构化的排查可以避免盲目尝试，提高效率。
明确定义问题是排查的第一步。问题定义越清晰，排查越有针对性。需要回答的关键问题包括：谁受影响（单个用户、部门、整个公司），什么时候开始（精确的时间点有助于查找相关变更），有什么症状（完全无法连接、速度慢、特定功能失败），最近有变化吗（配置变更、设备更换、软件更新）。
确定问题范围有助于定位故障层级。单个用户的问题可能是主机配置、网卡、网线问题。多个用户的问题可能是交换机、路由器、DHCP服务器问题。全网的问题可能是核心网络、互联网连接、防火墙问题。范围还可以按协议分类（只有Web慢、所有流量都慢），按时间分类（特定时段慢、一直慢），按方向分类（下载慢、上传慢、双向都慢）。
收集数据需要使用各种工具。ping测试基本连通性，traceroute/tracert查看网络路径，nslookup/dig测试DNS解析，Wireshark捕获详细流量。同时检查设备日志（syslog、事件查看器），收集用户报告（截图、错误消息、重现步骤）。
提出假设是基于收集的数据推测可能的原因。假设应该是可测试的，如”可能是交换机端口配置错误”或”可能是DNS服务器不可达”。测试假设需要设计实验验证，如更换网线、修改配置、切换DNS服务器。如果假设被证实，可以进入修复阶段。如果假设被否定，需要修改假设继续测试。
验证修复确保问题真正解决且没有引入新问题。观察一段时间确认问题不再出现，运行相关测试确认功能正常。最后文档化问题和解决方案，包括问题描述、根本原因、解决步骤、预防措施。文档化有助于知识积累和快速处理类似问题。
1.2 分层排查策略
网络是分层的，故障排查也应该从底层到高层逐层进行。
flowchart TD subgraph Layers["OSI分层排查策略"] direction TB L1[物理层<br>第1层] L2[数据链路层<br>第2层] L3[网络层<br>第3层] L4[传输层<br>第4层] L5[应用层<br>第5-7层] end Start[网络问题] --> Check1{物理层} Check1 -->|网线连接?| C1[检查网线/光纤<br>检查LED指示灯<br>测试线缆] Check1 -->|接口状态?| C2[检查接口状态<br>show interface<br>ipconfig/ifconfig] C1 --> OK1{正常?} C2 --> OK1 OK1 -->|否| Fix1[修复/更换物理层] OK1 -->|是| Check2{数据链路层} Check2 -->|MAC地址?| C3[检查ARP表<br>检查MAC地址表<br>检查VLAN配置] Check2 -->|交换机端口?| C4[检查端口状态<br>检查错误计数<br>检查 duplex 设置] C3 --> OK2{正常?} C4 --> OK2 OK2 -->|否| Fix2[修复二层配置] OK2 -->|是| Check3{网络层} Check3 -->|IP配置?| C5[检查IP地址<br>检查子网掩码<br>检查默认网关] Check3 -->|路由?| C6[检查路由表<br>测试路由<br>ping 网关] C5 --> OK3{正常?} C6 --> OK3 OK3 -->|否| Fix3[修复三层配置] OK3 -->|是| Check4{传输层} Check4 -->|端口?| C7[检查端口监听<br>netstat -an<br>检查防火墙] Check4 -->|连接?| C8[测试端口连通<br>telnet/nc<br>测试特定端口] C7 --> OK4{正常?} C8 --> OK4 OK4 -->|否| Fix4[修复四层配置] OK4 -->|是| Check5{应用层} Check5 -->|应用状态?| C9[检查服务运行<br>检查应用日志<br>测试应用功能] C9 --> OK5{正常?} OK5 -->|否| Fix5[修复应用层问题] OK5 -->|是| Solved[问题解决]
图表讲解：
这个分层排查图展示了从底层到高层逐层检查的方法。OSI模型提供了排查的理论框架，实际操作中可以简化为物理层、网络层、传输层、应用层的检查。
物理层检查是最基础的。网线是否插好，接口LED灯是否亮（绿色表示连接，橙色表示活动）。使用测试仪测试网线连通性。检查接口状态，Windows使用ipconfig /all查看接口状态，Linux使用ifconfig或ip addr show。Cisco设备使用show interface查看接口状态和错误计数。
数据链路层检查包括ARP和交换机配置。查看ARP缓存arp -a，确认能够解析网关MAC地址。查看交换机MAC地址表show mac address-table，确认端口学习正常。检查VLAN配置，确保设备在正确的VLAN。检查 duplex 设置（双工模式），mismatch（如一端全双工一端半双工）会导致大量错误。
网络层检查包括IP配置和路由。确认IP地址、子网掩码、默认网关配置正确。查看路由表route print（Windows）或route -n（Linux），确认有正确的路由。使用ping测试基本连通性：ping本地IP（测试协议栈）、ping网关（测试本地网络）、ping远程IP（测试路由）、ping域名（测试DNS）。
传输层检查关注端口和连接。使用netstat -an查看端口监听状态，确认服务端口在监听。检查防火墙规则，确认端口未被阻止。使用telnet IP port或nc -vz IP port测试特定端口连通性。如果可以ping通但无法连接端口，通常是防火墙或服务未运行。
应用层检查包括服务状态和功能。确认服务进程正在运行（如ps aux | grep httpd）。检查应用日志（如/var/log/httpd/error_log），查找错误信息。测试应用功能，如Web服务器返回200状态码，数据库服务器可以执行查询。
逐层排查的好处是不会遗漏，但效率可能不高。根据问题症状可以跳过某些层。如”完全无法连接”从物理层开始，“只有Web慢”直接从应用层开始。
二、连接问题诊断
2.1 完全无法连接
完全无法连接是指主机之间无法通信，ping超时，连接请求被拒绝。
诊断流程：
flowchart TD NoConn[完全无法连接] --> Step1[ping 127.0.0.1<br>测试本地协议栈] Step1 --> S1{成功?} S1 -->|否| Fix1[重新安装TCP/IP<br>重启计算机] S1 -->|是| Step2[ping 本地IP<br>测试网卡] Step2 --> S2{成功?} S2 -->|否| Fix2[检查网卡驱动<br>更换网卡] S2 -->|是| Step3[ping 网关<br>测试本地网络] Step3 --> S3{成功?} S3 -->|否| Check1{能ping通<br>其他本地主机?} Check1 -->|否| Fix3[检查交换机<br>检查VLAN] Check1 -->|是| Check2[网关配置错误<br>或网关故障] Step3 -->|是| Step4[ping 公网IP<br>8.8.8.8<br>测试互联网连接] Step4 --> S4{成功?} S4 -->|否| Check3[路由问题<br>或ISP问题] S4 -->|是| Step5[ping 域名<br>www.baidu.com<br>测试DNS] Step5 --> S5{成功?} S5 -->|否| Fix4[检查DNS配置<br>更换DNS服务器] S5 -->|是| Check4[连接正常<br>检查应用设置] Fix3 --> Capture[使用Wireshark<br>捕获ping流量] Check3 --> Capture Check2 --> Capture
图表讲解：
这个连接问题诊断流程展示了从本地到远程的逐步测试方法。完全无法连接需要系统性地定位故障点。
第一步测试本地协议栈。ping 127.0.0.1（回环地址）测试TCP/IP协议栈是否正常工作。如果失败，可能是TCP/IP协议损坏，需要重置协议栈或重启计算机。
第二步测试网卡功能。ping本地IP地址测试网卡是否正常发送接收数据。如果失败，可能是网卡驱动问题或网卡硬件故障。更新驱动、重新安装驱动、更换网卡可以解决。
第三步测试本地网络。ping网关（默认路由器）测试能否到达本地网络的出口。如果失败，可能是交换机问题、VLAN配置错误、网关故障。检查交换机端口状态（是否up、错误计数），检查VLAN配置（设备在正确VLAN），尝试ping其他本地主机确定范围。
第四步测试互联网连接。ping公网IP（如8.8.8.8）测试能否到达互联网。如果本地网络正常但无法到达公网，可能是路由问题或ISP问题。检查路由表确认有默认路由，检查路由器能否连接外网，联系ISP确认服务状态。
第五步测试DNS解析。ping域名测试DNS是否正常工作。如果IP能ping通但域名不能，是DNS问题。检查DNS配置（本地DNS服务器地址），尝试使用公共DNS（8.8.8.8、1.1.1.1），检查DNS服务器是否可达。
使用Wireshark捕获ping流量可以提供更多细节。查看ICMP Echo Request是否发出，是否收到Echo Reply。如果没有收到Reply，是网络路径问题。如果收到Reply但显示”Destination Unreachable”，查看ICMP错误代码（0=网络不可达、1=主机不可达、2=协议不可达、3=端口不可达），这些代码帮助定位问题。
2.2 间歇性连接问题
间歇性连接问题是最难诊断的，问题时好时坏，难以捕捉。
诊断策略：
flowchart TD Intermittent[间歇性连接] --> Monitor[长时间监控<br>捕获流量] Monitor --> Analysis[分析模式] Analysis --> TimePattern{有时间模式?} Analysis --> LoadPattern{有负载模式?} Analysis --> LocationPattern{有位置模式?} TimePattern --> T1[特定时段<br>可能是网络拥塞<br>或定时任务] TimePattern --> T2[随机时间<br>可能是硬件不稳定<br>或干扰] LoadPattern --> L1[高负载时<br>可能是带宽不足<br>或设备过载] LoadPattern --> L2[低负载时<br>可能是配置问题<br>或超时设置] LocationPattern --> Lo1[特定位置<br>可能是无线覆盖<br>或布线问题] LocationPattern --> Lo2[移动时<br>可能是漫游问题<br>或AP切换] T1 --> Capture[针对性捕获<br>问题发生时段] T2 --> LongCap[长期捕获<br>等待问题发生] L1 --> CheckBW[检查带宽利用<br>检查设备负载] L2 --> CheckConfig[检查配置<br>检查超时] Lo1 --> SiteSurvey[现场调查<br>信号强度测试] Lo2 --> Roam[检查漫游配置<br>检查AP设置] Capture --> Correlate[关联事件<br>找到触发因素] LongCap --> Correlate CheckBW --> Correlate CheckConfig --> Correlate SiteSurvey --> Correlate Roam --> Correlate
图表讲解：
这个间歇性连接诊断图展示了分析模式和长期监控的方法。间歇性问题需要捕获问题发生的时刻才能分析。
长时间监控是诊断间歇性问题的关键。配置Wireshark使用环形缓冲，保留最近几小时或几天的数据。当问题发生时，立即保存捕获数据。这样保留了问题发生前后的上下文，便于分析。
分析问题发生的模式有助于找到根本原因。时间模式：问题是否发生在特定时段（如每天上午9点、周末）。这可能是网络拥塞（高峰时段）、定时任务（备份、更新）、环境因素（温度、湿度）。负载模式：问题是否在高负载时发生（大量用户、大文件传输），这可能是带宽瓶颈、设备过载。位置模式：问题是否在特定位置发生（会议室、角落），这可能是无线覆盖差、布线问题、干扰。
针对时间模式的捕获可以缩小捕获范围，只捕获问题时段，减少数据量。针对随机模式的问题需要长期捕获，等待问题发生。使用display filter标记重要事件，使用注释记录观察，便于后续分析。
检查带宽利用使用Wireshark的IO Graph，查看流量随时间的变化。查看接口利用率（Statistics → Summary），如果接近100%表示带宽瓶颈。检查设备负载（CPU、内存），高负载可能导致处理延迟。
检查配置包括超时设置、keepalive设置、重传设置。某些间歇性问题是因为超时设置太短，在网络延迟增加时超时。增加超时值、启用keepalive可以改善。
现场调查对于无线问题很重要。使用无线分析工具（如inSSIDer、WiFi Explorer）查看信号强度、信道利用、干扰源。移动设备测试不同位置的信号质量。检查AP配置（信道、功率、漫游设置），优化无线覆盖。
2.3 Wireshark连接问题分析
捕获与过滤：
# 连接问题捕获过滤器
not arp and not icmp and not udp port 53
# 只看TCP流量
tcp
# 查看连接建立
tcp.flags.syn==1
# 查看连接重置
tcp.flags.reset==1
# 查看特定主机
ip.addr==192.168.1.100
# 查看特定端口
tcp.port==443
关键指标：
flowchart TD Metrics[连接问题<br>关键指标] --> Connectivity[连通性指标] Metrics --> Timing[时序指标] Metrics --> Error[错误指标] Connectivity --> C1[ping成功率<br>请求/响应比] Connectivity --> C2[可达性<br>哪些地址可达] Connectivity --> C3[路由可达性<br>跳数、TTL] Timing --> T1[RTT<br>往返时间] Timing --> T2[连接建立时间<br>三次握手耗时] Timing --> T3[TCP握手延迟<br>SYN到SYN-ACK时间] Error --> E1[ICMP不可达<br>错误代码] Error --> E2[TCP重传<br>重传计数] Error --> E3[TCP重置<br>RST计数] Error --> E4[超时<br>无响应时间] C1 --> Diagnose[综合诊断] C2 --> Diagnose C3 --> Diagnose T1 --> Diagnose T2 --> Diagnose T3 --> Diagnose E1 --> Diagnose E2 --> Diagnose E3 --> Diagnose E4 --> Diagnose
图表讲解：
这个连接问题指标图展示了诊断连接问题时需要关注的关键指标。
连通性指标衡量能否到达目标。ping成功率是请求发送和响应接收的比例，100%表示完全可达，低于100%表示有丢包。可达性测试应该从近到远：本地IP→网关→内网主机→公网IP→域名。路由可达性通过traceroute查看路径，每跳的RTT和TTL帮助理解网络路径。
时序指标衡量连接的速度。RTT（往返时间）是ping请求到响应的时间，正常LAN应该在1-5ms， WAN可能几十到几百ms。连接建立时间是TCP三次握手的时间，SYN到SYN-ACK的时间代表网络延迟，加上SYN-ACK到ACK的时间。如果连接建立时间很长（>1s），可能是路径延迟大或中间设备处理慢。
错误指标指示具体的故障类型。ICMP不可达消息有错误代码：0=网络不可达（路由问题）、1=主机不可达（ARP失败或主机关闭）、2=协议不可达（防火墙阻止）、3=端口不可达（端口未监听）。TCP重传表示数据包丢失或延迟。TCP重置表示连接被强制终止（防火墙拒绝、应用程序崩溃）。超时表示没有收到任何响应（可能是路径中断、防火墙静默丢弃）。
综合诊断需要结合多个指标。例如，ping成功但TCP连接失败，可能是防火墙阻止特定端口。ping成功率80%且延迟变化大，可能是网络质量问题。traceroute在某跳停止，表示该跳设备有问题或防火墙阻止。
三、性能问题诊断
3.1 网络慢问题
网络慢是最常见的用户投诉，但”慢”需要具体化才能诊断。
性能基线：
flowchart TD Slow[网络慢] --> Define[定义"慢"] Define --> Compare{与什么比较?} Compare --> Historical[历史基线<br>以前更快] Compare --> Expected[期望性能<br>应该更快] Compare --> Peer[同侪比较<br>别人更快] Historical --> Q1[什么时候<br>开始变慢?] Expected --> Q2[期望什么<br>性能水平?] Peer --> Q3[谁快谁慢<br>有什么不同?] Q1 --> Measure[测量当前性能] Q2 --> Measure Q3 --> Measure Measure --> Metrics[关键性能指标<br>吞吐量、延迟、丢包率] Metrics --> Benchmark[建立基线<br>记录正常值] Benchmark --> Identify[识别瓶颈<br>带宽、延迟、设备] Identify --> Optimize[针对性优化]
图表讲解：
这个性能基线图展示了定义和测量网络性能的方法。“慢”是主观的，需要客观化才能诊断。
首先需要定义”慢”的含义。与历史比较：以前加载网页需要2秒，现在需要10秒，这确实变慢了。与期望比较：千兆网络理论上125MB/s，实际只有10MB/s，可能是配置问题。与同侪比较：同事的下载速度50MB/s，我的只有5MB/s，需要找出差异。
测量当前性能使用工具和测试。iperf测试带宽：iperf -s（服务器端）、iperf -c server_ip（客户端），报告TCP吞吐量。ping测试延迟：ping -c 100 server_ip统计平均RTT、最小/最大RTT、丢包率。pathping/MTR测试路径：结合ping和traceroute，显示每跳的延迟和丢包。
关键性能指标包括吞吐量（单位时间传输的数据量）、延迟（数据包从源到目的的时间）、丢包率（丢失数据包的比例）。正常情况下，千兆局域网吞吐量应该接近900+ Mbps（考虑开销），延迟应该<5ms，丢包率应该<0.1%。如果明显偏离这些值，表示有性能问题。
识别瓶颈是优化的前提。带宽瓶颈：吞吐量远低于链路容量，可能是设备性能不足、链路质量问题、配置限制。延迟瓶颈：RTT异常高，可能是路径绕路、设备处理慢、排队延迟。丢包瓶颈：丢包率高，会导致TCP重传，严重降低有效吞吐量。
针对性优化取决于瓶颈类型。带宽问题：升级链路、使用负载均衡、优化应用减少传输量。延迟问题：优化路由（使用更短路径）、QoS（优先级流量）、CDN（内容缓存）。丢包问题：检查物理层（线缆、接口）、调整队列大小、检查拥塞。
3.2 TCP性能分析
TCP慢问题诊断：
flowchart TD TCPSlow[TCP性能差] --> Capture[捕获TCP流量] Capture --> Filter[tcp and ip.addr==server_ip] Filter --> Analysis1[检查握手<br>三次握手时间] Analysis1 --> A1{SYN到SYN-ACK<br>>100ms?} A1 -->|是| Network[网络延迟大<br>检查路径] A1 -->|否| Analysis2[检查初始窗口] Analysis2 --> A2{初始窗口<br>太小?} A2 -->|是| Window[窗口缩放<br>未启用?] A2 -->|否| Analysis3[检查数据传输] Analysis3 --> A3{有重传?} A3 -->|是| Retrans[重传分析<br>网络质量或拥塞] A3 -->|否| Analysis4[检查窗口] Analysis4 --> A4{窗口满<br>频繁?} A4 -->|是| Flow[流控问题<br>接收方处理慢] A4 -->|否| Analysis5[检查延迟] Analysis5 --> A5{RTT变化<br>大?} A5 -->|是| Jitter[抖动问题<br>网络不稳定] A5 -->|否| Other[应用层问题] Network --> Solution[针对性解决] Window --> Solution Retrans --> Solution Flow --> Solution Jitter --> Solution Other --> Solution
图表讲解：
这个TCP性能诊断图展示了分析TCP慢问题的系统方法。TCP性能问题可能来自多个方面，需要逐步排查。
首先检查TCP三次握手时间。正常LAN应该在<10ms，WAN可能在几十到几百ms。如果SYN到SYN-ACK时间异常长（如>100ms in LAN），表示网络延迟大。使用traceroute查看路径，检查是否有绕路或高延迟跳数。检查中间设备（防火墙、负载均衡器）是否引入延迟。
其次检查TCP初始窗口。初始窗口（IW）是连接建立后第一个RTT可以发送的数据量。传统是4个段（约4KB），现代可以使用10个段（约10KB）。如果初始窗口太小，慢启动阶段会很长。检查是否启用窗口缩放（WSopt），窗口缩放允许更大的窗口，提高高延迟网络的性能。
第三检查是否有重传。重传是性能杀手，每次重传至少消耗一个RTT，如果是超时重传可能等待更长时间。查看重传模式：如果重传集中在某个时间，可能是突发拥塞；如果重传分散，可能是线路质量差。使用tcp.analysis.retransmission过滤器查看重传，使用Statistics → TCP Stream Graphs → Time-Sequence Graph (tcptrace)可视化重传。
第四检查窗口问题。如果经常看到tcp.analysis.window_full，表示接收方的接收缓冲区满了，发送方无法继续发送。这可能是接收方应用处理慢，无法及时从缓冲区读取数据。解决方法包括：优化应用性能、增加接收缓冲区大小。
第五检查RTT变化（抖动）。如果RTT变化大（从5ms跳到200ms），表示网络不稳定。抖动会导致TCP的超时重传估计不准确，可能过早超时。抖动的原因包括：共享介质的其他流量、无线干扰、路径切换。解决方法包括：使用QoS优先级流量、使用更稳定的路径、调整TCP超时参数。
3.3 吞吐量测试与分析
使用iperf测试带宽：
flowchart TB subgraph Iperf["iperf带宽测试"] direction TB Server[iperf服务器<br>iperf -s -p 5001] Client[iperf客户端<br>iperf -c server -p 5001<br>-t 60 -i 1] Server -->|监听5001端口| Listen[等待连接] Client -->|连接到服务器| Connect[建立TCP连接] Connect --> Transfer[数据传输<br>默认发送TCP窗口大小] Transfer --> Report[每秒报告<br>吞吐量和丢包] end subgraph Wireshark["Wireshark捕获分析"] direction TB Capture[capture filter:<br>host server_ip and port 5001] Capture --> Analysis[分析结果] Analysis --> Throughput[实际吞吐量<br>应该接近链路容量] Analysis --> Retrans[重传率<br>应该<1%] Analysis --> Window[TCP窗口<br>应该足够大] Analysis --> CPU[CPU利用率<br>不应该100%] end Client -->|同时捕获| Capture Transfer --> Report --> Compare[比较iperf和<br>Wireshark结果] Compare --> Identify[识别瓶颈]
图表讲解：
这个iperf测试图展示了使用iperf和Wireshark结合测试带宽的方法。iperf是网络性能测试的标准工具，Wireshark提供详细的协议级分析。
iperf测试需要两台设备：一台作为服务器（iperf -s），一台作为客户端（iperf -c server_ip）。服务器监听默认5001端口，客户端连接到服务器并发送数据。测试时间默认10秒，可以使用-t参数指定（如-t 60测试60秒）。-i参数指定报告间隔（如-i 1每秒报告一次）。
在运行iperf测试时，使用Wireshark捕获流量。捕获过滤器host server_ip and port 5001只捕获iperf流量。分析捕获结果，查看实际吞吐量（Statistics → Summary → Captured data），应该接近链路容量（如千兆链路应该>900 Mbps）。
查看重传率（过滤器tcp.analysis.retransmission）。重传率应该<1%，如果更高表示网络质量差或拥塞。高重传会严重影响吞吐量，因为每次重传浪费时间和带宽。
查看TCP窗口大小（TCP头部的Win字段）。窗口大小应该足够大，充分利用带宽延迟积。带宽延迟积 = 带宽 × RTT，如1Gbps、100ms RTT的BDP = 12.5MB。如果窗口只有64KB，无法充分利用带宽。检查是否启用窗口缩放（tcp.options.wscale），窗口缩放允许更大的窗口。
查看CPU利用率（在两台设备上使用top或taskmgr）。如果CPU利用率100%，可能是CPU瓶颈而非网络瓶颈。iperf是单线程的，多核CPU可能无法完全利用。可以使用多个并行iperf进程（-P 4启动4个并行连接）测试多连接性能。
比较iperf报告和Wireshark分析的结果。两者应该一致，如果差异大，可能有测量问题或配置问题。识别瓶颈：如果iperf报告高吞吐量但实际应用慢，可能是应用瓶颈（单线程、磁盘I/O、锁竞争）。如果iperf报告低吞吐量，检查网络路径（是否有慢速链路）、设备配置（端口速率、duplex）、系统设置（TCP参数、防火墙）。
四、应用层问题诊断
4.1 Web应用问题
HTTP性能分析：
flowchart TD WebSlow[Web应用慢] --> Capture[捕获HTTP流量] Capture --> Questions[回答问题] Questions --> Q1[加载页面需要<br>多少HTTP请求?] Questions --> Q2[每个请求的<br>响应时间如何?] Questions --> Q3[有大量<br>错误响应吗?] Questions --> Q4[响应体<br>有多大?] Q1 --> Many{请求过多?} Q2 --> Slow{响应慢?} Q3 --> Errors{有错误?} Q4 --> Large{响应大?} Many --> Optimize1[资源合并<br>雪碧图<br>减少请求数] Slow --> Analyze[分析慢请求<br>服务器处理时间<br>网络传输时间] Errors --> Fix[修复错误<br>检查配置<br>检查代码] Large --> Compress[启用压缩<br>优化图片<br>减少大小] Analyze --> TTFB[TTFB分析<br>首字节时间] TTFB --> ServerSlow{服务器慢?} ServerSlow -->|是| Server[优化应用<br>优化数据库<br>增加资源] ServerSlow -->|否| Network[网络慢<br>检查带宽<br>检查延迟] Many --> Capture2[使用HTTP/2<br>多路复用] Slow --> Capture2
图表讲解：
这个Web性能分析图展示了诊断Web应用慢问题的方法。Web性能涉及多个因素，需要系统分析。
首先捕获HTTP流量，使用过滤器http。查看加载页面需要多少HTTP请求。请求过多是性能问题的主要原因之一。每个请求都需要DNS查询、TCP连接、TLS握手、请求发送、响应接收，固定开销大。如果页面需要100+个请求，考虑资源合并：合并CSS/JS文件、使用雪碧图合并图片、使用数据URI内联小资源。
分析每个请求的响应时间。在Wireshark中查看HTTP请求和响应之间的时间差。响应时间 = 服务器处理时间（TTFB）+ 网络传输时间。TTFB（Time To First Byte）是从请求发送到收到响应首字节的时间，代表服务器处理时间。如果TTFB长（>1s），服务器是瓶颈：应用代码慢、数据库查询慢、资源不足（CPU/内存）。如果TTFB短但总响应时间长，网络是瓶颈：带宽不足、延迟大。
查看错误响应。使用过滤器http.response.code >= 400查看错误响应。4xx错误（客户端错误）可能是前端配置错误、资源不存在。5xx错误（服务器错误）可能是服务器过载、应用程序错误。修复这些错误可以改善用户体验和性能。
查看响应体大小。使用Statistics → HTTP → Packet Counters查看响应大小分布。大的响应（>1MB）下载时间长。解决方法：启用压缩（gzip、brotli），通常可以将文本资源压缩70%+；优化图片（使用适当格式、压缩、响应式图片）；减少不必要的数据（只返回需要的字段）。
考虑使用HTTP/2。HTTP/2支持多路复用，可以在一个TCP连接上并发传输多个资源，减少连接开销。HTTP/2还支持头部压缩（HPACK）、服务器推送，可以进一步改善性能。在Wireshark中，HTTP/2流量显示为http2协议。
4.2 DNS问题诊断
DNS问题类型：
flowchart TD DNS[DNS问题] --> Symptom1[域名解析失败<br>无法访问网站] DNS --> Symptom2[解析很慢<br>访问延迟高] DNS --> Symptom3[解析错误<br>被重定向到错误IP] Symptom1 --> Diagnose1[诊断步骤] Symptom2 --> Diagnose2[诊断步骤] Symptom3 --> Diagnose3[诊断步骤] Diagnose1 --> D1[ping IP地址<br>测试网络连通性] D1 --> D2[nslookup域名<br>测试DNS解析] D2 --> Result1{结果} Result1 -->|NXDOMAIN| Fix1[域名不存在<br>拼写错误<br>域名过期] Result1 -->|Timeout| Fix2[DNS服务器<br>不可达<br>或无响应] Result1 -->|Server failure| Fix3[DNS服务器<br>配置错误] Symptom2 --> Measure[测量DNS响应时间] Measure --> M1[使用Wireshark<br>查看DNS查询响应时间] M1 --> M2{响应时间} M2 -->|<50ms| Normal[正常范围] M2 -->|50-500ms| Slow1[可接受<br>但可优化] M2 -->|>500ms| Slow2[太慢<br>需要解决] Slow1 --> Optimize1[更换DNS服务器<br>使用本地DNS缓存] Slow2 --> Optimize2[检查网络路径<br>检查DNS服务器负载] Symptom3 --> Analyze[分析DNS响应] Analyze --> Check[检查响应IP<br>是否正确] Check --> Compare{与预期<br>IP比较} Compare -->|不同| Poisoning[可能DNS欺骗<br>或劫持] Compare -->|相同| Other[其他问题<br>如hosts文件]
图表讲解：
这个DNS问题诊断图展示了DNS问题的类型和诊断方法。DNS是互联网的基础设施，DNS问题会影响所有网络应用。
域名解析失败表现为无法访问网站（浏览器显示”服务器未找到”或”DNS_PROBE_FINISHED_NXDOMAIN”）。诊断步骤：首先ping IP地址（如果知道），如果IP能ping通但域名不能，确认是DNS问题而非网络问题。使用nslookup或dig查询域名，查看DNS服务器的响应。
DNS查询结果可能是：NXDOMAIN（域名不存在），可能是域名拼写错误、域名未配置、域名过期。Timeout（超时），可能是DNS服务器不可达（网络中断或防火墙阻止）或服务器无响应（过载或故障）。Server failure（服务器失败），可能是DNS服务器配置错误或权威服务器问题。
解析很慢表现为访问网站时长时间”正在解析主机名”。在Wireshark中测量DNS查询和响应之间的时间差。正常本地DNS解析器响应应该在50ms以内（缓存命中），或几百ms（缓存未命中但网络正常）。如果响应时间>500ms，用户会感知延迟。
优化DNS响应时间的方法：更换DNS服务器（ISP的DNS可能慢，尝试Google 8.8.8.8或Cloudflare 1.1.1.1），使用本地DNS缓存（Windows DNS缓存、Linux dnsmasac、macOS mDNSResponder），检查网络路径（traceroute到DNS服务器，查看是否有高延迟跳数），检查DNS服务器负载（如果是自建DNS，确保资源充足）。
解析错误表现为访问网站时被重定向到错误IP（如广告页面、钓鱼网站）。检查DNS响应的IP地址，与预期的IP比较。如果不同，可能是DNS欺骗或劫持。使用多个DNS服务器查询比较结果，确认是否一致。检查hosts文件（Windows: C:\Windows\System32\drivers\etc\hosts，Linux: /etc/hosts），可能被恶意软件修改。检查路由器的DNS设置，可能被ISP劫持（透明DNS代理）。
4.3 文件传输问题
文件传输慢问题：
flowchart TD Transfer[文件传输慢] --> Type{传输类型} Type --> T1[HTTP下载] Type --> T2[FTP传输] Type --> T3[SMB/CIFS<br>文件共享] T1 --> Capture1[捕获HTTP流量<br>http.request.method == "GET"] T2 --> Capture2[捕获FTP流量<br>ftp] T3 --> Capture3[捕获SMB流量<br>smb or smb2] Capture1 --> Analysis1[分析HTTP下载] Capture2 --> Analysis2[分析FTP传输] Capture3 --> Analysis3[分析SMB] Analysis1 --> Metrics1[测量实际吞吐量<br>Statistics → Summary] Analysis2 --> Metrics2[测量吞吐量<br>查看FTP DATA包] Analysis3 --> Metrics3[测量吞吐量<br>查看SMB Read/Write] Metrics1 --> Bottleneck1{瓶颈在哪?} Metrics2 --> Bottleneck2{瓶颈在哪?} Metrics3 --> Bottleneck3{瓶颈在哪?} Bottleneck1 --> Server1[服务器<br>带宽/CPU/磁盘] Bottleneck1 --> Network1[网络<br>带宽/延迟/丢包] Bottleneck1 --> Client1[客户端<br>磁盘写入] Server1 --> Optimize[优化服务器] Network1 --> Optimize Client1 --> Optimize Optimize --> Specific[针对协议的优化] Specific --> HTTP[HTTP: 启用压缩<br>使用CDN<br>多线程下载] Specific --> FTP[FTP: 使用主动模式<br>调整块大小] Specific --> SMB[SMB: 启用SMB 3.0<br>禁用加密<br>调整缓存]
图表讲解：
这个文件传输诊断图展示了不同协议的文件传输性能分析方法。文件传输慢可能有多个瓶颈，需要定位具体位置。
HTTP下载分析：捕获HTTP GET请求和响应，测量实际吞吐量（捕获数据量 / 捕获时间）。查看服务器是否支持断点续传（Accept-Ranges、Content-Range），可以多线程下载。查看是否启用压缩（Content-Encoding: gzip），压缩可以大大减少传输量。查看响应时间，如果服务器处理慢（TTFB长），需要优化服务器端。
FTP传输分析：FTP使用控制连接（命令）和数据连接（数据传输）。捕获FTP流量，查看FTP DATA包的速率。FTP有主动模式（服务器连接客户端）和被动模式（客户端连接服务器），被动模式更适合穿越防火墙。查看块大小（FTP使用的传输块大小），调整块大小可以提高吞吐量（但可能增加内存使用）。
SMB/CIFS分析：SMB是Windows文件共享协议，性能可能受多种因素影响。SMB 1.0（老版本）性能差且不安全，应该使用SMB 2.0或3.0。SMB 3.0支持多通道和加密，但加密会增加CPU开销。查看SMB协商过程，确认使用的是哪个版本。SMB性能还受客户端缓存、服务器配置、网络质量影响。
通用优化包括：使用有线连接而非Wi-Fi（更稳定、更快），检查全链路带宽（最慢的链路决定吞吐量），检查duplex设置（mismatch会导致大量错误），关闭不必要的网络功能（QoS、防火墙检查可能增加延迟）。
对于大文件传输，考虑使用专门优化的协议：rsync（支持增量传输和断点续传）、FTP（比HTTP更简单、开销更小）、BitTorrent（P2P分布式传输，适合大文件分发）。
五、实战案例
5.1 案例一：网站访问缓慢
问题描述：公司内网用户报告访问公司网站很慢，但其他网站正常。
排查过程：
flowchart TD Problem[内网网站慢<br>其他网站正常] --> Hypothesis1[假设1:<br>网站服务器问题] Hypothesis1 --> Test1[从外网测试<br>访问公司网站] Test1 --> Result1{外网访问<br>速度如何?} Result1 -->|慢| Server[服务器问题<br>或接入带宽不足] Result1 -->|正常| Hypothesis2[假设2:<br>内网网络问题] Hypothesis2 --> Capture[在内网用户电脑<br>捕获访问网站流量] Capture --> Filter[过滤器:<br>host web_server_ip] Filter --> Analyze[分析流量] Analyze --> Find1{发现异常?} Find1 -->|大量重传| Retrans[重传分析<br>网络质量问题] Find1 -->|窗口小| Window[窗口问题<br>接收缓冲区不足] Find1 -->|延迟高| Latency[延迟问题<br>路径问题] Retrans --> CheckPath[检查网络路径<br>用户到服务器] CheckPath --> PathIssue{发现问题?} PathIssue -->| duplex<br>mismatch| Fix1[修复duplex<br>设置为全双工] PathIssue -->|错误帧多| Fix2[检查线缆<br>更换设备] PathIssue -->|路径绕路| Fix3[优化路由<br>直接路径] Fix1 --> Verify[验证修复] Fix2 --> Verify Fix3 --> Verify Verify --> Test2[重新测试<br>访问网站] Test2 --> Success[问题解决<br>访问恢复正常]
图表讲解：
这个网站慢问题案例展示了系统排查的实际过程。问题解决的关键是准确定位故障点。
首先提出假设并测试。假设1是网站服务器本身有问题，但从外网访问正常，排除这个假设。假设2是内网网络有问题，需要进一步验证。
在内网用户电脑上使用Wireshark捕获访问网站的流量。使用过滤器host web_server_ip只看与服务器相关的流量。分析流量模式，发现大量TCP重传（tcp.analysis.retransmission）。
重传表示网络质量问题。进一步检查网络路径。使用traceroute查看从用户到服务器的路径，发现第3跳延迟异常高（200ms vs 正常<10ms）。该跳是核心交换机到服务器接入交换机的链路。
登录交换机检查接口统计，发现大量错误帧（CRC错误、runts）。检查接口配置，发现 duplex mismatch：服务器端口是100Mbps全双工，交换机端口是100Mbps半双工。duplex mismatch会导致严重的性能问题，因为一端认为可以同时发送和接收，另一端认为只能发送或接收。
修复 duplex 设置：将交换机端口改为全双工（duplex full）。重新测试，访问网站速度恢复正常。错误计数停止增长，重传消失。
这个案例的教训：网络性能问题可能源于配置错误，而不仅仅是带宽不足。duplex mismatch是常见但容易被忽视的问题。使用Wireshark捕获流量可以揭示问题的本质（重传、错误），帮助快速定位故障点。
5.2 案例二：间歇性网络中断
问题描述：某用户电脑每天下午2-3点网络中断10-15分钟。
排查过程：
flowchart TD Problem[间歇性中断<br>特定时间] --> Pattern[分析模式] Pattern --> Time[时间模式:<br>每天下午2-3点] Pattern --> User[用户模式:<br>单个用户] Pattern --> Duration[持续时间:<br>10-15分钟] Time --> Hypothesis1[定时任务?] User --> Hypothesis2[用户设备?] Duration --> Hypothesis3[会话超时?] Hypothesis1 --> Monitor[长时间监控<br>配置环形缓冲<br>保存问题时段] Monitor --> Capture[下午2点前<br>开始捕获] Capture --> ProblemTime[问题发生时<br>保存捕获] ProblemTime --> Analyze[分析捕获] Analyze --> Find{发现什么?} Find -->|ARP请求<br>无响应| ARP[ARP问题<br>网关ARP老化] Find -->|DHCP请求<br>无响应| DHCP[DHCP问题<br>租期过期] Find -->|链路down| Link[物理链路<br>能源管理] ARP --> Check1[检查ARP超时<br>检查网络设备<br>ARP缓存时间] DHCP --> Check2[检查DHCP租期<br>检查DHCP服务器<br>检查续租过程] Link --> Check3[检查网卡<br>能源管理<br>线缆接触] Check1 --> RootCause[根本原因:<br>网关ARP缓存<br>老化时间太短<br>5分钟] Check2 --> RootCause2[根本原因:<br>DHCP租期太短<br>不发送续租] Check3 --> RootCause3[根本原因:<br>网卡能源管理<br>关闭网卡<br>节省电源] RootCause --> Fix[延长ARP缓存<br>在网关/PC上] RootCause2 --> Fix2[延长DHCP租期<br>或配置静态IP] RootCause3 --> Fix3[禁用能源管理<br>设备管理器中] Fix --> Resolve[问题解决]
图表讲解：
这个间歇性中断案例展示了长期监控和模式分析的重要性。间歇性问题难以捕捉，需要针对性的捕获策略。
首先分析问题模式：每天下午2-3点（时间模式）、单个用户（用户模式）、持续10-15分钟（持续时间）。这些模式有助于缩小问题范围。时间模式暗示可能与定时任务有关，如备份任务、系统更新、周期性进程。
配置长期监控，使用Wireshark的环形缓冲功能。设置环形缓冲保留最近1-2小时的数据（4-8个文件，每个文件15-30分钟）。当问题发生时立即保存捕获，保留问题发生前后的上下文。
分析捕获发现，问题发生时看到大量ARP请求（Who-has gateway? Tell-me），但没有ARP响应。这表明用户电脑无法解析网关MAC地址。进一步分析发现，ARP请求发生在长时间（如2小时）无网络活动后。
根本原因是网关的ARP缓存老化时间太短（5分钟）。用户电脑下午2点前可能有1-2小时没有网络活动（如午休、会议），网关的ARP缓存条目老化（删除）。当用户恢复活动时，需要发送ARP请求重新解析网关MAC地址。但ARP请求没有得到响应（可能是网络延迟或ARP包丢失），导致网络中断。
解决方案：延长网关的ARP缓存超时时间（从5分钟改为30分钟或更长），或者在用户电脑上配置静态ARP条目（arp -s gateway_ip gateway_mac）。静态ARP条目不会老化，避免了重新解析的需求。
这个案例的教训：间歇性问题需要长期监控和模式分析。问题可能源于超时配置（ARP、DHCP、会话）不匹配实际使用模式。延长超时时间或配置静态条目可以解决。
5.3 案例三：VoIP通话质量问题
问题描述：公司IP电话经常出现语音卡顿、断续。
排查过程：
flowchart TD Problem[VoIP质量差<br>卡顿、断续] --> Capture[捕获VoIP流量] Capture --> RTP[RTP流量<br>udp.portrange 10000-20000] Capture --> SIP[SIP流量<br>port 5060] RTP --> AnalyzeRTP[分析RTP流] SIP --> AnalyzeSIP[分析SIP信令] AnalyzeRTP --> Metrics1[RTP关键指标] Metrics1 --> M1[丢包率<br><1%可接受] Metrics1 --> M2[抖动<br><30ms可接受] Metrics1 --> M3[延迟<br><150ms可接受] M1 --> Evaluate1{丢包率<br>如何?} M2 --> Evaluate2{抖动<br>如何?} M3 --> Evaluate3{延迟<br>如何?} Evaluate1 -->|>5%| Bad[质量不可接受] Evaluate1 -->|1-5%| Poor[质量差] Evaluate1 -->|<1%| Good[质量可接受] Bad --> Diagnose[诊断丢包原因] Poor --> Diagnose Diagnose --> Check1[检查网络拥塞<br>IO Graph查看流量] Check1 --> Find1[发现备份任务<br>与VoIP冲突] Find1 --> QoS[实施QoS<br>优先级VoIP] QoS --> Configure[配置交换机<br>DSCP EF标记<br>优先级队列] Configure --> Verify1[验证QoS<br>捕获流量<br>查看DSCP标记] Verify1 --> Test[测试通话质量] Test --> Success[质量改善<br>丢包率<1%] Evaluate2 --> Jitter[抖动缓冲区] Evaluate3 --> Latency[网络路径优化]
图表讲解：
这个VoIP质量案例展示了实时应用性能分析的方法。VoIP对网络质量要求高，需要专门的指标和优化。
捕获VoIP流量需要识别RTP和SIP协议。RTP（Real-time Transport Protocol）承载实际的语音数据，通常使用UDP端口10000-20000。SIP（Session Initiation Protocol）是信令协议，用于建立、管理、终止通话，使用TCP或UDP端口5060。
分析RTP流的关键指标包括丢包率、抖动和延迟。丢包率是丢失的RTP包的百分比，<1%可接受，>5%质量明显下降。抖动是RTP包到达时间的变化，>30ms需要抖动缓冲区，过大的抖动会导致延迟增加。延迟是语音从发送到播放的时间，<150ms可察觉但可接受，>400ms会话困难。
使用Wireshark的Telephony → RTP → RTP Streams分析RTP流。Wireshark会计算丢包率、抖动、延迟，并给出MOS（Mean Opinion Score）评分。MOS是1-5的评分，5是完美，1是不可用。
诊断发现丢包率>5%，质量不可接受。进一步检查网络流量模式（Statistics → IO Graph），发现每天下午2点有大量流量（备份任务），导致网络拥塞，VoIP包被丢弃。
实施QoS（Quality of Service）优先级VoIP流量。配置交换机接口，将VoIP流量标记为DSCP EF（Expedited Forwarding），进入最高优先级队列。这样即使网络拥塞，VoIP包也会优先转发。
验证QoS配置：重新捕获流量，查看RTP包的DSCP字段是否设置为EF（46）。检查交换机队列统计，确认VoIP流量确实进入高优先级队列。测试通话质量，丢包率降到<1%，MOS评分提高到4+。
这个案例的教训：实时应用（VoIP、视频会议）对网络质量敏感，需要QoS保障。使用Wireshark的RTP分析功能可以量化语音质量，识别问题（丢包、抖动、延迟）。QoS配置可以确保关键流量优先传输，即使在拥塞时也保持可接受的质量。
六、核心概念总结
| 问题类型 | 关键指标 | Wireshark过滤器/工具 | 常见原因 |
|---|---|---|---|
| 连接问题 | ping成功率、ICMP错误、TCP标志 | icmp, tcp.flags.syn==1 | 物理层、ARP、路由、防火墙 |
| 性能问题 | 吞吐量、延迟、丢包率 | tcp.analysis.retransmission | 带宽瓶颈、duplex mismatch、拥塞 |
| DNS问题 | 响应时间、响应代码 | dns, dns.qry.name | DNS服务器、缓存、网络路径 |
| Web问题 | 请求数、响应时间、状态码 | http, http.response.code | 服务器性能、网络延迟、资源大小 |
| VoIP问题 | 丢包率、抖动、延迟 | Telephony → RTP Streams | 网络拥塞、QoS配置、路径质量 |
常见问题解答
Q1：网络完全断开时如何使用Wireshark排查？
答：网络完全断开时，Wireshark无法捕获远程流量，但仍然可以捕获本地流量进行诊断。关键是缩小问题范围，定位故障点。
首先，检查Wireshark能否看到任何流量。启动捕获，选择活动接口，查看是否有任何数据包。如果完全没有数据包（连广播/组播都没有），可能是接口驱动问题或物理层问题。如果能看到广播/组播但看不到单播，可能是交换机配置或VLAN问题。
其次，测试本地协议栈。ping 127.0.0.1，如果失败是TCP/IP协议栈问题。在Wireshark中应该能看到环回接口的ping流量。如果本地协议栈正常，ping本地IP地址，测试网卡功能。
第三，检查ARP流量。网络断开时，尝试ping网关，在Wireshark中查看是否有ARP请求发出，是否有ARP响应。如果没有ARP响应，可能是网关故障、交换机问题、或ARP欺骗。
第四，检查DHCP（如果使用动态IP）。如果IP地址配置有问题，使用ipconfig /release和ipconfig /renew（Windows）或dhclient（Linux）重新获取IP。在Wireshark中查看DHCP Discover、Offer、Request、ACK过程。
第五，检查接口状态。在命令行使用ipconfig /all（Windows）或ifconfig -a（Linux）查看接口状态。在Wireshark中，捕获接口统计应该显示接口up/down状态。
如果网络完全断开但Wireshark无法捕获到有用的数据（如没有ARP请求发出），可能是主机网络栈的问题（驱动损坏、防火墙阻止），而不是网络本身的问题。这种情况下需要检查网络适配器设置、更新驱动、禁用再启用适配器。
Q2：如何分析”网络慢”的用户报告？
答：“网络慢”是用户的主观感受，需要客观化和具体化才能有效分析。首先需要收集更多信息，然后使用工具测量性能。
收集信息时，问以下问题：什么慢（网页加载、文件下载、应用程序响应）？什么时候开始慢（突然变慢、逐渐变慢、特定时段慢）？谁受影响（单个用户、部门、全公司）？与其他用户比较（别人也慢吗）？使用什么应用（浏览器、特定软件、所有应用）？
测量性能使用工具。带宽测试：使用iperf、speedtest.net测量实际带宽。延迟测试：使用ping测量RTT，查看最小/最大/平均延迟。丢包测试：ping 100个包，查看丢包率。路径分析：使用traceroute或MTR查看每跳延迟和丢包。
在Wireshark中，捕获用户报告”慢”的操作。例如，如果用户说访问某网站慢，捕获访问该网站的流量。分析DNS查询时间（从查询到响应）、TCP连接建立时间（三次握手）、HTTP请求响应时间（从GET到200 OK）。哪个阶段慢就是那个阶段的问题。
使用IO Graph可视化问题。Statistics → IO Graph，绘制流量随时间的变化。查看是否有流量中断、突发、带宽限制。添加过滤器（如tcp.analysis.retransmission）查看重传随时间的变化，是否与用户报告的慢时段相关。
查看TCP性能指标。Statistics → Summary查看捕获的基本统计。Statistics → Conversations查看每个会话的吞吐量。Statistics → TCP Stream Graphs查看TCP序列号、窗口、RTT图形。这些可视化帮助理解TCP行为。
最后，建立性能基线。在正常情况下测量网络性能，记录基线值（带宽、延迟、丢包率）。当用户报告慢时，与基线比较，客观评估是否真的慢，慢的程度如何。这有助于区分”实际慢”和”感知慢”（如应用程序本身慢，而非网络）。
Q3：TCP重传太多，如何找到根本原因？
答：TCP重传是网络问题的明显指示，但根本原因可能多种多样。需要分析重传的模式、分布、时机，结合其他信息找到根本原因。
首先，分析重传类型。使用过滤器tcp.analysis.retransmission查看所有重传。查看是否有[TCP Fast Retransmission]（快速重传，由3个重复ACK触发）或[TCP Retransmission]（超时重传，由RTO超时触发）。快速重传通常是单个包丢失，超时重传可能是路径中断或严重拥塞。
第二，分析重传分布。查看重传是集中在某个时间段（突发重传），还是分散在整个捕获（随机重传）。突发重传可能是网络拥塞（如备份任务、大文件传输）、设备过载。随机重传可能是线路质量不稳定（无线干扰、物理链路问题）。
第三，分析重传时机。查看重传发生在连接的哪个阶段。握手后立即重传可能是路径问题（路由不可达、防火墙阻止）。数据传输中的重传可能是网络质量或拥塞。连接终止前的重传可能是链路中断。
第四，检查错误帧。如果捕获的是以太网流量，查看以太网错误。接口统计中的错误帧计数（FCS错误、alignment错误、runts）表示物理层问题。duplex mismatch是常见原因，检查接口配置（show interface或ethtool）。
第五，检查网络路径。使用traceroute或tracert查看路径，查看每跳的延迟和丢包。MTR（My traceroute）结合ping和traceroute，可以持续监控每跳的性能。某跳的高延迟或丢包可能是问题所在。
第六，检查网络设备。登录交换机、路由器，查看接口统计。查看CPU利用率、内存使用率、缓冲区使用率。设备过载可能导致丢包。查看日志，是否有错误消息（如接口flapping、路由震荡）。
第七，检查应用行为。某些应用可能导致重传。例如，发送方发送过快（窗口缩放未启用，窗口太小），接收方无法及时接收。或者应用程序延迟ACK，导致ACK堆积，触发快速重传。
综合这些信息，通常可以找到根本原因：物理层问题（线缆、duplex）、设备问题（过载、故障）、配置问题（MTU mismatch、QoS）、应用问题（TCP参数、发送速率）。针对性地解决根本原因，重传会消失，性能会改善。
Q4：如何诊断DNS解析缓慢的问题？
答：DNS解析缓慢会影响所有基于域名的网络应用，快速诊断和解决很重要。诊断需要测量响应时间，分析解析过程，找出慢的环节。
首先，测量DNS响应时间。使用Wireshark捕获DNS流量（过滤器dns），查看每个DNS查询和对应响应之间的时间差。查看DNS查询的类型（A记录、AAAA记录、CNAME记录）和响应的内容。记录响应时间，建立基线。
第二，分析响应时间分布。查看响应时间是集中在某个范围，还是差异很大。如果大多数查询<50ms，但某些查询>1000ms，可能是特定域名或特定DNS服务器的问题。如果所有查询都慢，可能是本地DNS服务器或网络路径问题。
第三，检查DNS服务器配置。查看当前使用的DNS服务器（ipconfig /all或resolv.conf）。测试不同的DNS服务器，比较响应时间。可以尝试ISP的DNS、公共DNS（Google 8.8.8.8、Cloudflare 1.1.1.1）、公司内部DNS。响应时间差异可能很大。
第四，检查网络路径。使用traceroute到DNS服务器，查看是否有高延迟跳数。网络路径慢会导致DNS响应慢。如果是ISP的DNS问题，考虑切换到其他DNS。如果是内部DNS，检查网络连接和服务器负载。
第五，检查DNS缓存。查看DNS缓存命中率。缓存命中时响应应该非常快（<5ms）。如果缓存命中率低，可能是缓存太小、TTL太短、查询模式分散。增加缓存大小、调整TTL可以改善。
第六，检查DNS查询模式。是否有大量失败的查询（NXDOMAIN），可能是配置错误或恶意软件。是否有异常的查询模式（如长随机名称），可能是DNS隧道或数据外泄。是否有大量PTR查询（反向解析），可能不需要或可以优化。
第七，使用DNS分析工具。使用dig（Domain Information Groper）查看详细的DNS响应。dig @server domain查询特定服务器，dig +trace domain查看完整的解析路径（从根到权威）。这可以帮助识别哪个环节慢。
优化DNS响应的方法：使用更快的DNS服务器（选择延迟最小的）、启用DNS缓存（本地缓存或转发器）、调整DNS超时和重试参数（避免过长等待）、预解析常用域名（应用启动时）、使用HTTP/3或QUIC（减少DNS查询需求）。
Q5：如何确定网络问题是主机问题还是网络问题？
答：区分主机问题和网络问题是故障排查的第一步，可以帮助缩小排查范围，避免浪费时间检查错误的设备。
首先，检查其他主机。如果多台主机有相同问题，很可能是网络问题。如果只有一台主机有问题，很可能是主机问题。但要注意，某些主机可能有特殊配置（不同的VLAN、不同的路由），可能看起来是主机问题实际是网络问题。
第二，测试基本连通性。ping 127.0.0.1（本地环回）测试TCP/IP协议栈。ping 本地IP测试网卡功能。ping 网关测试本地网络。ping 远程IP测试路由。这个逐步测试可以定位问题在哪一层。
第三，比较相同网络的主机。如果主机A（有问题）和主机B（无问题）在同一交换机、同一VLAN、使用相同配置，但A有问题而B正常，很可能是主机A的问题（网卡驱动、软件配置、防火墙设置）。如果A和B都有问题，很可能是网络问题。
第四，检查主机配置。使用ipconfig /all（Windows）或ifconfig（Linux）查看IP配置。确认IP地址、子网掩码、默认网关、DNS服务器配置正确。检查是否有冲突的IP地址（ARP欺骗或配置错误）。检查防火墙规则，是否阻止了必要的流量。
第五，从网络侧检查。登录交换机，查看主机连接的端口状态（show interface）。端口是up还是down？有错误帧吗？MAC地址学习正常吗？从交换机ping主机，能否ping通？这可以确定是主机问题还是交换机端口问题。
第六，使用对比测试。如果可能，将主机连接到已知正常的端口，看问题是否跟随主机。将已知正常的主机连接到问题端口，看问题是否跟随端口。这可以确定问题是主机还是网络。
第七，查看系统日志。主机的事件查看器（Windows）或syslog（Linux）可能记录网络相关的错误消息。网络设备的日志也可能记录端口状态变化、错误信息。这些日志可以提供线索。
总结判断标准：主机问题通常只影响单个主机，可能伴随其他主机特定症状（如应用程序错误、驱动错误消息）。网络问题通常影响多个主机（同一VLAN、同一子网），可能伴随网络设备错误（端口flapping、高错误计数）。使用系统的测试和对比方法，可以快速区分这两类问题。
总结
本文系统介绍了网络故障排查的方法论和实践技巧，主要内容包括：
- 故障排查方法论：结构化流程、分层排查策略
- 连接问题诊断：完全无法连接、间歇性连接
- 性能问题诊断：网络慢、TCP性能、吞吐量测试
- 应用层问题诊断：Web应用、DNS、文件传输
- 实战案例：网站慢、间歇性中断、VoIP质量问题
通过学习这些内容，你建立了系统化的故障排查思路，能够使用Wireshark快速定位网络问题的根本原因。
下篇预告
下一篇我们将探讨《网络安全威胁检测》，带你学习如何使用Wireshark识别和分析各种网络安全威胁，包括网络扫描、端口扫描、中间人攻击、DNS攻击、DDoS攻击等，掌握网络取证和安全事件响应技巧。