winsock的阻塞和非阻塞通信模型

摘要：在应用程序开发中，经常涉及各式各样的机器的交互通信问题。在Windows操作系统下，可以使用MFC中的CSocket，也可以使用以Windows Api为基础的Winsock等等。本文主要描述了Winsock的两种实现方式，即阻塞方式和非阻塞方式。并对应这两种方式，描述了Select模式和IOCP模式。

关键字：Winsock Blocking   NonBlocking   Select模式   完成端口（IOCP）模式

一、Winsock简介

对于众多底层网络协议，Winsock是访问它们的首选接口。而且在每个Win32平台上，Winsock都以不同的形式存在着。Winsock是网络编程接口，而不是协议。在Win32平台上，Winsock接口最终成为一个真正的“与协议无关”接口，尤其是在Winsock 2发布之后。

Win32平台提供的最有用的特征之一是能够同步支持多种不同的网络协议。Windows重定向器保证将网络请求路由到恰当的协议和子系统；但是，有了Winsock，就可以编写可直接使用任何一种协议的网络应用程序了。

在广泛使用的windows平台下，winsock2被简单包装为一组庞大的Api库，通过WSA Start up加载的关于Winsock版本的信息，初始了winsock相关的dll和lib，在成功调用了WSA Startup之后，即可设计自主的与通信有关的行为，当确认了执行完操作后，调用相应的WSA Cleanup，释放对winsock DLL的引用次数。几乎所有在windows平台下可使用的通信框架都是由Winsock扩展而来的。

这里，之所以要再提windows下的winsock Api编程，并不多余，虽然也可以使用CSocket或ACE（ADAPTIVE Communication Environment）框架，但直接对较底层的本地操作系统API，会使我们更深的理解隐藏在框架下的实现，有时也可以解决一些实用问题。

本文涉及的主要是Winsock中面向连接（TCP）部分。

二、阻塞和非阻塞

阻塞socket，又被称为锁定状态的socket。非阻塞socket，又被称为非锁定状态的socket。当调用一个Winsock Api时， Api的调用会耗费一定的CPU时间。当一个操作完成之后才返回到用户态，称其为阻塞，反之，则为非阻塞。当调用Api产生一个基于流协议（TCP）的socket时，系统开辟了接收和发送两个缓冲区，所以操作实际都是用户缓冲区和系统缓冲区的数据交互，并不是实际操作的完成，阻塞也是如此。如果综合被TCP协议默认使用的nagle算法，在数据包（TCP Payload）比较短时，协议可能推迟其发送，就不难想象了。

很多做过Winsock通信的人，都知道非阻塞的socket，也就是异步socket的效率远远高于阻塞socket。可是除了直观的认识外，底层的原理又是什么呢？首先，阻塞的socket的最合理方式是：先知道socket句柄的可读写性，再发起动作。因为如果不做检测而直接发起操作，那么TCP的默认超时将让你后悔不该这么鲁莽。于是,在一次动作中，完成了两次从用户态到系统态的状态转换，异步的socket实际只告诉系统，所期望的操作，而不完成这种操作，系统会对每次提交的操作进行排队。当指定的操作完成时，系统态跳转至用户态。这样，只用了一次状态转换。其次，由于阻塞的特性，它比非阻塞占用了更多的CPU时间。

当然，程序总是要适合需求，有时阻塞的socket亦可满足要求。

三、Select模式

select模式是Winsock中最常见的I/O模型。之所以称其为“select模式”，是由于它的中心思想是利用select函数，实现对I/O的管理。利用select函数，判断套接字上是否存在数据，或者能否向一个套接字写入数据。设计这个函数，唯一的目的是防止应用程序在套接字处于锁定模式中时，在一次I/O绑定调用（如send或recv）过程中，被迫进入“锁定”状态。

对select不再赘述，msdn已经给出了详细的解释。这里要讨论下面两个问题。

1.Select的fd_set数组可承受的最大数

细心的coder可能都注意到了msdn中对FD_SETSIZE（winsock2.h）宏的说明，可以在包含winsock2.h之前重新定义这个宏，它将允许在一个select操作中处理更多的socket句柄（>64）。但是为何定义就是64呢？这不仅是unix的遗留，更是select处理能力的一种衡量标准，过多的socket句柄检测毕竟会影响到对已存在操作的socket的响应。一个最合理的建议是，当程序运行在多CPU的机器上时，可以从逻辑上将socket句柄分为数个组，每组都小于64，用多个线程对每组socket进行select，这样可以增加程序的响应能力。如果是单CPU，则可将FD_SETSIZE增大至256，适当放大timeout。这时每个socket上吞吐量如果还很大，CPU利用率也据高不下，那就要考虑换种模型。

2.Select在多端口侦听中的应用

众所周知，在winsock api中，accept()是一个典型的阻塞操作，通常是建立一个侦听线程来单独执行accept()。如果程序要完成多于一个端口的侦听，自然，建立数个线程也是一个办法，但这里最好使用select。Msdn中解释了这种应用：readfds可以检测出当前listening的socket句柄上是否有有效的connect发生。把本地listening的socket句柄置入readfds，当某个socket有效时，对它调用accept()，此时，发现accept()会立刻成功返回，一个线程就完成了多端口的侦听。

四、非阻塞与完成端口模式

IO完成端口：一种windows独有的异步IO机制。它不专属socketIO，更多的应用是file IO和串口IO。这种模式的优点是：在句柄较多时，较低的CPU利用率和较高的吞吐量。但设计上有较高的复杂性，只有在应用程序需要同时管理数百乃至上千个套接字的时候，并希望随着系统内安装的CPU数量的增多，应用程序的性能也可以线性提升，才应考虑采用“完成端口”模式。

在windows下，IOCP已经可以说是顶级的通信方式了，在网上能搜到的资料都表明：windows的高效通信 ＝IOCP + 多线程。IOCP server的工作过程如下，代码在windows sdk中。

                主线程 

                    ¦  

  CreateIoCompletionPort                                                                                                                                      ¦                                                                                                     

CreateThread               —————————      完成端口线程  

                                                                                              ¦  

  ¦----   While(TRUE)                                             While(TRUE)----------   ¦  

                   ¦                                                                         ¦                            

             Accept                                             ¦------GetQueuedCompletionStatu s()      ¦  

¦                  ¦                                                 ¦                        ¦                      

¦   CreateIoCompletionPort         ¦                    WsaRev/WsaSend-------   ¦  

¦                  ¦                                                   ¦                        ¦  

¦----WsaRev/WsaSend                                   -------   Windows系统  

                      ¦                                                   ¦     

Windows系统      ---------  

应注意以下两个事项：

（1）当调用WsaRecv和WsaSend，会提供一个WSADATA的数据结构，其中的指针指向的是用户缓冲区，由于以上两个函数在大多数情况下并不是立即就可以完成的，所以，在GetQueuedCompletionStatu s没有收到完成事件前，这个缓冲区不可修改或释放。

（2）经常会在技术论坛中见到有人提问关于IOCP的异步方式会导致乱包的问题。首先看一下IOCP的原理，其实它就相当一个由windows底层管理的有事务功能的消息队列。看过所谓“windows泄漏代码”的人都会注意到windows并不保证这个队列是有序的，特别是当将完成事件通知用户的多个GetQueuedCompletionStatu s线程时，由于调度算法，并不能保证先递交的操作会先返回结果。这样,如果在当前队列中对一个socket句柄有两个recv的待完成操作，此时，socket底层缓冲区内数据为“abcd”，第一个操作完成了“ab”，第二个操作应该完成 “cd”，但第二个操作先找到了空闲线程返回了，于是，数据就乱了。解决的方法很简单，只要从逻辑上保证一个socket句柄接收和发送操作都是同步完成的（即完成一个，才发起下一个），就可以避免乱包。

下面提出两点技巧：

即使在网上能找到关于IOCP的代码，几乎都是照搬了sdk中的实例，在自己编写代码时，还是会碰到更多的问题。

(1)sdk代码中存在一个没有说明的问题。其中模拟的是一个基于一定固有消息的服务器，每收到一包消息，处理后发出一包消息，WsaRecv是常发出的，如果应用突然要发送一包消息呢？由于一个socket只存在一个异步操作使用的WSAOVERLAPPED结构，所以最常见的办法是使用api             PostQueuedCompletionStat us()将一个已投出的WsaRecv“召回”，再投出WsaSend，这样浪费了一次操作，在连接数较大时，这种代价是不可忽略的。更好的办法是使用两个WSAOVERLAPPED结构，我使用的数据结构如下：

     typedef enum _IO_OPERATION

     {

       ClientIoAccept,

       ClientIoRead,

       ClientIoWrite

     } IO_OPERATION, *PIO_OPERATION;

 

     typedef struct _PER_IO_CONTEXT

     {

       WSAOVERLAPPED                             Overlapped;

       char                                               *Buffer;

 

       WSABUF                                           wsabuf;

       IO_OPERATION                               IOOperation;

       SOCKET                                           SocketAccept;

       int                                                 State;

 

       int                                                 nTotalBytes;

       int                                                 nSentBytes;

 

       struct _PER_IO_CONTEXT           *pIOContextForward;

     } PER_IO_CONTEXT, *PPER_IO_CONTEXT;

 

     typedef struct _PER_SOCKET_CONTEXT

     {

     int                                             state;

     SOCKET                                       sock;

     struct   sockaddr_in                   remote;

 

     PPER_IO_CONTEXT                         pRIOContext;

     PPER_IO_CONTEXT                         pSIOContext;

 

     struct _PER_SOCKET_CONTEXT   *pCtxtBack;

     struct _PER_SOCKET_CONTEXT   *pCtxtForward;

     } PER_SOCKET_CONTEXT, *PPER_SOCKET_CONTEXT;

 

 

PER_IO_CONTEXT中包含了一个WSAOVERLAPPED结构，每个socket上下文PER_SOCKET_CONTEXT中包含了两个PER_IO_CONTEXT的指针，这样WsaRecv使用pRIOContext中的WSAOVERLAPPED，而WsaSend使用pSIOContext中的WSAOVERLAPPED，互不干扰。

(2)上述问题解决了，但又带来了一个新的问题。在socket注册入IOCP时，completionkey是PER_SOCKET_CONTEXT的地址。此时，如果在这个socket上有完成事件，completionkey会被返回，但如何知道是接收还是发送完成了呢？你一定会想到WSAOVERLAPPED的地址也不被返回了，和pRIOContext以及pSIOContext中的WSAOVERLAPPED地址比一下就可以了，然而，地址比较是C语言的大忌。其实，上面的数据结构也是在sdk代码上改来的，注意在WsaRecv以及WsaSend中用的Overlapped指针，正是PER_IO_CONTEXT的地址，强制类型转换即可，其中IO_OPERATION正是对操作类型的描述。

五、几点补充

IOCP到底有多高效呢？<<Network   Programming   for   Microsoft   Windows   2nd>>有个技术统计,采用IOCP时:  

Attempted/Connected:   50,000/49,997  

Memory   Used   (KB):   242,272  

Non-Paged   Pool:   148,192  

CPU   Usage:   55–65%  

Threads:   2  

Throughput  (Send/Receive  Bytes  Per  Second):4,326,946/4,326,496  (The  server  was a  Pentium  4  1.7  GHz   Xeon   with  768  MB   memory)

  因此，接受几千个连接是可能的,但要稳定处理就有赖于服务器性能和程序的健壮性。

对自己程序的测试还要注意一些windows特性：

（1）连接测试时，win2k缺省的出站连接的临时端口为1024－5000，要想使用更多的出站端口需要修改注册表，修改方式：  

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\项下建一个MaxUserPort（双字节值），例如：取值为10000时，大约有9000个端口可用。

（2）在intel x86上，非页面内存池仅占物理内存的1/8，windows将socket正是分配在这一区域上，根据“Busy-ness”原则，为每个socket分配的内存将随着socket的使用方式发生变化，但最少在2k以上，overlap也正是在申请非页面内存池，在NT下分块的大小是4k，接收发送共需要8k，这样一个socket大约需要10k的空间。服务器如果有1G内存，那么能支撑的socket数也在12,000左右。所以，所谓接受几万个连接完全不可能。真正这样的需求都是通过集群实现的。

（3）欲知socket的状态，一般要使用iphelper.h中GetTcpTable()实现，当然枚举属性为0x1a的handle也可以实现。

参考文献

[1]<<Network Programming for Microsoft Windows 2nd>>                 Microsoft press

[2]Platform SDK Documentation                                 Microsoft■