网络I/O模型 人多了，就会有问题。web刚出现的时候，光顾的人很少。近年来网络应用规模逐渐扩大，应用的架构也需要随之改变。C10k的问题，让工程师们需要思考服务的性能与应用的并发能力。
网络应用需要处理的无非就是两大类问题，网络I/O，数据计算。相对于后者，网络I/O的延迟，给应用带来的性能瓶颈大于后者。网络I/O的模型大致有如下几种：
同步模型（synchronous I/O）
阻塞I/O（bloking I/O）
非阻塞I/O（non-blocking I/O）
多路复用I/O（multiplexing I/O）
信号驱动式I/O（signal-driven I/O）
异步I/O（asynchronous I/O）
网络I/O的本质是socket的读取，socket在linux系统被抽象为流，I/O可以理解为对流的操作。这个操作又分为两个阶段：
等待流数据准备（wating for the data to be ready）。
第一步通常涉及等待网络上的数据分组到达，然后被复制到内核的某个缓冲区。
阻塞I/O（bloking I/O） 阻塞I/O是最流行的I/O模型。它符合人们最常见的思考逻辑。阻塞就是进程 "被" 休息, CPU处理其它进程去了。在网络I/O的时候，进程发起recvform系统调用，然后进程就被阻塞了，什么也不干，直到数据准备好，并且将数据从内核复制到用户进程，最后进程再处理数据，在等待数据到处理数据的两个阶段，整个进程都被阻塞。不能处理别的网络I/O。大致如下图：
这就好比我们去钓鱼，抛竿之后就一直在岸边等，直到等待鱼上钩。然后再一次抛竿，等待下一条鱼上钩，等待的时候，什么事情也不做，大概会胡思乱想吧。
阻塞IO的特点就是在IO执行的两个阶段都被block了非阻塞I/O（non-bloking I/O） 在网络I/O时候，非阻塞I/O也会进行recvform系统调用，检查数据是否准备好，与阻塞I/O不一样，"非阻塞将大的整片时间的阻塞分成N多的小的阻塞, 所以进程不断地有机会 '被' CPU光顾"。
也就是说非阻塞的recvform系统调用调用之后，进程并没有被阻塞，内核马上返回给进程，如果数据还没准备好，此时会返回一个error。进程在返回之后，可以干点别的事情，然后再发起recvform系统调用。重复上面的过程，循环往复的进行recvform系统调用。这个过程通常被称之为轮询。轮询检查内核数据，直到数据准备好，再拷贝数据到进程，进行数据处理。需要注意，拷贝数据整个过程，进程仍然是属于阻塞的状态。
我们再用钓鱼的方式来类别，当我们抛竿入水之后，就看下鱼漂是否有动静，如果没有鱼上钩，就去干点别的事情，比如再挖几条蚯蚓。然后不久又来看看鱼漂是否有鱼上钩。这样往返的检查又离开，直到鱼上钩，再进行处理。
非阻塞 IO的特点是用户进程需要不断的主动询问kernel数据是否准备好。多路复用I/O（multiplexing I/O） 可以看出，由于非阻塞的调用，轮询占据了很大一部分过程，轮询会消耗大量的CPU时间。结合前面两种模式。如果轮询不是进程的用户态，而是有人帮忙就好了。多路复用正好处理这样的问题。
多路复用有两个特别的系统调用select或poll。select调用是内核级别的，select轮询相对非阻塞的轮询的区别在于---前者可以等待多个socket，当其中任何一个socket的数据准好了，就能返回进行可读，然后进程再进行recvform系统调用，将数据由内核拷贝到用户进程，当然这个过程是阻塞的。多路复用有两种阻塞，select或poll调用之后，会阻塞进程，与第一种阻塞不同在于，此时的select不是等到socket数据全部到达再处理, 而是有了一部分数据就会调用用户进程来处理。如何知道有一部分数据到达了呢？监视的事情交给了内核，内核负责数据到达的处理。也可以理解为"非阻塞"吧。
对于多路复用，也就是轮询多个socket。钓鱼的时候，我们雇了一个帮手，他可以同时抛下多个钓鱼竿，任何一杆的鱼一上钩，他就会拉杆。他只负责帮我们钓鱼，并不会帮我们处理，所以我们还得在一帮等着，等他把收杆。我们再处理鱼。多路复用既然可以处理多个I/O，也就带来了新的问题，多个I/O之间的顺序变得不确定了，当然也可以针对不同的编号。
多路复用的特点是通过一种机制一个进程能同时等待IO文件描述符，内核监视这些文件描述符（套接字描述符），其中的任意一个进入读就绪状态，select， poll，epoll函数就可以返回。对于监视的方式，又可以分为 select， poll， epoll三种方式。
异步I/O（asynchronous I/O） 相对于同步I/O，异步I/O不是顺序执行。用户进程进行aio_read系统调用之后，无论内核数据是否准备好，都会直接返回给用户进程，然后用户态进程可以去做别的事情。等到socket数据准备好了，内核直接复制数据给进程，然后从内核向进程发送通知。I/O两个阶段，进程都是非阻塞的。
比之前的钓鱼方式不一样，这一次我们雇了一个钓鱼高手。他不仅会钓鱼，还会在鱼上钩之后给我们发短信，通知我们鱼已经准备好了。我们只要委托他去抛竿，然后就能跑去干别的事情了，直到他的短信。我们再回来处理已经上岸的鱼。
同步和异步的区别 通过对上述几种模型的讨论，需要区分阻塞和非阻塞，同步和异步。他们其实是两组概念。区别前一组比较容易，后一种往往容易和前面混合。在我看来，所谓同步就是在整个I/O过程。尤其是拷贝数据的过程是阻塞进程的，并且都是应用进程态去检查内核态。而异步则是整个过程I/O过程用户进程都是非阻塞的，并且当拷贝数据的时是由内核发送通知给用户进程。
对于同步模型，主要是第一阶段处理方法不一样。而异步模型，两个阶段都不一样。这里我们忽略了信号驱动模式。这几个名词还是容易让人迷惑，只有同步模型才考虑阻塞和非阻塞，因为异步肯定是非阻塞，异步非阻塞的说法感觉画蛇添足。
Select 模型 1.select 原理 网络通信被Unix系统抽象为文件的读写，通常是一个设备，由设备驱动程序提供，驱动可以知道自身的数据是否可用。支持阻塞操作的设备驱动通常会实现一组自身的等待队列，如读/写等待队列用于支持上层(用户层)所需的block或non-block操作。设备的文件的资源如果可用（可读或者可写）则会通知进程，反之则会让进程睡眠，等到数据到来可用的时候，再唤醒进程。
这些设备的文件描述符被放在一个数组中，然后select调用的时候遍历这个数组，如果对于的文件描述符可读则会返回改文件描述符。当遍历结束之后，如果仍然没有一个可用设备文件描述符，select让用户进程则会睡眠，直到等待资源可用的时候在唤醒，遍历之前那个监视的数组。每次遍历都是线性的。
2.select 回显服务器 select涉及系统调用和操作系统相关的知识，因此单从字面上理解其原理还是比较乏味。用代码来演示最好不过了。使用python的select模块很容易写出下面一个回显服务器：
import select
import socket
import sys
HOST = 'localhost'
PORT = 5000
BUFFER_SIZE = 1024
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind((HOST, PORT))
server.listen(5)
inputs = [server, sys.stdin]
running = True
while True:
try:
# 调用 select 函数，阻塞等待
readable, writeable, exceptional = select.select(inputs, [], [])
except select.error, e:
break
# 数据抵达，循环
for sock in readable:
# 建立连接
if sock == server:
conn, addr = server.accept()
# select 监听的socket
inputs.append(conn)
elif sock == sys.stdin:
junk = sys.stdin.readlines()
running = False
else:
try:
# 读取客户端连接发送的数据
data = sock.recv(BUFFER_SIZE)
if data:
sock.send(data)
if data.endswith('\r\n\r\n'):
# 移除select监听的socket
inputs.remove(sock)
sock.close()
else:
# 移除select监听的socket
inputs.remove(sock)
sock.close()
except socket.error, e:
inputs.remove(sock)
server.close()
Nach dem Login kopieren
运行上述代码，使用curl访问http://localhost:5000，即可看命令行返回请求的HTTP request信息。
下面详细解析上述代码的原理。
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind((HOST, PORT))
server.listen(5)
Nach dem Login kopieren
上述代码使用socket初始化一个TCP套接字，并绑定主机地址和端口，然后设置服务器监听。
inputs = [server, sys.stdin]
Nach dem Login kopieren
这里定义了一个需要select监听的列表，列表里面是需要监听的对象（等于系统监听的文件描述符）。这里监听socket套接字和用户的输入。
然后代码进行一个服务器无线循环。
try:
# 调用 select 函数，阻塞等待
readable, writeable, exceptional = select.select(inputs, [], [])
except select.error, e:
break
Nach dem Login kopieren
调用了select函数，开始循环遍历监听传入的列表inputs。如果没有curl服务器，此时没有建立tcp客户端连接，因此改列表内的对象都是数据资源不可用。因此select阻塞不返回。
客户端输入curl http://localhost:5000之后，一个套接字通信开始，此时input中的第一个对象server由不可用变成可用。因此select函数调用返回，此时的readable有一个套接字对象（文件描述符可读）。
for sock in readable:
# 建立连接
if sock == server:
conn, addr = server.accept()
# select 监听的socket
inputs.append(conn)
Nach dem Login kopieren
select返回之后，接下来遍历可读的文件对象，此时的可读中只有一个套接字连接，调用套接字的accept()方法建立TCP三次握手的连接，然后把该连接对象追加到inputs监视列表中，表示我们要监视该连接是否有数据IO操作。
由于此时readable只有一个可用的对象，因此遍历结束。再回到主循环，再次调用select，此时调用的时候，不仅会遍历监视是否有新的连接需要建立，还是监视刚才追加的连接。如果curl的数据到了，select再返回到readable，此时在进行for循环。如果没有新的套接字，将会执行下面的代码：
try:
# 读取客户端连接发送的数据
data = sock.recv(BUFFER_SIZE)
if data:
sock.send(data)
if data.endswith('\r\n\r\n'):
# 移除select监听的socket
inputs.remove(sock)
sock.close()
else:
# 移除select监听的socket
inputs.remove(sock)
sock.close()
except socket.error, e:
inputs.remove(sock)
Nach dem Login kopieren
通过套接字连接调用recv函数，获取客户端发送的数据，当数据传输完毕，再把监视的inputs列表中除去该连接。然后关闭连接。
整个网络交互过程就是如此，当然这里如果用户在命令行中输入中断，inputs列表中监视的sys.stdin也会让select返回，最后也会执行下面的代码：
elif sock == sys.stdin:
junk = sys.stdin.readlines()
running = False
Nach dem Login kopieren
有人可能有疑问，在程序处理sock连接的是时候，假设又输入了curl对服务器请求，将会怎么办？此时毫无疑问，inputs里面的server套接字会变成可用。等现在的for循环处理完毕，此时select调用就会返回server。如果inputs里面还有上一个过程的conn连接，那么也会循环遍历inputs的时候，再一次针对新的套接字accept到inputs列表进行监视，然后继续循环处理之前的conn连接。如此有条不紊的进行，直到for循环结束，进入主循环调用select。
任何时候，inputs监听的对象有数据，下一次调用select的时候，就会繁返回readable，只要返回，就会对readable进行for循环，直到for循环结束在进行下一次select。
主要注意，套接字建立连接是一次IO，连接的数据抵达也是一次IO。
3.select的不足 尽管select用起来挺爽，跨平台的特性。但是select还是存在一些问题。
为了解决这些问题，操作系统又提供了poll方案，但是poll的模型和select大致相当，只是改变了一些限制。目前Linux最先进的方式是epoll模型。
许多高性能的软件如nginx, nodejs都是基于epoll进行的异步。
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Neueste Artikel des Autors
2024-09-20 15:51:33
2024-09-20 15:47:32
2024-09-20 15:45:32
2024-09-20 15:39:32
2024-09-20 15:38:32
2024-09-20 15:27:32
2024-09-20 15:26:32
2024-09-20 15:12:32
2024-09-20 14:53:01
2024-09-20 14:51:01
