Docker 容器化部署 EtherNet/IP 协议栈（ESDK）：Windows 与国产银河麒麟 V10 实测对比

一、 背景：为什么要将 ESDK 容器化？

在工业 4.0 场景下，传统的 EtherNet/IP (EIP) 协议栈部署往往受限于操作系统环境。ESDK (EtherNet/IP Scanner Development Kit) 作为实现 CIP 协议的核心组件，通过 Docker 进行容器化封装，可以实现“一次开发，全现场部署”。

本文将记录 ESDK 在 Windows 10/11 (WSL2) 与 国产化操作系统银河麒麟 V10 环境下的网络模式与通信端口实测结果。

二、 环境准备

测试涉及两个典型的开发与运行环境：

三、 核心技术点：Docker 网络模式

对于 EIP 协议，TCP 44818 (显式报文) 和 UDP 2222 (隐式 I/O) 是核心端口。在 Docker 部署时需注意：

• Bridge 模式：需手动映射 -p 44818:44818 和 -p 2222:2222/udp。

• Host 模式：建议在国产 Linux 环境下使用 --net=host，以获得最佳的实时性并支持组播报文。

四、 实测结果对比

• 稳定性：ESDK 进程在 Docker Desktop 环境下运行极度稳定，无异常退出。

• 网络连通性：得益于 WSL2 的网络转发，容器内部的 Scanner 与外部真实的 PLC 或模拟器通信完全正常。

• 兼容性：ESDK 完美适配银河麒麟内核，无需额外补丁。

• 启动速度：冷启动时间保持在 3-5 秒，适合工业现场快速恢复业务。

五、 终端日志逻辑复盘（重点）

通过日志我们可以清晰地观察到 CIP 协议在容器内的交互流程：

1. 适配器（Adapter）端启动与对象注册：
在容器内运行 ./ConsoleApp3，可以看到协议栈成功注册了 Class 7F 自定义应用对象。

codeBash

Custom Application Object registered:
   Class 7F, Instance 1, Attributes 1(Get), 2(Get), 3(Get), 4(Get/Set 2 bytes)
Waiting for a request...

2. 扫描器（Scanner）端非连接请求测试：
运行 ./ConsoleApp2 发起请求。

• 初次报错：ID 256/257 返回错误，提示路径引用了未知对象。这证明了 ESDK 的异常反馈机制在容器内响应正常。

• 请求成功：ID 258 成功获得响应数据 5A A5，标志着 UCMM 通道（非连接消息管理器）完全跑通。

SendUnconnectedRequest ID = 258
Response for request 258:
5A A5

3. I/O 连接建立（Class 1 Connection）：
通过 ./ConsoleApp1 模拟周期性 I/O 通信。

Assembly instances and members created for use over Class 1 connection. 
Connection with instance 1 successfully opened
Connection with instance 1 closed

日志解读：successfully opened 意味着 UDP 2222 端口在 Docker 网桥上通过了流量校验。如果该日志卡在 opening 状态，通常需要检查宿主机防火墙是否放行了 UDP 流量。

六、 结论与建议

1. 环境对等性：ESDK 在国产银河麒麟与 Windows Docker 环境下的表现高度一致，证明了其优异的跨平台特性。

2. 网络建议：在生产环境中，若涉及大规模 I/O 数据交换，建议优先选择银河麒麟环境并开启 Docker 的 Host 网络模式，以消除网桥转发带来的抖动。