在当今万物互联的时代，物联网（IoT）设备的数量正以一种让程序员们头皮发麻的速度增长。这些设备每天通过网络传输的数据量，大概可以把一个普通开发者的大脑硬盘塞到格式化重装的程度。

而在这个"一切皆联网"的洪流中，TCP 服务器扮演着承上启下的核心角色——它既要接受来自四面八方、操着各种稀奇古怪协议方言的设备连接，又要把这些数据可靠地处理并转发出去。说白了，它就是那个全能保姆，还不能休假。

作为 TouchSocket 网络通信框架的作者，我经常在各种群里看到这样的场景：

某开发者：为什么我的 TCP 服务器运行一段时间就崩了？

我：你的服务器是怎么创建的？

某开发者：new TcpService() 啊，哪里有问题？

这就好比你找了一个世界顶级主厨，然后让他站在路边摆摊煎饼果子——不是不行，但总感觉哪里不对劲。

TCP 服务器不是一个随手创建、用完即弃的玩具。它需要精心设计的架构、合理的配置管理、优雅的插件化扩展，以及——最重要的——要能活得久。

所以，我决定写这篇博客，手把手带你构建一个真正高可用的 TCP 服务器。用通俗的话说——就是那种即使凌晨 3 点宕机了，你的手机也不会被运维的电话打爆的服务器。

二、技术细节​

2.1 技术框架​

本文使用微软提供的通用主机（Generic Host） 进行构建，这套体系就像是给你的应用装了一套 PM（进程管理）+ 配置中心 + IOC 容器的豪华套餐，支持：

• 跨平台（Windows、Linux、macOS，就差运行在烤面包机上了）
• Windows 服务（让服务器在后台默默干活，不打扰你工作摸鱼）
• IIS 托管
• Options 选项配置（告别硬编码端口，yyds）
• 插件化加载（像乐高一样搭积木）
• IOC 容器（依赖注入，让代码松耦合不粘手）
• Native AOT（让你的 exe 小到让同事以为你在传病毒）

2.2 框架版本​

支持：

• .NET Framework 4.6.2 及以上（是的，古老的 462 也没被抛弃）
• .NET 6 及以上

2.3 实现功能​

本示例将实现以下功能（画的饼，本文全部会兑现）：

• 接收、发送数据
• 消息单次响应
• 消息广播（群发，比你微信群艾特所有人还快）
• 数据库持久化（把数据存起来，不然断电就白干了）

三、项目结构设计​

本文示例使用 .NET 10.0 构建，拆分为 5 个项目，如果你觉得这样太麻烦，可以先把所有代码塞在一个文件里……不过等你的代码行数超过 3000 行时，你会来感谢我的。

也支持完整的 Native AOT。

项目结构如下：

HighlyAvailableTcpService.App                  ← 主程序，启动入口
HighlyAvailableTcpService.Core                 ← 核心库，定义接口和 Options
HighlyAvailableTcpService.Plugins              ← 插件层，业务逻辑的家
HighlyAvailableTcpService.DataHandlingAdapters ← 数据适配器，数据解包的地方
HighlyAvailableTcpService.Db                   ← 数据库层，数据的最终归宿

项目引用关系：

App → Core, Plugins, DataHandlingAdapters, Db
Plugins → Core, DataHandlingAdapters, Db
DataHandlingAdapters → Core
Db（无额外引用）

四、创建项目​

首先，使用 辅助角色服务 模板创建一个 .NET 10.0 项目，名称为 HighlyAvailableTcpService.App。这是我们的主程序，也是最终启动的入口。

如果你仍在坚守 .NET Framework 4.6.2，也可以先按 net10 创建，再把 .csproj 里的 <TargetFramework>net10.0</TargetFramework> 改成 <TargetFramework>net462</TargetFramework>。记得勾选不使用顶级语句和取消勾选 AOT，否则编译时会给你一个"惊喜"。

然后用 nuget 安装 TouchSocket.Hosting。如果不熟悉 nuget，可以参考入门指南。

接下来，再分别新建以下类库项目：

• HighlyAvailableTcpService.Core

• HighlyAvailableTcpService.Plugins
• HighlyAvailableTcpService.DataHandlingAdapters
• HighlyAvailableTcpService.Db

按照第三章的项目引用关系配置好后，我们就可以愉快地开始码字了。

五、完善 Core 核心库​

HighlyAvailableTcpService.Core 是整个项目的基础设施层，里面住着各种接口、配置类——用一句流行语来说，它是整个系统的"灵魂"。

5.1 创建自定义 Tcp 会话客户端接口​

首先定义 IHighlyAvailableSessionClient 接口，继承 ITcpSessionClient。这个接口就像是给每个连进来的设备颁发的"身份证"，让我们统一管理：

接口里定义了 SetHighlyAvailableAdapter 方法，用于为会话单独设置数据处理适配器（别把适配器搞混了，它不是充电头）。详情见适配器介绍与使用。

接下来，定义实现类 HighlyAvailableSessionClient，继承 TcpSessionClient 并实现上面的接口：

5.2 创建自定义 Tcp 服务接口与实现​

再定义服务接口 IHighlyAvailableTcpService，继承 ITcpService<HighlyAvailableSessionClient>。有了这个接口，以后想扩展功能就直接往接口里加，不用到处乱找实现类：

然后是内部实现类 HighlyAvailableTcpService，注意这里用了 internal——外面的世界看不到它，就让它安安静静地在内部干活：

5.3 定义 Options 配置类​

接下来定义配置选项类 HighlyAvailableTcpServiceOption，用于映射配置文件中的每条监听配置：

因为服务器可能需要同时监听多个端口（比如同时对外提供 HTTP 和私有协议的服务），所以还需要一个集合配置类。顺带考虑了 Native AOT 的兼容性：

5.4 注册扩展方法​

因为 HighlyAvailableTcpService 是 internal 的，外部项目不能直接 new 它出来，所以我们提供一个扩展方法来暴露注册能力。这样外部只需要调用一个方法，内部的脏活我们全包了：

5.5 主项目中应用​

首先，在 Program.cs 中绑定配置文件：

对应的开发环境配置文件如下：

{
  "HighlyAvailableTcpServiceOptions": {
    "Options": [
      {
        "Name": "HighlyAvailableTcpService",
        "Port": 7789,
        "Ip": "127.0.0.1",
        "Backlog": 100,
        "SslPath": "",
        "SslKey": ""
      }
    ]
  }
}

然后注册 TCP 服务。此刻先不配置监听端口——我们计划用插件机制动态添加监听，避免在启动逻辑里硬编码一堆端口号，顺带利用插件机制 和动态监听 来完成：

完成以上步骤后，可以尝试启动项目，控制台应该会出现类似这样的日志——说明服务器已经成功站岗了：

info: TouchSocket.Sockets.CheckClearPlugin begin polling
info: TouchSocket.Hosting.Sockets.HostService.ServiceHost[0]
      服务器已启动。
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.

六、完善数据适配器项目​

数据适配器项目 HighlyAvailableTcpService.DataHandlingAdapters 的职责是：把从 TCP 流里读出来的一坨字节，翻译成程序能理解的结构化数据。关于适配器的详细介绍，可以参考适配器文档。

本示例的数据解析规则很简单：

• 接收字符串数据，遇到 \r\n 就认为一条消息结束了

（就像古代的竹简，遇到空白就代表一句话说完了。）

6.1 解析数据​

首先定义承载解析结果的类 HighlyAvailableRequestInfo，以及继承自 CustomBetweenAndDataHandlingAdapter 的适配器类 HighlyAvailableDataAdapter：

6.2 关于适配器的应用​

适配器可以在 TouchSocketConfig 中进行全局统一配置，但在本示例中，我们把适配器的设置交给了插件层来管理——这样可以为不同类型的设备连接单独设置不同的适配器，具体实现见下一章的 AdapterPlugin。

七、完善插件项目​

插件项目 HighlyAvailableTcpService.Plugins 是业务逻辑的主战场。我们遵循单一职责原则：每个插件只做一件事，处理不了的就传给下一个插件。这套机制就像流水线作业，每个工人只负责自己这道工序。

关于插件系统的介绍，可以参考插件系统文档。

7.1 监听配置插件​

监听配置插件负责在服务器启动时，从配置文件读取端口信息并动态添加监听。

这样做的好处是：改个端口只需要改配置文件，不用重新编译代码。运维同学会感谢你的：

7.2 适配器插件​

当一个新设备连接进来时，这个插件立刻为它分配专属的数据适配器。你可以在这里根据 IP、端口、连接时间……甚至月相来决定给它用什么适配器：

7.3 日志插件​

日志是程序员最好的朋友，尤其是在凌晨 3 点被电话叫醒排查问题的时候。

这里使用了 PluginOption(FromIoc = true)，让日志插件从 IOC 容器中取实例，支持 Scoped 依赖注入：

配置 NLog 日志组件。首先 nuget 安装 NLog.Extensions.Logging，然后在 Program.cs 中配置：

并且把 TouchSocket 的内部日志也接入 AspNetCore 日志体系：

7.4 Hello 数据处理插件​

这是一个最简单的业务插件示例：收到 "hello" 就回复 "hi"。虽然逻辑简单，但它展示了插件链式处理数据的核心思路——如果数据不归我处理，就往后传：

7.5 登录插件与会话状态暂存​

在实际业务中，我们经常需要记录某个会话的状态，比如"这个设备登录了吗？用户名叫什么？"。

TouchSocket 提供了基于依赖属性的扩展机制。我们先定义扩展属性——注意 SetUserName 是 internal 的，只有在我们自己的插件里才能设置用户名，外部只能读取，防止外部乱改：

然后定义登录处理插件：

7.6 广播插件​

广播功能是很多物联网平台的刚需——比如把某个传感器的告警消息推送给所有连接中的监控终端。

这里使用了 Channel<string> 来做异步消息队列，避免在接收数据的线程上直接遍历所有会话导致性能抖动：

当收到 "broadcast" 消息时，就把数据塞进 Channel，由后台任务负责挨个发送给所有在线会话。即使某个会话发送失败，也不会影响其他会话的发送——这才叫"高可用"。

7.7 注册插件到容器（Scoped 支持）​

需要使用 IOC 注入的插件（即标注了 [PluginOption(FromIoc = true)] 的），需要先在服务容器中注册：

7.8 插件注册扩展​

和 Core 层一样，插件层也提供一个统一的扩展方法，让外部只需一行代码就能启用所有插件：

最终在主项目中调用：

八、完善 Db 数据库层​

数据库层 HighlyAvailableTcpService.Db 负责把重要数据持久化到磁盘中。毕竟，内存是易忘症患者，断电就失忆；数据库才是靠谱的日记本。

本项目使用 SQLite + SqlSugar 的组合：

• SQLite：轻量级嵌入式数据库，零配置，随项目走，适合中小规模的 IoT 数据存储
• SqlSugar：国产 ORM 框架，API 简洁，性能优秀（而且 Native AOT 支持做得很好）

8.1 定义数据库实体​

定义用户实体类，这里只是一个示例结构：

8.2 注册数据库服务​

注册 SQLite 连接和仓储模式。这里通过 CodeFirst 方式在首次运行时自动建表，省去了手动执行 SQL 脚本的麻烦：

在 Program.cs 中调用：

8.3 DbPlugin 数据库插件​

当收到 "Add" 消息时，自动往数据库里插入一条用户记录。需要注意的是，AOT 环境下 ORM 的反射功能受限，所以这里用了条件编译符来区分：

九、Native AOT​

如果你追求极致的启动速度和极小的发布体积，.NET 10.0 及以上版本可以使用 Native AOT 发布。

只需在 .csproj 中添加：

<PublishAot>true</PublishAot>

然后右击项目 → 发布 → 新建配置，最终发布配置如下：

发布后，可执行文件仅 6.6 MB，是的你没看错，6.6 MB，比你手机上随手下载的一个表情包 App 还小：

十、设为 Windows 服务​

10.1 配置 Windows 服务​

通用主机天然支持作为 Windows 服务运行。详细介绍，请参考：使用 BackgroundService 创建 Windows 服务。

首先 nuget 安装 Microsoft.Extensions.Hosting.WindowsServices，然后在 Program.cs 中加入：

这段代码我们已经在主程序里写好了——而且加了跨平台判断，在 Linux 上运行时不会出错，毕竟我们承诺过跨平台。

10.2 安装、启动服务​

sc create HighlyAvailableTcpService binPath= %~dp0HighlyAvailableTcpService.App.exe start= auto
sc description HighlyAvailableTcpService "高可用Tcp服务"
Net Start HighlyAvailableTcpService
pause

10.3 卸载、停止服务​

net stop HighlyAvailableTcpService
sc delete HighlyAvailableTcpService
pause

十一、最佳实践​

积累了无数次被用户"温柔鞭打"的经验后，给大家整理以下最佳实践——希望你少踩一点坑。

11.1 日志分级别输出​

TouchSocket 内部会把网络异常（比如对端突然断开）记录为日志，这些日志在生产环境中往往是"已知噪音"。建议在 NLog 配置中：

• 通信组件的日志输出到单独的文件（比如 touchsocket.log）
• 业务日志输出到主日志文件

这样排查问题时就不会被一堆 "连接已断开" 日志淹没。

11.2 使用依赖属性暂存会话状态​

如果需要为每个连接的设备暂存状态（比如认证信息、设备类型、最后活跃时间），推荐使用 TouchSocket 提供的 DependencyProperty 机制，而不是用 ConcurrentDictionary 满天飞。

好处：

• 随会话生命周期自动管理，不用担心内存泄漏
• 访问接口统一，代码整洁
• SetUserName 设为 internal 后，外部只能读不能写，天然防止误操作

11.3 插件顺序很重要​

插件的执行顺序就是注册顺序。日志插件要放在业务数据处理插件前面，这样才能记录到完整的处理耗时。否则日志只记录到"数据到了"，不知道后续花了多少时间处理。

11.4 广播消息用 Channel 解耦​

不要在接收数据的回调里直接遍历所有会话发送消息！这会导致发送耗时阻塞接收线程。正确姿势是用 Channel<T> 或其他异步队列，把消息投递交给专属后台任务处理。

BroadcastPlugin 就是这个思路的最佳实践。

11.5 Native AOT 兼容性注意​

如果使用 Native AOT 发布，需要注意：

• 反射受限，某些 ORM 的动态查询功能不可用（如示例中的 DbPlugin 用了 #if !AOT）
• 检查所有第三方库是否支持 AOT（SqlSugar 需要手动开启 StaticConfig.EnableAot = true）

十二、总结​

好了，我们用一整篇博客，把一个"高可用 TCP 服务器"的各个器官全部安装完毕：

核心设计理念：

• 插件化：每个业务逻辑一个插件，互不干扰，随时可插拔
• 配置驱动：端口、IP、证书全部走配置文件，零硬编码
• 分层解耦：Core / Adapters / Plugins / Db 各司其职，改一层不影响另一层
• 高可用：健康清理插件 + 异步广播 + AOT 支持 = 稳定运行，不让运维老哥半夜起床

希望这篇博客能帮你少走弯路，早日构建出那个不会让手机被叫爆的 TCP 服务器。祝编译一次通过，Bug 从不出现在生产！

十三、参考资料​

1. TouchSocket 官网
2. .NET 通用主机
3. 使用 BackgroundService 创建 Windows 服务
4. 适配器介绍与使用
5. 插件系统文档

十四、本文示例 Demo​

在一个阳光明媚的下午，我正悠哉悠哉地更新博客。忽然，一条来自群友的私信打破了宁静——这位朋友是一名对网络编程充满热情的大学生，最近正在研究 TCP 连接数量限流和接收流量限流。他噼里啪啦连续发来一堆问题，我的屏幕差点没装下……

其实，限流这个话题，本质上就是 "服务器学会说不" 的艺术。

你想想：一个热门餐厅，如果不限号，来多少人接多少，厨师当场崩溃，菜没法做，最终所有人都饿肚子。但如果合理地限制每桌用餐人数、控制上菜速度，反而能让大家都享受美食体验。TCP 限流的道理如出一辙。

以前写过一篇博客聊过相关话题，但那会儿写得太简单，点到即止。这次要升级一下方案，把原理和代码都聊清楚，让你彻底搞明白——如何用最优雅的方式，礼貌而坚定地"限制"你的客户端。

二、技术选型：站在巨人的肩膀上​

2.1 TCP 服务器：TouchSocket​

这里使用 TouchSocket-TcpService 作为 TCP 服务器。

为什么选它？因为 TouchSocket 支持插件化的开发方式，我们可以把限流逻辑封装进插件里，做到：

• 逻辑清晰，一眼看出这个插件是干嘛的
• 可插拔，不需要限流了直接卸载插件即可
• 可复用，写一次，到处用

就好比给餐厅门口配了一个"礼貌但强硬"的门卫，而不是让每个厨师自己去拦客——专业分工，效率翻倍。

2.2 限流算法：微软官方出品​

限流算法使用微软提供的 System.Threading.RateLimiting 库。这个库是 .NET 官方在 .NET 7 中引入的，专门用来实现流量控制，可靠性拉满。

它内置了 4 种限流算法，各有特点：

本文示例以固定时间窗口为例。其他算法的用法大同小异，具体参数可参考微软官方文档，举一反三即可。

三、实践效果：眼见为实​

话不多说，先看效果。下图演示了连接数量限流和流量限流的实际效果：

• 当连接数超过上限时，新连接会被礼貌拒绝（服务器内心：对不起，我已经满了）
• 当某个客户端发送数据过快时，服务器会优雅减速（不是不收，是慢慢收）

是不是很丝滑？接下来我们就来看看这背后的代码实现。

四、代码实现：插件化的艺术​

4.1 整体架构​

整个限流方案基于 TouchSocket 的插件体系，我们只需要在服务器启动时注册好两个插件即可——连接限流插件和接收流量限流插件。

服务器启动代码如下：

就这么简单！接下来分别看这两个插件的内部实现。

4.2 连接限流插件​

连接限流的核心思路：在握手阶段就拦截。

TouchSocket 提供了 ITcpConnectingPlugin 接口，它会在 TCP 连接建立之前触发。我们在这里检查是否超过连接数限制，超了就拒之门外——就像夜店门口的保镖，超员了直接让你回家。

完整插件代码如下：

关键点解析​

限流器初始化：

这里的参数含义：

• PermitLimit = 2：每个时间窗口内最多允许 2 个新连接（演示用，生产环境请适当调大）
• QueueLimit = 4：允许最多 4 个请求在队列中等待（这里我们选择直接拒绝，所以这个参数不太关键）
• Window = TimeSpan.FromSeconds(5)：时间窗口为 5 秒

连接拒绝逻辑：

代码非常直接：AttemptAcquire(1) 尝试获取一个令牌，如果没拿到（IsAcquired == false），就设置 e.IsPermitOperation = false，直接拒绝连接。顺便记录一条警告日志，让你知道是谁在"碰壁"。

4.3 接收流量限流插件​

流量限流和连接限流有一个本质区别：连接限流是全局的（针对所有连接），而流量限流是per-client 的（每个客户端独立计算自己的配额）。

这就像：餐厅的座位总数是固定的（全局），但每桌的上菜速度要单独控制（per-client），不能因为某桌狼吞虎咽就让其他桌也饿着。

4.3.1 per-client 的限流器绑定​

为了给每个客户端绑定独立的限流器，这里巧妙地使用了 TouchSocket 的 DependencyProperty（扩展属性）机制，而不是靠字典维护——这样可以随着客户端的生命周期自动管理，免去了手动清理的麻烦。

这段代码声明了一个懒加载的扩展属性：当某个 ITcpSession 第一次调用 GetValue(RateLimiterProperty) 时，才会触发 OnCreateRateLimiter 工厂方法，为这个客户端创建专属的限流器并缓存起来。

这就是典型的"按需创建，随用随取"的设计思路，既优雅又高效。

4.3.2 流量消费逻辑​

这里有一个细节需要注意：每次 AcquireAsync(step) 请求的 step 不能超过限流器的 PermitLimit。当一次性接收的数据量很大时，需要用循环分批"消费"令牌，直到所有数据都被处理完毕。

这类似于自助餐的取菜逻辑——盘子只有那么大，超过盘子容量的食物需要分两盘装。

4.3.3 完整插件代码​

五、进阶思考：限流的背后​

5.1 为什么要限流？​

不限流会发生什么？想象一下：

1. 连接爆炸：某个脑回路不正常的客户端（或者被攻击了）疯狂建立连接，服务器的文件描述符耗尽，新连接一个都接不了——这就是经典的连接耗尽攻击。
2. 带宽打爆：某个客户端疯狂发数据，独占了所有带宽，其他客户端的数据淤积在缓冲区，体验极差。
3. 内存溢出：接收缓冲区无限增长，最终 OOM——这比上面两个更惨烈。

限流就是在这些悲剧发生之前，给系统加一道"自我保护"的防线。

5.2 四种算法怎么选？​

本文的示例使用了固定时间窗口，简单直接，适合入门理解。

5.3 TouchSocket 插件体系的优势​

插件体系最大的好处是关注点分离。业务逻辑和限流逻辑完全解耦：

• 想换限流算法？改插件内部，不动业务代码
• 想临时关闭限流？注释掉 a.Add<LimitNumberOfConnectionsPlugin>() 这一行
• 想针对不同端口用不同限流策略？注册多个不同配置的插件实例

这种灵活性，如果用传统的"在业务代码里硬编码限流逻辑"的方式，根本实现不了。

六、总结​

本文用一种"能吃饭就不饿肚子"的思路，介绍了如何用 TouchSocket + System.Threading.RateLimiting 给 TCP 服务器加上限流保护：

1. 连接限流：在 ITcpConnectingPlugin 中，通过 FixedWindowRateLimiter 实现全局连接数控制——超员直接拒绝，没有商量余地。
2. 流量限流：在 ITcpReceivedPlugin 中，通过 DependencyProperty 给每个客户端绑定独立的限流器——流量超标不断开，优雅地慢下来。

两个插件，两段代码，轻松搞定"贪婪"客户端的问题。

当然别忘了，PermitLimit、Window 等参数需要根据实际业务场景调整。演示里设置得很小，是为了方便看到效果，实际生产环境中需要结合压测数据来设定合理的阈值。

代码写好了，服务器就不再是那个来者不拒的"烂好人"，而是一个懂得保护自己的"成熟的服务器"。

七、参考资料​

1. TouchSocket 官网
2. System.Threading.RateLimiting 库
3. Announcing Rate Limiting for .NET
4. 以前的限流博客文章

八、本文示例 Demo​