个人对网络编程中的一点思考

一、背景

在高并发服务器模型中， 为了充分利用CPU的硬件资源， 多进程/多线程模型是必不可少的。 在多进程/多线程模型中， 还要考虑尽量减少上下文切换、进程/线程切换、CPU核心调度切换、锁竞争等。

 

二、多进程/多线程模型

在多核时代，一般使用以下比较典型的多进程/多线程服务器模型。

首先需要单线程listen一个端口并负责accept连接，当有新连接到来时，根据负载均衡原则唤醒一个worker并传递connection fd给其。 而worker线程则维护一个connection fd队列， 负责对已经建好的connection进行读/写操作以及相关业务处理。 

由于采用的是单线程listener，在处理高速率海量连接时，一样会成为瓶颈。

在 Linux kernel 3.9带来了SO_REUSEPORT特性，可以解决上面(单进程listen，多工作进程accept() )的瓶颈问题.

SO_REUSEPORT是 支持多个进程或者线程绑定到同一端口，提高服务器程序的吞吐性能，具体来说解决了下面的几个问题：

允许多个套接字 bind()/listen() 同一个TCP/UDP端口

每一个线程拥有自己的服务器套接字

在服务器套接字上没有了锁的竞争，因为每个进程一个服务器套接字

内核层面实现负载均衡

 

三、IO多路复用

IO多路复用+异步的事件驱动机制已经成为了当前网络编程的主流思想。随着epoll的强势崛起， 传统的select、poll也已经被人们慢慢遗忘。epoll不仅能够监听网络事件， 也可以监听其它事件， 如管道、文件、timer、串口等等几乎所有拥有文件描述符的事件。

通常异步编程的思想：

1. 主线程通过epoll或libevent监听各种事件， 注册事件的回调函数。

2. 当有新事件触发时，根据事件类型， dispatch到worker线程。

3. worker线程被唤醒（可通过管道或Posix pthread）， 进入状态机， 根据当前状态和事件类型做相应业务处理。 工作完成后，继续阻塞。

4. 主线程继续等待事件。