简介：这份资源提供了一套用C#编写的TCP客户端与服务器源代码，面向刚接触网络编程、希望理解异步Socket通讯机制的开发者，尤其适合需要搭建压力测试环境或做课程实验的新手参考。压缩包共101个文件，约235KB，以cs源码文件为主，辅以resources资源、config配置、resx与settings等工程文件，以及exe可执行程序、dll类库和pdb调试符号，完整覆盖客户端与服务端两个解决方案，可直接编译运行。资源已实测可用，作者将其用于TCP通讯压力测试，代码结构清晰、注释与命名便于阅读，读者可从中掌握Socket连接建立、异步收发、异常处理与多客户端并发的基本写法，并据此改造出符合自身业务需求的通讯模块。目前已有450人学习下载，适合作为入门异步Socket编程与压力测试的实践素材。
1. 从一份 C# TCP 源码说起：异步 Socket 到底解决了什么
很多人第一次写 C# 网络程序，都是从TcpListener和TcpClient的同步方法开始的。AcceptTcpClient()一调用，线程就卡在那里；Read()一执行，没数据就死等。单机测试没问题，一旦同时接入几十个连接，界面直接假死，服务端吞吐断崖式下跌。这份 C# 写的 TCP 客户端和服务端源代码，核心价值就在于它用异步 Socket 把「等待」这件事从线程里剥离了出来——连接、收发、断线重连都不再阻塞主流程。它适合两类人：一是刚接触 TCP/IP 通讯、想找一个能跑通的最小闭环的开发者；二是手里有同步代码、正被并发问题折磨、想对照重构的熟手。下面我按「先跑起来、再看清结构、最后避开坑」的顺序，把这份源码拆开讲。
2. 异步 Socket 的底层逻辑与源码结构拆解
2.1 为什么不用同步 Socket：线程模型与吞吐量的账
同步 Socket 的模型很直观：一个连接占一个线程。10 个连接开 10 个线程，100 个连接开 100 个线程。线程本身有栈空间开销，默认 1MB，100 个就是 100MB 虚拟内存；更致命的是上下文切换，CPU 大量时间花在保存和恢复线程状态上，而不是处理数据。异步 Socket 走的是另一条路：基于 IOCP（I/O 完成端口）的完成通知模型，少量线程就能管理大量连接。当你调用Socket.BeginReceive或await socket.ReceiveAsync时，操作系统内核负责等待数据到达，数据就绪后才回调或恢复执行。线程在等待期间被释放去干别的事，这就是异步带来的吞吐量优势。
这份源码里，服务端用的是TcpListener配合AcceptTcpClientAsync，客户端用的是TcpClient.ConnectAsync，收发环节统一走NetworkStream的异步读写。整个链路没有一处.Result或.Wait()，这是判断一份异步代码是否合格的第一道门槛。
2.2 服务端骨架：监听、接受、分发三段式
服务端的启动流程可以拆成三段：绑定端口开始监听、循环接受新连接、为每个连接启动独立的数据处理任务。源码里对应的结构大致如下：
// 服务端启动与连接接受循环 public async Task StartAsync(int port, CancellationToken token) { var listener = new TcpListener(IPAddress.Any, port); listener.Start(); // 开始监听，不阻塞 Console.WriteLine($"服务端已启动，监听端口 {port}"); while (!token.IsCancellationRequested) { // 异步等待新连接，期间不占用线程 TcpClient client = await listener.AcceptTcpClientAsync(); Console.WriteLine($"新客户端接入：{client.Client.RemoteEndPoint}"); // 每个连接独立处理，不阻塞接受循环 _ = HandleClientAsync(client, token); } }这段代码的关键点有三个。第一，AcceptTcpClientAsync返回的是Task<TcpClient>，await之后才拿到连接对象，等待期间线程池线程可以复用。第二，_ = HandleClientAsync(...)用的是丢弃符，表示「启动这个任务但不在当前上下文等待它」，这样接受循环能立刻回去处理下一个连接。第三，CancellationToken贯穿始终，这是优雅停机的后悔药——没有它，程序退出时后台任务可能还在写数据，导致数据截断。
HandleClientAsync内部负责读取数据、解析协议、回写响应。源码里通常会在NetworkStream.ReadAsync返回 0 时判断为客户端断开，然后清理资源。这个判断不能省，否则连接断了你还在等数据，任务永远不结束。
2.3 客户端骨架：连接、发送、接收的异步闭环
客户端比服务端多一层「连接管理」的考虑。源码里的客户端大致长这样：
// 客户端连接与收发 public async Task ConnectAndSendAsync(string host, int port, byte[] payload) { using var client = new TcpClient(); await client.ConnectAsync(host, port); // 异步连接，不卡界面 Console.WriteLine("已连接到服务端"); NetworkStream stream = client.GetStream(); // 发送数据 await stream.WriteAsync(payload, 0, payload.Length); Console.WriteLine($"已发送 {payload.Length} 字节"); // 接收响应 byte[] buffer = new byte[4096]; int bytesRead = await stream.ReadAsync(buffer, 0, buffer.Length); if (bytesRead > 0) { string response = Encoding.UTF8.GetString(buffer, 0, bytesRead); Console.WriteLine($"收到响应：{response}"); } }ConnectAsync的异步特性在跨网段或目标主机响应慢时尤其明显——同步Connect会一直卡到超时，异步版本可以配合CancellationToken设置连接超时。WriteAsync之后不一定立刻收到响应，ReadAsync返回的字节数可能小于缓冲区大小，这是 TCP 的流式特性决定的，不能假设「一次读到的就是一条完整消息」。源码里如果做了消息边界处理，通常会配合长度前缀或分隔符，这部分在 2.4 节展开。
2.4 消息边界处理：长度前缀与粘包拆包
TCP 是字节流协议，不保留消息边界。发送方连续调用两次WriteAsync，接收方可能一次ReadAsync就把两段数据都读出来，这叫粘包；也可能一条消息被拆成两次读到，这叫拆包。源码里常见的解法是「长度前缀」：每条消息前面加 4 个字节表示消息体长度，接收方先读 4 字节拿到长度，再按长度读满消息体。
// 发送带长度前缀的消息 public static async Task SendMessageAsync(NetworkStream stream, byte[] body) { byte[] lengthPrefix = BitConverter.GetBytes(body.Length); // 4 字节长度头 await stream.WriteAsync(lengthPrefix, 0, 4); await stream.WriteAsync(body, 0, body.Length); } // 接收带长度前缀的消息 public static async Task<byte[]> ReceiveMessageAsync(NetworkStream stream) { byte[] lengthBuffer = new byte[4]; int totalRead = 0; while (totalRead < 4) // 确保长度头读满 { int read = await stream.ReadAsync(lengthBuffer, totalRead, 4 - totalRead); if (read == 0) throw new IOException("连接已关闭"); totalRead += read; } int bodyLength = BitConverter.ToInt32(lengthBuffer, 0); byte[] bodyBuffer = new byte[bodyLength]; totalRead = 0; while (totalRead < bodyLength) // 确保消息体读满 { int read = await stream.ReadAsync(bodyBuffer, totalRead, bodyLength - totalRead); if (read == 0) throw new IOException("连接已关闭"); totalRead += read; } return bodyBuffer; }这里有两个容易翻车的点。一是BitConverter的字节序依赖运行平台，x86/x64 是小端序，如果服务端和客户端平台不同，需要统一用IPAddress.HostToNetworkOrder转成网络字节序。二是ReadAsync的循环读取不能省，单次ReadAsync不保证读满请求的字节数，必须用while循环累积到目标长度。源码里如果没做这两点，跨平台或大数据量场景下必然出问题。
3. 把源码跑起来：环境配置与最小可运行步骤
3.1 开发环境与项目结构确认
这份源码基于 .NET 平台，常见做法是用 .NET 6 或 .NET 8 的 Console 项目模板。打开源码包后，先确认目录结构：通常包含一个服务端项目和一个客户端项目，可能还有共享的协议定义文件。用dotnet --list-sdks检查本机 SDK 版本，如果源码的目标框架是net6.0而本机只有net8.0，可以在.csproj里改<TargetFramework>或者安装对应运行时。
# 查看已安装的 .NET SDK dotnet --list-sdks # 进入服务端项目目录并还原依赖 cd TcpServer dotnet restore # 编译并运行服务端 dotnet run服务端启动后会在控制台打印监听端口，默认可能是 8888 或 9000，具体看源码里的常量定义。如果端口被占用，会抛SocketException，错误码通常是AddressAlreadyInUse，换一个端口即可。
3.2 客户端连接测试与参数调整
服务端跑起来后，另开一个终端运行客户端：
cd TcpClient dotnet run -- --host 127.0.0.1 --port 8888 --message "hello"如果源码没有做命令行参数解析，就需要手动改客户端里的host和port变量。连接成功后，服务端控制台会打印客户端端点信息，客户端会收到服务端的回显或确认消息。测试时建议先用127.0.0.1本机回环，排除网络因素；本机通了再换局域网 IP，最后再考虑跨网段。
参数方面，有几个值值得关注：ReceiveBufferSize和SendBufferSize影响单次收发的吞吐，默认值在大多数场景够用，但大文件传输时可以适当调大；NoDelay属性控制是否禁用 Nagle 算法，实时性要求高的场景（如游戏、即时通讯）建议设为true，代价是可能增加小包数量。
3.3 多客户端并发验证
单客户端跑通后，验证异步模型是否真正生效的方法是同时启动多个客户端。可以开多个终端手动运行，也可以写一个简单的批量脚本：
# 同时启动 20 个客户端实例（Linux/macOS） for i in $(seq 1 20); do dotnet run --project TcpClient -- --message "client-$i" & done wait观察服务端控制台是否同时打印了 20 个连接，以及各客户端的响应是否正常返回。如果服务端在处理某个连接时卡住，其他连接也收不到响应，说明代码里某处用了同步阻塞调用，需要回头检查是否有.Result或.Wait()混在异步链路里。
4. 避坑与排查：异步 Socket 最常见的五类翻车
4.1 现象：客户端连上了但收不到任何响应
原因通常是服务端在HandleClientAsync里用了同步stream.Read，而客户端发送的数据没有触发完整的消息边界，服务端一直在等更多数据。另一种可能是服务端把响应写到了错误的流上，比如多连接场景下用了共享的NetworkStream变量。
解决：检查HandleClientAsync内部是否每个连接独立持有自己的NetworkStream，确认读取循环有明确的退出条件（读到 0 字节或长度满足）。在关键路径加日志，打印「收到 N 字节」「准备回写 M 字节」，定位卡在哪一步。
4.2 现象：程序退出时抛ObjectDisposedException
原因是在CancellationToken触发后，后台任务还在访问已经被using释放的TcpClient或NetworkStream。异步任务的生命周期没有和资源释放对齐。
解决：在HandleClientAsync内部捕获ObjectDisposedException和OperationCanceledException，把它们当作正常退出信号处理。更稳妥的做法是用CancellationToken贯穿所有异步调用，在finally块里统一关闭连接，而不是依赖using的作用域。
4.3 现象：大数据量传输时内存暴涨
原因是接收端每次ReadAsync都new byte[bodyLength]，如果消息体很大（比如几十 MB），频繁分配大对象会触发 LOH（大对象堆）压力，GC 跟不上就内存飙升。
解决：对固定大小的消息用ArrayPool<byte>.Shared.Rent租借缓冲区，用完归还；或者限制单条消息的最大长度，超过阈值的消息走分片传输。源码里如果没做长度上限校验，恶意客户端可以发一个声称长度 2GB 的包头，直接让服务端 OOM。
4.4 现象：局域网内正常，跨网段连接超时
原因是ConnectAsync没有设置超时，默认依赖系统 TCP 超时（可能长达 20 秒以上）。跨网段时如果目标端口被防火墙丢弃而不是拒绝，连接会一直挂起。
解决：用CancellationTokenSource配合Task.WhenAny给连接加超时：
using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5)); try { await client.ConnectAsync(host, port, cts.Token); } catch (OperationCanceledException) { Console.WriteLine("连接超时，请检查目标地址和端口"); }4.5 现象：服务端 CPU 占用率异常高但吞吐很低
原因通常是「忙等待」——某个循环里没有await，线程一直在空转。比如while (!token.IsCancellationRequested) { }这种写法，或者ReadAsync返回 0 后没有退出循环，导致反复读 0 字节。
解决：用性能分析工具抓一下热点，确认 CPU 时间花在哪个方法上。检查所有while循环内部是否有真正的异步等待点，ReadAsync返回 0 时必须break或return，不能继续循环。
5. 进阶技巧：用PipeReader替代NetworkStream做零拷贝解析
NetworkStream的ReadAsync需要你自己管理缓冲区、处理粘包拆包，代码写多了容易乱。.NET 提供了System.IO.Pipelines，用PipeReader可以把「读数据」和「解析数据」解耦，天然支持背压和零拷贝切片。下面是一个用PipeReader读取长度前缀消息的示例：
// 使用 PipeReader 解析长度前缀消息 public static async Task<byte[]> ReadMessageWithPipeAsync(PipeReader reader) { while (true) { ReadResult result = await reader.ReadAsync(); ReadOnlySequence<byte> buffer = result.Buffer; // 尝试从缓冲区中解析出一条完整消息 if (buffer.Length >= 4) { // 读取长度头（不消费缓冲区） var lengthSlice = buffer.Slice(0, 4); int bodyLength = BitConverter.ToInt32(lengthSlice.ToArray(), 0); if (buffer.Length >= 4 + bodyLength) { // 消息体完整，切片取出 ReadOnlySequence<byte> bodySlice = buffer.Slice(4, bodyLength); byte[] body = bodySlice.ToArray(); // 告诉 PipeReader 已消费的字节数 reader.AdvanceTo(buffer.GetPosition(4 + bodyLength)); return body; } } // 数据不够，告诉 PipeReader 已检查的位置，等待更多数据 reader.AdvanceTo(buffer.Start, buffer.End); if (result.IsCompleted) throw new IOException("连接已关闭"); } }AdvanceTo的两个参数分别表示「已消费位置」和「已检查位置」。已消费位置之前的数据可以被回收，已检查位置表示你已经看过但还没消费的数据。这个机制让PipeReader能在不复制数据的情况下处理半包，比手动管理byte[]缓冲区高效得多。我一般会在新项目里直接用PipeReader，老代码迁移时才会保留NetworkStream的写法。
从那以后我每次拿到一份 TCP 源码，第一件事就是搜.Result和.Wait()，有就直接标红——异步链路里混同步阻塞，迟早出玄学问题。希望这份拆解能帮到你。
本文还有配套的精品资源，点击获取
