本文波及到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多路复用的文章