本文的内容是下面几篇文章阅读后的内容摘要:

http://www.kegel.com/c10k.html （英文版）

http://www.oschina.net/translate/c10k （中文翻译版）
http://www.cnblogs.com/fll/archive/2008/05/17/1201540.html

The C10K problem
http://blog.csdn.net/xiao_qiang_/article/details/8960229

千万级并发实现的秘密：内核不是解决方案，而是问题所在！
http://www.csdn.net/article/2013-05-16/2815317-The-Secret-to-10M-Concurrent-Connections 

从 C10K 到 C500K
http://dbanotes.net/arch/c10k_c500k.html

几种解决思路的优缺点

 

 

一个线程或者进程服务于一个客户端（Serve one client with each thread/process, and use blocking I/O ）

 

这种策略很能难足高性能程序的需求，好处是实现极其简单，容易嵌入复杂的交互逻辑。Apache、ftpd等都是这种工作模式。

这样不好的地方在于需要为每个客户端使用一个完整的栈，从而比较浪费内存。 许多操作系统仍在处理数百个线程时存在一定的问题。如果每个线程使用2MB的栈，那么当你在32位的机器上运行 512（2^30 / 2^21=512）个线程时，你就会用光所有的1GB的用户可访问虚拟内存（Linux也是一样运行在x86上的）。 你可以减小每个线程所拥有的栈内存大小，但是由于大部分线程库在一旦线程创建后就不能增大线程栈大小，所以这样做 就意味着你必须使你的程序最小程度地使用内存。当然你也可以把你的程序运行在64位的处理器上去。

 

每个线程服务多个客户端，使用非阻塞I/O和水平触发的就绪通知（Serve many clients with each thread, and use nonblocking I/O and level-triggered readiness notification）

网络句柄设置为非阻塞模型，然后使用select()或poll()来告知哪个句柄已有数据在等待 处理。
注意：牢记内核的就绪通知仅仅只是个提示，当你试图从一个文件描述符读取数据时，该文件描述符可能并没有准备好。这就是为什么需要在使用就绪通知的时候使用非阻塞模型的原因。

 

 

一个线程服务多个客户端，使用非阻塞I/O和就绪改变时通知（Serve many clients with each thread, and use nonblocking I/O and readiness change notification）

 

Readiness change notification（或边缘触发就绪通知）的意思就是当你给内核一个文件描述 符，一段时间后，如果该文件描述符从没有就绪到已经准备就绪，那么内核就会发出通知，告知 该文件描述符已经就绪，并且不会再对该描述符发出类似的就绪通知直到你在描述符上进行一些 操作使得该描述符不再就绪（如直到在send，recv或者accept等调用上遇到EWOULDBLOCK错误，或 者发送/接收了少于需要的字节数）。
当使用Readiness change notification时，必须准备好处理乱真事件，因为最常见的实现是只 要接收到任何数据包都发出就绪信号，而不管文件描述符是否准备就绪。

 

一个服务线程服务多个客户端，使用异步I/O（Serve many clients with each thread, and use asynchronous I/O and completion notification）

 

在标准Unix下，异步I/O是由"aio_"接口 提供的，它把一个信号和值与每一个I/O操作关联起来。信号和其值的队列被有效地分配到用户的 进程上。异步I/O是POSIX 1003.1b实时标准的扩展，也属于Single Unix Specification,version 2.

AIO使用的是边缘触发的完成时通知，例如，当一个操作完成时信号就被加入队列