【目录】
一 IO模型介绍
二 阻塞IO(blocking IO)
三 非阻塞IO(non-blocking IO)
四 多路复用IO(IO multiplexing)
五 异步IO(Asynchronous I/O)
六 IO模型比较分析
七 selectors模块
本文讨论的背景是Linux环境下的network IO
一、 IO模型介绍
回顾：同步/异步 阻塞/非阻塞
1、IO分类
同步（synchronous） IO
异步（asynchronous） IO
阻塞（blocking） IO
非阻塞（non-blocking）IO
2、IO模型
五种IO Model：
* blocking IO、 * nonblocking IO、* IO multiplexing 、* signal driven IO 、* asynchronous IO
（由于signal driven IO（信号驱动IO）在实际中并不常用，所以主要介绍其余四种 IO Model）
3、IO发生时涉及的对象和步骤
对于一个network IO (这里我们以read举例)，它会涉及到两个系统对象——
一个是 调用这个IO的process (or thread)，另一个就是 系统内核(kernel)。
当一个read操作发生时，该操作会经历两个阶段：
#1）等待数据准备 (Waiting for the data to be ready)
#2）将数据从内核拷贝到进程中(Copying the data from the kernel to the process)
记住这两点很重要，因为这些IO模型的区别就是在两个阶段上各有不同的情况。
4、补充
#1、输入操作：read、readv、recv、recvfrom、recvmsg共5个函数，如果会阻塞状态，则会经历wait data和copy data两个阶段，如果设置为非阻塞则在wait 不到data时抛出异常
#2、输出操作：write、writev、send、sendto、sendmsg共5个函数，在发送缓冲区满了会阻塞在原地，如果设置为非阻塞，则会抛出异常
#3、接收外来链接：accept，与输入操作类似
#4、发起外出链接：connect，与输出操作类似
二、 阻塞IO(blocking IO)
1、图解
在linux中，默认情况下所有的socket都是blocking，一个典型的读操作流程大概是这样：
分析版——
2、过程描述：
kernel（内核 / 操作系统）：
当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。
对于network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候kernel就要等待足够的数据到来。
用户进程：
而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。
3、特点：
blocking IO的特点：在IO执行的两个阶段（等待数据和拷贝数据两个阶段）都被block了
4、补充：
所谓阻塞型接口是指系统调用（一般是IO接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。
实际上，除非特别指定，几乎所有的IO接口 ( 包括socket接口 ) 都是阻塞型的。
如何解决调用阻塞问题——
在服务器端使用多线程 / 多进程（让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接）
或者 使用 线程池 / 连接池（“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如websphere、tomcat和各种数据库等。）
上述两种手段，都没有很好地解决阻塞问题，该阻塞等待的还是如此——因此，尝试使用 非阻塞IO
""" 我们之前写的都是阻塞IO模型 协程除外 """ import socket server = socket.socket() server.bind(('127.0.0.1',8080)) server.listen(5) while True: conn, addr = server.accept() while True: try: data = conn.recv(1024) if len(data) == 0:break print(data) conn.send(data.upper()) except ConnectionResetError as e: break conn.close() # 在服务端开设多进程或者多线程 进程池线程池 其实还是没有解决IO问题 该等的地方还是得等 没有规避 只不过多个人等待的彼此互不干扰