我们现在已经搞定了 C10K并发连接问题 ，升级一下，如何支持千万级的并发连接？你可能说，这不可能。你说错了，现在的系统可以支持千万级的并发连接，只不过所使用的那些激进的技术，并不为人所熟悉。
要了解这是如何做到的，我们得求助于Errata Security的CEO Robert Graham，看一下他在 Shmoocon 2013 的绝对奇思妙想的演讲，题目是 C10M Defending The Internet At Scale。
Robert以一种我以前从来没有听说过的才华横溢的方式来搭建处理这个问题的架构。他的开场是一些历史，关于Unix最初为什么不是设计成一个通用的服务器的OS，而是为电话网络的控制系统设计的。真正传输数据的是电话网络，因而控制层和数据层有非常清晰的区分。问题是，我们现在用的Unix服务器还是数据层的一部分，虽然并不应当是这样的。如果一台服务器只有一个应用程序，为这样的系统设计内核，与设计一个多用户系统的内核的区别是非常大的。
这也是为什么他说重要的是要理解： 这意味着： - 不要让内核去做所有繁重的调度。把数据包处理，内存管理以及处理器调度从内核移到可以让他更高效执行的应用程序中去。让Linux去处理控制层，数据层由应用程序来处理。
结果就是成为一个用200个时钟周期处理数据包，14万个时钟周期来处理应用程序逻辑，可以处理1000万并发连接的系统。而作为重要的内存访问花费300个时钟周期，这是尽可能减少编码和缓存的设计方法的关键。
用一个面向数据层的系统你可以每秒处理1000万个数据包。用一个面向控制层的系统每秒你只能获得1百万个数据包。
如果这貌似有点极端，记住一句老话：可扩展性是专业化。要做些牛X的事儿，你不能局限于操作系的性能。你必须自己去做。
现在，让我们学习Robert是怎样创作一个能处理1000万并发连接的系统……
C10K的问题——过去十年
十年前，工程师在处理C10K可扩展性问题时，都尽可能的避免服务器处理超过10,000个的并发连接。通过修正操作系统内核以及用事件驱动型服务器（如Nginx和Node）替代线程式的服务器（如Apache）这个问题已经解决。从Apache转移到可扩展的服务器上，人们用了十年的时间。在过去的几年中，（我们看到）可扩展服务器的采用率在大幅增长。
Apache的问题- Apache的问题是，（并发）连接数越多它的性能会越低下。
- 关键问题：（服务器的）性能和可扩展性并不是一码事。它们指的不是同一件事情。当人们谈论规模的时候往往也会谈起性能的事情，但是规模和性能是不可同日而语的。比如Apache。
- 在仅持续几秒的短时连接时，比如快速事务处理，如果每秒要处理1000个事务，那么大约有1000个并发连接到服务器。
- 如果事务增加到10秒，要保持每秒处理1000个事务就必须要开启10K（10000个）的并发连接。这时Apache的性能就会陡降，即使抛开DDos攻击。仅仅是大量的下载就会使Apache宕掉。
- 如果每秒需要处理的并发请求从5,000增加到10,000，你会怎么做?假使你把升级硬件把处理器速度提升为原来的两倍。会是什么情况?你得到了两倍的性能，但是却没有得到两倍的处理规模。处理事务的规模或许仅仅提高到了每秒6,000个（即每秒6000个并发请求）。继续提高处理器速度，还是无济于事。甚至当性能提升到16倍时，并发连接数还不能达到1000个。由此，性能和规模并不是一回事。
- 问题在于Apache总是创建了一个进程然后又把它关闭了。这并不是规模的。
- 为什么?因为内核采用的O(n^2) 算法导致服务器不能处理10K个并发连接。
- 内核中的两个基本问题：
- 连接数 = 线程数/进程数。当一个包（数据包）来临时，它（内核）会遍历所有的10K进程以决定由哪个进程处理这个包。
- 连接数= 选择数/轮询次数（单线程情况下）。同样的扩展性问题。每个包不得不遍历一遍列表中的socket。
- 解决方法：修正内核在规定的时间内进行查找
- 不管有多少线程，线程切换的时间都是恒定的
- 使用一个新的可扩展的epoll()/IOCompletionPort在规定的时间内做socket查询
- 由于线程调度依然没有被扩展，因此服务器对sockt大规模的采用epoll，导致需要使用异步编程模式，然而这正是Node和Nginx所采用的方式。这种软件迁移会得到（和原来）不一样的表现（指从apache迁移到ngix等）。即使在一台很慢（配置较低）的服务器上增加连接数性能也不会陡降。介于此，在开启10K并发连接时，一台笔记本电脑（运行ngix）的速度甚至超越了一台16核的服务器（运行Apache）。
| 
