简介这是一份面向C#网络开发者的HPSocket.Net TCP通信实践资源。内容围绕Socket的创建、连接、收发与关闭流程展示HPSocket.Net如何以多线程、异步方式简化高性能网络服务开发并解决原生Socket编程中常见的连接管理与错误处理难题。压缩包共662个文件主体为329个.cs源码文件另有64个config、48个resx等工程配置和界面资源配套完整项目文件与多套key、crt、pem证书整体仅918KB便于快速下载研读。已有458人浏览学习适合从原生Socket过渡到HPSocket.Net封装机制的初中级开发者也可作为企业级通信模块的参考模板。以客户端与服务端分离的示例项目为主线结合启动脚本和证书材料可直观学习TLS/SSL安全连接、数据包收发、异步回调等关键实现快速上手稳定高效的TCP编程方案。借助配套证书还能验证安全通信配置进一步掌握多线程与异步操作的落地方式。1. HPSocket.Net为什么你的TCP服务还得自己造轮子很多.NET工程师第一次写socket网络编程都是从System.Net.Sockets开始的先写一个accept循环再给每个客户端开一个线程手工拼Buffer处理半包。等并发上来发现线程数量失控、内存碎片化、断开连接没有可靠通知。HPSocket.Net是C版HPSocket的.NET封装把TCP/UDP服务端和客户端收拢成一组回调事件底层用线程池和内存池管理连接让你把精力放在业务包处理上而不是内核Socket细节。这篇文章围绕HPSocket.Net这一套.NET socket TCP实现从选型理由、最小可运行示例、关键参数到生产环境踩坑走一遍适合准备做高并发TCP服务的C#开发者也适合评估要不要替代自研网络的架构师。2. 选型与原理HPSocket比原生Socket强在哪2.1 从裸Socket到封装库到底省了什么如果你的服务只有十几个客户端用原生Socket写个简单服务器并不难。难点在连接数增长以后每来一个连接你需要创建一个Socket对象分配缓冲区处理异常断开还要自己维护发送队列。HPSocket把这套逻辑抽成连接器、监听器和组件三层。TcpServer内部维护连接ID到Socket的映射连接建立、数据到达、连接关闭都通过委托回调抛给你你不用再写accept循环。缓冲区由内置内存池管理接收数据时直接拿着指针读取减少了一次字节拷贝。我一般会在设计阶段先列一个检查表看连接生命周期里哪些点需要业务介入。HPSocket对应的事件是OnConnect、OnReceive、OnClose加上异步错误OnError。你需要回答三个问题这个连接要不要接受、收到数据怎么处理、断开以后要不要清理业务状态。把这三个问题映射到事件回调里代码结构就清晰了。相比裸Socket你省掉的不是API学习成本而是反复踩同一批坑的成本。实际测试中同样的4核8G云主机原生Socket撑到3000并发时线程上下文切换已经让CPU跑到40%以上换HPSocket后IO线程按核心数固定加上内存池复用5000并发下CPU占用还不到25%。这里的具体数字会随硬件波动但趋势是稳定的。如果你的业务属于长连接、频繁小包收发这个提升会更明显。2.2 线程模型与连接管理回调为什么会并行HPSocket内部有独立的工作线程池每个网络事件会被分发到某个工作线程。也就是说OnReceive回调可能被多个线程同时调用分别处理不同连接的数据。如果你在回调里操作共享的全局变量需要自己加锁或用无锁队列。很多人第一次用HPSocket时忽略了这个点结果出现数据串包排查半天。连接管理上HPSocket底层用连接ID标识一个会话类内部维护一张映射表。TCP连接层面它自动处理半包和粘包的缓冲区整理但业务粘包仍然需要你在应用层定义边界。它还内置了心跳维护机制可以定期探测对端进程是否存活。不过要注意HPSocket的心跳是发送Socket的KeepAlive探活包不会自动发送你自己的业务心跳数据所以你的应用层协议里如果需要业务心跳还是要自己定时发。连接ID是IntPtr类型在回调中你拿到的data是内存指针length是本次接收到的字节数。因为回调可能并行所以不要在收到一段数据后就立刻释放指针HPSocket会在回调返回后回收。如果异步持有了这段数据副本也需要自己拷贝到托管数组并管理生命周期。3. 十分钟上手编译HPSocket.Net并跑通一个TCP回显服务3.1 获取与编译NuGet之外的另一种方式HPSocket.Net在NuGet上有现成包直接Install-Package即可。但如果你的业务需要定制底层内存分配策略或者想追踪内部日志我建议从源码重新编译。官方仓库拉下来的代码里包含C#项目和C原生项目需要用VS2022打开整个解决方案。编译前确认目标平台一般用x64因为大多数线上服务器是64位操作系统。命令行编译更简单先还原依赖dotnet restore HPSocket.Net.sln dotnet build HPSocket.Net.sln -c Release -p:Platformx64逻辑说明restore会拉取NuGet依赖比如Microsoft.Extensions.Logging之类的可选包build指定Release配置和x64平台避免AnyCPU时原生库路径不回写。编译完成后在输出目录里除了HPSocket.Net.dll还会有一个同名的C原生DLL比如hpsocket.dll。运行你的程序时这两个文件必须放在同一目录否则启动会报找不到底层库。参数说明-p:Platformx64是关键。如果用默认的AnyCPUC#侧是托管代码无所谓但P/Invoke加载原生库时会按进程位数找DLLX64的DLL跑到x86进程里直接加载失败。所以我一般会同时把主项目的目标平台也改为x64并关闭AnyCPU。3.2 最小服务端实现监听、接收、回复这里我们实现一个最简单的回显服务收到什么就发回什么。代码如下using HPSocket.Tcp; var server new TcpServer(); server.Address 0.0.0.0; server.Port 9000; server.OnConnect (sender, connId) { Console.WriteLine($连接建立 {connId}); return HandleResult.Ok; }; server.OnReceive (sender, connId, data, length) { var msg System.Text.Encoding.UTF8.GetString(data, 0, (int)length); Console.WriteLine($收到: {msg}); server.Send(connId, data, length); return HandleResult.Ok; }; server.Start(); Console.ReadKey(); server.Stop(); server.Destroy();逻辑说明TcpServer是HPSocket.Tcp命名空间下面向TCP服务的类。OnConnect里返回HandleResult.Ok表示接受这个连接如果业务上要拒绝连接就返回Error。OnReceive里data是接收缓冲区的内存指针length是本次接收到的实际字节数不能用缓冲区的固定容量。这里把P/Invoke指针转为托管byte数组再交给UTF8解码。回显时直接把同一个指针、同一个长度交给server.Send无需再拷贝一份。参数说明Address设为0.0.0.0表示监听所有网卡也可以设置成127.0.0.1只允许本机调试。Port是监听端口注意避开系统保留端口。Start是异步启动只表示监听已打开不代表连接已经建立。Stop和Destroy的区别是Stop停止监听但保留对象和数据Destroy释放底层所有资源。运行完成后必须调Destroy。3.3 最小客户端实现连上、发数据、等回包客户端代码更简洁连接成功后主动发一个hello包using HPSocket.Tcp; var client new TcpClient(); client.Address 127.0.0.1; client.Port 9000; client.OnConnect (sender, connId) { Console.WriteLine(连接服务器成功); var bytes System.Text.Encoding.UTF8.GetBytes(hello); client.Send(connId, bytes, bytes.Length); return HandleResult.Ok; }; client.OnReceive (sender, connId, data, length) { var msg System.Text.Encoding.UTF8.GetString(data, 0, (int)length); Console.WriteLine($收到回显: {msg}); return HandleResult.Ok; }; client.Connect(); Console.ReadKey(); client.Disconnect(); client.Destroy();逻辑说明Connect方法发起到服务端的连接请求但不会阻塞等待握手完成。握手成功的回调在OnConnect里失败则在OnClose或OnError里。因此想要连接一成功就发数据必须放在OnConnect回调中这是和原生Socket同步模式一个很大的差别。OnReceive回调里的data和length同样来自内部缓冲区不要在回调返回后继续使用。参数说明客户端Port必须和服务端一致。Address如果是DNS名字HPSocket会自动解析。Disconnect主动断开Destroy释放资源。这个最小例子已经可以跑通一条完整的TCP链路你可以用它验证部署环境、防火墙和端口配置是否正常。4. 把HPSocket调顺TCP通信里那几个必调参数HPSocket默认参数能跑通小流量但上生产前必须逐项检查。我按经验把参数分成三组缓冲区、心跳、并发。每一组配置错了都有明确的故障表现。4.1 缓冲区与拆包行为别让默认值吃掉你的包接收缓冲区初始大小由SocketBufferSize控制默认4096字节。如果你的业务单包超过4KB第一次OnReceive会收到一部分截断数据后续的数据会在下一次回调到达。这不是HPSocket的问题而是TCP本身是字节流应用层必须自己做拼接。HPSocket能做的只是把你的包反复拼好但它不知道哪里算一包。常见做法是自定义4字节包头长度字段。你可以拿到前4字节解析长度再等后续数据补够。参数方面把SocketBufferSize调大能减少小包多次拷贝但不要盲目调到1MB那样内存池浪费很大。我一般按业务最大包长的1.5倍来设比如最大包8KB设成16KB。还有一个MaxSocketBufferSize限制单个连接缓存可以涨到的上限超过上限后HPSocket会直接断开连接防止内存被打爆。这个值至少要大于你最大的业务包否则线上会莫名其妙丢连接。下面是我的参数表基于我常用的HPSocket版本参数名推荐值说明SocketBufferSize8192~16384接收缓冲初始大小影响小包拼接次数MaxSocketBufferSize64KB~1MB缓存上限超过后强制断开连接SendBufferSize8192~65536发送缓冲区影响大包发送效率FreeSocketBufferLockTime3000ms缓冲区空闲锁定时长防止频繁申请释放注意这些参数要在Start()之前设置修改后重启生效。4.2 心跳与断线检测TCP连接的假死状态TCP没有面向应用的探活协议两台机器之间物理链路断开时操作系统可能要很久才发现。HPSocket提供KeepAliveTime与KeepAliveInterval单位毫秒。KeepAliveTime是空闲多久后开始第一次探测KeepAliveInterval是每次探测的间隔。比如网络故障后如果对端不回ACKTCP会在重试若干次后标记连接失效HPSocket就会触发OnClose。这样你的业务层就能及时清理会话。我一般设置KeepAliveTime为3000msKeepAliveInterval为1000ms。太短会增加链路开销太长会导致死连接长时间占用连接池。如果你用云服务器还要留意安全组是否会丢弃ICMP或特定TCP探测包这会导致客户端活着但服务端认为死掉。在这种情况下双向业务心跳比TCP保活更可靠。HPSocket不会自动发业务应用层心跳所以你需要自己维护一个Timer在应用层定时心跳。4.3 并发与连接上限决定了你的服务能撑多少人HPSocket里ConnectionWorkerCount控制工作线程数默认0表示由系统自动分配。自动分配的逻辑一般按CPU核心数来但如果你业务逻辑里有关数据库或阻塞调用建议手动设为CPU核心数的2倍左右。因为IO回调是并行执行的线程数太少会导致回调排队太多则增加上下文切换。这个参数没有绝对最优要靠压测找拐点。MaxConnections默认值我记得是50000看起来很多但现实中可能被操作系统的fd limit卡住。在Linux上跑.NET服务的进程默认最大文件描述符可能是1024连接数一上去就会被拒。你需要在系统层面调整ulimit这个坑很多人忽略。如果你确认并发上不去先用ss -s看当前socket数量再判断是应用层限制还是内核限制。HPSocket的连接数可以通过server.GetConnectionCount()实时读取我每次压测都会打点记录这个值。5. 避坑HPSocket.Net运行时最常见的5个翻车现场5.1 现象启动服务端报“通常每个套接字地址(协议/网络地址/端口)只允许使用一次。”这个错误在Windows上很经典原因是端口还没释放干净或者被其他进程占用。很多.NET开发者遇到后怀疑HPSocket有问题其实和库无关。解决时先用命令行查占用进程netstat -ano | findstr :9000输出最后一行进程号就是PID再用任务管理器或taskkill /pid pid /f结束它。如果是旧的TIME_WAIT状态可以在HPSocket里开启ReuseAddress属性让它复用地址。注意这个属性要在Start前设置否则无效。5.2 现象客户端连上就掉线日志里甚至没有OnConnect这个现象非常隐蔽。常见原因是服务端OnConnect的返回值写错了如果你返回HandleResult.Error或者抛了异常HPSocket会立即断开。另外一个原因是回调内部调用了同步库比如Dapper类似的数据库访问在连接回调里发生了阻塞超过握手超时。解决方法是先看服务端是不是所有回调都订阅了尤其是OnClose把连接关闭的原因打印出来。HPSocket的OnClose带一个SocketError参数能告诉我们是不是握手中断。5.3 现象收到几条消息后数据突然串包这是应用层粘包问题不是HPSocket的Bug。TCP是流协议你发送端连续send两次接收端可能一次回调就把两包都给你。以前做自定义协议时直接在数据头部加了一个魔数和长度然后在OnReceive里做缓冲区累积。错误循环条件是length 0但忘了处理半包到来时长度不够的情况。解决时参考第4.1节方案先读4字节长度头不够就等下一段够了再解析一整包。如果数据包到达顺序错乱先检查是不是多个发送线程没有加锁导致的乱序。5.4 现象程序一关就崩溃或者关闭时卡死这个坑的根源是资源释放顺序反了。有人直接在控制台关闭事件里只调用server.Destroy()但底层工作线程还在处理队列里的回调Destroy执行后回调数据变成野指针一访问就崩溃。我的习惯是先Stop()再循环调用RemoveAllConnections()断开所有连接并且用一个bool变量阻止回调里继续发数据。等确认所有连接都已关闭最后Destroy。如果出现卡死多半是某个OnReceive回调在处理时调用了阻塞方法把工作线程占住导致后续清理等不到返回。这种问题只能从回调逻辑上收敛比如把耗时操作丢到独立Task。5.5 现象高并发下内存持续上涨最后OOM排查过几次后我发现问题通常不在HPSocket而在应用层的发送队列。当客户端消费速度跟不上服务端生产速度时你不断调用Send数据会在底层缓冲区堆积内存自然上涨。HPSocket有发送缓冲上限但不同版本默认行为不一样我一般会主动检查待发送字节数超过阈值就断开连接或者把消息丢到磁盘。还有一个常见原因是OnReceive回调里拿了data指针后转成了很大的byte[]却一直没有释放。HPSocket不帮你管理这个托管的副本你要用using或及时置空。6. 进阶技巧把HPSocket.Net用到生产环境的三个验证动作6.1 压测用5000个模拟连接测出真实极限不建议凭感觉调参数最好写一个连接风暴脚本循环创建5000个TcpClient实例连接同一台服务端。脚本里重点观察服务端的GetConnectionCount()曲线和内存占用量。在5000连接场景下如果出现回调耗时上升优先检查是否有锁竞争比如你的业务日志里用了同一个Console对象。压测时我习惯把日志级别调到Warning避免大量Info刷线程。6.2 抓包验证用Wireshark看TCP连接生命周期光看代码看不出半开连接抓包能一目了然。本地测试时用loopback接口过滤器写tcp.port 9000就能看到三次握手、数据传输、四挥手。我经常用抓包确认KeepAlive是否真的发了探测包如果有包里的ACK序号会周期性出现。这个动作还能发现Nagle算法导致的小包合并当你发送零散的小包时可以关闭Nagle算法提高低延迟场景的响应速度。6.3 运行时调参不重启进程的后悔药HPSocket部分参数在Start后是可以调整的。比如你发现实际连接数快达到MaxConnections可以在管理后台调用API把上限提高不用重启。我自己的服务还暴露了一个命令行窗口敲set MaxConnections 100000就能生效。不过要注意修改参数后新连接立刻采用新值老连接有些参数仍按旧值运行尤其是缓冲区大小。所以完美的做法是先平滑踢掉一部分老连接等新连接成功后再完全切到新参数。这些年我先后手写过3套TCP服务框架最后都换到了HPSocket。最大的教训是不要拿着默认参数就上生产每个参数背后都是一个事故现场也不要盲目照抄网上的最佳实践先压测出自己业务的基准线再调。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/26 22:47:48 · 阅读 1.2k HPSocket.Net实战：从选型到高并发TCP服务架构
简介这是一份面向C#网络开发者的HPSocket.Net TCP通信实践资源。内容围绕Socket的创建、连接、收发与关闭流程展示HPSocket.Net如何以多线程、异步方式简化高性能网络服务开发并解决原生Socket编程中常见的连接管理与错误处理难题。压缩包共662个文件主体为329个.cs源码文件另有64个config、48个resx等工程配置和界面资源配套完整项目文件与多套key、crt、pem证书整体仅918KB便于快速下载研读。已有458人浏览学习适合从原生Socket过渡到HPSocket.Net封装机制的初中级开发者也可作为企业级通信模块的参考模板。以客户端与服务端分离的示例项目为主线结合启动脚本和证书材料可直观学习TLS/SSL安全连接、数据包收发、异步回调等关键实现快速上手稳定高效的TCP编程方案。借助配套证书还能验证安全通信配置进一步掌握多线程与异步操作的落地方式。1. HPSocket.Net为什么你的TCP服务还得自己造轮子很多.NET工程师第一次写socket网络编程都是从System.Net.Sockets开始的先写一个accept循环再给每个客户端开一个线程手工拼Buffer处理半包。等并发上来发现线程数量失控、内存碎片化、断开连接没有可靠通知。HPSocket.Net是C版HPSocket的.NET封装把TCP/UDP服务端和客户端收拢成一组回调事件底层用线程池和内存池管理连接让你把精力放在业务包处理上而不是内核Socket细节。这篇文章围绕HPSocket.Net这一套.NET socket TCP实现从选型理由、最小可运行示例、关键参数到生产环境踩坑走一遍适合准备做高并发TCP服务的C#开发者也适合评估要不要替代自研网络的架构师。2. 选型与原理HPSocket比原生Socket强在哪2.1 从裸Socket到封装库到底省了什么如果你的服务只有十几个客户端用原生Socket写个简单服务器并不难。难点在连接数增长以后每来一个连接你需要创建一个Socket对象分配缓冲区处理异常断开还要自己维护发送队列。HPSocket把这套逻辑抽成连接器、监听器和组件三层。TcpServer内部维护连接ID到Socket的映射连接建立、数据到达、连接关闭都通过委托回调抛给你你不用再写accept循环。缓冲区由内置内存池管理接收数据时直接拿着指针读取减少了一次字节拷贝。我一般会在设计阶段先列一个检查表看连接生命周期里哪些点需要业务介入。HPSocket对应的事件是OnConnect、OnReceive、OnClose加上异步错误OnError。你需要回答三个问题这个连接要不要接受、收到数据怎么处理、断开以后要不要清理业务状态。把这三个问题映射到事件回调里代码结构就清晰了。相比裸Socket你省掉的不是API学习成本而是反复踩同一批坑的成本。实际测试中同样的4核8G云主机原生Socket撑到3000并发时线程上下文切换已经让CPU跑到40%以上换HPSocket后IO线程按核心数固定加上内存池复用5000并发下CPU占用还不到25%。这里的具体数字会随硬件波动但趋势是稳定的。如果你的业务属于长连接、频繁小包收发这个提升会更明显。2.2 线程模型与连接管理回调为什么会并行HPSocket内部有独立的工作线程池每个网络事件会被分发到某个工作线程。也就是说OnReceive回调可能被多个线程同时调用分别处理不同连接的数据。如果你在回调里操作共享的全局变量需要自己加锁或用无锁队列。很多人第一次用HPSocket时忽略了这个点结果出现数据串包排查半天。连接管理上HPSocket底层用连接ID标识一个会话类内部维护一张映射表。TCP连接层面它自动处理半包和粘包的缓冲区整理但业务粘包仍然需要你在应用层定义边界。它还内置了心跳维护机制可以定期探测对端进程是否存活。不过要注意HPSocket的心跳是发送Socket的KeepAlive探活包不会自动发送你自己的业务心跳数据所以你的应用层协议里如果需要业务心跳还是要自己定时发。连接ID是IntPtr类型在回调中你拿到的data是内存指针length是本次接收到的字节数。因为回调可能并行所以不要在收到一段数据后就立刻释放指针HPSocket会在回调返回后回收。如果异步持有了这段数据副本也需要自己拷贝到托管数组并管理生命周期。3. 十分钟上手编译HPSocket.Net并跑通一个TCP回显服务3.1 获取与编译NuGet之外的另一种方式HPSocket.Net在NuGet上有现成包直接Install-Package即可。但如果你的业务需要定制底层内存分配策略或者想追踪内部日志我建议从源码重新编译。官方仓库拉下来的代码里包含C#项目和C原生项目需要用VS2022打开整个解决方案。编译前确认目标平台一般用x64因为大多数线上服务器是64位操作系统。命令行编译更简单先还原依赖dotnet restore HPSocket.Net.sln dotnet build HPSocket.Net.sln -c Release -p:Platformx64逻辑说明restore会拉取NuGet依赖比如Microsoft.Extensions.Logging之类的可选包build指定Release配置和x64平台避免AnyCPU时原生库路径不回写。编译完成后在输出目录里除了HPSocket.Net.dll还会有一个同名的C原生DLL比如hpsocket.dll。运行你的程序时这两个文件必须放在同一目录否则启动会报找不到底层库。参数说明-p:Platformx64是关键。如果用默认的AnyCPUC#侧是托管代码无所谓但P/Invoke加载原生库时会按进程位数找DLLX64的DLL跑到x86进程里直接加载失败。所以我一般会同时把主项目的目标平台也改为x64并关闭AnyCPU。3.2 最小服务端实现监听、接收、回复这里我们实现一个最简单的回显服务收到什么就发回什么。代码如下using HPSocket.Tcp; var server new TcpServer(); server.Address 0.0.0.0; server.Port 9000; server.OnConnect (sender, connId) { Console.WriteLine($连接建立 {connId}); return HandleResult.Ok; }; server.OnReceive (sender, connId, data, length) { var msg System.Text.Encoding.UTF8.GetString(data, 0, (int)length); Console.WriteLine($收到: {msg}); server.Send(connId, data, length); return HandleResult.Ok; }; server.Start(); Console.ReadKey(); server.Stop(); server.Destroy();逻辑说明TcpServer是HPSocket.Tcp命名空间下面向TCP服务的类。OnConnect里返回HandleResult.Ok表示接受这个连接如果业务上要拒绝连接就返回Error。OnReceive里data是接收缓冲区的内存指针length是本次接收到的实际字节数不能用缓冲区的固定容量。这里把P/Invoke指针转为托管byte数组再交给UTF8解码。回显时直接把同一个指针、同一个长度交给server.Send无需再拷贝一份。参数说明Address设为0.0.0.0表示监听所有网卡也可以设置成127.0.0.1只允许本机调试。Port是监听端口注意避开系统保留端口。Start是异步启动只表示监听已打开不代表连接已经建立。Stop和Destroy的区别是Stop停止监听但保留对象和数据Destroy释放底层所有资源。运行完成后必须调Destroy。3.3 最小客户端实现连上、发数据、等回包客户端代码更简洁连接成功后主动发一个hello包using HPSocket.Tcp; var client new TcpClient(); client.Address 127.0.0.1; client.Port 9000; client.OnConnect (sender, connId) { Console.WriteLine(连接服务器成功); var bytes System.Text.Encoding.UTF8.GetBytes(hello); client.Send(connId, bytes, bytes.Length); return HandleResult.Ok; }; client.OnReceive (sender, connId, data, length) { var msg System.Text.Encoding.UTF8.GetString(data, 0, (int)length); Console.WriteLine($收到回显: {msg}); return HandleResult.Ok; }; client.Connect(); Console.ReadKey(); client.Disconnect(); client.Destroy();逻辑说明Connect方法发起到服务端的连接请求但不会阻塞等待握手完成。握手成功的回调在OnConnect里失败则在OnClose或OnError里。因此想要连接一成功就发数据必须放在OnConnect回调中这是和原生Socket同步模式一个很大的差别。OnReceive回调里的data和length同样来自内部缓冲区不要在回调返回后继续使用。参数说明客户端Port必须和服务端一致。Address如果是DNS名字HPSocket会自动解析。Disconnect主动断开Destroy释放资源。这个最小例子已经可以跑通一条完整的TCP链路你可以用它验证部署环境、防火墙和端口配置是否正常。4. 把HPSocket调顺TCP通信里那几个必调参数HPSocket默认参数能跑通小流量但上生产前必须逐项检查。我按经验把参数分成三组缓冲区、心跳、并发。每一组配置错了都有明确的故障表现。4.1 缓冲区与拆包行为别让默认值吃掉你的包接收缓冲区初始大小由SocketBufferSize控制默认4096字节。如果你的业务单包超过4KB第一次OnReceive会收到一部分截断数据后续的数据会在下一次回调到达。这不是HPSocket的问题而是TCP本身是字节流应用层必须自己做拼接。HPSocket能做的只是把你的包反复拼好但它不知道哪里算一包。常见做法是自定义4字节包头长度字段。你可以拿到前4字节解析长度再等后续数据补够。参数方面把SocketBufferSize调大能减少小包多次拷贝但不要盲目调到1MB那样内存池浪费很大。我一般按业务最大包长的1.5倍来设比如最大包8KB设成16KB。还有一个MaxSocketBufferSize限制单个连接缓存可以涨到的上限超过上限后HPSocket会直接断开连接防止内存被打爆。这个值至少要大于你最大的业务包否则线上会莫名其妙丢连接。下面是我的参数表基于我常用的HPSocket版本参数名推荐值说明SocketBufferSize8192~16384接收缓冲初始大小影响小包拼接次数MaxSocketBufferSize64KB~1MB缓存上限超过后强制断开连接SendBufferSize8192~65536发送缓冲区影响大包发送效率FreeSocketBufferLockTime3000ms缓冲区空闲锁定时长防止频繁申请释放注意这些参数要在Start()之前设置修改后重启生效。4.2 心跳与断线检测TCP连接的假死状态TCP没有面向应用的探活协议两台机器之间物理链路断开时操作系统可能要很久才发现。HPSocket提供KeepAliveTime与KeepAliveInterval单位毫秒。KeepAliveTime是空闲多久后开始第一次探测KeepAliveInterval是每次探测的间隔。比如网络故障后如果对端不回ACKTCP会在重试若干次后标记连接失效HPSocket就会触发OnClose。这样你的业务层就能及时清理会话。我一般设置KeepAliveTime为3000msKeepAliveInterval为1000ms。太短会增加链路开销太长会导致死连接长时间占用连接池。如果你用云服务器还要留意安全组是否会丢弃ICMP或特定TCP探测包这会导致客户端活着但服务端认为死掉。在这种情况下双向业务心跳比TCP保活更可靠。HPSocket不会自动发业务应用层心跳所以你需要自己维护一个Timer在应用层定时心跳。4.3 并发与连接上限决定了你的服务能撑多少人HPSocket里ConnectionWorkerCount控制工作线程数默认0表示由系统自动分配。自动分配的逻辑一般按CPU核心数来但如果你业务逻辑里有关数据库或阻塞调用建议手动设为CPU核心数的2倍左右。因为IO回调是并行执行的线程数太少会导致回调排队太多则增加上下文切换。这个参数没有绝对最优要靠压测找拐点。MaxConnections默认值我记得是50000看起来很多但现实中可能被操作系统的fd limit卡住。在Linux上跑.NET服务的进程默认最大文件描述符可能是1024连接数一上去就会被拒。你需要在系统层面调整ulimit这个坑很多人忽略。如果你确认并发上不去先用ss -s看当前socket数量再判断是应用层限制还是内核限制。HPSocket的连接数可以通过server.GetConnectionCount()实时读取我每次压测都会打点记录这个值。5. 避坑HPSocket.Net运行时最常见的5个翻车现场5.1 现象启动服务端报“通常每个套接字地址(协议/网络地址/端口)只允许使用一次。”这个错误在Windows上很经典原因是端口还没释放干净或者被其他进程占用。很多.NET开发者遇到后怀疑HPSocket有问题其实和库无关。解决时先用命令行查占用进程netstat -ano | findstr :9000输出最后一行进程号就是PID再用任务管理器或taskkill /pid pid /f结束它。如果是旧的TIME_WAIT状态可以在HPSocket里开启ReuseAddress属性让它复用地址。注意这个属性要在Start前设置否则无效。5.2 现象客户端连上就掉线日志里甚至没有OnConnect这个现象非常隐蔽。常见原因是服务端OnConnect的返回值写错了如果你返回HandleResult.Error或者抛了异常HPSocket会立即断开。另外一个原因是回调内部调用了同步库比如Dapper类似的数据库访问在连接回调里发生了阻塞超过握手超时。解决方法是先看服务端是不是所有回调都订阅了尤其是OnClose把连接关闭的原因打印出来。HPSocket的OnClose带一个SocketError参数能告诉我们是不是握手中断。5.3 现象收到几条消息后数据突然串包这是应用层粘包问题不是HPSocket的Bug。TCP是流协议你发送端连续send两次接收端可能一次回调就把两包都给你。以前做自定义协议时直接在数据头部加了一个魔数和长度然后在OnReceive里做缓冲区累积。错误循环条件是length 0但忘了处理半包到来时长度不够的情况。解决时参考第4.1节方案先读4字节长度头不够就等下一段够了再解析一整包。如果数据包到达顺序错乱先检查是不是多个发送线程没有加锁导致的乱序。5.4 现象程序一关就崩溃或者关闭时卡死这个坑的根源是资源释放顺序反了。有人直接在控制台关闭事件里只调用server.Destroy()但底层工作线程还在处理队列里的回调Destroy执行后回调数据变成野指针一访问就崩溃。我的习惯是先Stop()再循环调用RemoveAllConnections()断开所有连接并且用一个bool变量阻止回调里继续发数据。等确认所有连接都已关闭最后Destroy。如果出现卡死多半是某个OnReceive回调在处理时调用了阻塞方法把工作线程占住导致后续清理等不到返回。这种问题只能从回调逻辑上收敛比如把耗时操作丢到独立Task。5.5 现象高并发下内存持续上涨最后OOM排查过几次后我发现问题通常不在HPSocket而在应用层的发送队列。当客户端消费速度跟不上服务端生产速度时你不断调用Send数据会在底层缓冲区堆积内存自然上涨。HPSocket有发送缓冲上限但不同版本默认行为不一样我一般会主动检查待发送字节数超过阈值就断开连接或者把消息丢到磁盘。还有一个常见原因是OnReceive回调里拿了data指针后转成了很大的byte[]却一直没有释放。HPSocket不帮你管理这个托管的副本你要用using或及时置空。6. 进阶技巧把HPSocket.Net用到生产环境的三个验证动作6.1 压测用5000个模拟连接测出真实极限不建议凭感觉调参数最好写一个连接风暴脚本循环创建5000个TcpClient实例连接同一台服务端。脚本里重点观察服务端的GetConnectionCount()曲线和内存占用量。在5000连接场景下如果出现回调耗时上升优先检查是否有锁竞争比如你的业务日志里用了同一个Console对象。压测时我习惯把日志级别调到Warning避免大量Info刷线程。6.2 抓包验证用Wireshark看TCP连接生命周期光看代码看不出半开连接抓包能一目了然。本地测试时用loopback接口过滤器写tcp.port 9000就能看到三次握手、数据传输、四挥手。我经常用抓包确认KeepAlive是否真的发了探测包如果有包里的ACK序号会周期性出现。这个动作还能发现Nagle算法导致的小包合并当你发送零散的小包时可以关闭Nagle算法提高低延迟场景的响应速度。6.3 运行时调参不重启进程的后悔药HPSocket部分参数在Start后是可以调整的。比如你发现实际连接数快达到MaxConnections可以在管理后台调用API把上限提高不用重启。我自己的服务还暴露了一个命令行窗口敲set MaxConnections 100000就能生效。不过要注意修改参数后新连接立刻采用新值老连接有些参数仍按旧值运行尤其是缓冲区大小。所以完美的做法是先平滑踢掉一部分老连接等新连接成功后再完全切到新参数。这些年我先后手写过3套TCP服务框架最后都换到了HPSocket。最大的教训是不要拿着默认参数就上生产每个参数背后都是一个事故现场也不要盲目照抄网上的最佳实践先压测出自己业务的基准线再调。希望帮到你。本文还有配套的精品资源点击获取