用Wireshark排查DICOM网络假死：从关联协商到性能优化

搞医院网络的人，多半都有过这种经历：技师那边明明按了发送，影像科诊断工作站却死活等不到图；或者诊断医生打开某患者检查列表，缩略图一直转圈，过了几分钟才提示超时。服务器没宕机、网络交换机也没报警，问题到底出在哪？我干了这些年医疗信息化集成，得出的结论是：这种“假死”十有八九是DICOM协议会话层面出了问题，而最快定位问题的办法，就是直接抓包看Wireshark。

Wireshark对DICOM协议的支持比很多人想象中成熟得多。它不仅能解析四层TCP连接，还能完整还原应用层的DICOM关联协商、命令集和数据集PDV，甚至能直接看到当前传输用的是哪种传输语法、图像有没有走压缩。这篇东西不打算讲教科书式的协议概述，而是按我平时排障的习惯，从DICOM传输架构、Wireshark抓包配置、PDU行为识别、性能计算到常见故障排查，完整走一遍。适合医院信息科、系统集成商工程师、设备厂商实施人员，以及所有需要对接PACS、RIS或影像设备的同行参考。

1. DICOM网络通信架构与信息模型

这里先说清楚一个问题：DICOM不是像HTTP那样的简单“请求-响应”协议，而是一整套面向医学影像对象的应用层协议规范，平时我们说的“传图”，只是它众多服务当中的一个子集。如果不先把架构搞明白，后面看抓包就是看天书。

1.1 DICOM在TCP/IP协议栈中的位置

DICOM标准定义了从网络层到应用层的完整通信行为，但在实际部署中，几乎都运行在TCP/IP协议栈上。默认使用TCP端口104，这是DICOM标准规定的默认端口，绝大多数PACS和影像设备都支持。如果涉及TLS加密传输，则使用11112端口；有些第三方集成引擎会用2761、2762这样的高端口做内部数据转发。

值得注意的是，DICOM依赖TCP提供可靠传输，所以它不需要自己处理丢包重传、报文分片这些底层逻辑。Wireshark里看到大量TCP重传或快速重传时，往往是网络链路本身有丢失，而不是DICOM应用层的问题。这个区别会在排障时省很多力气。

还有一点，DICOM连接是可长可短的。C-ECHO这种连通性测试通常一个TCP连接只做一次请求和响应就断开；C-STORE批量传图则经常出现一个TCP连接持续几分钟甚至几小时，连接上不断传出多个数据集。排查问题时不能像分析HTTP那样，只看一次请求响应就算完，而是要顺着整个TCP流去观察关联建立、数据P-DATA阶段、关联释放三个阶段的行为。

1.2 SCU与SCP：谁请求、谁响应

DICOM通信模型里有两个基本角色：SCU和SCP。SCU（Service Class User）是服务调用方，发起请求；SCP（Service Class Provider）是服务提供方，接收请求并执行操作。拿实际场景举例：CT设备向PACS发送图像，CT就是C-STORE SCU，PACS就是C-STORE SCP；诊断工作站查询患者列表，工作站是C-FIND SCU，PACS是C-FIND SCP。同一个软件系统在不同的服务里可以扮演不同角色，这种角色模型经常被等价于“客户端-服务器”，但更准确的理解是“服务调用-服务响应”。

在Wireshark的DICOM解析结果里，SCU发的命令叫请求（例如C-STORE-RQ），SCP回的叫响应（例如C-STORE-RSP）。通过消息类型字段配合消息ID、关联上下文ID，就能把同一操作的一来一回对应起来。这对于判断操作是否成功非常有用，因为DICOM的错误反馈并不是靠TCP断开表现的，而是靠响应包里的状态码表达的。

1.3 AETitle、端口与上下文的三角关系

DICOM排障中，AETitle是绕不开的概念。AETitle（Application Entity Title）是应用实体的字符串名字，最长16个字符，用于在DICOM应用网络中唯一标识一个节点。一个PACS系统会配置多个AETitle，例如“PACS_MAIN”“PACS_ARCHIVE”“PACS_QUERY”，分别对应不同服务端点。设备给PACS发图时，必须知道自己要连接的目标IP、目标端口、目标AETitle，以及自己对外宣告的AETitle。

我见过很多集成故障，根本不是网络问题，而是AETitle配置错误。比如设备端把调用AETitle填成了别的科室名字，PACS一查本地设备注册表对不上，直接拒绝关联。在Wireshark里，关联请求包（A-ASSOCIATE-RQ）中的Called AE Title和Calling AE Title字段会把这个错误暴露得一清二楚。所以收到“Association Rejected”时，第一件事不是查防火墙，而是先看这两个字段填的是什么。

这里还涉及一个叫“表现上下文”的概念，英文是Presentation Context。它描述了关联过程中双方就哪一类DICOM服务、哪一种数据编码格式达成的一致。具体包含三部分：表示上下文ID、抽象语法、传输语法。抽象语法标识服务或对象类型，比如CT图像存储；传输语法标识数据编码方式，比如未压缩的小端字节序、JPEG-LS无损压缩、JPEG2000有损压缩等。后续数据阶段，每一包P-DATA-TF都靠表示上下文ID来区分该数据属于哪个服务、使用哪种编码。

2. Wireshark抓包前的关键设置与过滤策略

很多人打开Wireshark就点Start，抓到一堆数据才开始发愁。做DICOM分析，抓包之前的准备工作决定了后续分析效率。正确做法是先在Wireshark里配置好显示列、过滤条件和解码规则，再开始抓包。

2.1 抓包过滤器与显示过滤器怎么选

Wireshark有两套过滤机制：抓包过滤器（Capture Filter）和显示过滤器（Display Filter）。抓包过滤器是BPF语法，工作在内核层，只决定哪些报文被记录下来；显示过滤器是Wireshark自己的语法，每次从原始报文里筛选出感兴趣的包。对DICOM排障，两者都要用上。

抓包过滤器建议这样写：

tcp port 104 or tcp port 11112 or tcp port 2761 or tcp port 2762

这样只保留DICOM相关TCP端口流量，避免抓一堆系统广播、音视频流量干扰分析。如果场景里有设备乱用高端口，比如某厂商设备用4006端口传输，那就需要把端口也加进去，或者直接抓两端IP之间的全部流量：

host 10.20.30.40 and host 10.20.30.50

显示过滤器方面，Wireshark会自动识别DICOM协议，只要在过滤器栏输入dicom，就能看到所有被解析为DICOM的包。进一步细分场景时，用dicom && tcp.port == 104只查标准端口上的DICOM流量；排查响应状态时，可以关注包含错误码的包。需要注意的是，抓包过滤器只抓端口监听后的流量语义，如果数据包恰好处在TCP分片和重组的中间状态，Wireshark的DICOM解析器会自动重组，显示为完整PDU结构，但此时Packet Bytes窗口里看到的可能是多个TCP段拼接后的数据。

2.2 开启DICOM协议解析器与预解析技巧

新装Wireshark的DICOM解析器默认是开启的，但个别发行版或定制版可能会禁用。检查方式很简单，打开一个含DICOM流的报文，看协议概要列是否显示DICOM，如果显示的是TCP或Data，说明解析器没生效。这时右键该报文，选择“Decode As”，把TCP端口104及其余DICOM端口手动指定为DICOM即可。

还有个技巧是预先加载PDU过滤器。如果某个对接项目反复出现，可以把常用显示过滤器保存为自定义快捷栏，例如“待解决关联异常”对应的过滤器。我习惯把这几条存成快捷按钮：

• dicom：所有DICOM包
• dicom && frame.time_delta > 1：前后包间隔超过1秒的DICOM帧，用来快速找网络或应用延迟
• tcp.analysis.flags && dicom：带有TCP异常标记的DICOM包，比如重传、零窗口、乱序

这样从一堆几十万包的抓包里快速过滤，比临时敲命令快得多。

2.3 从TCP流中还原完整DICOM会话

Wireshark的“Follow TCP Stream”功能对DICOM排障特别重要。右键任意一个DICOM报文，选择“追踪TCP流”，Wireshark会把该TCP连接的所有载荷以原始顺序拼接出来。左边是客户端发的数据，右边是服务端回的。默认编码视图是ASCII，但DICOM PDV里的图像二进制内容会让人看得眼花缭乱，建议把视图切换成Hex Dump，这样能清晰看到DICOM头、命令集结构和数据集内容的字节流。

通过TCP流还能直观看到关联建立阶段PDU、数据阶段多个P-DATA-TF PDU以及最后的释放PDU。很多现场问题，比如“设备已发送数据但PACS没收到”，Possibly大多数时候看到的是数据阶段刚开始就断了TCP连接，或者数据阶段一直持续但响应迟迟不来。这些在TCP流视图里都是一目了然的。

3. DICOM PDU结构解读与关联协商分析

DICOM应用层通信的基本单位叫PDU（Protocol Data Unit）。关联协商和关联释放各自使用专门的PDU类型，数据阶段则统一用P-DATA-TF PDU装载命令或数据。这部分我会结合实际排查中最常见的报文特征展开。

3.1 四种关键PDU类型与报文识别

Wireshark协议树中，DICOM PDU类型字段有明确标识。常见的有四种：

• A-ASSOCIATE-RQ（类型0x01）：关联请求，由发起方发给接受方，请求建立一个DICOM关联。
• A-ASSOCIATE-AC（类型0x02）：关联接受，表示接受方同意建立关联。
• A-ASSOCIATE-RJ（类型0x03）：关联拒绝，接受方拒绝建立关联。
• P-DATA-TF（类型0x04）：数据PDU，实际承载DICOM消息，包括命令集和数据集。
• A-RELEASE-RP（类型0x06）：关联释放响应，一方请求正常释放关联后，另一方返回释放确认。

关联拒绝包（A-ASSOCIATE-RJ）是排查集成问题时的关键线索。它包含结果字段和诊断字段。常见的拒绝原因有“没有匹配到的表现上下文”“调用AETitle未注册”“达到最大关联数限制”。从Wireshark里看到这些字段后，再回到PACS日志核对配置，问题基本能定位。

P-DATA-TF PDU内还可以再细分为多个表示数据值（PDV）。Wireshark会明确标注PDV是命令集还是数据集，以及它所关联的表示上下文ID。如果一幅图像传了一半关联被中止，通过观察PDV在哪个上下文ID上中断，就能判断是哪个SOP实例出了问题。

3.2 关联协商的关键字段：从请求包里读出配置真相

拿一个典型的A-ASSOCIATE-RQ包来说，协议树里常看到以下字段：

• 协议版本：固定为1，如果看到不是1的版本号，说明一端用的老得掉牙的协议栈。
• Calling AE Title：发起方应用实体名。设备发图时，这个字段来自设备自身的配置。
• Called AE Title：接收方应用实体名，也就是目标PACS上期望被调用的AE名。
• Application Context Name：应用上下文名，通常固定为“1.2.840.10008.3.1.1.1”，表示DICOM V3.0标准应用上下文。
• Presentation Contexts：携带抽象语法和传输语法列表，每个表现上下文都有独立的上下文ID。

我处理过一个挺典型的案例：某超声设备连不上PACS，抓包看到一个A-ASSOCIATE-RQ里Calling AE Title是“ULTRASOUND_01”，Called AE Title却是“PACSSERVER_OLD”，而PACS上新配置的AETitle是“PACSSERVER_NEW”，两个字，配置完全对不上。把设备端Called AETitle改掉后，关联立即建立。这类问题如果只盯着PACS日志看，还真不一定能一眼发现，因为PACS可能记录了“未知调用AETitle”，但不会告诉你设备端配置成了什么值。

3.3 传输语法决定数据体量：为什么同样一批图体积差好几倍

传输语法是DICOM排障和性能优化里最值得关注的字段，因为它直接决定了图像数据的实际字节量。常见的传输语法有以下几类：

• 未压缩传输语法：如Implicit VR Little Endian、Explicit VR Little Endian，存储的是原始像素数据，体积最大。
• JPEG基线有损：常见于超声、内镜等动态影像设备，压缩比高但会损失细节。
• JPEG-LS无损：在CT、MR、DR等需要保真度的场景中应用广泛，压缩率适中。
• JPEG2000：支持有损和无损两种模式，无损模式下对乳腺、断层融合这类大体积数据很友好。

在Wireshark关联协商阶段，就能看到双方就每个抽象语法最终选择了哪个传输语法。如果设备端支持JPEG2000，但PACS端没有配置对应传输语法，协商就会回退到未压缩模式，同一批射野影像的体积翻三到五倍，传输时间自然成倍拉长。这解释了为什么抓包看协商结果比盲目扩带宽更重要。

4. 实操：基于Wireshark的DICOM性能计算与瓶颈定位

排障和优化是两回事。排障搞清楚关联能不能建、命令返回正不正常；优化则要搞清楚数据到底以多大速率流经链路、消耗时间花在哪个环节。Wireshark能同时回答这两个问题。

4.1 传输吞吐量计算：一个实例看懂数据链路效率

假设某影像设备向PACS发送一个CT检查，数据集大小约1.5GB。抓包显示，从第一个包含C-STORE-RQ的P-DATA-TF帧到最后一个包含C-STORE-RSP的帧，时间戳相差约200秒。链路的理论带宽是1000Mbps（千兆）。

计算实际吞吐量的公式很简单：

实际吞吐量(Mbps) = 数据量(MB) × 8 / 传输时间(秒)

代入上面数据：1.5GB约等于1536MB，1536×8÷200 ＝ 61.44Mbps。千兆链路只跑出61M，这显然不正常。接着用Wireshark的统计功能查看TCP重传率，如果重传包占比不高，说明物理链路损包不是主因，更大的可能性是应用层逐包确认的串行化传输，或者PACS存储IO到达瓶颈。

反过来说，如果实际吞吐量在800Mbps以上，基本可以判定网络侧和DICOM传输语法侧没有问题，瓶颈大概率在接收端应用处理或磁盘阵列，没必要再去调交换机参数。

4.2 用IO Graph定位传输节奏：为什么连接空闲了3秒

Wireshark自带的IO Graph非常适用于观察DICOM传输节奏。打开路径是Statistics—IO Graph，在过滤器里输入dicom或者dicom && tcp.dstport == 104，再设置合适的间隔（比如0.5秒或1秒），就能看到DICOM流量在时间轴上的脉冲分布。

把Graph Type从“Packets”切换为“Bytes”，还能看出数据量的密集程度。如果图上出现密集发送然后长时间空白，再密集发送的锯齿状波形，说明发送端使用了窗口机制，常用块状发送等待应用层确认。如果空白间隙持续数秒，大概率是发送端在等待数据库查询或磁盘读取，这种延迟不是网络能解决的。

用多个Graph叠加可以进一步区分发送方向和接收方向。把发送端IP到PACS IP、PACS IP到发送端IP分别用不同Graph显示，就能看出传输是单向拥塞还是双方都在排队。

4.3 重传与零窗口分析：分清网络问题与应用问题

TCP重传是网络性能劣化的经典标志。Wireshark在Expert Info里会统计重传包数量。但重传多了不一定代表链路丢包，也可能是连接两端的系统TCP栈参数不匹配，比如MTU过大导致分片后丢包。这时候结合ICMP“Fragmentation Needed”和路径MTU探测结果一起看，才能定位是链路还是系统配置。

还有一种常见的“假性慢速”，症状是传输全过程几乎没有重传，但速度就是上不去。这要查零窗口现象。零窗口意味着接收方的TCP接收缓冲区已经满了，接收方暂时无法继续接收数据。在Wireshark里，看到大量“TCP ZeroWindow”和“TCP Window Update”，说明接收端应用进程来不及从内核缓冲区取数据，可能的瓶颈是PACS写入阵列太慢或应用线程数不足。这种情况下，加带宽、调交换机都白搭，得从接收端应用侧下功夫。

4.4 用会话统计快速判断大流量占用者

医院网络环境里，DICOM服务可能同时连着CT、MR、DR、超声、内镜、乳腺机等几十台设备。出现传输慢时，先看是谁在占用带宽。用Wireshark的Statistics—Conversations，翻到TCP页签，按“Bytes”排序，瞬间就能找出流量最大的几个连接。

我常用这个办法判断：是不是某台设备长期占用带宽导致其他设备排队，或者PACS存储节点某条链路已经到达饱和。如果是，直接看该连接两端的IP、端口和持续时长，顺藤摸瓜找到对应设备，再去核对它的传输语法和相关参数。

5. 常见DICOM故障排查实战与排查速查表

踩过的坑多了，就总结出了一套排查顺序。我的习惯是从关联建立开始逐层往下查，这样不会在错误层浪费时间。

5.1 关联拒绝排查链路

Wireshark里看到A-ASSOCIATE-RJ时，先展开Diagnostic字段，通常能直接看到拒绝代码。常见的几个含义：

• 拒绝原因是“Called AE Title not recognized”：接收方PACS不认识请求包里的Called AE Title，检查设备和PACS两端的AE配置。
• “Calling AE Title not recognized”：接收方不认识发起方的AE Title，需要在PACS设备注册表里加上该设备。
• “Application Context Name not supported”：两端DICOM标准版本或应用上下文名称不一致，这种多发生在老旧设备与新版PACS对接时。
• “No presentation context proposed”或者“没有可接受的表现上下文”：设备提出的抽象语法或传输语法列表，PACS一个都不支持。需要核对设备支持哪种SOP类和传输语法，再调整PACS配置。

5.2 图像传输超时与数据中断

症状是设备显示已发送，但PACS或者诊断工作站始终找不到图像。抓包后看TCP连接是否在数据阶段被RST断开。RST意味着连接被异常重置，通常是接收端应用崩溃或主动中止。此时要看RST之前的最后一个PDU是命令集还是数据集，以及有没有完整个数据帧的结束标记“DICOM数据集结束”。

如果TCP连接正常关闭，但图像没有完整落库，问题多半在接收端对PDV的重组逻辑。可以先看发送端是否把一个数据集拆成了多个P-DATA-TF发送，再核对Wireshark中每个PDU的长度字段和表示上下文ID，确认中途没有断档。

5.3 慢速传输优化：从协商到参数调整

处理“传得太慢”这类问题，我的顺序是：先确认传输语法是否选择了压缩，再看是否启用了多个并发的表示上下文，最后看应用层有没有限速参数。很多PACS集成引擎里都有“最大PDU大小”配置，默认值也许只有16384字节，如果改成65534字节，每次网络往返能携带的数据量会明显增大，传输吞吐量往往能提升百分之二十以上。抓包时在关联协商请求包里能看到对方提出的“Maximum Length Received”，如果这个值很小，说明对方主动限制了PDU尺寸，需要去调整相关配置。

还遇到过一种情况：设备每次传完一个患者检查就断开关联，等PACS处理完再重新建关联传下一个，造成大量时间和TCP握手消耗。这种情况可以通过抓包看到TCP连接频繁建立、拆除，解决办法是让设备端或集成引擎复用连接，在同一个关联里连续传多个数据集。

5.4 排障速查表：从现象到结论

6. 我实际用下来的几点工程建议

说了这么多理论，最后聊几句大实话。

抓DICOM包之前，务必先确认自己有没有权限，以及哪些数据会被抓到。DICOM里含有患者影像和敏感信息，抓包文件一旦流出机房门，就是重大隐私事故。我习惯只抓必要连接的流量，抓到后立刻把敏感字段做脱敏处理，分析完就删除，绝不长期留存。

另外，Wireshark看到的现象永远要和系统日志结合着看。抓包只能证明线上有这个流量、有这个行为，但“为什么PACS拒绝写入”这类问题，还是得回到PACS侧日志里找答案。抓包的价值是帮你把排查范围缩小，比如告诉你“问题发生在关联协商阶段”，剩下的事情交给对应系统排查，效率会高很多。

最后建议每个做医疗集成的工程师，都自己在实验室里搭一对SCU/SCP，用模拟器发一批测试DICOM文件，再用Wireshark完整抓一遍关联、存图、查询、取图的流程。亲自上手看过一遍协议表现，比背一百篇理论文章都管用。踩过几次坑之后，你会发现DICOM协议排障并不可怕，可怕的是不看包就瞎猜。