企业官网建设流程全解析

简介：Conquest DICOM Server 是一套开源的 DICOM 服务器测试工具，面向医疗影像系统开发者、集成工程师与运维人员，用于模拟 DICOM SCP 接收请求、验证设备间通信、开展 PACS 联调与数据迁移测试。压缩包约22.28MB，包含可执行程序、批处理脚本、核心 DLL、DICOM 字典以及 7-Zip 命令行工具等主要文件类型，可完成服务器启动、控制台交互、Web 安装与自动更新，也能通过字典和脚本解析 DICOM 消息、执行患者信息匿名化，为测试环境配置提供完整基础。已有718人学习下载。实际应用中，服务器可接收并存储影像、提供 worklist 工作列表服务，并借助网关组件与其他设备建立连接。阅读配套脚本与目录结构，有助于理解 SCP 工作机制、掌握监控日志与排查通信故障的方法，提升医疗影像系统集成与验收效率。

1. 先搞清楚你要测的是什么

刚接触 dicomserver 测试工具这件事时，我最大的错觉是：用网页把一张 DICOM 图传进 ConquestDICOMServer，看到“上传成功”就算测完。后来在接入第三方设备时才发现，网页网关通，不等于 C-STORE 通，更不等于设备端的 AE Title 和端口配置能被服务器认下来。所谓测试工具，不是某一个软件，而是一套按 DICOM 协议模型去探活、推图、查询、取图的方法组合：用最小命令验证网络身份，用批量脚本模拟一整天的影像吞吐，用查询条件验证 QR 服务端规则。适合做 PACS 验收、版本升级回归，以及新设备接入前的自测——这些事提前跑一遍，能省下大量现场联调时间。

2. 测试工具先立骨架：Conquest 的 DICOM 服务模型与三个关键网络参数

2.1 DICOM 不是传文件，是协商表示上下文再交换数据

很多刚上手的人会把 DICOM 通信想象成 FTP 上传，实际上它是先建立 TCP 连接，再协商表示上下文，然后按消息一条一条交换数据。表示上下文里最重要的内容是传输语法，它决定了像素数据按什么字节序、什么 VR 编码方式解析。Conquest 在收到关联请求时，会拿着自己的配置去比对客户端声明的传输语法列表，列表里没有的语法直接拒绝整个连接。

所以测试工具的第一层作用，是验证“双方能不能协商成功”。C-ECHO 是最小的协商标定测试，它不携带影像数据，只发一个空操作请求；如果 Conquest 连 C-ECHO 都拒绝，基本不用往下查影像路径，问题出在网络身份或传输语法上。如果 C-ECHO 通过而 C-STORE 失败，问题多半出在存储路径或数据库写入环节。把这两层分开看，能少走很多弯路。

2.2 AE Title、IP、端口：测之前先对齐这三个参数

DICOM 通信里设备不靠 IP 认人，靠 AE Title 认人。你在客户端写-aet TESTAET，Conquest 收到的就是这个名字；它会在日志里记录“谁来推图”以及“这个 AE 允许做什么”。如果 Conquest 配置了具体的授权 AE 列表，而你客户端用的名字不在里面，会直接收到 association rejected。测试工具要做的第一件事，就是把你准备用的 AE Title、服务器 IP、端口三个值钉死，不要在测试中途换来换去。

我一般建议把这三个参数写进一个环境变量或者配置文件里，所有测试脚本统一引用，避免命令一多就前后不一致。下表是常见的测试取值和对应翻车症状：

2.3 用配置文件把 Conquest 跑起来，端口别落在特权区

Conquest 的配置文件是 conquest.ini，字段名在不同版本之间有差异，但骨架一致。我要启动一个干净的测试实例时，会新建一份配置，把端口、存档目录、数据库连接分开设置，避免误用生产数据。下面是一份参考骨架，字段名以你本地版本自带的 conquest.ini 样例为准：

[ssc] ; 监听端口，DICOM 服务默认走这个 TCPPort = 5678 ; 连接超时（秒），设备误配时能快速失败 SSCTimeout = 30 ; 影像落地目录，测试前确认目录存在且可写 ArchivePath = D:/DICOM/Archive ; 外接数据库连接；不用外接时留空走内置存储 DBHost = 127.0.0.1 DBName = conquest

这里最容易被忽略的是SSCTimeout。它决定了一个半开连接占多久才被释放，做并发压测时如果超时设得太长，堆积的僵尸连接会把文件句柄耗光。测试环境建议直接设成 30 秒以内，线上再按需调大。另外端口尽量不要选 104 或 11112 这类特权端口，Linux 下非 root 用户无法绑定，Windows 下也容易被安全软件扫描拦截，5678 这类非特权端口做内部测试更省事。

启动完成后，先做一个不依赖任何 DICOM 客户端的自检：用系统命令看端口是否在监听。Windows 下用netstat -ano | findstr 5678，Linux 下用ss -lntp | grep 5678。看到 LISTEN 之后再上客户端工具，否则后面所有错误都会指向“服务器没起来”，排查起来没有头绪。

2.4 造一张标准的测试影像：最小 DICOM 文件的生成脚本

测试要可控，就必须用自己造的影像，而不是拿随时会变的真实病例。我一般用 Python 生态里最常用的 DICOM 解析库（import pydicom）生成最小影像，控制患者姓名、模态、像素灰度和唯一标识符。下面这段脚本生成一张 64x64 的单帧 CT，字段精简但协议字段齐全，足够跑通 C-STORE 和 C-FIND：

import pydicom from pydicom.dataset import Dataset, FileMetaDataset from pydicom.uid import ( generate_uid, ExplicitVRLittleEndian ) import numpy as np # 文件头声明：这是 CT 影像，传输语法用 Explicit VR Little Endian file_meta = FileMetaDataset() file_meta.MediaStorageSOPClassUID = "1.2.840.10008.5.1.4.1.1.2" file_meta.MediaStorageSOPInstanceUID = generate_uid() file_meta.TransferSyntaxUID = ExplicitVRLittleEndian ds = Dataset() ds.file_meta = file_meta # 患者信息写清楚，后面 C-FIND 要靠它做匹配 ds.PatientName = "TEST^PATIENT" ds.PatientID = "TEST0001" ds.Modality = "CT" ds.StudyInstanceUID = generate_uid() ds.SeriesInstanceUID = generate_uid() ds.SOPInstanceUID = file_meta.MediaStorageSOPInstanceUID # 图像基础信息 ds.Rows, ds.Columns = 64, 64 ds.PixelSpacing = [0.5, 0.5] ds.SliceThickness = "1.0" ds.BitsAllocated = 16 ds.BitsStored = 16 ds.HighBit = 15 ds.PixelRepresentation = 0 ds.SamplesPerPixel = 1 ds.PhotometricInterpretation = "MONOCHROME2" # 均匀灰度的像素，避开压缩分支，只测协议层 ds.PixelData = np.full((64, 64), 100, dtype=np.uint16).tobytes() ds.save_as("test_ct.dcm", enforce_file_format=True) print("已生成 test_ct.dcm，SOP:", ds.SOPInstanceUID)

代码里有两个关键点：一是显式指定TransferSyntaxUID为 Explicit VR Little Endian，避免生成器用默认的 Implicit VR 造成服务器不支持；二是用generate_uid()生成唯一标识符，多张影像连续推送时不会因为 UID 重复被服务器去重，导致你以为丢了数据。像素用固定灰度值，是为了排除压缩、调窗等干扰，让测试结论集中在协议链路上。

如果你要测动态范围更大的场景，可以在生成后改一段像素再另存一份，改 PatientID 和 StudyInstanceUID 就能模拟不同患者、不同检查。这样一套脚本能造出几十张形态相似但属性不同的影像，比从真实设备拷贝文件更灵活。

3. 协议级测试：用 C-ECHO、C-STORE、C-FIND、C-MOVE 逐项验收 Conquest

3.1 C-ECHO：探活命令怎么写，返回看什么

C-ECHO 是 DICOM 世界的 ping。它不传业务数据，只验证两件事：网络通不通、AE Title 认不认。很多设备的 DICOM 设置界面里都有一个“测试连接”按钮，底层发的就是 C-ECHO。我们自己下手时，用开源 DICOM 命令行工具集里的 echoscu 就够了，下面是一个最小命令：

# -aet 是客户端 AE，-aec 是服务器 AE，最后是服务器 IP 和端口 echoscu -v -aet TESTAET_01 -aec CONQUESTSRV -td 15 127.0.0.1 5678

各参数含义：-v打印完整请求响应过程；-aet告诉服务器这次关联请求来自谁；-aec是你要呼叫的服务器 AE Title，如果与 Conquest 配置不一致，服务器通常会直接拒绝；-td是连接超时时间，设成 15 秒是为了让失败快速返回，而不是卡在系统默认的几分钟。像这样逐参数说清楚之后，你换别的实现时也能类推。

成功后返回里会有Response: Success之类的字段，同时伴随一个耗时值。我一般会把耗时记下来，连续测三次，取一个中位数作为基线。如果三次里有一次失败，先看是不是-aec拼写和大小写问题，再看端口扫出来到底是什么状态。C-ECHO 的成功只代表关联层 OK，影像能不能落库，要继续往下测。

3.2 C-STORE：真正把影像送进去，存储路径成功与否全看这里

C-ECHO 通了只说明双方能握手，真正要验证的是 Conquest 能不能把影像文件落到存档目录、能不能把记录写进数据库。这一步用 storescu 推刚才生成的 test_ct.dcm：

# 推单张：-v 输出每个 DICOM 消息的收发状态 storescu -v -aet TESTAET_01 -aec CONQUESTSRV 127.0.0.1 5678 test_ct.dcm

看到正常结束的标志是最后一行带C-STORE: 0或Success字样，同时 Conquest 的日志里会出现一条完整的存储记录。这里我要强调一个排查思路：如果命令报 rejected，不要急着怀疑服务器，先看一眼本机到服务器端口的连通性，再拿-aec和 conquest.ini 里配置的 AE Title 做逐字符比对，最后才轮到去改传输语法列表。

如果报Unable to negotiate这一类错，大概率是表示上下文没有交集。常见做法是给 storescu 加上手动指定传输语法的参数，把客户端限定在 Conquest 支持的语法上。大多数版本里 Conquest 同时支持 Implicit VR Little Endian 和 Explicit VR Little Endian，优先使用 Explicit 通常最稳。部分实现里参数写法略有差异，先用工具的-h确认一下参数名。

3.3 C-FIND：查询条件与匹配规则，别让空结果骗了你

C-FIND 验证的是 Conquest 的查询检索能力，也就是它的 Q/R 服务端规则。这个环节的坑和 C-STORE 完全不在一个层面，很多 C-STORE 跑得好好的环境，一上来查不到任何数据。原因通常是查询模板里写了太多字段，或者使用了错误的匹配语法。下面用 findscu 做一次按患者姓名通配的查询：

# -m 指定匹配键 PatientName 用 * 通配，StudyDate 限定最近一年 findscu -v -aet TESTAET_01 -aec CONQUESTSRV -m PatientName="*" -m StudyDate="20240101-20251231" 127.0.0.1 5678

这里有一个 DICOM 匹配规则的细节：PatientName 用*做通配是通用行为，但 Conquest 的某些版本对大小写敏感，test和TEST会返回不同结果。日期区间用YYYYMMDD-YYYYMMDD格式，中间是短横线；如果你只写20240101，某些版本会按单日精确匹配。空字符串在 DICOM C-FIND 里是“全部匹配”的意思，不是“匹配空值”，这一点和 SQL 的习惯完全不同。

如果查询返回空，先换一个最小条件，比如只按 StudyInstanceUID 精确查，能查到说明数据在库里，问题出在复杂条件的匹配规则上；查不到就要回头检查 C-STORE 那一步是否真的成功了。我习惯把 C-FIND 的查询条件写成一个脚本文件，每次只改一个键，避免一个复杂模板里不知哪一环节出了错。

3.4 C-MOVE：把数据拉回来，Move AET 配置错了会推错地方

C-MOVE 和 C-FIND 一样是查询接口，区别在于 C-FIND 返回的是查询结果列表，C-MOVE 会触发服务器主动向某个 AE 推数据。这里的核心参数叫 Move AET，也就是“服务器要把影像推到谁那里”。你必须在本地打开一个监听端口的 DICOM 接收服务，再把那个服务的 AE Title 告诉 Conquest，否则服务器推出去的包没人接收，命令会报no association或move destination unknown。

# -p 指定本地监听端口，-aem 声明本地接收 AE，服务器会回调这个 AE movescu -v -aet TESTAET_01 -aec CONQUESTSRV -aem TESTAET_01 -p 11113 -m StudyDate="20240101-20251231" 127.0.0.1 5678

命令里-aem是对端的 Move 目标 AE，这个值不是随便写的，它必须和本地监听服务启动时注册的 AE 完全一致。如果 Conquest 配置了目的 AE 到 IP 的映射表，你还要保证映射表里 TESTAET_01 指向本机 IP 和 11113 端口。这一条是最容易翻车的地方，我见过多次 C-MOVE 返回成功后影像出现在别的节点上，原因就是映射表写错。拉取成功后再用文件工具核对本机 11113 端口收到的文件数，才算闭环。

4. 模拟真实影像链路：批量投递、并发压力与存储一致性测试

4.1 用循环脚本模拟单台设备一天的真实产量

单张测试通过后，下一步是模拟一台设备一整天的推送节奏。设备的特点是每做完一个检查就推一组图，几秒一批，批量不大但频率稳定。用循环脚本就能模拟，关键是中间加一个随机间隔，不要让所有推送在同一个时间点爆发：

# 模拟单个设备一天 200 次检查，每次间隔 0 到 2 秒随机 for i in $(seq 1 200); do cp test_ct.dcm img_$i.dcm storescu -aet CAMERA_01 -aec CONQUESTSRV 127.0.0.1 5678 img_$i.dcm >> push_$i.log 2>&1 sleep $((RANDOM % 3)) done

每跑完一批要统计一下成功率。统计时只数 C-STORE 响应的成功标志，别去看日志里有没有连接记录，连接记录不代表落库成功。脚本跑完，先对比一下存档目录里的文件个数，再用 C-FIND 按日期查一次，做到“推了多少张、库里有多少条、目录里有多少文件”三处一致。三处对不上，优先怀疑重复 UID 被覆盖或者推送超时后没有重传。

4.2 多设备并发投递：xargs -P 与日志观察

单设备的节奏模拟完，还差多设备并发。真实环境里一台 Conquest 可能同时接收 CT、DR、超声几台设备的数据，峰值出现在上午检查高峰段。压测手法和测 API 并发很类似：把任务并行度提上去，然后盯服务器的日志和连接数。下面用xargs -P控制并发数：

# 生成 50 个推图任务，同一时刻最多 5 个进程并发投递 seq 1 50 | xargs -P 5 -I{} \ storescu -aet DEV_{} -aec CONQUESTSRV 127.0.0.1 5678 test_ct.dcm \ >> xargs_{}.log 2>&1

并发数不要一拍脑袋定 50，先按真实设备数量的两倍设，比如 4 台设备就设 8。跑的过程里另开一个终端观察ss -lntp，看 Conquest 监听端口上 ESTABLISHED 连接是否持续堆积；同时tail -f它的日志文件，记录每分钟新入片的数量。如果连接数一路涨不回落，说明处理器或数据库写入跟不上，这不是并发脚本的问题，是服负重已经到了上限。

压测结束后还有一个容易被忽视的步骤：到存档目录里数文件数，看有没有因为并发写入导致文件名冲突或半截文件残留。出现半截文件时，Conquest 日志里通常可以看到传输中断的记录，这类情况不影响已落库的影像，但会让你知道服务器的异常中断处理能力。

4.3 存储落地与数据库一致性：文件数核对，别被“上传成功”骗了

C-STORE 返回成功只代表服务器接收了数据，不代表数据库里一定有一致记录。Conquest 默认的存储流程是先把影像写进存档目录，再登记数据库索引；如果第二步失败，日志里会有报错，但客户端看到的可能还是成功。所以每轮压力测试结束，我要做的事有两件：数文件，和用 C-FIND 反查。

文件数核对可以一行命令完成，Windows 下用 dir 统计，Linux 下这样数：

# 数存档目录下所有 .dcm 文件数量，和推送总数对一下 find /data/conquest/archive -type f -name "*.dcm" | wc -l

影像文件数一致后，再用 C-FIND 按 StudyDate 和 Modality 查一遍所有记录，得到的条数理论上和文件数一致。这里我习惯把统计手法做得和测硬盘读写速度测试工具那样——先跑一轮小样本取基线，再压到满负荷看曲线，最后看回落是否平稳。DICOM 服务器本身就是一个网络加磁盘加数据库的复合链路，任何一环掉速都会表现为“文件够了但查询慢”或者“查询快但文件数对不上”。

4.4 中断与重传：杀进程、断网后看什么

压力测试通过不代表一切正常，DICOM 设备在真实场景里经常遇到网络抖动，传输到一半连接断掉。我要模拟这种场景时，会在 storescu 推送过程中直接kill -9掉客户端进程，然后观察 Conquest 侧的行为。重点看三件事：存档目录里有没有残留的半截文件、日志里有没有记录失败的子操作、以及同一张图重新推送时能否正常覆盖。

# 推送大文件的过程中强制杀掉客户端，模拟网络异常中断 storescu -aet TESTAET_01 -aec CONQUESTSRV 127.0.0.1 5678 big_study.dcm & sleep 2 kill -9 $!

杀完进程后，重新用正常参数再推一遍同一张图，如果 Conquest 根据 SOP Instance UID 做了去重，第二次推送会很快返回成功，并且文件不重复；如果直接生成了第二个文件，说明服务器端没有做去重处理，后续做数据迁移时要小心重复影像。这一步能提前暴露服务器在异常恢复上的表现，比等到设备接入现场再发现问题省心得多。

5. Conquest 测试中的高频翻车与排查清单

5.1 C-ECHO 通、C-STORE 必败：八成是传输语法协商没对齐

现象：echoscu 每次都成功，换成 storescu 推同一张图，立刻报 Unable to negotiate。原因在于 C-ECHO 用的表示上下文非常单一，几乎所有服务器都支持；而 C-STORE 要求客户端声明一个具体的影像传输语法，服务器只在两者有交集时才接受关联。解决方法是先确认服务器支持的传输语法列表，再把客户端指定到同一个语法上。测试工具里一般都有强制指定传输语法的参数，设成 Explicit VR Little Endian 后绝大多数 Conquest 配置都能通。

5.2 C-FIND 有数据却返回空：通配符、日期格式、空值规则

现象：数据确认已经推进去了，C-FIND 按患者姓名查却一条都查不到。原因通常是查询条件里的匹配键写法不对，PatientName 通配符在某些版本里只认大写，日期范围中间用了英文逗号而不是-，或者查询层级写成了 PATIENT 而实际数据在 STUDY 层级下。解决办法是把查询条件逐步简化，先按 StudyInstanceUID 精确查，查到后再把条件一个个加回去，每加一个键查一次，定位到是哪一条规则没匹配上。DICOM C-FIND 的空值语义与 SQL 不同，空字符串反而匹配所有值，这一点要特别记住。

5.3 C-MOVE 拉回一堆不该有的影像：Study 级别匹配会把整个检查都带走

现象：本意是拉一个序列的几幅图，C-MOVE 返回成功后却收到整个检查上百幅图。原因是查询模板里查询级别默认停在 STUDY，而 C-MOVE 按这个级别把整个检查的所有序列都推了过来。解决办法是明确查询级别，在命令里指定查询键的层级为 SERIES，并给查询条件加上 SeriesInstanceUID 或具体序列号。如果查询模板是文件形式，直接改文件里的 QueryRetrieveLevel 字段；如果是命令行，通常会对应一个级别参数，设成 SERIES 后重测。

5.4 Conquest 重启后查询不到刚推的图：数据库与文件目录不同步

现象：推送成功、文件也在存档目录里，重启 Conquest 后用 C-FIND 查不到任何记录。原因多出在数据库索引没有及时刷新，或者启动时数据目录指向了另一套路径。解决方法是先检查 conquest.ini 里存档路径和数据库路径是否真的是刚才写入的那一套，路径没错就重建索引。Conquest 一般带有扫描存档目录并重建数据库索引的功能，跑完一遍后 C-FIND 就能查到了。这个坑在测试环境常见，因为测试时经常改配置路径，改了路径忘了扫库是常态。

5.5 中文患者姓名乱码：字符集字段没写，或者 Padding 规则不对

现象：C-STORE 正常，但 C-FIND 返回的患者姓名是乱码，或者查询时中文名永远匹配不上。原因通常有两个：一是生成的 DICOM 文件里没有写 SpecificCharacterSet 字段，服务器按默认字符集解析中文就变成乱码；二是姓名两边没补空格，DICOM 字符串字段有固定的 Padding 规则。解决办法是在造影像脚本里显式设置字符集，中文字符集常见值是 GB18030，输出端也按同一字符集解码。测试脚本最好把字符集和姓名写到同一个常量里，后面换任何数据集都先改常量再跑，避免只改一处漏一处。

6. 把测试工具沉淀成回归脚本：升级前后三分钟出结论

6.1 一键体检脚本：echo、store、find、文件数核对一条龙

单条命令测试做多了之后，我习惯把整个流程封装成一个脚本，参数全部放顶部，每次换服务器只改常量，不碰逻辑。脚本顺序固定为 C-ECHO 探活、C-STORE 推送、C-FIND 反查、文件数核对，任何一步失败直接以非零退出码结束，方便接入 CI 或者自动化巡检：

import subprocess, sys, time HOST = "127.0.0.1" PORT = "5678" AET = "REGR_TEST" CALL = "CONQUESTSRV" DCM = "test_ct.dcm" def run(cmd): p = subprocess.run(cmd, capture_output=True, text=True) return p.returncode, (p.stdout + p.stderr) # 第一步：协议探活 code, out = run(["echoscu", "-aet", AET, "-aec", CALL, HOST, PORT]) print("C-ECHO:", "OK" if code == 0 else out) if code != 0: sys.exit(1) # 第二步：推图 code, out = run(["storescu", "-aet", AET, "-aec", CALL, HOST, PORT, DCM]) print("C-STORE:", "OK" if code == 0 else out) if code != 0: sys.exit(1) # 第三步：按 PatientID 反查入库记录 code, out = run(["findscu", "-aet", AET, "-aec", CALL, "-m", "PatientID=TEST0001", HOST, PORT]) print("C-FIND:", "OK" if code == 0 else "查不到，检查落库") if code != 0: sys.exit(1) print("回归体检通过")

脚本里的每个步骤都对应前面章节验证过的一个协议行为。C-ECHO 不通过就退出，不浪费时间去跑后续；C-STORE 失败会附带完整输出方便现场定位。这里没有写文件数核对，是因为不同后端的数据目录结构不一样，留给你按实际环境补一条路径统计。我自己的习惯是把输出追加到一个带时间戳的日志文件里，跑完再看一眼最后的 PASS/FAIL 标记。

6.2 基准数据留档：升级前后对比，三分钟定位回归

脚本能跑只是第一步，第二步是把结果留档。我会在升级 Conquest 前先跑一次完整脚本，把每步耗时和输出存成 json 文件，升级后再跑一遍，两个文件做 diff。格式大致是每条记录带时间戳、C-ECHO 耗时、C-STORE 耗时、C-FIND 返回条数。大多数回归问题并不表现为直接失败，而是表现为“以前 20 秒推完的 200 张图，现在要 40 秒”，这类性能回归没有基线根本没法察觉。

有一次我在升级后跑回归，C-ECHO、C-STORE 全过，唯独 C-MOVE 拉回来的文件比推送的少了十几张，原因是对端版本把查询层级从 SERIES 改成了默认的 STUDY。这不算 Conquest 自身的故障，但却是测试工具最有价值的发现——它说明协议行为在版本之间是会变的，不能只看 “通没通”，还要看返回的数量和路径。自那以后我的回归脚本里都会加一个“C-MOVE 拉取文件数与推送文件数对比”的断言，用这个习惯兜底。希望这篇笔记里的命令和排查路径能帮到你，把 Conquest 的测试从“凭感觉试”变成一套随时能复现、能对比的流程。

本文还有配套的精品资源，点击获取