高性能Socket模型

1. 常见的Socket模型

服务器端编程经常需要构造高性能的IO模型，常见的IO模型有四种：
（1）同步阻塞IO（Blocking IO）：即传统的IO模型。
（2）同步非阻塞IO（Non-blocking IO）：默认创建的socket都是阻塞的，非阻塞IO要求socket被设置为NONBLOCK。注意这里所说的NIO并非Java的NIO（New IO）库。
（3）IO多路复用（IO Multiplexing）：即经典的Reactor设计模式，有时也称为异步阻塞IO，Java中的Selector和Linux中的epoll都是这种模型。
（4）异步IO（Asynchronous IO）：即经典的Proactor设计模式，也称为异步非阻塞IO。

针对同步和异步（IO交互）、阻塞和非阻塞（IO操作）的概念下面进行区分和解释：
同步和异步的概念描述的是用户线程与内核的交互方式：同步是指用户线程发起IO请求后需要等待或者轮询内核IO操作完成后才能继续执行；而异步是指用户线程发起IO请求后仍继续执行，当内核IO操作完成后会通知用户线程，或者调用用户线程注册的回调函数。
阻塞和非阻塞的概念描述的是用户线程调用内核IO操作的方式：阻塞是指IO操作需要彻底完成后才返回到用户空间；而非阻塞是指IO操作被调用后立即返回给用户一个状态值，无需等到IO操作彻底完成。

1.1 同步阻塞IO

同步阻塞IO模型是最简单的IO模型，用户线程在内核进行IO操作时被阻塞。

如上图，用户线程通过系统调用read发起IO读操作，由用户空间转到内核空间。内核等到数据包到达后，然后将接收的数据拷贝到用户空间，完成read操作。
用户线程使用同步阻塞IO模型的伪代码描述为：

{
	read(socket, buffer);
	process(buffer);
}

即用户需要等待read将socket中的数据读取到buffer后，才继续处理接收的数据。整个IO请求的过程中，用户线程是被阻塞的，这导致用户在发起IO请求时，不能做任何事情，对CPU的资源利用率不够。

1.2 同步非阻塞IO

同步非阻塞IO是在同步阻塞IO的基础上，将socket设置为NONBLOCK。这样做用户线程可以在发起IO请求后可以立即返回。

如上图所示，由于socket是非阻塞的方式，因此用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据到达后，才真正读取到数据，继续执行。

用户线程使用同步非阻塞IO模型的伪代码描述为：

{
	while(read(socket, buffer) != SUCCESS);
	process(buffer);
}

即用户需要不断地调用read，尝试读取socket中的数据，直到读取成功后，才继续处理接收的数据。整个IO请求的过程中，虽然用户线程每次发起IO请求后可以立即返回，但是为了等到数据，仍需要不断地轮询、重复请求，消耗了大量的CPU的资源。一般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。

1.3 IO多路复用

IO多路复用模型是建立在内核提供的多路分离函数select基础之上的，使用select函数可以避免同步非阻塞IO模型中轮询等待的问题。

如上图所示，用户首先将需要进行IO操作的socket添加到select中，然后阻塞等待select系统调用返回。当数据到达时，socket被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行。
从流程上来看，使用select函数进行IO请求和同步阻塞模型没有太大的区别，甚至还多了添加监视socket，以及调用select函数的额外操作，效率更差。但是， 使用select以后最大的优势是用户可以在一个线程内同时处理多个socket的IO请求 。用户可以注册多个socket，然后不断地调用select读取被激活的socket，即可达到在 同一个线程内同时处理多个IO请求的目的 。而在同步阻塞模型中，必须通过多线程的方式才能达到这个目的。
用户线程使用select函数的伪代码描述为：

{
	select(socket);
	while(1)
	{
		sockets = select();
		for(socket in sockets)
		{
			if(can_read(socket))
			{
				read(socket, buffer);
				process(buffer);
			}
		}
	}
}

其中while循环前将socket添加到select监视中，然后在while内一直调用select获取被激活的socket，一旦socket可读，便调用read函数将socket中的数据读取出来。
然而，使用select函数的优点并不仅限于此。虽然上述方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只注册自己感兴趣的socket或者IO请求，然后去做自己的事情，等到数据到来时再进行处理，则可以提高CPU的利用率。
IO多路复用模型使用了Reactor设计模式实现了这一机制。

如上图所示，EventHandler抽象类表示IO事件处理器，它拥有IO文件句柄Handle（通过get_handle获取），以及对Handle的操作handle_event（读/写等）。继承于EventHandler的子类可以对事件处理器的行为进行定制。Reactor类用于管理EventHandler（注册、删除等），并使用handle_events实现事件循环，不断调用同步事件多路分离器（一般是内核）的多路分离函数select，只要某个文件句柄被激活（可读/写等），select就返回（阻塞），handle_events就会调用与文件句柄关联的事件处理器的handle_event进行相关操作。

如上图所示，通过Reactor的方式，可以将用户线程轮询IO操作状态的工作统一交给handle_events事件循环进行处理。用户线程注册事件处理器之后可以继续执行做其他的工作（异步），而Reactor线程负责调用内核的select函数检查socket状态。当有socket被激活时，则通知相应的用户线程（或执行用户线程的回调函数），执行handle_event进行数据读取、处理的工作。由于select函数是阻塞的，因此多路IO复用模型也被称为异步阻塞IO模型。注意，这里的所说的阻塞是指select函数执行时线程被阻塞，而不是指socket。一般在使用IO多路复用模型时，socket都是设置为NONBLOCK的，不过这并不会产生影响，因为用户发起IO请求时，数据已经到达了，用户线程一定不会被阻塞。
用户线程使用IO多路复用模型的伪代码描述为：

void UserEventHandler::handle_event()
{
	if(can_read(socket)) 
	{
		read(socket, buffer);
		process(buffer);
	}
}

{
	Reactor.register(new UserEventHandler(socket));
}

用户需要重写EventHandler的handle_event函数进行读取数据、处理数据的工作，用户线程只需要将自己的EventHandler注册到Reactor即可。Reactor中handle_events事件循环的伪代码大致如下。

Reactor::handle_events()
{
	while(1) 
	{
		sockets = select();
		for(socket in sockets)
		{
			get_event_handler(socket).handle_event();
		}
	}
}

事件循环不断地调用select获取被激活的socket，然后根据获取socket对应的EventHandler，执行器handle_event函数即可。
IO多路复用是最常使用的IO模型，但是其异步程度还不够“彻底”，因为它使用了会阻塞线程的select系统调用。因此IO多路复用只能称为异步阻塞IO，而非真正的异步IO。

1.4 异步IO

“真正”的异步IO需要操作系统更强的支持。在IO多路复用模型中，事件循环将文件句柄的状态事件通知给用户线程，由用户线程自行读取数据、处理数据。而在异步IO模型中，当用户线程收到通知时，数据已经被内核读取完毕，并放在了用户线程指定的缓冲区内，内核在IO完成后通知用户线程直接使用即可。
异步IO模型使用了Proactor设计模式实现了这一机制。

如图所示，Proactor模式和Reactor模式在结构上比较相似，不过在用户（Client）使用方式上差别较大。Reactor模式中，用户线程通过向Reactor对象注册感兴趣的事件监听，然后事件触发时调用事件处理函数。而Proactor模式中，用户线程将AsynchronousOperation（读/写等）、Proactor以及操作完成时的CompletionHandler注册到AsynchronousOperationProcessor。AsynchronousOperationProcessor使用Facade模式提供了一组异步操作API（读/写等）供用户使用，当用户线程调用异步API后，便继续执行自己的任务。AsynchronousOperationProcessor 会开启独立的内核线程执行异步操作，实现真正的异步。当异步IO操作完成时，AsynchronousOperationProcessor将用户线程与AsynchronousOperation一起注册的Proactor和CompletionHandler取出，然后将CompletionHandler与IO操作的结果数据一起转发给Proactor，Proactor负责回调每一个异步操作的事件完成处理函数handle_event。虽然Proactor模式中每个异步操作都可以绑定一个Proactor对象，但是一般在操作系统中，Proactor被实现为Singleton模式，以便于集中化分发操作完成事件。

如上图所示，异步IO模型中，用户线程直接使用内核提供的异步IO API发起read请求，且发起后立即返回，继续执行用户线程代码。不过此时用户线程已经将调用的AsynchronousOperation和CompletionHandler注册到内核，然后操作系统开启独立的内核线程去处理IO操作。当read请求的数据到达时，由内核负责读取socket中的数据，并写入用户指定的缓冲区中。最后内核将read的数据和用户线程注册的CompletionHandler分发给内部Proactor，Proactor将IO完成的信息通知给用户线程（一般通过调用用户线程注册的完成事件处理函数），完成异步IO。
用户线程使用异步IO模型的伪代码描述为：

void UserCompletionHandler::handle_event(buffer)
{
	process(buffer);
}

{
	aio_read(socket, new UserCompletionHandler);
}

用户需要重写CompletionHandler的handle_event函数进行处理数据的工作，参数buffer表示Proactor已经准备好的数据，用户线程直接调用内核提供的异步IO API，并将重写的CompletionHandler注册即可。
相比于IO多路复用模型，异步IO并不十分常用，不少高性能并发服务程序使用IO多路复用模型+多线程任务处理的架构基本可以满足需求。况且目前操作系统对异步IO的支持并非特别完善，更多的是采用IO多路复用模型模拟异步IO的方式（IO事件触发时不直接通知用户线程，而是将数据读写完毕后放到用户指定的缓冲区中）。

2. 基于Windows平台的IOCP模型

Windows平台上性能比较好的一种I/O模型莫过IOCP了。IOCP模型在针对成千上万个套接字的并发处理中，采用了 线程池 + 队列 + 重叠结构 的内核机制完成任务。需要说明的是IOCP其实不仅可以接受套接字对象句柄，还可以接受文件对象句柄等。

2.1 传统IO流程及改进

首先对于传统服务器的网络IO流程如下：
接到一个客户端连接->创建一个线程负责这个连接的IO操作->持续对新线程进行数据处理->全部数据处理完毕->终止线程。
但是这样的设计代价是：
（1）每个连接创建一个线程，将导致过多的线程。
（2）维护线程所消耗的堆栈内存过大。
（3）操作系统创建和销毁线程过大。
（4）线程之间切换的上下文代价过大。
此时为了减小线程创建和线程切换上带来的开销，可以考虑使用线程池解决其中3和4的问题。这种传统的服务器网络结构称之为会话模型。之后为了防止对大量线程的维护的开销，创建了I/O模型，它被希望要求可以:
（1）允许一个线程在不同时刻给多个客户端进行服务。
（2）允许一个客户端在不同时间被多个线程服务。
这样做可以使得线程大幅度减少，但是就要求以下两点：
（1）客户端状态的分离，之前会话模式我们可以通过线程状态得知客户端状态，但现在客户端状态要通过其他方式获取。
（2）I/O请求的分离。一个线程不再服务于一个客户端会话，则要求客户端对这个线程提交I/O处理请求。
那么就产生了这样一个模式:
（1）会话状态管理模块。它负责接收到一个客户端连接，就创建一个会话状态。
（2）当会话状态发生改变，例如断掉连接，接收到网络消息，就发送一个I/O请求给I/O工作模块进行处理。
（3）I/O工作模块接收到一个I/O请求后，从线程池里唤醒一个工作线程，让该工作线程处理这个I/O请求，处理完毕后，该工作线程继续挂起。
上面的做法，则将网络连接和I/O工作线程分离为两个部分，相互通讯仅依靠I/O请求。

线程池、工作线程数的建议：
1：在进行I/O请求处理的工作线程是被唤醒的工作线程，一个CPU对应一个的话，可以最大化利用CPU。所以活跃线程的个数建议等于硬件CPU个数。
2：工作线程我们开始创建了线程池，免除创建和销毁线程的代价。因为线程是对I/O进行操作的，且一一对应，那么当I/O全部并行时，工作线程必须满足I/O并行操作需求，所以 线程池内最大工作线程个数建议大于或者等于I/O并行个数。
3：但是我们可知CPU个数又限制了活跃的线程个数，那么线程池过大意义很低，所以按常规建议线程池大小等于CPU个数*2左右为佳。例如，8核服务器建议创建16个工作线程的线程池。

2.2 Windows平台IOCP

对于IOCP，它是一种WIN32的网络I/O模型，既包括了网络连接部分，也负责了部分的I/O操作功能，用于方便我们控制有并发性的网络I/O操作。它有如下特点：
（1）它是一个WIN32内核对象，所以无法运行于Linux.
（2）它自己负责维护了工作线程池，同时也负责了I/O通道的内存池。
（3）它自己实现了线程的管理以及I/O请求通知，最小化的做到了线程的上下文切换。
（4）它自己实现了线程的优化调度，提高了CPU和内存缓冲的使用率。

IOCP的基本操作使用流程图：

使用IOCP的基本步骤大体分为如下步骤：
（1）创建IOCP对象，由它负责管理多个Socket和I/O请求。CreateIoCompletionPort需要将IOCP对象和IOCP句柄绑定。
（2）创建一个工作线程池，以便Socket发送I/O请求给IOCP对象后，由这些工作线程进行I/O操作。注意，创建这些线程的时候，将这些线程绑定到IOCP上。
（3）创建一个监听的socket。
（4）轮询，当接收到了新的连接后，将socket和完成端口进行关联并且投递给IOCP一个I/O请求。注意：将Socket和IOCP进行关联的函数和创建IOCP的函数一样，都是CreateIoCompletionPort，不过注意传参必然是不同的。
（5）因为是异步的，应用进程可以去做其他，等待IOCP将I/O操作完成会回馈一个消息，应用进程再进行处理。
其中需要知道的是：I/O请求被放在一个I/O请求队列里面，对，是队列，LIFO机制。当一个设备处理完I/O请求后，将会将这个完成后的I/O请求丢回IOCP的I/O完成队列。
应用程序则需要在GetQueuedCompletionStatus去询问IOCP，该I/O请求是否完成。
其中有一些特殊的事情要说明一下，有时有需要人工的去投递一些I/O请求，则需要使用PostQueuedCompletionStatus函数向IOCP投递一个I/O请求到它的请求队列中。

上面讲了为避免线程上下文切换，它采用了线程池。除此之外，在基于事件模型或重叠模型中不得不遇到WSAWaitForMultipleEvent的WSA_MAXIMUM_WAIT_EVENTS的限制，由此必须由自己来设计线程池来避开这种限制。而IOCP则由系统来实现线程池，对用户来说透明，由此减少了设计线程池带来的复杂性并提高了安全性。看看GetQueuedCompletionStatus这个函数，它包含了封包队列排队机制以及基于事件的重叠结构OVERLAPPED的通知，用户无需再去设计队列和OVERLAPPED结构中显示地创建事件。

IOCP一般被用于Windows平台上大规模服务器程序的设计。所以设计起来有很多地方需要注意。因为IOCP设计中需要用到很多异步操作，所以对到来的数据包的排序是需要额外处理的，简单和常用的方法是为每个封包添加一个序列号。接受方每接受一个封包就需要判断其是否为当前需要读取的下一个序列号封包，如果不是就要将之插入封包队列，如果是则返回给用户。当关闭IOCP时，我们要避免重叠操作正在进行的时候却要释放它的OVERLAPPED结构，阻止其发生的最好方法是在每个套接字句柄上调用closesocket，如此所有的未决重叠IO操作都会完成。一旦所有的套接字句柄关闭，就该终止IOCP上处理IO的工作线程了。这可以通过PostQueuedCompletionStatus来操作。在接受连接方面，投递多少连接是个需要认真考虑的问题，因为每创建一个套接字都会占用系统不小的开销，在Win2000及以后版本中可以通过在创建监听套接字时采用WSAEventSelect，注册FD_ACCEPT通知消息的方式，在投递的AcceptEx用完时但仍有客户连接时，事件对象将会受信，通知继续投递。另外，可以对每个客户套接字采用定时轮询的方法查询其连接时间长短，以此可以判断哪些客户连接有恶意的迹象（只连接服务器不发送任何数据）。

3. 参考资料

1. 高性能IO模型浅析

2. IOCP模型与网络编程

3. IOCP模型与EPOLL模型的比较