搞医院网络的人多半都有过这种经历技师那边明明按了发送影像科诊断工作站却死活等不到图或者诊断医生打开某患者检查列表缩略图一直转圈过了几分钟才提示超时。服务器没宕机、网络交换机也没报警问题到底出在哪我干了这些年医疗信息化集成得出的结论是这种“假死”十有八九是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。SCUService Class User是服务调用方发起请求SCPService Class Provider是服务提供方接收请求并执行操作。拿实际场景举例CT设备向PACS发送图像CT就是C-STORE SCUPACS就是C-STORE SCP诊断工作站查询患者列表工作站是C-FIND SCUPACS是C-FIND SCP。同一个软件系统在不同的服务里可以扮演不同角色这种角色模型经常被等价于“客户端-服务器”但更准确的理解是“服务调用-服务响应”。在Wireshark的DICOM解析结果里SCU发的命令叫请求例如C-STORE-RQSCP回的叫响应例如C-STORE-RSP。通过消息类型字段配合消息ID、关联上下文ID就能把同一操作的一来一回对应起来。这对于判断操作是否成功非常有用因为DICOM的错误反馈并不是靠TCP断开表现的而是靠响应包里的状态码表达的。1.3 AETitle、端口与上下文的三角关系DICOM排障中AETitle是绕不开的概念。AETitleApplication 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应用层通信的基本单位叫PDUProtocol 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约等于1536MB1536×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 排障速查表从现象到结论抓包现象可能原因建议处理方向A-ASSOCIATE-RJCalled AE不识别设备端目标AE配置错误核对设备与PACS两侧AETitleA-ASSOCIATE-RJCalling AE不识别PACS未注册设备在PACS设备管理中添加该AE关联建立但C-ECHO无响应服务端应用线程阻塞查PACS日志与磁盘状态C-STORE-RSP状态码非0x0000存储服务拒绝或空间不足根据状态码定位SOP类或存储目标P-DATA-TF持续发送但吞吐量极低PDU最大值协商过小调大最大PDU长度并重新协商大量TCP ZeroWindow接收端应用读取速度慢排查PACS存储IO和应用线程大量TCP重传链路丢包或MTU问题检查物理链路、交换机端口及MTU传输完成但PACS无影像数据集未发完整或存储异常检查末段PDU和PACS归档日志6. 我实际用下来的几点工程建议说了这么多理论最后聊几句大实话。抓DICOM包之前务必先确认自己有没有权限以及哪些数据会被抓到。DICOM里含有患者影像和敏感信息抓包文件一旦流出机房门就是重大隐私事故。我习惯只抓必要连接的流量抓到后立刻把敏感字段做脱敏处理分析完就删除绝不长期留存。另外Wireshark看到的现象永远要和系统日志结合着看。抓包只能证明线上有这个流量、有这个行为但“为什么PACS拒绝写入”这类问题还是得回到PACS侧日志里找答案。抓包的价值是帮你把排查范围缩小比如告诉你“问题发生在关联协商阶段”剩下的事情交给对应系统排查效率会高很多。最后建议每个做医疗集成的工程师都自己在实验室里搭一对SCU/SCP用模拟器发一批测试DICOM文件再用Wireshark完整抓一遍关联、存图、查询、取图的流程。亲自上手看过一遍协议表现比背一百篇理论文章都管用。踩过几次坑之后你会发现DICOM协议排障并不可怕可怕的是不看包就瞎猜。