本文波及到 socket 模型 / 多过程模型 / 多线程模型 /IO 多路复用模型，上面进行开展。
根底的 socket 模型
让客户端和服务端能在网络中进行通信得应用 socket 编程，它能够跨主机间通信，这是过程间通信里比拟非凡的的中央。
单方在进行网络通信前得各自创立一个 socket，在创立的过程中能够指定网络层应用的是 IPv4 还是 IPv6 传输层应用的是 TCP 还是 UDP。咱们具体来看下服务端的 socket 编程过程是怎么的。
服务端首先调用 socket() 函数，创立网络协议为 IPv4，以及传输协定为 TCP 的 socket，接着调用 bind 函数，给这个 sokcet 绑定一个 IP 地址和端口，绑定 IP 地址和端口的目标：
- 绑定端口的目标：当内核收到 TCP 报文，通过 TCP 头里的端口号找到咱们的应用程序，而后将数据传递给咱们。
- 绑定 IP 的目标：一台机器是能够有多个网卡的，每个网卡都有对应的 IP 地址，当绑定一个网卡时，内核在收到该网卡上的包才会发给对应的应用程序。
绑定完 IP 地址和端口后，就能够调用 listen() 函数进行监听，此时对应 TCP 状态图中的 listen，如果咱们要断定服务器中一个网络程序有没有启动，能够通过 netstat 命令查看对应的端口号是否有被监听。服务端进入了监听状态后，通过调用 accept() 函数，来从内核获取客户端的连贯，如果没有客户端连贯，则会阻塞期待客户端连贯的到来。
上面咱们再来看下客户端发动连贯的过程，客户端在创立好 socket 后，调用 connect() 函数发动连贯，函数参数须要指明服务端的 IP 与端口，而后就是 TCP 的三次握手。
在 TCP 连贯的过程中，服务器的内核实际上为每个 socket 保护了两个队列：
- 一个是还没有齐全建设连贯的队列，称为 TCP 半连贯队列，这个队列都是没有实现三次扬的连贯，此时服务端处于 syn_rcvd 状态。
- 一个是曾经建设连贯的队列，称为 TCP 全连贯队列，这个队列都是实现了三次扬的连贯，此时服务端处于 established 状态。
当 TCP 全连贯队列一为空后，服务端的 accept() 函数就会从内核中的 TCP 全连贯队列里取出一个曾经实现连贯的 socket 返回应用程序，后续数据传输都应用这个 socket。须要留神的是，监听的 socket 与真正用来传数据的 sokcet 是两个：一个叫作监听 socket，一个叫作已连贯 soket。建设连贯后，客户端与服务端就开始互相传输数据了，单方都能够通过 read() 和 write() 函数来读写数据。这就是 TCP 协定的 socket 程序的调用过程。
多过程模型
下面提到的 TCP socket 调用流程是最简略、最根本的，它基本上只能一对一通信，因为应用的是同步阻塞的形式，当服务端还没解决完一个客户端的网络 IO 时，或读写操作产生阻塞时，其它客户端是无奈与服务端连贯的。那在这种单过程模式下服务器单机实践最大能连贯多少客户端呢？TCP 连贯是由四元组惟一确认的，这里的四元组指：本机 IP，本机端口，对端 IP，对端端口。服务器作为服务方，通常会在本地固定监听一个端口，因而服务里的本机 IP 与本机端口是固定的，所以最大 TCP 连接数 = 客户端 * 客户端端口数。对于 IPv4，客户端的 IP 数最多为 2 的 32 次方，客户端的端数最多为 2 的 16 次方，也就是服务端单机最大 TCP 连接数约为 2 的 48 次方，不过这是咱们没有思考其它限度因素的，次要的限度有：
- 文件描述符，socket 实际上是一个文件，也就会对应一个文件描述符，在 linux 下，单个过程关上的文件描述符是有限度的，默认为 1024，不过咱们能够进行批改
- 零碎内存，每个 TCP 连贯在内核中都有对应的数据结构，意味着每个连贯都是会占用肯定内存的
显然这种单过程模式反对的连接数是很无限的。
多过程模型
基于最原始的阻塞网络 IO，如果服务器要反对多个客户端，其中比拟传统的形式，就是应用多过程模型，也就是为每个客户端调配一个过程来解决。服务器的主过程负责监听客户的连贯，一旦与客户端连贯实现，accept 函数就会返回一个‘已连贯 socket’，这时通过 fork 函数创立一个子过程，实际上就是将父过程所有相干的资源都复制一份，像文件描述符、内存地址空间、程序计数器、执行的代码等。咱们能够通过返回值来辨别父子过程，父子过程各有分工：父过程只须要关怀‘监听 socket’而不必关怀‘已连贯 socket’，子过程则只关怀‘已连贯 socket’而不必关怀‘监听 socket’，能够看下图：
子过程占用着系统资源，随着子过程数量上的减少，还有过程间上下文切换（上下文切换不仅蕴含了虚拟内存、栈、全局变量等用户空间的资源，还包含了内核堆栈、寄存器等内核空间的资源），服务端必定是应答不了。
多线程模型
既然过程间上下文切换很耗性能，于是轻量级的线程就呈现了。线程是运行在过程中的一个‘逻辑流’，一个过程中能够运行多个线程，同过程里的多个线程能够共享过程的局部资源，像文件描述符列表、过程空间、代码、全局数据、堆、共享库，因为这些资源是共享的所以在应用的时候不须要切换，而保须要切换线程的公有数据、寄存器等不共享的数据，所以这比过程间的上下文切换开销要小很多。
因为将已连贯的 socket 退出到的队列是全局的，每个线程都会操作，为了防止多线程间的竞争，线程在操作这个队列前须要加锁。理念上多线程模型比多过程模型反对的连贯要多，但线程间的调度、共享资源的竞争也很耗性能，另外线程也不是有限的，一个线程会占 1M 的内存空间，如果须要解决的连贯特地耗时那性能就会直线降落。
IO 多路复用
既然为每个申请调配一个过程 / 线程的形式不适合，那有没可能只应用一个过程来保护多个 socket 呢？当然是有的，就是 IO 多路复用技术。一个过程尽管任一时刻只能解决一个申请，然而解决每个申请将耗时管制在极短的工夫内，这样 1 秒内就能够解决上千个申请，将工夫拉长来看，多个申请复用了一个过程，这就是多路复用，这种思维很相似一个 CPU 并发多个过程，所以也叫时候多路复用。
咱们相熟的 select/poll/epoll 内核提供给用户态的多路复用零碎调用，过程能够通过一个零碎调用函数从内核中取得多个事件。select/poll/epoll 是如何获取网络事件的呢？在获取事件时，先把所有连贯（文件描述符）传给内核，再由内核返回产生了事件的连贯，而后在用户态中再解决这些连贯对应的申请即可。
select/poll
这两种实现的形式差不多所以放在一起说。select 实现多路复用的形式是，将已连贯的 socket 都放到一个文件描述符汇合，而后调用 select 函数将文件描述符汇合拷贝到内核里，让内核来查看是否有网络事件产生，查看的形式就是通过遍历文件描述符汇合的形式，当查看到有事件产生后，将此 socket 标记为可读或可写，接着再将整个文件描述符汇合拷贝回用户态里，而后用户态还须要再次遍历找到可读或可写的 socket 而后再对其解决。所以，对于 socket 这种形式，须要进行 2 次遍历文件描述符汇合，一次是在内核态一次是在用户态，而且还会产生 2 次拷贝文件描述符汇合，先从用户空间传入内核空间，由内核空间批改后，再传出到用户空间中。
select 应用固定长度的 bitsMap 示意文件描述符汇合，文件描述符的个数是有限度的，在 linux 零碎中，由内核中的 FD_SETSIZE 限度，默认最大值为 1024，只能监听 0～1023 的文件描述符。
poll 不再应用 BitsMap 来存储所关注的文件描述符，而是应用动静数组，以链表模式来组织，冲破了 select 的文件描述符个数限度，不过还是会受到系统文件描述符限度。
poll 与 select 并没有太大的本质区别，都是应用线性构造存储过程关注的 socket 汇合，因而都南非要遍历文件描述符汇合来找到可读或可写的 socket，工夫复杂度为 O(n)，而且也须要在用户态与内核态之间拷贝文件描述符汇合，这种形式随着并发数上来，性能的损耗会呈指数级别增长。
epoll
epoll 通过两个方面来解决 select/poll 的问题。
- epoll 在内核里应用红黑树来跟踪过程所有待检测的文件描述符，将须要监控的 socket 通过 epoll_ctl() 函数退出内核中的红黑树里，红黑树的操作工夫复杂度个别是 O(logn)，通过对红黑树的操作，就不须要像 select/poll 每次操作时都传入整个 socket 汇合，只须要传入一个待检测的 socket，缩小了内核和用户空间大量的数据拷贝和内存调配。
- epoll 应用事件驱动的机制，内核保护了一个链表来记录就绪事件，当某个 socket 有事件产生时，通过回调函数内核会将其退出到这个就绪事件列表中，当用户调用 epoll_wait() 函数时，只会返回有事件产生的文件描述符的个数，不须要像 select/poll 那样轮询扫描整个 socket 汇合，从而大大提高了检测是的效率。
epoll 的形式即便监听的 socket 数量增多时，效率也不会大幅度降低，可能同时监听的 socket 数量下限为零碎定义的过程关上的最大文件描述符个数。
epoll 反对的两种事件触发模式，别离是边缘触发与程度触发。
- 边缘触发：当被监听的 socket 描述符上有可读事件产生时，服务器端只会从 epoll_wait 中世界杯一次，即便过程没有调用 read 函数从内核读取数据，也仍然只昏迷一次，因而咱们程序要保障一次性将内核缓冲区的数据读取完
- 程度触发：录被监听的 socket 上有可读事件产生时，服务器端一直地从 epoll_wait 中昏迷，直到内核缓冲区数据被 read 函数读完才完结，目标是通知咱们有事件须要读取。
举个例子，你的快递被放到了一个快递箱里，如果快递箱只会通过短信告诉你一次，即便你始终没有去取，它也不会再发送第二条短信揭示你，这个形式就是边缘触发；如果快递箱发现你的快递没有被取出，它就会不停地发短信告诉你，直到你取出了快递，它才消停，这个就是程度触发的形式。
一般来说，边缘触发的效率比程度触发的效率要高，因为边缘触发能够缩小 epoll_wait 的零碎调用次数，零碎调用也是有肯定的开销的的，毕竟也存在上下文的切换。select/poll 只有程度触发模式，epoll 默认的触发模式是程度触发，然而能够依据利用场景设置为边缘触发模式。
多路复用 API 返回的事件并不一定可读写的，如果应用阻塞 I/O，那么在调用 read/write 时则会产生程序阻塞，因而最好搭配非阻塞 I/O，以便应答极少数的非凡状况。
总结
最根底的 TCP 的 socket 编程，它是阻塞 IO 模型，基本上只能一对一通信，那为了服务更多的客户端，咱们须要改良网络 IO 模型。
比拟传统的形式是应用多过程 / 线程模型，每来一个客户端连贯，就调配一个过程 / 线程，而后后续的读写都在对应的过程 / 线程。当客户端一直增大时，过程 / 线程的高度还有上下文切换及它们占用的内存都会有成瓶颈。
为了解决下面这个问题，就呈现了 IO 的多路复用，能够只在一个过程里解决多个文件的 IO，linux 下有三种提供 IO 多路复用的 API，别离是是：select/poll/epoll。
select 与 poll 没有实质的区别，它们外部都是应用‘线性构造’来存储过程关注的 socket 汇合。在应用的时候，首先须要把关注的 Socket 汇合通过 select/poll 零碎调用从用户态拷贝到内核态，而后由内核检测事件，当有网络事件产生时，内核须要遍历过程关注 Socket 汇合，找到对应的 Socket，并设置其状态为可读 / 可写，而后把整个 Socket 汇合从内核态拷贝到用户态，用户态还要持续遍历整个 Socket 汇合找到可读 / 可写的 Socket，而后对其解决。
很显著发现，select 和 poll 的缺点在于，当客户端越多，也就是 Socket 汇合越大，Socket 汇合的遍历和拷贝会带来很大的开销。
于是呈现了 epoll，它是通过在内核应用红黑树来存储所有待检测的文件描述符，因为不须要每次都传入整个 socket 汇合，就缩小了内核和用户空间大量的数据拷贝和内存调配，另一点就是应用事件驱动的机制在内核保护了一个链表来记录就绪事件而不须要将 select/poll 轮询整个汇合，大大提高了检测的效率。
另外，epoll 反对边缘触发和程度触发的形式，而 select/poll 只反对程度触发，一般而言，边缘触发的形式会比程度触发的效率高。
本文次要参考：
小林 coding 解答 IO 多路复用的文章