1、单进程服务器

同一时刻只能为一个客户进行服务， 不能同时为多个客户服务，类似于找一个“明星”签字一样， 客户需要耐心等待才可以获取到服务，当服务器为一个客户端服务时， 若另外的客户端发起了connect请求， 只要服务器listen的队列有空闲的位置， 就会为这个新客户端进行连接， 并且客户端可以发送数据， 但当服务器为这个新客户端服务时， 可能一次性把所有数据接收完毕。当recv接收数据时， 返回值为空， 即没有返回数据， 那么意味着客户端已经调用了close关闭了； 因此服务器通过判断recv接收数据是否为空 来判断客户端是否已经下线。

单进程服务器

多客户端测试

虽然多个客户端几乎同时像单进程服务器发起了链接请求，但单进程服务器却是一次只为一个客户端创建accept，即使设置的最大监听数量是5，在同一时刻，severSock服务器虽然监听到了五个请求，但有四个是在挂起等待处理的。

2、单进程服务器--非阻塞模式

在上面的单进程服务器中，accept的方式是阻塞的，客户端与服务器在进行链接时，有一个三次握手的过程，如果客户端不进行第三次握手，那么服务器就会一直阻塞在这里，等着其进行第三次握手，在单进程的条件下，这就导致了其他挂起的客户端请求迟迟得不到响应，这样以来就十分浪费CPU的资源。这种情况下，将服务器端套接字设置成非阻塞状态就会好很多，不仅可以极大的减少CPU的浪费，而且可以模拟多进行对客户端进行处理。

多客户端测试程序同上

3、单进程服务器select版

多路复用的模型中， 比较常用的有select模型和epoll模型。 这两个都是系统接口， 由操作系统提供。 当然， Python的select模块进行了更高级的封装。网络通信被Unix系统抽象为文件的读写， 通常是一个设备， 由设备驱动程序提供， 驱动可以知道自身的数据是否可用。设备的文件的资源如果可用（ 可读或者可写） 则会通知进程， 反之则会让进程睡眠， 等到数据到来可用的时候， 再唤醒进程。这些设备的文件描述符被放在一个数组中， 然后select调用的时候遍历这个数组， 如果对于的文件描述符可读则会返回该文件描述符。 当遍历结束之后，如果仍然没有一个可读设备文件描述符， select让用户进程则会睡眠， 直到等待资源可用的时候在唤醒， 遍历之前那个监视的数组。 每次遍历都是依次进行判断的。

总结：

优点：select目前几乎在所有的平台上都支持， 其良好跨平台性也是它的一个优点。

缺点：select的一个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024。一般来说这个数量和系统内存关系很大， 具体数目可以cat /proc/sys/fs/filemax察看。 32位机默认是1024个， 64位机默认是2048。对socket进行扫描时是依次扫描的， 即采用轮询的方法， 效率较低。当套接字比较多的时候， 每次select()都要通过遍历FD_SETSIZE个Socket来完成调度， 不管哪个Socket是活跃的， 都遍历一遍，这会浪费很多CPU时间。

4、单进程服务器epoll版

为了改善select版的缺陷，引入了更优化的epoll服务器，epoll版服务器没有最大并发连接的限制， 能打开的FD(指的是文件描述符， 通俗的理解就是套接字对应的数字编号)的上限远大于1024。并且效率也得到了提升，不采用轮询的方式， 不会随着FD数目的增加效率下降。 只有活跃可用的FD才会调用callback函数，即epoll最大的优点就在于它只管“活跃”的连接， 跟连接总数无关， 因此在实际的网络环境中， epoll的效率就会远远高于select和poll。epoll版在Windows下不支持，需要在Linux/Unix运行。

说明：

EPOLLIN （ 可读）；         EPOLLOUT （ 可写）；      EPOLLET （ ET模式）

epoll对文件描述符的操作有两种模式： LT（水平触发） 和ET（ 边沿触发），LT模式是默认模式， LT模式与ET模式的区别如下：

LT模式： 当epoll检测到描述符事件发生并将此事件通知应用程序， 应用程序可不立即处理该事件

ET模式： 当epoll检测到描述符事件发生并将此事件通知应用程序， 应用程序必须立即处理该事件