简介：这份资源面向具备C#基础、希望深入理解网络编程的开发者，围绕Socket套接字构建一套面向连接的客户端与服务器通信示例，重点解决多客户端接入、消息收发与异常处理等实际问题。压缩包共44个文件，约104KB，以13个cs源码文件为核心，配合2个csproj工程文件、4个resx与4个resources界面资源、6个exe可执行程序及若干txt说明和pdb调试文件，可直接运行对照学习。已有5207人学习下载，说明其在同类教学示例中具有一定参考价值。资源完整呈现服务端响应单个或任意多个客户端连接、向单个客户发送消息及群发消息的实现思路，并包含双方异常退出时的响应处理；其中客户端之间直接通信、不经过服务器中转的设计，是理解点对点通信与消息路由的典型素材。读者可据此梳理WinForm界面与Socket通信的协作方式，掌握连接管理、数据收发与容错处理的关键环节。
1. 从「客户端之间直接通信」说起：这个 Socket 项目到底解决什么问题
很多人第一次听到「客户端之间直接通信」，下意识会以为就是两台机器各自开个 Socket 互相连。真动手才发现，客户端往往在局域网里、在 NAT 后面，根本没有公网可达的地址，A 想直连 B，十次有八次连不上。这个项目的价值就在这儿：它用 C# 的 Socket 把「客户端到客户端」这条链路真正跑通，而不是停留在两台机器插同一根网线的实验室场景。适合谁？适合已经会写TcpListener/TcpClient基础 demo、但一到真实网络环境就翻车的开发者，也适合想给桌面工具加个点对点传输能力、又不想引入重型框架的人。下面我按「它怎么组织 → 怎么跑起来 → 怎么改」的顺序拆，代码和目录都按能直接抄作业的粒度写。
2. 架构拆解：三个角色和一条消息链路
2.1 为什么不能纯 P2P，必须有个「牵线」的角色
纯客户端直连的死结在于寻址：A 不知道 B 的公网映射地址，B 也不知道 A 的。合格开发最常用的做法是引入一个轻量的协调端（下文叫它「信令服务」），它不转发业务数据，只负责两件事——登记每个客户端的外部可达地址，以及在 A 请求连 B 时把双方地址互相告知。真正的大块数据仍然走 A 到 B 的直连 Socket，协调端只承担「介绍人」的角色，压力很小。
这个项目里三个角色分工是这样的：
| 角色 | 职责 | 是否传输业务数据 |
|---|---|---|
| 信令服务（SignalingServer） | 登记客户端、交换地址、撮合连接 | 否 |
| 客户端 A（发起方） | 向信令服务请求 B 的地址，主动连 B | 是 |
| 客户端 B（接收方） | 向信令服务登记自己，监听并接受 A 的连接 | 是 |
这样拆的好处是：协调端可以部署在一台有公网地址的机器上，客户端随便在什么网络里都能先连上它完成「报到」，再由它撮合。业务数据不经过协调端，延迟和带宽都不受它拖累。
2.2 目录结构：一个解决方案装下三个可执行项目
我一般会把这类项目组织成一个 solution 加三个项目，公共协议单独抽一个类库，避免三处各写一份消息格式：
P2PComm/ ├── P2PComm.sln ├── P2PComm.Protocol/ # 公共协议：消息类型、序列化 │ ├── MessageType.cs │ └── WireMessage.cs ├── P2PComm.Signaling/ # 信令服务，控制台程序 │ ├── Program.cs │ └── PeerRegistry.cs ├── P2PComm.ClientA/ # 发起方客户端 │ └── Program.cs └── P2PComm.ClientB/ # 接收方客户端 └── Program.csP2PComm.Protocol是关键：消息类型枚举、定长头 + 变长体的封包格式都放这里，三个项目引用同一份，改协议只改一处。PeerRegistry单独成类而不是塞进Program.cs，是为了后面换成数据库或加过期清理时不动主流程。
2.3 消息格式：先定协议再写 Socket
Socket 编程翻车最多的地方不是连接，是「粘包」。TCP 是字节流，你发两条消息，对面可能一次Receive全收到，也可能一条消息分两次到。所以协议层必须先解决边界问题。常见做法是定长头 + 变长体：
// P2PComm.Protocol/WireMessage.cs public enum MessageType : byte { Register = 1, // 客户端向信令服务登记 QueryPeer = 2, // 发起方查询目标地址 PeerInfo = 3, // 信令服务返回目标地址 Data = 4 // 客户端之间的业务数据 } public sealed class WireMessage { public MessageType Type { get; set; } public byte[] Payload { get; set; } = Array.Empty<byte>(); // 序列化：1 字节类型 + 4 字节长度 + 负载 public byte[] ToBytes() { var buffer = new byte[5 + Payload.Length]; buffer[0] = (byte)Type; BitConverter.GetBytes(Payload.Length).CopyTo(buffer, 1); Payload.CopyTo(buffer, 5); return buffer; } }Type占 1 字节，Payload.Length占 4 字节（BitConverter.GetBytes(int)），后面才是真正的负载。接收端先读满 5 字节拿到长度，再按长度读满负载，一条消息的边界就确定了。参数上要注意：长度字段用int而不是short，单条消息上限 2GB 够用；如果业务里消息都很小，也可以换成ushort省 2 字节，但改的时候收发两端必须同步改，否则就是血泪经验里的「长度对不上，读出来全是乱码」。
2.4 信令服务的撮合逻辑
信令服务收到Register就把对方的IPEndPoint记下来，收到QueryPeer就把目标地址回过去。核心就一个字典加一把锁：
// P2PComm.Signaling/PeerRegistry.cs public sealed class PeerRegistry { private readonly Dictionary<string, IPEndPoint> _peers = new(); private readonly object _gate = new(); public void Register(string peerId, IPEndPoint endpoint) { lock (_gate) { _peers[peerId] = endpoint; } } public IPEndPoint? Lookup(string peerId) { lock (_gate) { return _peers.TryGetValue(peerId, out var ep) ? ep : null; } } }peerId是客户端自己上报的标识（比如用户名或 GUID），IPEndPoint从TcpClient.Client.RemoteEndPoint取。这里有个细节：如果信令服务和客户端在同一台机器上测试，RemoteEndPoint会是127.0.0.1，撮合出来的地址客户端之间连不通——这是本地联调最常见的坑，后面避坑章节会展开。lock不能省，信令服务通常用异步循环处理多个连接，字典不是线程安全的。
3. 跑起来：从零到两个客户端互发消息
3.1 环境与项目创建
需要 .NET 6 或以上（dotnet --version确认），三个项目都用控制台模板。命令按顺序执行：
dotnet new sln -n P2PComm dotnet new classlib -n P2PComm.Protocol dotnet new console -n P2PComm.Signaling dotnet new console -n P2PComm.ClientA dotnet new console -n P2PComm.ClientB dotnet sln add P2PComm.Protocol P2PComm.Signaling P2PComm.ClientA P2PComm.ClientB dotnet add P2PComm.Signaling reference P2PComm.Protocol dotnet add P2PComm.ClientA reference P2PComm.Protocol dotnet add P2PComm.ClientB reference P2PComm.Protocolclasslib建协议库，三个console建可执行项目，sln add把它们挂进解决方案，最后三行add reference让可执行项目能引用协议库。跑之前先dotnet build确认没有编译错误，比直接run再排查省事。
3.2 信令服务主循环
信令服务监听一个固定端口，每个进来的连接开一个任务处理：
// P2PComm.Signaling/Program.cs（核心片段） var listener = new TcpListener(IPAddress.Any, 9000); listener.Start(); var registry = new PeerRegistry(); Console.WriteLine("Signaling on :9000"); while (true) { var client = await listener.AcceptTcpClientAsync(); _ = Task.Run(() => HandleAsync(client, registry)); } static async Task HandleAsync(TcpClient client, PeerRegistry registry) { using var _ = client; var stream = client.GetStream(); var header = new byte[5]; await stream.ReadExactlyAsync(header); // 先读定长头 var type = (MessageType)header[0]; var len = BitConverter.ToInt32(header, 1); var payload = new byte[len]; await stream.ReadExactlyAsync(payload); // 再读满负载 // 按 type 分发：Register 存地址，QueryPeer 回 PeerInfo }ReadExactlyAsync是 .NET 7 起提供的，能保证读满指定字节数，比手写循环Read干净得多；如果目标框架是 .NET 6，就自己写个ReadFullyAsync循环。IPAddress.Any表示监听所有网卡，端口 9000 可改，但客户端要同步改。_ = Task.Run(...)让每个连接独立处理，不阻塞Accept循环。
3.3 客户端 B：登记并监听
B 先连信令服务报到，然后在本机开一个监听端口等 A 来连：
// P2PComm.ClientB/Program.cs（核心片段） var signaling = new TcpClient(); await signaling.ConnectAsync("127.0.0.1", 9000); var reg = new WireMessage { Type = MessageType.Register, Payload = Encoding.UTF8.GetBytes("peer-b") }; await signaling.GetStream().WriteAsync(reg.ToBytes()); var listener = new TcpListener(IPAddress.Any, 9100); listener.Start(); Console.WriteLine("B listening on :9100"); var incoming = await listener.AcceptTcpClientAsync(); // 之后从 incoming.GetStream() 读 A 发来的 Data 消息Register消息里带自己的peerId，信令服务据此登记。监听端口 9100 是 B 的「数据端口」，和信令端口 9000 分开，职责清晰。真实环境里 B 的监听端口需要在路由器上做端口映射才能被外部连到，这一步是纯 P2P 绕不开的，项目里通常配合 UPnP 或手动映射解决。
3.4 客户端 A：查询地址并直连
A 先问信令服务 B 在哪，拿到地址后直接连 B 的数据端口：
// P2PComm.ClientA/Program.cs（核心片段） var signaling = new TcpClient(); await signaling.ConnectAsync("127.0.0.1", 9000); var query = new WireMessage { Type = MessageType.QueryPeer, Payload = Encoding.UTF8.GetBytes("peer-b") }; await signaling.GetStream().WriteAsync(query.ToBytes()); // 读回 PeerInfo，解析出 B 的 IP 和端口 var (ip, port) = await ReadPeerInfoAsync(signaling.GetStream()); var data = new TcpClient(); await data.ConnectAsync(ip, port); var msg = new WireMessage { Type = MessageType.Data, Payload = Encoding.UTF8.GetBytes("hello from A") }; await data.GetStream().WriteAsync(msg.ToBytes());ReadPeerInfoAsync就是按 2.3 的格式读一条PeerInfo，把负载按ip:port解析。A 连 B 用的是 B 登记时上报的地址，所以 B 上报的地址必须是 A 能访问到的——本地测试时如果 B 上报的是127.0.0.1，A 在另一台机器上就连不上，这是第二个高频坑。
3.5 验证链路是否真的通了
按顺序开三个终端：先跑信令服务，再跑 B，最后跑 A。B 的控制台应打印B listening on :9100，A 跑完后 B 应收到hello from A。如果 B 没反应，先看信令服务有没有打印登记和查询日志，再看 A 的ConnectAsync是否抛异常——异常信息里的目标地址能直接告诉你撮合出来的地址对不对。这一步别急着改代码，先把「谁连谁、连的什么地址」用日志打出来，比盲猜快得多。
4. 避坑与排查：五个真实会卡住你的点
4.1 现象：本地测试 A 连不上 B，报连接超时
原因：B 向信令服务登记时，RemoteEndPoint拿到的是127.0.0.1（因为 B 和信令服务同机），信令服务把这个回环地址给了 A，A 去连127.0.0.1:9100连的是自己。解决：本地联调时让 B 显式上报局域网 IP（用Dns.GetHostAddresses过滤出非回环地址），或者干脆在信令服务里对回环地址做替换。生产环境则依赖公网映射，逻辑不同，别把测试补丁带上去。
4.2 现象：收到消息但内容错位，解析出乱码
原因：收发两端对消息头的理解不一致，比如一端用short存长度、另一端用int读，或者BitConverter的大小端假设不同（x86 是小端，跨平台通信要统一）。解决：协议字段宽度和字节序在WireMessage里写死并注释清楚，两端引用同一个类库，不要各写一份。改协议时先改类库再全量重编译。
4.3 现象：并发多个客户端时信令服务偶发崩溃
原因：PeerRegistry的字典被多个Task同时读写，没加锁，Dictionary在并发写入时会抛InvalidOperationException或进入损坏状态。解决：所有读写走lock，或者换成ConcurrentDictionary。注意ConcurrentDictionary的TryGetValue和AddOrUpdate语义不同，登记用AddOrUpdate覆盖旧地址，查询用TryGetValue。
4.4 现象：客户端断开后信令服务仍保留旧地址，A 连过去失败
原因：没有过期清理，客户端异常退出后登记记录一直留着。解决：登记时记一个时间戳，后台定时任务清理超过阈值（比如 60 秒）没心跳的记录；或者客户端正常退出时发一条Unregister。两者都做最稳，异常退出靠超时兜底。
4.5 现象：大消息发送时 B 只收到一半
原因：WriteAsync不保证一次写完，网络缓冲区满时会只写一部分，返回值是实际写入字节数。解决：发送端用循环写直到全部写完，或者用stream.WriteAsync配合检查；接收端用ReadExactlyAsync读满。这个坑在小消息测试时几乎不出现，一上大文件就暴露，属于典型的「测试环境玄学，生产环境翻车」。
5. 二次开发：把 demo 改成能用的点对点传输
5.1 先加心跳和断线重连，再谈功能
这个项目跑通链路只是起点，真正拿去用之前，我建议先补两件事：心跳和重连。心跳让信令服务知道谁还活着，重连让客户端在网络抖动后自动恢复。做法是在WireMessage里加一个Heartbeat类型，客户端每 15 秒发一次，信令服务更新对应记录的时间戳；客户端侧用一个CancellationTokenSource管理重连循环，ConnectAsync失败后按指数退避重试（1s、2s、4s，上限 30s）。这两块补上之后，demo 才具备「挂着不崩」的基本素质。
5.2 协议扩展：加一个文件传输消息类型
业务数据走Data类型时，负载是裸字节，没有文件名和分片信息。要传文件，最省事的改法是给Data的负载加一层子头：4 字节分片序号 + 4 字节总分片数 + 文件名长度 + 文件名 + 数据块。接收端按分片序号落盘，全部收齐后合并。改的时候只动WireMessage的负载构造和解析，Type枚举不用变，因为传输层不关心负载语义。这种「传输层稳定、负载层演进」的分层是这类项目能长期维护的关键。
5.3 验证改造是否正确的三个检查点
改完别只看「能发出去」，按这三个点验：一是用netstat -an确认数据连接确实是从 A 直连 B 的端口，而不是绕回信令服务；二是故意在传输中途Ctrl+C杀掉 B，看 A 是否在超时后进入重连而不是卡死；三是发一个 10MB 以上的负载，确认接收端字节数完全一致（用哈希比对）。第三个检查点能一次性暴露 4.5 里的半包问题，我一般把它当成改造后的必过项。
5.4 一个我踩过的教训
早些年我做类似的东西，图省事把信令服务和数据转发合在一个进程里，测试时一切正常，上线后一传大文件整个服务就卡住——因为转发线程被大块数据占满，新客户端连登记都排不上队。从那以后我每次拆这类项目，都强制把「控制面」和「数据面」分成两个独立监听端口、两套处理逻辑，哪怕初期多写几十行代码。这个项目里 9000 和 9100 两个端口的划分就是照着这个习惯来的，你二次开发时也别为了省事把它们合并。希望帮到你。
本文还有配套的精品资源，点击获取
