企业官网建设流程全解析

简介：Conquest DICOM Server 是一款开源的 DICOM 服务器测试工具，适合医疗影像领域的开发人员、系统集成工程师和运维人员使用。该工具以 DICOM SCP 身份运行，能够接收并处理来自 PACS 或其他设备的 DICOM 请求，支持工作列表查询，可用来模拟真实临床环境中的影像交换与预约流程，辅助验证网络通信的正确性。压缩包大小 22.28MB，里面包含可执行程序、批处理脚本、DICOM 字典、匿名化脚本、动态链接库等多种文件类型，分别覆盖服务器启动、自动更新与安装、消息解析、患者数据脱敏以及核心协议处理等关键环节，并提供控制台交互和网关连接能力，方便监控状态与跨设备联动。该资源已有 710 人学习浏览。借助这些文件，读者可以快速搭建本地 DICOM 测试环境，检查新设备或新软件的兼容性，通过日志分析评估服务器性能，在异构 PACS 间迁移数据时充当中间代理，同时利用匿名化脚本保护患者隐私。尤其适合系统上线前的联调与验收测试。掌握这套工具后，开发 DICOM 应用或管理医疗影像系统都会更加高效、准确。 做医学影像相关的开发，最烦的事情不是功能实现，而是缺一台能随时“折腾”的 DICOM 服务端。对接医院真实 PACS 成本高、权限严，不可能让你随便发几张测试图、跑几个查询。dicomserver测试工具里我常用的一台靶机就是 ConquestDICOMServer。它轻量、免费、单文件就能跑起来，非常适合用来模拟 PACS 行为、验证 C-STORE/C-FIND/C-MOVE 流程，或者给 DICOM 工作站做联调测试。如果你也在找一套能快速部署、又足够接近真实 DICOM 服务的测试环境，这篇文章可以直接参考。

1. 为什么我拿 Conquest 当 DICOM 测试的靶机

先说说我的使用场景：平时开发 DICOM 客户端、写图像传输脚本、调试 RIS 或工作站对接，最需要的是一个能自主控制的 SCP（Service Class Provider）服务端。真实 PACS 不能随便动，DCMTK 自带的storescp只能做最简单的接收，功能不够。Conquest 这个老牌开源项目在测试场景里就特别顺手。

Conquest 的核心能力不复杂，但它把最常用的 DICOM 服务都覆盖了：

• C-ECHO：验证网络和 AE 连接是否通
• C-STORE：接收客户端推过来的 DICOM 文件
• C-FIND：按患者、检查、序列等层级查询数据
• C-MOVE：把存储的 DICOM 文件推送到指定的接收端
• 数据库索引：默认支持 dbase、SQLite、MySQL，可以按 PatientID、StudyDate 等条件检索

我选 Conquest 最重要的一点是“可摧毁性”。测试环境里的服务端必须经得起反复清空数据、改配置、重启，甚至删掉重装。Conquest 的数据目录和配置文件都是独立的，删了不影响系统，重来一遍也就几分钟。这一点在联调阶段被坑过的人都知道有多重要。

和其他常见 DICOM 服务端相比，Conquest 的定位很明确：

所以我的结论很直接：如果只搭一个“够用又可控”的测试靶机，Conquest 是性价比最高的选择。

2. 从零搭起 Conquest DICOM Server 测试环境

2.1 安装包选型和目录规划

Conquest 的官网提供 Windows、Linux 和 macOS 版本，测试环境建议直接用二进制发行版。Windows 下解压 zip 到一个路径里，比如C:\Conquest，注意路径里尽量不要带空格和中文。Linux 下可以下载 tar.gz 包，解压后放在/opt/conquest或用户目录下。

解压出来的文件里，核心是：

• dgate.exe/dgate：服务进程，负责监听 DICOM 端口
• dicom.ini：主配置，服务端口、AE Title、数据库类型都在这里
• dgate.log：运行日志，测试排查全靠它
• data/目录：默认接收和索引 DICOM 文件的地方

如果准备长期跑，建议把数据目录单独建出来，比如data目录放到独立磁盘或专门分区，方便后期清理和备份。这个习惯在测试机上也值得保留，因为反复初始化数据库时，数据目录越干净越好。

2.2 dicom.ini 里的关键修改项

第一次启动前，必须改dicom.ini。直接双击运行是能起来，但不改配置的话，数据库类型、AE Title、端口可能都不符合你的测试计划。

我通常先改这几个关键项：

# 数据库类型，测试环境推荐 SQLite，稳定且方便备份 DatabaseType = sqlite # 服务监听端口，默认 5678，被占用的时候自己换 TCPPort = 5678 # 本服务的 AE Title，客户端连过来时要用 MyACRNema = DICOM # 数据库文件存放路径 SQLiteDatabase = data\conquest.db

重点解释一下DatabaseType。Conquest 默认使用 dbase 格式，老项目里很常见，但 dbase 在数据量大了之后稳定性一般，而且索引文件散落。换成 SQLite 之后，整个索引就是一个conquest.db文件，测试时想备份或者清空都特别方便。第一次切换后，需要清空数据目录初始化一个新的数据库，否则可能报错。

MyACRNema就是本服务器对外暴露的 AE Title，默认是DICOM。很多客户端工具默认 AE Title 也是大写，这里保持大写最简单，避免因为大小写不一致连不上。

2.3 启动服务并确认端口监听

Windows 下可以直接双击dgate.exe，也可以注册成 Windows 服务。注册服务的命令是：

dgate -install

然后到服务管理器里启动Conquest DICOM Server服务就行。如果只是临时测试，前台运行更直观，日志直接打在控制台，方便一边发数据一边看。

Linux 下直接执行./dgate，如果报缺库，先确认 32 位兼容库是否装上。启动后检查端口：

ss -lntp | grep 5678

能看到监听就说明服务起来了。再用dgate.log确认数据库初始化是否正常，日志里通常会有类似“SQLite database opened”的信息。

3. 用 DCMTK 命令行工具把 Conquest 各项服务打一遍

3.1 C-ECHO：先确认链路通不通

不管调试什么 DICOM 服务，我都习惯先用 C-ECHO 打头阵。C-ECHO 不发真实图像数据，只交换一个 DIMSE 消息，能通就说明 IP、端口、AE Title 都配对成功了。

DCMTK 里用echoscu：

echoscu -v -aet TESTC 127.0.0.1 5678

注意这里-aet是客户端自己的 AE Title，可以随便起，但不能为空。Conquest 默认不校验客户端 AE Title，所以TESTC这种名字也能通过。如果加了-aec指定服务端 AE Title，就必须跟dicom.ini里的MyACRNema完全一致。

连接超时或者被拒绝时，先别急着调客户端。我一般按这个顺序排查：

• 端口监听是否正常：ss -lntp或netstat -ano
• Windows 防火墙是否拦截了 5678
• Conquest 是否真的在运行，日志最后一行有没有报错

3.2 C-STORE：验证图像能不能收

C-ECHO 通了，标志链路没问题。接着就要验证最核心的 C-STORE——把 DICOM 文件推给 Conquest。

测试前需要一张 DICOM 文件。最简单的办法是用 DCMTK 自带的dcmdata工具转换一张普通图片，或者从之前测试数据里拿一张。手头没有数据时，可以用storescp配合dump2dcm手工造一个最小 DICOM 文件，但更快的办法是直接下载公开的样例数据。

发送命令：

storescu -v -aet TESTC -aec DICOM 127.0.0.1 5678 test.dcm

看到C-STORE返回 Success 状态码，就说明 Conquest 已经接受了这份文件。想知道对方到底落没落盘，可以去data目录看有没有生成新的 DICOM 文件，或者看dgate.log里有没有对应的存储记录。

我见过不少人在这里犯迷糊：C-STORE 返回成功后，敲命令的终端就丢下不管了，从来不看日志。但测试过程中，客户端收到 Success 只能说明服务端协议层处理了，数据库索引是否建立成功、文件是否写完整，都要靠服务端日志确认。养成每次发送后扫一眼日志的习惯，能少踩很多隐蔽的坑。

3.3 C-FIND：验证数据被正确索引

光能收图还不够，一个 PACS 系统还得能被查询。C-FIND 是验证数据索引是否建好的最直接方式。

Conquest 默认允许 C-FIND 查询，但需要按层级指定查询条件。用 DCMTK 的findscu发一个按 STUDY 级别的查询：

findscu -v -S -aet TESTC -aec DICOM \ -k QueryRetrieveLevel=STUDY \ -k StudyDate \ -k StudyInstanceUID \ 127.0.0.1 5678

返回结果里能看到 Conquest 把已存储的研究信息列出来，说明数据库索引工作正常。如果查询结果为空，先确认是不是发了 IMAGE 级别的查询但数据里没有对应的 SOP Instance UID；也可以直接在 Conquest 自带的 GUI 里搜一下患者，看看数据到底在不在库里。

C-FIND 在真实 PACS 场景里非常依赖 AE Title 和权限配置。Conquest 测试环境里默认全放行，能省不少事，但也意味着某些权限相关的边界问题在 Conquest 上复现不出来。如果是为对接真实 PACS 做预研，这一点心里要有数。

3.4 C-MOVE：验证服务端能否主动推图

C-MOVE 是查询-取回流程里的关键动作。客户端向 Conquest 发一个 C-MOVE 请求，Conquest 随后主动向目标 AE 发起 C-STORE，把匹配的图像推送到指定接收端。

这个动作比 C-STORE 复杂，因为需要一个“接收端 SCP”在那边老老实实等着。我通常的做法是同时开两个终端：

终端 A 起一个storescp作为接收端：

storescp -v -aet RECEIVER 11112

终端 B 发 C-MOVE 请求：

movescu -v -aet TESTC -aec DICOM -aem RECEIVER \ -k QueryRetrieveLevel=STUDY \ -k StudyInstanceUID=1.2.3.4.5 \ 127.0.0.1 5678

注意-aem RECEIVER必须和storescp里的-aet RECEIVER一致。C-MOVE 的语义就是：Conquest 收到这个请求后，会把匹配的数据主动推给 AE Title 为RECEIVER的那台机器。如果接收端没起，或者 AE Title 对不上，Conquest 日志里会明确报错。

这里常见的问题是很多人忘了 ConQuest 的 C-MOVE 需要目标 AE 被识别。有的 PACS 会有“已知 AE”白名单，Conquest 测试环境虽然放开，但也需要接收端先跟 Conquest 建立过联系，或在配置中注册。如果 movescu 报 “Unknown AE Title”，就去dicom.ini里检查KnownAETitles是否配置正确。

4. Conquest 配置与测试中容易踩的暗坑

4.1 AE Title 大小写与空格的幽灵问题

AE Title 是 DICOM 协议里最基础也最容易被忽略的字段。规定是大小写敏感，且不能包含空格。Conquest 在匹配 AE Title 时比较严格，dicom和DICOM会被当成两个完全不同的实体。

我在迁移测试环境时踩过一次：旧的初始化脚本里用的是DICOM_SERVER，换了新服务器后配置写成DICOM，客户端没改，结果 C-ECHO 一直超时。排查半天才发现是 AE Title 不一致。所以建议测试环境里把所有 AE Title 统一定义，客户端、服务端、自动化脚本里都用同一个字符串常量，不要手敲。

4.2 换数据库类型后旧数据不生效

前面推荐了 SQLite，但如果你是从默认 dbase 切换过去的，最典型的坑就是服务起来了，但查不到之前收的图像。原因很简单：数据库类型变了，Conquest 需要重新初始化数据索引，旧数据不会自动迁移。

解决办法不是手动搬文件，而是：

• 停掉 dgate
• 清空data目录（或备份后删掉）
• 启动服务，让它用 SQLite 重新建库
• 用 C-STORE 重新发一遍测试数据

如果不想丢掉旧数据，就得用 Conquest 自带的导入/导出功能把 DICOM 文件重新索引。测试环境里重发的成本很低，直接清库反而最省事。

4.3 端口和防火墙的组合拳

很多刚接触的人 C-ECHO 连不上，第一反应是配置错了。其实八成是防火墙或者端口占用。

Windows 上跑 Conquest，服务装好后要额外放行端口。更隐蔽的是某些安全软件会拦截 dgate.exe 进程的网络通信，服务看着在跑，端口也监听，但外面的请求就是进不来。遇到这种情况，直接看 dgate.log，如果只有连接接受记录、没有完整 DIMSE 交互，那多半是网络层问题。

Linux 下相对好排查，tcpdump -i lo port 5678直接抓本地回环包，几秒钟就能确认请求有没有到服务进程。

4.4 日志级别别开太低

Conquest 的dgate.log在测试阶段是最好的调试工具。默认日志级别有时太简略，看不到 C-STORE 存储细节。可以适当调高日志级别，比如在配置里把日志设置为显示 DIMSE 消息和数据库操作记录。

日志级别开高会带来一个问题：大量并发压测时日志写入会拖慢性能。所以我的习惯是：功能验证阶段开高，压测之前调回默认。

5. 进阶玩法：把 Conquest 融入自动化回归测试

命令行工具手动验证是一层，如果团队里有自动化测试需求，Conquest 完全可以当固定靶机，配合脚本做 DICOM 全流程回归。我目前的测试框架里，就用 Bash 脚本封装了 echoscu、storescu、findscu、movescu 四个阶段：

• 第一步：C-ECHO 验证服务在线
• 第二步：C-STORE 推送一组测试 DICOM 文件
• 第三步：C-FIND 查询这批 StudyInstanceUID，断言返回条数
• 第四步：C-MOVE 将数据拉到本地临时目录，用dcmftest检查拉取文件的完整性

每个阶段都可以用脚本判断返回值，任何一个失败就直接终止并输出日志。这样每次代码改动后跑一遍，能快速发现网络配置、数据库索引之类的回归问题。

Conquest 的服务端日志在自动化里也很重要。脚本跑完后，我会自动 grepdgate.log里的 ERROR 和 Warning 关键词，全部为空才算通过。这样即使 DICOM 协议层面返回成功，服务端内部如果有异常也能被捞出来。

这套流程看着简单，但对保证 DICOM 对接质量非常有效。我现在每接一个新影像系统，都会先拿 Conquest 跑一遍这套回归脚本，确认基础链路没问题，再去和真实设备联调，能省下大把来回排查的时间。

如果你也是刚接触 DICOM 测试，建议先照着前面的步骤把 Conquest 搭起来，用 DCMTK 把 C-ECHO、C-STORE、C-FIND、C-MOVE 各跑一遍。这四个流程通了，你对 DICOM 服务端的工作机制也就有了一个直观的整体认识。

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