简介这份资源提供了一套用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 个线程。线程本身有栈空间开销默认 1MB100 个就是 100MB 虚拟内存更致命的是上下文切换CPU 大量时间花在保存和恢复线程状态上而不是处理数据。异步 Socket 走的是另一条路基于 IOCPI/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返回的是TaskTcpClientawait之后才拿到连接对象等待期间线程池线程可以复用。第二_ 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 Taskbyte[] 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 跟不上就内存飙升。解决对固定大小的消息用ArrayPoolbyte.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 Taskbyte[] ReadMessageWithPipeAsync(PipeReader reader) { while (true) { ReadResult result await reader.ReadAsync(); ReadOnlySequencebyte 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) { // 消息体完整切片取出 ReadOnlySequencebyte 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()有就直接标红——异步链路里混同步阻塞迟早出玄学问题。希望这份拆解能帮到你。本文还有配套的精品资源点击获取