排查网络连接超时、IP电话无法注册、通话单向无声或摄像机取流异常时，仅检查设备是否在线，往往无法确定故障发生在网络传输还是应用协议。Wireshark是一款开源网络数据包分析工具，可以捕获经过指定网络接口的数据，并按协议层级展示报文内容，帮助工程人员判断通信双方实际发送了什么、收到了什么。
它既可用于TCP、UDP、DNS等基础网络协议分析，也常用于SIP电话、RTP语音和RTSP视频接入的联调。Wireshark能够提供可核对的数据包证据，但抓不到的数据不等于网络中没有发生，协议解码结果也不能脱离抓包位置和业务流程单独判断。
工具定位与主要用途
Wireshark属于网络协议分析器（Network Protocol Analyzer），核心作用是观察、筛选和解释数据包，而不是替代交换机、防火墙或业务服务器。它可以实时抓取网络流量，也能打开已有的pcap、pcapng文件，对故障发生时的数据进行离线复核。
- 网络连接排障：检查DNS解析、TCP建连、连接重置、重传和应用请求响应。
- 通信系统联调：观察SIP注册与呼叫信令，结合RTP分析媒体流是否到达。
- 视频取流分析：检查RTSP会话协商、RTP传输路径和异常响应。
- 协议开发与测试：确认客户端、服务器或网关发出的字段是否符合预期。
- 安全与运维审查：在授权范围内识别异常连接或协议行为，辅助还原问题发生的时间顺序。
抓包尤其适合分析明确的故障时间段与通信对象。长期监测带宽利用率或设备在线状态，应使用网络监控平台；Wireshark则用于解释某次通信为什么失败，以及失败时交换了哪些报文。
工作原理：从网络接口到协议解析
数据包怎样进入Wireshark
Wireshark依靠操作系统提供的抓包机制读取网络接口上的数据。Windows环境通常使用Npcap；Linux、macOS等平台依赖对应的捕获接口及权限设置。捕获到的内容可能包括链路层帧、IP数据报、TCP或UDP报文，以及其上承载的应用协议。
抓包位置决定能看到的流量。在普通交换网络中，电脑连接某个交换机端口，并不意味着能够直接看到其他两个端口之间的全部通信。排查终端与服务器之间的故障，可以在终端、服务器或经授权配置了端口镜像（SPAN）的交换机端口采集；必要时对照多个位置的抓包结果，判断数据在哪一段链路丢失。
协议解析与三栏界面
获得原始数据包后，Wireshark会依据已识别的协议结构将字段逐层展开。典型界面可以分为三个区域：
- 数据包列表（Packet List）：显示捕获时间、源地址、目标地址、协议以及摘要信息。
- 数据包详情（Packet Details）：展开以太网、IP、TCP/UDP及应用协议字段，查看各层参数。
- 原始字节（Packet Bytes）：展示报文的十六进制和字符数据，便于核对实际字节内容。
Wireshark的协议识别依赖端口、会话信息和协议解析器。若设备使用非标准端口、抓包缺少前面的协商过程，或报文已经加密，界面可能只能显示TCP、UDP或TLS等较底层信息，不能据此断言上层业务不存在。
从安装到保存：一次基本抓包流程
建议从Wireshark官方网站下载安装包。Windows用户应确认Npcap等抓包组件已正确安装；macOS用户需要按安装提示完成抓包权限配置。实际菜单与安装步骤可能随系统和软件版本略有变化。
- 确定问题与抓包位置。记录故障时间、涉及设备IP、协议和业务操作，明确要抓取客户端、服务器还是镜像端口的流量。
- 选择正确的网络接口。打开Wireshark，在接口列表中观察数据流量变化，选择正在承载目标业务的以太网或无线接口。
- 开始捕获并复现问题。启动抓包后，执行一次可控的操作，例如让SIP电话重新注册、拨打一通测试电话，或让播放器重新打开视频。
- 停止并缩小分析范围。复现结束后停止捕获，记录对应时间，使用显示过滤器查找相关会话。
- 保存证据。通过文件菜单保存pcapng抓包文件，同时记录采集位置、时间和对应操作；对外共享前检查内容是否包含敏感信息。
如果尚不确定业务使用的端口，先在授权范围内保留相关主机的流量，再通过显示过滤器缩小分析范围。只采集5060端口可能抓到SIP信令，却漏掉使用其他UDP端口的RTP语音。在高流量链路中，可结合目标主机、抓包时长和文件轮转控制数据量。
捕获过滤器与显示过滤器有什么区别
Wireshark具有两套不同的过滤语言：捕获过滤器（Capture Filter）决定哪些数据包会被写入抓包结果；显示过滤器（Display Filter）只决定已经捕获的数据包中哪些显示在界面上。两者的语法和使用位置不能混用。
| 比较项 | 捕获过滤器 | 显示过滤器 |
|---|---|---|
| 生效阶段 | 抓包前或抓包过程中 | 抓包后查看，也可用于实时显示 |
| 作用 | 限制实际采集的数据范围 | 隐藏暂时不相关的数据包，不改变已保存内容 |
| 语法 | 基于libpcap/BPF表达式 | Wireshark协议字段表达式 |
| 适用场景 | 限制设备IP、端口、抓包量 | 定位SIP方法、TCP重传、RTP及RTSP会话 |
捕获过滤器示例
以下示例应逐条选择使用，填写在捕获选项的Capture Filter栏，而不是把所有行一次性粘贴进去。IP地址使用文档保留地址作为示例。
Capture Filter · 捕获过滤器示例
host 192.0.2.10
udp port 5060
tcp port 5060
说明：第一条保留与指定主机相关的流量，适合需要同时观察信令和媒体的场景；后两条分别限定UDP或TCP的5060端口，仅适合已确认业务使用该端口时的定向抓包。
显示过滤器示例
显示过滤器用于分析已有抓包。以下各行同样是独立表达式，一次使用一条；可根据实际故障进一步组合条件。
Display Filter · 显示过滤器示例
ip.addr == 192.0.2.10
sip
sip.Method == "INVITE"
rtp
rtsp
tcp.analysis.retransmission
其中，sip.Method == "INVITE"用于查看已识别的SIP INVITE请求；tcp.analysis.retransmission用于筛选Wireshark标记的疑似TCP重传。看到重传提示，不等于已经证明具体哪台设备或哪条线路发生故障，还需结合抓包位置、时间差及对应的ACK观察。
对于非标准端口上的协议，可能需要使用“Analyze → Decode As”手动指定解析方式。部分RTP流还依赖先前的会话协商信息才能正确识别，因此过滤器返回空结果，并不总意味着媒体包不存在。过滤语法与字段可以参考Wireshark官方过滤器文档。
如何阅读数据包并定位网络故障
分析抓包时，最好沿着域名解析 → 网络连接 → 应用请求 → 实际数据传输的顺序检查，不宜一看到异常颜色或“重传”提示就直接判定网络故障。
- 先确认通信双方。查看源/目标IP与端口，确定流量是否经过预期服务器、网关和网络路径。
- 再确认请求是否到达。例如DNS是否返回解析结果，TCP SYN是否得到响应，应用服务器是否收到客户端请求。
- 检查响应状态与耗时。区分服务器拒绝、超时、连接重置和应用协议错误，不把所有“连接失败”归为同一问题。
- 结合统计工具复核。可使用“Follow TCP Stream”查看同一TCP会话中的应用数据，使用统计信息观察协议占比、会话及往返时间。
例如，TCP连接已经建立但应用端始终没有返回有效响应，排查方向应转向服务器处理、业务超时或后续协议交互；若三次握手都无法完成，才优先检查网络路由、端口访问策略和对端服务状态。
另外，交换机镜像口丢包、抓包电脑处理性能不足，以及抓包从会话中途开始，都可能让分析结果出现缺口。抓包能够记录观测点看到的网络行为，不等同于完整的端到端监控。
SIP、RTP与RTSP在通信系统中的抓包分析
IP电话注册和呼叫建立
对于IP PBX、SIP服务器或工业电话终端，Wireshark最常见的用途是核对注册与呼叫信令。终端发出REGISTER后，服务器可能先返回401认证挑战，再由终端携带认证信息重新请求；单独看到一次401，不能立即判断注册失败，还要检查后续REGISTER及最终响应。
呼叫分析可按照INVITE、临时响应、最终响应、ACK以及会话结束时的BYE等消息检查。实际呼叫可能经过代理服务器、分机转接或其他业务节点，消息顺序也会不同。可以通过“Telephony → VoIP Calls”查找Wireshark识别到的呼叫，使用相应的流程视图检查信令交互。
通话单向无声与RTP媒体
当SIP信令显示通话已经建立，但一方听不到声音时，应把信令和媒体分开核查：首先从SDP中确认双方协商的媒体地址、端口和编解码信息，再检查各方向是否有实际的RTP包到达。
- 双向均无声：检查媒体是否被发送、地址协商是否正确，以及网络边界是否允许媒体通过。
- 单向无声：分别检查主叫到被叫、被叫到主叫两个方向，核对RTP目的地址和实际到达位置。
- 语音断续：结合RTP流分析中的序列号、到达间隔和抖动指标，判断是否存在传输异常或缓冲问题。
Wireshark的“Telephony → RTP → RTP Streams”可列出已识别的RTP会话，查看源/目的地址、端口、包数量以及部分丢包和时间指标。分析时应先找到两个通话方向的媒体流，再检查是否存在某个方向完全没有RTP包，或到达数据与会话协商参数不一致。
RTP统计只能反映抓包点观察到的媒体情况，不能单凭一项指标判断实际语音质量。实际听感还与网络路径、编解码、终端音频处理和抖动缓冲有关。RTP实时传输协议的独立文章可进一步解释序列号与时间戳的作用。
RTSP视频取流异常
针对摄像机或视频服务器，可用rtsp显示过滤器检查DESCRIBE、SETUP、PLAY和TEARDOWN等请求，确认是否完成媒体描述与传输通道协商。SETUP或PLAY返回成功，并不意味着客户端已经成功接收和解码视频。下一步仍需检查RTP/UDP媒体端口或TCP交错媒体数据。
如果服务器返回401、404或461，应根据认证、资源路径、传输方式分别定位。RTSP协议自身的消息格式、状态码和传输机制可参考站内RTSP协议详解，本篇重点放在如何使用抓包工具找到这些报文，而不重复展开协议规范。
使用限制、数据安全与实际选型
加密通信会限制可见信息。HTTPS、SIP over TLS等连接通常只能看到部分握手、地址及连接元数据；SRTP媒体也无法直接按照明文RTP解码。只有在获得授权且实现支持的情况下，才能使用合适的密钥材料进一步分析加密内容。
抓包文件可能包含电话号码、内部IP、账户标识、认证字段、URL、业务数据甚至音视频内容。生产环境应按照最小必要原则选择采集范围，并限制文件保存时间和访问权限。对外提供故障样本时，还需按规定脱敏；简单修改文件名并不会清除包内敏感信息。
Wireshark适用于需要逐包分析和可视化操作的排障任务；如果要在服务器上进行长时间的命令行采集，可以结合tcpdump、dumpcap或TShark等工具，再将抓包文件交由Wireshark查看。对于科能融合的SIP话机、IP PBX、对讲和视频联动项目，排障时同时保留终端日志、服务器日志和相关时间段的数据包，通常比仅凭单侧抓包更容易定位问题。
常见问题（FAQ）
Wireshark能直接修改或拦截网络数据包吗？
Wireshark主要用于数据包捕获和分析，并不是防火墙或在线流量改写工具。需要阻断流量或执行访问控制，应在交换机、防火墙或相关网络组件上实施。
抓包里明明有UDP数据，为什么显示过滤器rtp没有结果？
Wireshark可能尚未将该UDP流识别为RTP，尤其在缺少SIP/SDP协商或使用非标准端口时。可以先核对发送端口和媒体协商信息，再在确有依据时使用Decode As等方式指定解析，不能将所有UDP流都按RTP处理。
pcap和pcapng有什么区别，保存时选哪种？
pcap是一种较传统的数据包捕获文件格式，兼容范围广；pcapng支持更丰富的元数据，例如多接口信息和部分注释。日常用Wireshark分析通常可以优先保存pcapng；如需交给只支持pcap的软件，再确认格式转换和信息丢失的影响。
能否通过一次抓包证明网络一定没有丢包？
不能。抓包只能反映特定接口、采集时间和工具能力范围内观察到的数据。镜像口本身可能丢包，终端也可能在采集点之外丢弃数据。需要验证端到端丢包时，应结合多个观测点、交换机接口计数器及应用侧统计判断。
