关于Web服务器底层技术线程阻塞和多路复用的疑问，web多路复用,我记得《unix网络编程

为什么不使用异步IO模型？
1）异步要通过大量的callback，hook函数实现，调试，维护，可读性都是一个很大的挑战，现在还没有很好的工具集来支持异步编程。
2）阻塞io+线程和多路复用已经比较好的解决了高并发问题，成本也不高。
3）异步IO不一定真的异步，比如POSIX AIO(glibc AIO)，性能也不好。详见异步IO应用

我来说下为什么不使用同步非阻塞模型。

由于socket是非阻塞的方式，因此用户线程发起IO请求时立即返回。但并没有读取到任何数据，用户线程需要不断地发起IO请求，知道数据到达后，才真正读取到数据，继续执行。

用户线程使用同步非阻塞IO模型的伪代码描述为：

{    while(read(socketfd, buffer) != SUCCESS)        ...    process(buffer);}

即用户需要不断地调用read，尝试读取socket中的数据，直到读取成功后，才继续处理接收的数据。整个IO请求过程中，虽然用户线程每次发起IO请求后可以立即返回，但是为了等到数据，仍需要不断轮询、重复请求，消耗了大量的CPU的资源。所以一般很少用这种模型。

node是异步io吧
而且确实性能很好

Nginx就是一个异步IO的实现啊， 他有一个大的eventloop所以不允许有任何阻塞的进程 不然会阻塞所有， 在开发一个nginx模块的时候尤其要注意这一点， 这也带来了一些问题 比如全异步的IO会导致程序不宜读，所以后期维护上可能会带来问题 这个时候Lua来了～～

epoll 是 linux 2.6 以后才出现的，所以，Nginx 使用了 epoll 模型。所以，Nginx 处理静态文件或者做反代很强行，因为主要是 IO 操作。

epoll 是 select/poll 的增强版，就是基于事件通知的。

Apache、Tomcat，他们虽然也是 Web 服务器，但是也承担应用服务器的角色，之所以称他们为应用服务器，是因为他们真的要跑具体的业务应用，如科学计算、图形图像、数据库读写等。它们很可能是 CPU 密集型的服务，事件驱动并不合适。

鱼与熊掌不可兼得。事件驱动适合于 IO 密集型服务，多进程或线程适合于 CPU 密集型服务。

再者，根据 TCP、HTTP 协议的特点，大部分服务器都会保留 time_wait 的持久链接。Web 服务器主要是用来处理 HTTP 协议的请求。

没有最完美的，只有更适合的