• 在任何 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 满，无法再发送数据。

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

  1. Accept 到新的 Socket，构建新的 Connection 需要分配各种资源，分配资源慢；
  2. Accept 到新的 Socket，没有及时触发下一次 Accept；
  3. Read 到新的 Buffer，判定 Payload 消息长度，判定过程长；
  4. Read 到新的 Buffer，发现 Payload 还没有收全，继续 Read，则 "可能" 会导致一次 Buffer Copy；
  5. Payload 接收完毕，进行 De-Serialization 转成可识别的 Protocol Message，反序列化慢；
  6. 由 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 的实现。

1 单独测试不停的有新的client连接server时：

测试方法：写个client创建软件，调用timer，每隔几秒就创建一个新的client到server之间的连接，测试时打开多个client创建软件

异步编程模式leafsoft软件所写的服务器在上百万个可时连接状态，单单只有连接没有其他数据交互时，200万、300万都没问题的，300万以上时UI界面刷新就有些吃力，而连接数目到一定程度时，此时server阻塞，无法分配新的资源给接下来的client,相当于server停止监听，此时client软件和server软件都会有异常发生，异常位置在client连接server的方法内