一、 背景：为什么要将 ESDK 容器化？
在工业 4.0 场景下，传统的 EtherNet/IP (EIP) 协议栈部署往往受限于操作系统环境。ESDK (EtherNet/IP Scanner Development Kit) 作为实现 CIP 协议的核心组件，通过 Docker 进行容器化封装，可以实现"一次开发，全现场部署"。
本文将记录 ESDK 在 Windows 10/11 (WSL2) 与 国产化操作系统银河麒麟 V10 环境下的网络模式与通信端口实测结果。
二、 环境准备
测试涉及两个典型的开发与运行环境：
|----------|-------------------------------|-------------------------|
| 维度 | 环境 A：Windows 宿主 | 环境 B：国产化宿主 |
| 操作系统 | Windows 10/11 Professional | 银河麒麟 V10 (Kylin OS) |
| 容器引擎 | Docker Desktop (Hyper-V/WSL2) | 原生 Docker Engine 18.x |
| 协议栈 | ESDK (Linux 版镜像) | ESDK (Linux 版镜像) |
三、 核心技术点：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 流量。
六、 结论与建议
-
环境对等性：ESDK 在国产银河麒麟与 Windows Docker 环境下的表现高度一致，证明了其优异的跨平台特性。
-
网络建议 ：在生产环境中，若涉及大规模 I/O 数据交换，建议优先选择银河麒麟环境并开启 Docker 的 Host 网络模式，以消除网桥转发带来的抖动。