服务器网络编程模型

1、循环服务器模型：在同一个时刻只可以响应一个客户端的请求

1）循环服务器:UDP服务器

UDP循环服务器的实现:UDP服务器每次从套接字上读取一个客户端的请求,处理, 然后将结果返回给客户机. 因为UDP是非面向连接的,没有一个客户端可以老是占住服务端. 只要处理过程不是死循环, 服务器对于每一个客户机的请求总是能够满足.算法示例如下： 

socket(...); 
bind(...); 
while(1) 
{ 
　　recvfrom(...); 
　　process(...); 
　　sendto(...); 
}

2）循环服务器:TCP服务器

TCP循环服务器的实现:TCP服务器接受一个客户端的连接,然后处理,完成了这个客户的所有请求后,断开连接. 算法示例如下：

socket(...); 
bind(...); 
listen(...); 
while(1) 
{ 
    accept(...); 
    while(1) 
    { 
        read(...); 
        process(...); 
        write(...); 
　　} 
　　close(...); 
}             

TCP循环服务器一次只能处理一个客户端的请求.只有在这个客户的所有请求都满足后, 服务器才可以继续后面的请求.这样如果有一个客户端占住服务器不放时,其它的客户机都不能工作了.因此,TCP服务器一般很少用循环服务器模型的。

2、并发服务器：同一个时刻可以响应多个客户端的请求　

1）并发服务器:子进程模式

并发服务器的思想是每一个客户机的请求并不由服务器直接处理,而是服务器创建一个子进程来处理.算法如下：

socket(...); 
bind(...); 
listen(...); 
while(1) 
{ 
    accept(...); 
    if(fork(..)==0) //the child process.
    { 
        while(1) 
        { 
            read(...); 
            process(...); 
            write(...); 
        } 
        close(...); 
        exit(...); 
    } 
    close(...); 
}

子进程的TCP并发服务器可以解决TCP循环服务器客户机独占服务器的情况. 不过也同时带来了一个不小的问题.为了响应客户机的请求,服务器要创建子进程来处理. 而创建子进程是一种非常消耗资源的操作.  

2）并发服务器:多路复用I/O

使用以上子进程模式，进程有可能在读写出阻塞,直到一定的条件满足. 比如我们从一个套接字读数据时,可能缓冲区里面没有数据可读(通信的对方还没有 发送数据过来),这个时候我们的读调用就会等待(阻塞)直到有数据可读.如果我们不希望阻塞且解决创建子进程带来的系统资源消耗,人们又想出了多路复用I/O模型.

如下使用select后的服务器程序算法：

初始化(socket,bind,listen); 

while(1) 
{ 
    设置监听读写文件描述符(FD_*); 

    调用select; 

    如果是倾听套接字就绪,说明一个新的连接请求建立 
    { 
        建立连接(accept); 
        加入到监听文件描述符中去; 
    } 
    否则说明是一个已经连接过的描述符 
    { 
        进行操作(read或者write); 
    } 

} 

相比于select，linux 2.6后使用的epoll最大的好处在于它不会随着监听fd数目的增长而降低效率。因为在内核中的select实现中，它是采用轮询来处理的，轮询的fd数目越多，自然耗时越多。同时由于服务器依次处理客户的请求,所以可能会导致有的客户会等待很久。并且，在linux/posix_types.h头文件有这样的声明：
#define __FD_SETSIZE    1024
表示select最多同时监听1024个fd，当然，可以通过修改头文件再重编译内核来扩大这个数目，但这似乎并不治本。

epoll的接口非常简单，一共就三个函数：

1. int epoll_create(int size);
创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大。这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值。需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。
2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。第一个参数是epoll_create()的返回值，第二个参数表示动作，用三个宏来表示：
EPOLL_CTL_ADD：注册新的fd到epfd中；
EPOLL_CTL_MOD：修改已经注册的fd的监听事件；
EPOLL_CTL_DEL：从epfd中删除一个fd；
第三个参数是需要监听的fd，第四个参数是告诉内核需要监听什么事，struct epoll_event结构如下：
struct epoll_event {
  __uint32_t events;  /* Epoll events */
  epoll_data_t data;  /* User data variable */
};

events可以是以下几个宏的集合：
EPOLLIN ：表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；
EPOLLOUT：表示对应的文件描述符可以写；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP：表示对应的文件描述符被挂断；
EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
等待事件的产生，类似于select()调用。参数events用来从内核得到事件的集合，maxevents告之内核这个events有多大，这个maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1将不确定，也有说法说是永久阻塞）。该函数返回需要处理的事件数目，如返回0表示已超时。

epoll支持水平触发(LT：level triggered)和边缘触发(ET：edge-triggered)，理论上来说边缘触发性能更高，但是使用更加复杂，因为任何意外的丢失事件都会造成请求处理错误。Nginx就使用了epoll的边缘触发模型。它们的区别是只要句柄满足某种状态，水平触发就会发出通知；而只有当句柄状态改变时，边缘触发才会发出通知。例如一个socket经过长时间等待后接收到一段100k的数据，两种触发方式都会向程序发出就绪通知。假设程序从这个socket中读取了50k数据，并再次调用监听函数，水平触发依然会发出就绪通知，而边缘触发会因为socket“有数据可读”这个状态没有发生变化而不发出通知且陷入长时间的等待。因此在使用边缘触发时，要注意每次都要读到 socket返回 EWOULDBLOCK为止。

水平触发是epoll缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表．

边缘触发是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)。

当使用epoll的ET模型来工作时，当产生了一个EPOLLIN事件后，读数据的时候需要考虑的是当recv()返回的大小如果等于请求的大小，那么很有可能是缓冲区还有数据未读完，也意味着该次事件还没有处理完，所以还需要再次读取。如下代码示例：

while(rs)
{
  buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);
  if(buflen < 0)
  {
    // 由于是非阻塞的模式,所以当errno为EAGAIN时,表示当前缓冲区已无数据可读
    // 在这里就当作是该次事件已处理处.
    if(errno == EAGAIN)
     break;
    else
     return;
   }
   else if(buflen == 0)
   {
     // 这里表示对端的socket已正常关闭.
   }
   if(buflen == sizeof(buf)
     rs = 1;   // 需要再次读取
   else
     rs = 0;
}

还有，假如发送端流量大于接收端的流量(即epoll所在的程序读比转发的socket要快),由于是非阻塞的socket,那么send()函数虽然返回,但实际缓冲区的数据并未真正发给接收端,这样不断的读和发，当缓冲区满后会产生EAGAIN错误,同时,不理会这次请求发送的数据.所以,需要封装socket_send()的函数用来处理这种情况,该函数会尽量将数据写完再返回，返回-1表示出错。在socket_send()内部,当写缓冲已满(send()返回-1,且errno为EAGAIN),那么会等待后再重试.这种方式并不很完美,在理论上可能会长时间的阻塞在socket_send()内部,但暂没有更好的办法.

ssize_t socket_send(int sockfd, const char* buffer, size_t buflen)
{
  ssize_t tmp;
  size_t total = buflen;
  const char *p = buffer;

  while(1)
  {
    tmp = send(sockfd, p, total, 0);
    if(tmp < 0)
    {
      // 当send收到信号时,可以继续写,但这里返回-1.
      if(errno == EINTR)
        return -1;

      // 当socket是非阻塞时,如返回此错误,表示写缓冲队列已满,
      // 在这里做延时后再重试.
      if(errno == EAGAIN)
      {
        usleep(1000);
        continue;
      }

      return -1;
    }

    if((size_t)tmp == total)
      return buflen;

    total -= tmp;
    p += tmp;
  }

  return tmp;
}

3、高并发服务器：多线程+IO复用服务器（one event loop per thread）

1）两种I/O多路复用模式：Reactor和Proactor

一般地,I/O多路复用机制都依赖于一个事件多路分离器(Event Demultiplexer)。分离器对象可将来自事件源的I/O事件分离出来，并分发到对应的read/write事件处理器(Event Handler)。开发人员预先注册需要处理的事件及其事件处理器（或回调函数）；事件分离器负责将请求事件传递给事件处理器。两个与事件分离器有关的模式是Reactor和Proactor。Reactor模式采用同步IO，而Proactor采用异步IO。

在Reactor中，事件分离器负责等待文件描述符或socket为读写操作准备就绪，然后将就绪事件传递给对应的处理器，最后由事件处理器负责完成实际的读写工作。而在Proactor模式中，处理器或者兼任处理器的事件分离器，只负责发起异步读写操作。IO操作本身由操作系统来完成。传递给操作系统的参数需要包括用户定义的数据缓冲区地址和数据大小，操作系统才能从中得到写出操作所需数据，或写入从socket读到的数据。事件分离器捕获IO操作完成事件，然后将事件传递给对应处理器。比如，在windows上，处理器发起一个异步IO操作，再由事件分离器等待IOCompletion事件。典型的异步模式实现，都建立在操作系统支持异步API的基础之上，我们将这种实现称为“系统级”异步或“真”异步，因为应用程序完全依赖操作系统执行真正的IO工作。以读操作为例：

在Reactor中实现读：

- 注册读就绪事件和相应的事件处理器
- 事件分离器等待事件
- 事件到来，激活分离器，分离器调用事件对应的处理器。
- 事件处理器完成实际的读操作，处理读到的数据，注册新的事件，然后返还控制权。
在Proactor中实现读：

- 处理器发起异步读操作（注意：操作系统必须支持异步IO）。在这种情况下，处理器无视IO就绪事件，它关注的是完成事件。
- 事件分离器等待操作完成事件
- 在分离器等待过程中，操作系统利用并行的内核线程执行实际的读操作，并将结果数据存入用户自定义缓冲区，最后通知事件分离器读操作完成。
- 事件分离器呼唤处理器。
- 事件处理器处理用户自定义缓冲区中的数据，然后启动一个新的异步操作，并将控制权返回事件分离器。

通过上例可以看出，两个模式的相同点，都是对某个IO事件的事件通知(即告诉某个模块，这个IO操作可以进行或已经完成)。在结构上，两者也有相同点：demultiplexor负责提交IO操作(异步)、查询设备是否可操作(同步)，然后当条件满足时，就回调handler；不同点在于，异步情况下(Proactor)，当回调handler时，表示IO操作已经完成；同步情况下(Reactor)，回调handler时，表示IO设备可以进行某个操作(can read or can write)。

使用Proactor框架和Reactor框架都可以极大的简化网络应用的开发，但它们的重点却不同。Reactor框架中用户定义的操作是在实际操作之前调用的。比如你定义了操作是要向一个SOCKET写数据，那么当该SOCKET可以接收数据的时候，你的操作就会被调用；而Proactor框架中用户定义的操作是在实际操作之后调用的。比如你定义了一个操作要显示从SOCKET中读入的数据，那么当读操作完成以后，你的操作才会被调用。

Proactor和Reactor都是并发编程中的设计模式。在我看来，他们都是用于派发/分离IO操作事件的。这里所谓的IO事件也就是诸如read/write的IO操作。"派发/分离"就是将单独的IO事件通知到上层模块。两个模式不同的地方在于，Proactor用于异步IO，而Reactor用于同步IO。目前应用最广泛的是Reactor模boost::asio，ACE和Windows I/O Completion Ports 实现了Proactor 模式，应用面似乎要窄一些。

2）线程模型

目前网络编程中使用的线程模型主要有以下几种：

1. 每个请求创建一个线程，使用阻塞式IO 操作。在Java 1.4 引入NIO 之前，这是Java 网络编程的推荐做法。可惜伸缩性不佳。
2. 使用线程池，同样使用阻塞式IO 操作。与1 相比，这是提高性能的措施。
3. 使用非阻塞（non-blocking IO） + one loop per thread。即Java NIO 的方式。
4. Leader/Follower 等高级模式

目前使用第3种的比较多，此种模型下，程序里的每个IO 线程有一个event loop （或者叫Reactor），用于处理读写和定时事件（无论周期性的还是单次的）。这种方式主要有如下好处：

• 线程数目基本固定，可以在程序启动的时候设置，不会频繁创建与销毁。
• 可以很方便地在线程间调配负载。event loop 代表了线程的主循环，需要让哪个线程干活，就把timer 或IO channel(TCP connection) 注册到那个线程的loop 里即可。对实时性有要求的connection 可以单独用一个线程；数据量大的connection 可以独占一个线程，并把数据处理任务分摊到另几个线程中；其他次要的辅助性connections 可以共享一个线程。

多线程程序对Reactor 提出了更高的要求，那就是“线程安全”。要允许一个线程往别的线程的loop 里塞东西，这个loop 必须得是线程安全的。此时对于没有IO 光有计算任务的线程，使用event loop 有点浪费，我会用有一种补充方案，此时可以直接用blocking_queue<T> 实现数据的消费者-生产者队，blocking_queue<T>的C++ 实现可以用deque 来做底层的容器 + 1 个mutex + 2 个condition variables。

 

总结以上分析，推荐的多线程服务端编程模式为：event loop per thread + thread pool。

• event loop 用作non-blocking IO 和定时器。可以直接使用libevent开源库。
• thread pool 用来处理与客户端的连接以及相关业务，具体可以是任务队列或消费者-生产者队列。
  
• 主线程只处理监听客户端的连接请求，并将请求平均分配给子线程。

整个程序实现可参照以下流程图：