python网络编程——IO多路复用之select

出处：https://www.cnblogs.com/maociping/p/5121788.html

1 IO多路复用的概念  

      原生socket客户端在与服务端建立连接时，即服务端调用accept方法时是阻塞的，同时服务端和客户端在收发数据(调用recv、send、sendall)时也是阻塞的。原生socket服务端在同一时刻只能处理一个客户端请求，即服务端不能同时与多个客户端进行通信，实现并发，导致服务端资源闲置(此时服务端只占据 I/O，CPU空闲)。

    现在的需求是：我们要让多个客户端连接至服务器端，而且服务器端需要处理来自多个客户端请求。很明显，原生socket实现不了这种需求，此时我们该采用什么方式来处理呢？

    解决方法：采用I/O多路复用机制。在python网络编程中，I/O多路复用机制就是用来解决多个客户端连接请求服务器端，而服务器端能正常处理并响应给客户端的一种机制。书面上来说，就是通过1种机制：可以同时监听多个文件描述符，一旦描述符就绪，能够通知程序进行相应的读写操作。

    I/O多路复用是指：通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。

    1.1 linux中的IO多路复用

(1)select     select最早于1983年出现在4.2BSD中，它通过一个select()系统调用来监视多个文件描述符的数组，当select()返回后，该数组中就绪的文件描述符便会被内核修改标志位，使得进程可以获得这些文件描述符从而进行后续的读写操作。     select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点，事实上从现在看来，这也是它所剩不多的优点之一。     select的一个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，不过可以通过修改宏定义甚至重新编译内核的方式提升这一限制。     另外，select()所维护的存储大量文件描述符的数据结构，随着文件描述符数量的增大，其复制的开销也线性增长。同时，由于网络响应时间的延迟使得大 量TCP连接处于非活跃状态，但调用select()会对所有socket进行一次线性扫描，所以这也浪费了一定的开销。 (2)poll     poll在1986年诞生于System V Release 3，它和select在本质上没有多大差别，但是poll没有最大文件描述符数量的限制。     poll和select同样存在一个缺点就是，包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间，而不论这些文件描述符是否就绪，它的开销随着文件描述符数量的增加而线性增大。     另外，select()和poll()将就绪的文件描述符告诉进程后，如果进程没有对其进行IO操作，那么下次调用select()和poll()的时候 将 再次报告这些文件描述符，所以它们一般不会丢失就绪的消息，这种方式称为水平触发（Level Triggered）。 (3)epoll     直到Linux2.6才出现了由内核直接支持的实现方法，那就是epoll，它几乎具备了之前所说的一切优点，被公认为Linux2.6下性能最好的多路I/O就绪通知方法。     epoll可以同时支持水平触发和边缘触发（Edge Triggered，只告诉进程哪些文件描述符刚刚变为就绪状态，它只说一遍，如果我们没有采取行动，那么它将不会再次告知，这种方式称为边缘触发），理论上边缘触发的性能要更高一些，但是代码实现相当复杂。     epoll同样只告知那些就绪的文件描述符，而且当我们调用epoll_wait()获得就绪文件描述符时，返回的不是实际的描述符，而是一个代表就绪描 述符数量的 值，你只需要去epoll指定的一个数组中依次取得相应数量的文件描述符即可，这里也使用了内存映射（mmap）技术，这样便彻底省掉了这些文件描述符在 系统调用时复制的开销。     另一个本质的改进在于epoll采用基于事件的就绪通知方式。在select/poll 中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一个文件描述符，一旦基于某 个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便得到通知。

     1.2 python中的IO多路复用

Python中有一个select模块，其中提供了：select、poll、epoll三个方法，分别调用系统的 select，poll，epoll从而实现IO多路复用。     Windows Python：提供： select     Mac Python：提供： select     Linux Python：提供： select、poll、epoll

2 python中的IO多路复用

    IO多路复用有些地方也称这种IO方式为事件驱动IO(event driven IO)。我们都知道，select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select /epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。它的流程如图：

      Python中有一个select模块，其中提供了：select、poll、epoll三个方法(根据系统的不同，select模块提供了不同的方法，在linux中select模块提供了全部三种方法)，分别调用系统的 select，poll，epoll从而实现IO多路复用。

    注意：网络操作、文件操作、终端操作等均属于IO操作，对于windows只支持Socket操作，其他系统支持其他IO操作，但是无法检测普通文件操作,自动检测文件是否已经变化。普通文件操作，所有系统都是完成不了的，普通文件是属于I/O操作！但是对于python来说文件变更，python是监控不了的，所以我们能用的只有是“终端的输入输出，Socket的输入输出”

   2.1 select方法

    select 的中文含义是”选择“，select机制也如其名，监听一些 server 关心的套接字、文件等对象，关注他们是否可读、可写、发生异常等事件。一旦出现某个 select 关注的事件，select 会对相应的套接字或文件进行特定的处理，这就是 select 机制最主要的功能。

　　select 机制可以只使用一个进程/线程来处理多个socket或其他对象，因此又被称为I/O复用。

　　关于select机制的进程阻塞形式，与普通的套接字略有不同。socket对象可能阻塞在accept(),recvfrom()等方法上，以recvfrom()方法为例，当执行到socket.recvfrom()这一句时，就会调用一个系统调用询问内核：client/server发来的数据包准备好了没？此时从进程空间切換到内核地址空间，内核可能需要等数据包完全到达，然后将数据复制到程序的地址空间后，recvfrom()才会返回，接下来进程继续执行，对读取到的数据进行必要的处理。

　　而使用select函数编程时，同样针对上面的recvfrom()方法，进程会阻塞在select()调用上，等待出现一个或多个套接字对象满足可读事件，当内核将数据准备好后，select()返回某个套接字对象可读这一条件，随后再调用recvfrom()将数据包从内核复制到进程地址空间。

　　所以可见，如果仅仅从单个套接字的处理来看，select()反倒性能更低，因为select机制使用两个系统调用。但select机制的优势就在于它可以同时等待多个fd就绪，而当某个fd发生满足我们关心的事件时，就对它执行特定的操作。

句柄列表11, 句柄列表22, 句柄列表33 = select.select(句柄列表1, 句柄列表2, 句柄列表3, 超时时间) 参数： 可接受四个参数（前三个必须） 返回值：三个列表 select方法用来监视文件句柄，如果句柄发生变化，则获取该句柄。 1、当 参数1 序列中的句柄发生可读时（accetp和read），则获取发生变化的句柄并添加到 返回值1 序列中 2、当 参数2 序列中含有句柄时，则将该序列中所有的句柄添加到 返回值2 序列中 3、当 参数3 序列中的句柄发生错误时，则将该发生错误的句柄添加到 返回值3 序列中 4、当 超时时间未设置，则select会一直阻塞，直到监听的句柄发生变化 5、当 超时时间＝1时，那么如果监听的句柄均无任何变化，则select会阻塞1秒，之后返回三个空列表，如果监听的句柄有变化，则直接执行。

      由于select()接口可以同时对多个句柄进行读状态、写状态和错误状态的探测，所以可以很容易构建为多个客户端提供独立问答服务的服务器系统。这里需要指出的是，客户端的一个connect()操作，将在服务器端激发一个“可读事件”，所以 select() 也能探测来自客户端的connect()行为。
    上述模型中，最关键的地方是如何动态维护select()的三个参数。程序员需要检查对应的返回值列表，以确定到底哪些句柄发生了事件。所以如果select()发现某句柄捕捉到了“可读事件”，服务器程序应及时做recv()操作，并根据接收到的数据准备好待发送数据，并将对应的句柄值加入句柄序列1，准备下一次的“可写事件”的select()探测。同样，如果select()发现某句柄捕捉到“可写事件”，则程序应及时做send()操作，并准备好下一次的“可读事件”探测准备。

 实例1：利用select监听终端输入

 实例2：利用select监听浏览器访问

执行程序，在浏览器中输入地址：127.0.0.1:6666  

执行结果如下：

('127.0.0.1', 42510)

 实例3：利用select监听多端口

执行程序，在浏览器中分别输入地址：127.0.0.1:6666  127.0.0.1:7777

执行结果如下：

('127.0.0.1', 54509)
('127.0.0.1', 53458)

 实例4：利用select实现伪同时处理多个Socket客户端请求—服务端

 实例4：利用select实现伪同时处理多个Socket客户端请求—客户端

 实例4执行过程分析

 实例5：实例4服务端的优化

    此处的Socket服务端相比与原生的Socket，他支持当某一个请求不再发送数据时，服务器端不会等待而是可以去处理其他请求的数据。但是，如果每个请求的耗时比较长时，select版本的服务器端也无法完成同时操作。

    select参数注解

rlist, wlist, elist = select.select(inputs,[],[],1) 1、第一个参数，监听的句柄序列，当有任一句柄变化时，select就能捕获到并返回赋值给rlist； 2、如果第二参数有值，即只要不是空列表，select就能感知，wlist就能获取第二个参数的值； 3、对于第三个参数，在select内部会检测列表中的描述符在底层执行过程中是否发生异常，如果发生异常，则把发生异常的句柄赋值给elist， 一般第三个参数和第一个参数相同 4、第四个参数是设置阻塞时间，如1秒（这个如果不写，select会阻塞住，直到监听的描述符发生变化才继续往下执行）

    对于I/O多路复用，咱们上面的例子就可以了，但是为了遵循select规范需要把读和写进行分离：

#rlist -- wait until ready for reading #等待直到有读的操作 #wlist -- wait until ready for writing #等待直到有写的操作 #xlist -- wait for an ``exceptional condition'' #等待一个错误的情况

    为了实现读写分离，需要构造一个字典，字典里为每一客户端维护一个队列。收到的信息放到队列里，然后写的时候直接从队列取数据

     2.2 Queue 队列

      队列的特点：

      1、队列是先进先出，栈是相反的，后进先出

      2、队列是线程安全的

 队列取值顺序

 当队列为空时，取值会阻塞

 取值时，get_nowait非阻塞，但无值时会报错

 捕获get_nowait异常

 存放数据时，如果队列已满，也会阻塞

 存放数据时，put_nowait非阻塞，但是队列无法存放时会报错

 利用select和队列实现多客户端读写分离

       使用select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多CPU，同时能够为多客户端提供服务。如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值。但这个模型依旧有着很多问题。首先select()接口并不是实现“事件驱动”的最好选择。因为当需要探测的句柄值较大时，select()接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如linux提供了epoll，BSD提供了queue，Solaris提供了/dev/poll  ...。如果需要实现更高效的服务器程序，类似epoll这样的接口更被推荐。遗憾的是不同的操作系统特供的epoll接口有很大差异，所以使用类似于epoll的接口实现具有较好跨平台能力的服务器程序会比较困难。
       其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的。如下例，庞大的执行体1的将直接导致响应事件2的执行体迟迟得不到执行，并在很大程度上降低了事件探测的及时性。

 

 

参考资料：

    http://www.cnblogs.com/wupeiqi/articles/5040823.html

    http://www.cnblogs.com/luotianshuai/p/5098408.html

    http://www.cnblogs.com/Security-Darren/p/4746230.html