简介：面向医疗检验与工业自动化开发者的TCP/IP双向通讯示例工程，演示如何通过C#搭建服务端、等待客户端接入并自动收发数据，可自行回应对方，功能类似TCP/IP调试助手；同时附带ASTM协议数据解析Demo，适合LIS系统对接检验仪器时参考。包体共143个文件，约3.07MB，核心为9个cs源码文件与36个dll依赖库，另有xml配置、txt说明文档、exe可执行程序及png示意图片，目录结构完整，可独立打开调试。目前已有1355人学习下载。通过源码可快速掌握服务端监听、客户端连接、数据自动接收与回应的完整流程，并理解ASTM协议字段拆解与解析思路；医疗或工业场景中需要与设备做双向通讯的开发者，可直接复用核心代码或在此基础上扩展业务逻辑。
1. LIS 双向通讯不是写个 Socket 就完事：这份 C# TCP/IP 示例能当通讯底座
在检验科或工业现场，仪器和 LIS 系统之间的数据交换，绝大多数走的是 TCP/IP。很多人以为双向通讯就是开一个 Socket 收发字符串，但真拿生化仪、血球仪联调时，帧格式、校验位、粘包、半包、断线重连会一个个冒出来。这份资源是一个用 C# 写好的 TCP/IP 服务端示例，核心逻辑是：创建服务端，等待仪器作为客户端接入，连接成功后自动接收对方发来的数据，并允许你按协议自行回应。它还附带一段 ASTM 协议数据解析 Demo，适合做医疗检验或工业设备数据采集的开发者参考。它不是完整产品，但完全能当通讯底座来用。
2. TCP/IP 服务端底座：监听模型、连接生命周期与参数选择
2.1 为什么选“服务端等待连接”而不是主动连仪器
大多数 LIS 对接场景里，生化仪、血球仪、免疫分析仪都把自己当作客户端，开机后配置一个服务器 IP 和端口，只要有检验数据要传就主动连过来。LIS 那边则固定监听一个端口，等仪器来连。这样设计有三个现实原因：一是仪器端基本没有长期监听端口的必要，它在业务里是主动发起方；二是 LIS 要同时接入多台型号不同的仪器，每台仪器对应一个设备编号或 IP，服务端统一监听、按连接来源区分身份，管理起来更清晰；三是多数仪器厂商的协议文档会明确写“仪器作为 TCP 客户端连接 LIS 服务端”。
如果你遇到少数需要 LIS 主动连仪器的设备（比如某些老式酶标仪），可以把角色反过来。这份资源里的监听模型依然适用，只是把TcpListener放到仪器侧。但按我的经验，95% 以上的检验仪器都是客户端主动连服务端，所以你直接照示例做服务端，基本上不会踩到反向连接的坑。
2.2 TcpListener 与异步 Accept：阻塞与非阻塞怎么选
C# 里建 TCP 服务端最直接的方式是TcpListener。示例工程大概率就是它，因为代码短、逻辑清楚，不用手动管理原生 Socket。它的监听核心代码大致如下：
TcpListener listener = new TcpListener(IPAddress.Any, 15000); listener.Start(10); // backlog：最多排队的未处理连接数 while (true) { TcpClient client = listener.AcceptTcpClient(); Task.Run(() => HandleClient(client)); }代码说明：IPAddress.Any表示监听本机所有网卡，回环地址127.0.0.1和局域网 IP 都能连进来。端口15000是示例值，部署时要避开 0-1024 的常用端口和已被占用的区间。listener.Start(10)里的 10 是 backlog 参数，代表操作系统层面允许排队等待处理的连接数；如果预计几十台仪器同时连，就调大一些。AcceptTcpClient是阻塞式调用，执行到这里会卡住，直到一个客户端连进来。用Task.Run把每个客户端的后续逻辑放到线程池线程上，才不至于处理第一台仪器时把后面仪器的连接全部堵在队列里。
这个模型的优点是简洁，把并发问题丢给线程池；缺点是每个连接占用一个线程，如果连接数到几千上万，线程切换开销会变大。但一个 LIS 前置机一般也就同时挂几台到几十台仪器，完全够用。如果你是做工业现场的大规模采集，可以考虑用SocketAsyncEventArgs做纯异步，但资源里没涉及，那是后话。
从资源工程的源码组织来看，使用TcpListener的方案意味着你必须处理好客户端断开时的资源释放。否则每台仪器反复重连，线程池会被僵尸连接占满，程序表面还活着，实际已经拒绝服务。
2.3 连接生命周期：从 Accept 到断开，双向数据流怎么维护
一个双向连接建立后，要做两件事：读仪器发来的数据，以及回写数据给仪器。最容易出的问题是把“读”和“写”串行化：仪器不会按你的节奏来，它可能连上后立刻发一包，也可能半小时不发；服务端如果一直阻塞在Read上，就没办法主动给仪器发心跳或查询指令。所以读和写要分离，资源里的处理可以抽象成这个循环：
public void HandleClient(TcpClient client) { using (TcpClient tcpClient = client) using (NetworkStream stream = tcpClient.GetStream()) { byte[] buffer = new byte[4096]; while (true) { int bytesRead = stream.Read(buffer, 0, buffer.Length); if (bytesRead <= 0) { break; // 客户端关闭连接 } string received = Encoding.ASCII.GetString(buffer, 0, bytesRead); string response = ProcessReceived(received); byte[] responseBytes = Encoding.ASCII.GetBytes(response); stream.Write(responseBytes, 0, responseBytes.Length); } } }这里展示的是最简单的“收到什么就处理什么，处理完立刻回写”模型。stream.Read是同步阻塞读，返回 0 表示对端已经正常关闭，此时要跳出循环并释放资源。ProcessReceived是业务协议入口，也就是 ASTM 解析 Demo 要接管的地方。
这段代码有两个隐患。第一，Encoding.ASCII遇到中文字符会丢信息，后面避坑章节专门讲。第二，一次Read读到的字节数不等于一条完整消息的长度。TCP 是流协议，不保证一次Write对应一次Read。你发了 100 字节，对方可能一次收到 100，也可能分两次收 60+40，还可能三包数据拼一次收到。所以，收到字节后不要立刻GetString再拼字符串，而是先把byte[]追加到一个接收缓冲区，去缓冲区里找帧头和帧尾，解析出一条帧后再把剩余的字节留给下一帧。这个思路是 ASTM 解析 Demo 的立足点。
如果你还要管理多台仪器，就得维护一个Dictionary<string, TcpClient>，用仪器编号做 key。例如：
private readonly ConcurrentDictionary<string, TcpClient> _clients = new ConcurrentDictionary<string, TcpClient>(); private void RegisterClient(string instrumentId, TcpClient client) { _clients[instrumentId] = client; } public void SendToInstrument(string instrumentId, string message) { if (_clients.TryGetValue(instrumentId, out TcpClient client)) { NetworkStream stream = client.GetStream(); byte[] data = Encoding.ASCII.GetBytes(message); stream.Write(data, 0, data.Length); } }说明：ConcurrentDictionary保证多线程下操作安全。每次新连接握手后，根据仪器标识（比如 ASTM 头消息里的仪器名称）把它放到字典里；仪器断开时手动TryRemove。否则字典里全是死连接，往里面Write会抛异常。资源示例可能没有做这层封装，你自己扩展时要补上。
3. ASTM 协议解析：帧结构、Checksum 与粘包拆包
3.1 ASTM E1394 帧格式：STX、ETX、Checksum 到底长什么样
LIS 最常用的通讯协议是 ASTM，实际上是 E1394 标准的一个子集，国内很多仪器厂商在此基础上做了简化。ASTM 消息不是裸字符串，而是包在一种“帧”里。帧的基本结构是：
- STX（Start of Text）：ASCII 0x02，表示一帧开始
- Frame Number：一位字符，通常是 0-9 循环使用
- Text Type：一个字符，比如 1 表示头消息、2 表示查询/订单、3 表示检验结果、L 表示终止帧
- 数据部分：以竖线
|分隔字段，字段内用^分隔子字段 - ETX（End of Text）：ASCII 0x03，表示数据部分结束
- Checksum：两个十六进制大写字符
- 帧尾通常还有 CR（0x0D）或 LF（0x0A）
校验和计算有两种常见变体：一种是从 STX 之后到 ETX 之前的所有字节求和，取低 8 位；另一种是把 STX 本身也算进去。资源里的 Demo 用哪种，你去翻它的Checksum方法就知道。这里给一个可对照的实现：
public static string ComputeChecksum(byte[] data, int start, int end) { int sum = 0; for (int i = start; i < end; i++) { sum += data[i]; } return (sum & 0xFF).ToString("X2"); }参数说明：start指向 STX 的后一个字节，end指向 ETX 的位置，也就是求和范围覆盖帧号、类型、数据部分。sum & 0xFF取低八位，ToString("X2")转成两位大写十六进制。很多初次对接的人在这里翻车，因为校验和如果只有一位，比如0xA，必须补0写成0A，否则仪器直接丢帧。
3.2 增量接收与缓冲区处理：把一串字节切成一帧一帧
ASTM 解析 Demo 的核心，是把网络层送来的连续字节流切分成一条条完整帧。下面是我见过的主流拆包骨架：
private List<byte> buffer = new List<byte>(); private void AppendData(byte[] data, int length) { for (int i = 0; i < length; i++) { buffer.Add(data[i]); } TryExtractFrames(); } private void TryExtractFrames() { while (true) { int stxIndex = buffer.IndexOf(0x02); if (stxIndex < 0) { buffer.Clear(); return; } if (stxIndex > 0) { buffer.RemoveRange(0, stxIndex); stxIndex = 0; } int etxIndex = buffer.IndexOf(0x03, stxIndex); if (etxIndex < 0) { return; // 数据还没到 ETX，等待更多字节 } if (etxIndex + 2 >= buffer.Count) { return; // 校验和字符还没收全 } string checksumFromFrame = Encoding.ASCII.GetString(buffer.ToArray(), etxIndex + 1, 2); string computedChecksum = ComputeChecksum(buffer.ToArray(), stxIndex + 1, etxIndex); if (!string.Equals(checksumFromFrame, computedChecksum, StringComparison.OrdinalIgnoreCase)) { throw new InvalidDataException($"Checksum mismatch: {checksumFromFrame} != {computedChecksum}"); } byte[] frame = buffer.GetRange(stxIndex, etxIndex - stxIndex + 3).ToArray(); ProcessFrame(frame); buffer.RemoveRange(0, etxIndex + 3); } }这段代码有三个关键点。第一，buffer是累积缓冲区，每次网络层收到新数据就AppendData，解析完不能清空，因为后面可能还残留着半条帧。第二，TryExtractFrames用 while 循环，因为缓冲区里可能同时存在多条完整帧；解析一条之后要接着看后面还有没有。第三，如果已经找到 ETX 但校验和还没凑齐，就return等下一次数据到达，这是处理半包的核心手法。
我额外加了一个stxIndex > 0的判断：当缓冲区里出现 STX 之前有脏数据时，先把它丢弃。真实网络环境里，仪器刚上电或重连时可能发几个字节的空包，不做这个清理就会帧头定位错误。
3.3 解析 Demo 的骨架：从字节流到结构化检验数据
帧外壳拆下来后，数据部分是一串竖线分隔的字段。以最常见的检验结果帧（Text Type = 3）为例，结构大致是：
3O|1|12345678^^^|||.....
但不同仪器字段位置差异很大，有些仪器会在空字段里塞入\F转义符。示例 Demo 通常做的就是把字段切开存进字典：
public Dictionary<string, string> ParseResultFrame(string dataPart) { string[] fields = dataPart.Split('|'); var dict = new Dictionary<string, string>(); if (fields.Length > 0) dict["RecordType"] = fields[0]; if (fields.Length > 1) dict["SequenceNumber"] = fields[1]; if (fields.Length > 2) dict["SampleId"] = fields[2].Split('^')[0]; // 其余字段按协议文档补齐 return dict; }这里必须注意：Split('|')的前提是数据字段里没有转义竖线。ASTM 规范里，如果字段内需要包含竖线，可以用\F转义，但不少厂商不按规范来。你接真实仪器时，先抓 100 条消息，确认哪些字段会产生空串、哪些会多出\F，再决定解析逻辑。资源里的 Demo 能帮你把帧外壳拆下来，但字段映射必须针对手头仪器型号微调。
4. 把示例跑起来：编译、启动服务端与模拟仪器联调
4.1 工程配置：.NET 版本、端口、编码与超时参数
这份资源是 Visual Studio 工程，从缓存文件看是 .NET Framework 项目。拿到后打开.csproj，先确认三件事：目标框架版本、启动项目、端口占用。
我一般先在工程里搜TcpListener和port，把端口改成不冲突的本地端口，比如15000。如果端口是硬编码，直接改代码；如果用了app.config配置项，改那里更省事。编码方面，先确认Encoding用的是ASCII还是GBK。很多国产仪器虽然标称 ASTM，但实际传输用 GBK 或扩展 ASCII。示例默认ASCII，中文样本号会变成?，我的建议是写成可配置项。
超时参数容易被忽视。NetworkStream.Read没有默认超时，可能一直挂着。可以设置stream.ReadTimeout = 30000，但超时后Read会抛IOException，你需要捕获后判断是超时还是断开。资源示例如果没做超时，你在生产环境必须补上，否则某个仪器掉线后，连接线程会永远傻等。
4.2 启动服务端，用 TCP 调试助手扮演仪器客户端
编译并运行后，服务端进入监听状态。用你顺手的 TCP 调试助手（网络调试助手、Sokit，甚至 Python 脚本），模拟仪器作为客户端去连127.0.0.1:15000。连接成功后，服务端应出现新连接记录，这验证了 TCP 握手没问题。
如果连不上，优先检查三处：
- 服务端监听的是不是
IPAddress.Any - 端口是否被占用
- Windows 防火墙是否放行了入站规则
本机测试用127.0.0.1可能绕过防火墙，换成局域网 IP 就连不上。生产环境部署时，记得在防火墙入站规则里放行这个 TCP 端口。
4.3 请求与响应：手动触发一条 ASTM 消息并观察回应
连接建立后，往发送框里输入一条完整 ASTM 帧。手工算校验和容易错，建议用 Python 快速生成：
import socket def calc_checksum(data: bytes) -> str: s = sum(data) & 0xFF return f"{s:02X}" def build_frame(msg_type: int, message: str) -> bytes: stx = b'\x02' etx = b'\x03' body = f"{msg_type}".encode('ascii') + message.encode('ascii') checksum = calc_checksum(body) return stx + body + etx + checksum.encode('ascii') + b'\r' s = socket.create_connection(('127.0.0.1', 15000)) frame = build_frame(1, "H|\\^&|||demoInstrument|||||LIS||P|1") s.sendall(frame) print(s.recv(4096))这段脚本的作用是：计算 ASTM 帧校验和，组装成完整帧，作为客户端连接服务端并发送，最后打印服务端响应。注意build_frame里msg_type是 1，对应头消息；实际业务要换成仪器手册里的类型。calc_checksum的输入是“帧号 + 类型 + 消息体”，也就是 STX 之后到 ETX 之前的全部内容。recv(4096)只读一次，如果服务端回应超长，回显会截断，那只是测试脚本的问题，不是服务端问题。
服务端收到这条帧后，ASTM Demo 应打印出解析后的字段，并回一个类似ACK的 ASCII 响应。你看到 ACK，双向通讯链路就算跑通了。有些仪器要求回EOT或NAK，具体看协议文档，资源示例里一般留了ResponseBuilder之类的方法给你改。
5. TCP/IP 双向通讯避坑指南：5 个我调了两天才发现的细节
5.1 半包：一次 Receive 收到的不是一整条 ASTM 帧
现象：第一次联调，服务端收到的字符串缺了一半，报文头还在，数据字段被截断，解析直接抛异常。多试几次发现截断位置每次都不一样。
原因：TCP 是字节流协议，发送端Write100 字节，接收端Read可能只返回 40 字节，剩下 60 字节要等下一次Read。如果按“收到多少就解析多少”处理，就会出现半个帧。
解决：把每次收到的字节追加到接收缓冲区，去缓冲区里找 STX、ETX 和校验和，等一条帧的所有字节齐了再解析。用第 3 章讲的AppendData+TryExtractFrames结构，缓冲区没攒够就等下一次。这是从串口转网口的开发者最容易翻车的地方，串口按帧发送，网口不保证帧边界。
5.2 粘包：仪器连发两条消息，Socket 全粘在一起
现象：服务端收到的一段完整数据里包含了两条完整 ASTM 帧，首尾相连。解析器只认出第一条，第二条被当垃圾数据丢掉，或者字段错乱。
原因：TCP 不按发送方的Write次数切分数据。仪器快速连续发两条帧，网络栈可能合并成一个 TCP 段送过来，缓冲区里会出现两个 STX 开头的数据块。
解决：拆包逻辑必须用 while 循环反复提取帧，直到剩余字节构不成完整帧。注意移除时要连同校验和和帧尾一起移除，否则第二条帧会带一个前导垃圾字节，stxIndex定位错，整个解析就乱了。
5.3 端口占用：重启服务端报“地址已被使用”
现象：改代码后重启服务端，控制台直接抛SocketException: Address already in use。等一分钟再启动又好了，有时候彻底不行。
原因：TCP 连接断开时，主动关闭的一方会进入TIME_WAIT状态，占用端口一段时间（通常两分钟）。服务端如果是主动断开方，端口会被系统锁住。另外，调试时开多个服务端实例也会抢端口。
解决：给 Socket 设置ReuseAddress选项。C# 写法：
Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true); socket.Bind(new IPEndPoint(IPAddress.Any, 15000)); socket.Listen(10); TcpListener listener = new TcpListener(socket); listener.Start();代码说明：用显式Socket替代TcpListener的简化构造，ReuseAddress允许端口在TIME_WAIT期间重新绑定。注意 Windows 和 Linux 上该选项的语义不完全一致，Windows 下基本能解决重启报错。更稳妥的做法是程序退出时调用listener.Stop()，并确保所有TcpClient都 Dispose。
5.4 编码不对：ASCII 里没有中文字符集，结果全变问号
现象：仪器发来的数据里有中文样本号或备注，服务端收到后全是?，或者乱码。
原因：ASTM 协议基于 ASCII，但很多国内仪器实际用 GBK/GB2312，甚至把扩展 ASCII 的 0x80-0xFF 区间用作中文编码。服务端用ASCII解码时，非 ASCII 字节被替换成?，信息直接丢失。
解决：不要写死Encoding.ASCII，把编码做成可配置项，支持GBK、UTF-8、Latin-1。C# 里用Encoding.GetEncoding("GBK")应急，同时确认仪器协议文档。更稳妥的方式是先用字节缓冲拆 ASTM 帧，帧内字段再按目标编码解码。Encoding.Default在不同系统上结果不同，千万别依赖它。
5.5 假死连接：仪器不主动发包，服务端怎么维持心跳
现象：连接建立后，仪器很久不发数据，看起来一切正常。等仪器要上报结果时，服务端发请求才发现连接早就断了。连接还占着一个线程，资源没释放。
原因：TCP 没有应用层心跳，两端都不发数据时，操作系统不会立刻发现对端已断开。服务端的Read一直阻塞等待，客户端默默重启或断网后，这条连接就成了一条僵尸连接。
解决：应用层加心跳。ASTM 协议里有ENQ（0x05）和EOT（0x04）控制字符，很多仪器会周期发心跳，或响应 LIS 发来的ENQ。你可以起一个定时器，每 30 秒发一条ENQ探测；如果在规定时间没收到任何响应，就主动Close连接并重新等待接入。同时给NetworkStream.ReadTimeout设一个值，超时捕获后判断是重连还是标记断开。这样才能保证某台设备死机后，服务端能在一分钟内释放资源，不会越积越多。
6. 把双向通讯模块化：协议层与界面分离，再用回环脚本自检
拿到这份资源跑通基本链路后，别急着接真机。我建议先做一个内部改造：把 Socket 收发、ASTM 拆帧、业务字段解析三层拆开。Socket 层只负责字节流，不感知 ASTM；ASTM 层把二进制流切成帧并校验；业务层拿到解析后的字段对象，再决定存库还是上报告警。以后换仪器型号，只需要改第三层的字段映射，Socket 和 ASTM 层基本不动。
验证方法上，我习惯用一个“回环自检”脚本：在同一台机器上开两个线程，一个启动资源里的服务端，另一个创建TcpClient连上来，连续发送 100 条带随机校验和的 ASTM 帧，然后对比服务端回发的 ACK 数量和收到的帧数。这个脚本能验拆包逻辑，还能压出半包和粘包。关键点是每条帧之间随机等待 0 到 5 毫秒，故意制造 TCP 段合并，拆包逻辑如果不够稳健，这一轮就会暴露。
之前我在某跨平台系统上调试时，就是因为漏了“帧号要循环 0-9”这个细节，导致仪器一直回 NAK。从那以后，我每次对接新仪器都强制自己先跑一遍回环自检，确认帧结构、校验和、ACK 三方都对，才敢接真机。希望帮到你。
本文还有配套的精品资源，点击获取
