首页 ›存档› 技术 › 查看内容

C#高性能TCP服务的多种实现方式

2018-3-30 13:00 |来自: 互联网 893 0

摘要: (点击上方公众号，可快速关注) 来源：Dennis Gao 链接：http://www.cnblogs.com/gaochundong/p/csharp_tcp_service_models.html 本篇文章的主旨是使用.NET/C# 实现 TCP 高性能服务的不同方式，包括但不限于如下 ...

(点击上方公众号，可快速关注)

来源：Dennis Gao

链接：http://www.cnblogs.com/gaochundong/p/csharp_tcp_service_models.html

本篇文章的主旨是使用.NET/C# 实现 TCP 高性能服务的不同方式，包括但不限于如下内容：

APM 方式，即 Asynchronous Programming Model
TAP 方式，即 Task-based Asynchronous Pattern
SAEA 方式，即 SocketAsyncEventArgs
RIO 方式，即 Registered I/O

在 .NET/C# 中对于 Socket 的支持均是基于Windows I/O Completion Ports完成端**术的封装，通过不同的 Non-Blocking 封装结构来满足不同的编程需求。以上方式均已在Cowboy.Sockets中有完整实现，并且 APM 和 TAP 方式已经在实际项目中应用。Cowboy.Sockets还在不断的进化和完善中，如有任何问题请及时指正。

虽然有这么多种实现方式，但抽象的看，它们是一样一样的，用两个 Loop 即可描述：Accept Loop和Read Loop，如下图所示。（这里提及的 “Loop” 指的是一种循环方式，而非特指while/for 等关键字。）

在任何 TCP Server 的实现中，一定存在一个 Accept Socket Loop，用于接收 Client 端的 Connect 请求以建立 TCP Connection。
在任何 TCP Server 的实现中，一定存在一个 Read Socket Loop，用于接收 Client 端 Write 过来的数据。

如果 Accept 循环阻塞，则会导致无法快速的建立连接，服务端 Pending Backlog 满，进而导致 Client 端收到 Connect Timeout 的异常。如果 Read 循环阻塞，则显然会导致无法及时收到 Client 端发过来的数据，进而导致 Client 端 Send Buffer 满，无法再发送数据。

从实现细节的角度看，能够导致服务阻塞的位置可能在：

Accept 到新的Socket，构建新的 Connection 需要分配各种资源，分配资源慢；
Accept 到新的Socket，没有及时触发下一次 Accept；
Read 到新的Buffer，判定Payload消息长度，判定过程长；
Read 到新的Buffer，发现 Payload 还没有收全，继续 Read，则可能会导致一次 Buffer Copy；
Payload 接收完毕，进行 Serialization 转成可识别的 Protocol Message，序列化慢；
由 Business Module 来处理相应的 Protocol Message，处理过程慢；

1-2 涉及到 Accept 过程和 Connection 的建立过程，3-4 涉及到 ReceiveBuffer 的处理过程，5-6 涉及到应用逻辑侧的实现。

Java 中著名的 Netty 网络库从 4.0 版本开始对于 Buffer 部分做了全新的尝试，采用了名叫ByteBuf的设计，实现 Buffer Zero Copy 以减少高并发条件下Buffer 拷贝带来的性能损失和 GC 压力。DotNetty，Orleans，Helios等项目正在尝试在 C# 中进行类似的 ByteBuf 的实现。