比较传统的服务端程序（PHP、FAST CGI等），大多都是通过每产生一个请求，都会有一个进程与之相对应，请求处理完毕后相关进程自动释放。由于进程创建、销毁对资源占用比较高，所以很多语言都通过常驻进程、线程等方式降低资源开销。即使是资源占用最小的线程，当并发数量超过1k的时候，操作系统的处理能力就开始出现明显下降，因为有太多的CPU时间都消耗在系统上下文切换。
由此催生了c10k编程，指的是服务器同时支持成千上万个连接，也就是concurrent 10 000 connection（这也是c10k这个名字的由来）。由于硬件成本的大幅度降低和硬件技术的进步，加上一台服务器同时能够服务更多的客户端，就意味着服务每一个客户端的成本大幅度降低，从这个角度来看，c10k问题显得非常有意义。
理想情况下，具备c10k能力的服务端处理能力是c1k的十倍，返回来说我们可以减少90%的服务器资源，多么诱人的结果。
c10k解决了这几个主要问题：
c10k编程的世界，一定是异步编程的世界，他俩绝对是一对儿好基友。服务端一直都不缺乏新秀，各种语言、框架层出不穷。笔者了解的就有OpenResty，Golang，Node.js，Rust，Python(gevent)等。每个语言或解决方案，都有自己完全不同的定位和表现，甚至设计哲学。但是他们从系统底层API应用、基本结构，都是相差不大。这些语言自身的实现机理、运行方式可能差别很大，但只要没有严重的代码错误，他们的性能指标都应该是在同一个级别的。
如果你用了这些解决方案，发现自己的性能非常低，就要好好看看自己是不是姿势有问题。
c1k --> c10k --> c100k --> ???
人类前进的步伐，没有尽头的，总是在不停的往前跑。c10k的问题，早就被解决，而且方法还不止一个。目前方案优化手段给力，做到c100k也是可以达到的。后面还有世界么？我们还能走么？
告诉你肯定是有的，那就是c10m。推荐大家了解一下dpdk这个项目，并搜索一些相关领域的知识。要做到c10m，可以说系统网络内核、内存管理，都成为瓶颈了。所以要揭竿起义，统统推到重来。直接操作网卡绕过内核对网络的封装，直接使用用户态内存，再次绕过系统内核。
c10m这个动作比较大，而且还需要特定的硬件型号支持（主要是网卡，网络处理嘛），所以目前这个项目进展还比较缓慢。不过对于有追求的人，可能就要两眼放光了。
前些日子dpdk组织国内CDN厂商开了一个小会，阿里的朋友说已经用这个开发出了c10m级别的产品。小伙伴们，你们怎么看？心动了，行动不？