操作系统IO模型与实现原理
阻塞IO 模型
应用程序调用一个IO函数，导致应用程序阻塞，等待数据准备好。如果数据没有准备好，一直等待....数据准备好了，从内核拷贝到用户空间,IO函数返回成功指示。
当调用recv()函数时，系统首先查是否有准备好的数据。如果数据没有准备好，那么系统就处于等待状态。当数据准备好后，将数据从系统缓冲区复制到用户空间，然后该函数返回。在套接应用程序中，当调用recv()函数时，未必用户空间就已经存在数据，那么此时recv()函数就会处于等待状态。
非阻塞IO模型
我们把一个SOCKET接口设置为非阻塞就是告诉内核，当所请求的I/O操作无法完成时，不要将进程睡眠，而是返回一个错误。这样我们的I/O操作函数将不断的测试数据是否已经准备好，如果没有准备好，继续测试，直到数据准备好为止。在这个不断测试的过程中，会大量的占用CPU的时间。上述模型绝不被推荐。
把SOCKET设置为非阻塞模式，即通知系统内核：在调用Windows Sockets API时，不要让线程睡眠，而应该让函数立即返回。在返回时，该函数返回一个错误代码。图所示，一个非阻塞模式套接字多次调用recv()函数的过程。前三次调用recv()函数时，内核数据还没有准备好。因此，该函数立即返回WSAEWOULDBLOCK错误代码。第四次调用recv()函数时，数据已经准备好，被复制到应用程序的缓冲区中，recv()函数返回成功指示，应用程序开始处理数据。
IO复用模型
主要是通过select和epoll；对一个IO端口，两次调用，两次返回，比阻塞IO并没有什么优越性；关键是能实现同时对多个IO端口进行监听；
I/O复用模型会用到select、poll、epoll函数，这几个函数也会使进程阻塞，但是和阻塞I/O所不同的的，这两个函数可以同时阻塞多个I/O操作。而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数。
当用户进程调用了select，那么整个进程会被block；而同时，kernel会"监视"所有select负责的socket；当任何一个socket中的数据准备好了，select就会返回。这个时候，用户进程再调用read操作，将数据从kernel拷贝到用户进程。
这个图和blocking IO的图其实并没有太大的不同，事实上还更差一些。因为这里需要使用两个系统调用(select和recvfrom)，而blocking IO只调用了一个系统调用(recvfrom)。但是，用select的优势在于它可以同时处理多个connection。（select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。
信号驱动IO模型
两次调用，两次返回；
允许套接口进行信号驱动I/O,并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据。
异步IO模型
简单进程/线程模型
这是一种非常简单的模式，服务器启动后监听端口，阻塞在accept上，当新网络连接建立后，accept返回新连接，服务器启动一个新的进程/线程专门负责这个连接。从性能和伸缩性来说，这种模式是非常糟糕的，原因在于
- 进程/线程创建和销毁的时间，操作系统创建一个进程/线程显然需要时间，在一个繁忙的服务器上，如果每秒都有大量的连接建立和断开，采用每个进程/线程处理一个客户连接的模式，每个新连接都要创建创建一个进程/线程，当连接断开时，销毁对应的线程/进程。创建和销毁进程/线程的操作消耗了大量的CPU资源。使用链接池和线程池可以缓解这个问题。
- 内存占用，主要包含两方面；一个是内核数据结构所占用的内存空间，另外一个是Stack所占用的内存。有些应用的调用栈很深，比如Java应用，经常能看到几十上百层的调用栈。
- 上下文切换的开销；上下文切换时，操作系统的调度器中断当前线程，选择另外一个可运行的线程在CPU上继续运行。调度器需要保存当前线程的现场信息，然后选择一个可运行的线程，再将新线程的状态恢复到寄存器中。保存和恢复现场所需要的时间和CPU型号有关，选择一个可运行的线程则完全是软件操作，Linux 2.6才开始使用常量时间的调度算法。 以上是上下文切换的直接开销。除此之外还有一些间接开销，比如上下文切换导致相关的缓存失效影响程序的性能，但是此类的很多间接开销很难衡量。
有意思的是，这种模式虽然性能极差，但却依然是我们今天最常见到的模式，很多Web程序都是这样的方式在运行。
select/poll
另外一种方式是使用select/poll，在一个线程内处理多个客户连接。select和poll能够监控多个socket文件描述符，当某个文件描述符就绪，select/soll从阻塞状态返回，通知应用程序可以处理用户连接了。使用这种方式，我们只需要一个线程就可以处理大量的连接，避免了多进程/线程的开销。之所以把select和poll放在一起说，原因在于两者非常相似，性能上基本没有区别，唯一的区别在于poll突破了select 1024个文件描述符的限制，然而当文件描述符数量增加时，poll性能急剧下降，因此所谓突破1024个文件描述符实际上毫无意义。select/poll并不完美，依然存在很多问题：
- 每次调用select/poll，都要把文件描述符的集合从用户地址空间复制到内核地址空间
- select/poll返回后，调用方必须遍历所有的文件描述符，逐一判断文件描述符是否可读/可写。
这两个限制让select/poll完全失去了伸缩性。连接数越多，文件描述符就越多，文件描述符越多，每次调用select/poll所带来的用户空间到内核空间的复制开销越大。最严重的是当报文达到，select/poll返回之后，必须遍历所有的文件描述符。假设现在有1万个连接，其中只一个连接发送了请求，但是select/poll就要把1万个连接全部检查一遍。
epoll
epoll是如何提供一个高性能可伸缩的IO多路复用机制呢？首先，epoll引入了epoll instance这个概念，epoll instance在内核中关联了一组要监听的文件描述符配置：interest list，这样的好处在于，每次要增加一个要监听的文件描述符，不需要把所有的文件描述符都配置一次，然后从用户地址空间复制到内核地址空间，只需要把单个文件描述符复制到内核地址空间，复制开销从O(n)降到了O(1)。
注册完文件描述符后，调用epoll_wait开始等待文件描述符事件。epoll_wait可以只返回已经ready的文件描述符，因此，在epoll_wait返回之后，程序只需要处理真正需要处理的文件描述符，而不用把所有的文件描述符全部遍历一遍。假设在全部N个文件描述符中，只有一个文件描述符Ready，select/poll要执行N次循环，epoll只需要一次。
epoll出现之后，Linux上才真正有了一个可伸缩的IO多路复用机制。基于epoll，能够支撑的网络连接数取决于硬件资源的配置，而不再受限于内核的实现机制。CPU越强，内存越大，能支撑的连接数越多。
select、poll、epoll的区别
1、支持一个进程所能打开的最大连接数
|--------|------------------------------------------------------------------------------------------------------------------------|
| select | 单个进程所能打开的最大连接数有FD_SETSIZE宏定义，其大小是32个整数的大小（在32位的机器上，大小就是32*32，同理64位机器上FD_SETSIZE为32*64），可以对进行修改，然后重新编译内核，但是性能可能会受到影响。 |
| poll | poll本质上和select没有区别，但是它没有最大连接数的限制，原因是它是基于链表来存储的 |
| epoll | 连接数有上限，但是很大，1G内存的机器上可以打开10万左右的连接，2G内存的机器可以打开20万左右的连接 |
2、FD剧增后带来的IO效率问题
|--------|--------------------------------------------------------------------------------------------------------------------------------------|
| select | 因为每次调用时都会对连接进行线性遍历，所以随着FD的增加会造成遍历速度慢的"线性下降性能问题"。 |
| poll | 同上 |
| epoll | 因为epoll内核中实现是根据每个fd上的callback函数来实现的，只有活跃的socket才会主动调用callback，所以在活跃socket较少的情况下，使用epoll没有前面两者的线性下降的性能问题，但是所有socket都很活跃的情况下，可能会有性能问题。 |
3、消息传递方式
|--------|---------------------------|
| select | 内核需要将消息传递到用户空间，都需要内核拷贝动作 |
| poll | 同上 |
| epoll | epoll通过内核和用户空间共享一块内存来实现的。 |
什么是TCP粘包半包？
假设场景：使用程序，用客户端发送100遍消息
假设客户端分别发送了两个数据包D1和D2给服务端，由于服务端一次读取到的字节数是不确定的，故可能存在以下4种情况。
（1）服务端分两次读取到了两个独立的数据包，分别是D1和D2，没有粘包和拆包；
（2）服务端一次接收到了两个数据包，D1和D2粘合在一起，被称为TCP粘包；
（3）服务端分两次读取到了两个数据包，第一次读取到了完整的D1包和D2包的部分内容，第二次读取到了D2包的剩余内容，这被称为TCP拆包；
（4）服务端分两次读取到了两个数据包，第一次读取到了D1包的部分内容D1_1，第二次读取到了D1包的剩余内容D1_2和D2包的整包。
如果此时服务端TCP接收滑窗非常小，而数据包D1和D2比较大，很有可能会发生第五种可能，即服务端分多次才能将D1和D2包接收完全，期间发生多次拆包。
TCP粘包/半包发生的原因
由于TCP协议本身的机制（面向连接的可靠地协议-三次握手机制）客户端与服务器会维持一个连接（Channel），数据在连接不断开的情况下，可以持续不断地将多个数据包发往服务器，但是如果发送的网络数据包太小，那么他本身会启用Nagle算法（可配置是否启用）对较小的数据包进行合并（基于此，TCP的网络延迟要UDP的高些）然后再发送（超时或者包大小足够）。那么这样的话，服务器在接收到消息（数据流）的时候就无法区分哪些数据包是客户端自己分开发送的，这样产生了粘包；服务器在接收到数据库后，放到缓冲区中，如果消息没有被及时从缓存区取走，下次在取数据的时候可能就会出现一次取出多个数据包的情况，造成粘包现象
UDP：本身作为无连接的不可靠的传输协议（适合频繁发送较小的数据包），他不会对数据包进行合并发送（也就没有Nagle算法之说了），他直接是一端发送什么数据，直接就发出去了，既然他不会对数据合并，每一个数据包都是完整的（数据+UDP头+IP头等等发一次数据封装一次）也就没有粘包一说了。
分包产生的原因就简单的多：可能是IP分片传输导致的，也可能是传输过程中丢失部分包导致出现的半包，还有可能就是一个包可能被分成了两次传输，在取数据的时候，先取到了一部分（还可能与接收的缓冲区大小有关系），总之就是一个数据包被分成了多次接收。
更具体的原因有三个，分别如下。
-
应用程序写入数据的字节大小大于套接字发送缓冲区的大小
-
进行MSS大小的TCP分段。MSS是最大报文段长度的缩写。MSS是TCP报文段中的数据字段的最大长度。数据字段加上TCP首部才等于整个的TCP报文段。所以MSS并不是TCP报文段的最大长度，而是：MSS=TCP报文段长度-TCP首部长度
-
以太网的payload大于MTU进行IP分片。MTU指：一种通信协议的某一层上面所能通过的最大数据包大小。如果IP层有一个数据包要传，而且数据的长度比链路层的MTU大，那么IP层就会进行分片，把数据包分成托干片，让每一片都不超过MTU。注意，IP分片可以发生在原始发送端主机上，也可以发生在中间路由器上。
解决粘包半包问题
由于底层的TCP无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案，可以归纳如下。
（1）在包尾增加分割符，比如回车换行符进行分割，例如FTP协议；linebase包和delimiter包下，分别使用LineBasedFrameDecoder和DelimiterBasedFrameDecoder
（2）消息定长，例如每个报文的大小为固定长度200字节，如果不够，空位补空格；fixed包下，使用FixedLengthFrameDecoder
（3）将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体长度）的字段，通常设计思路为消息头的第一个字段使用int32来表示消息的总长度，LengthFieldBasedFrameDecoder；。