C10K问题
C10K问题: 一万个客户端同时连接
常识一：文件句柄限制
在linux下每一个tcp连接都要占一个文件描述符，一旦文件描述符使用完了，新的连接到来返回给我们的错误是“Socket/File:Can’t open so many files”。
操作系统可以打开的最大文件数的限制。
1 进程限制
执行 ulimit -n 输出 1024，说明对于一个进程而言最多只能打开1024个文件，所以采用此配置最多可以并发上千个TCP连接。
临时修改：ulimit -n 1000000，但是这种临时修改只对当前登录用户目前的使用环境有效，系统重启或用户退出后就会失效。
重启后失效的修改: （CentOS 6.5下测试，重启后未发现失效），编辑 /etc/security/limits.conf 文件， 修改后内容为：
1 | soft nofile 1000000 |
永久修改：编辑/etc/rc.local，在其后添加如下内容：
1 | ulimit -SHn 1000000 |
2 全局限制
执行cat /proc/sys/fs/file-nr输出9344 0 592026，分别为：
- 已经分配的文件句柄数，
- 已经分配但没有使用的文件句柄数，
- 最大文件句柄数。
但在kernel 2.6版本中第二项的值总为0，这并不是一个错误，它实际上意味着已经分配的文件描述符无一浪费的都已经被使用了。我们可以把这个数值改大些，用 root 权限修改 /etc/sysctl.conf 文件:
- fs.file-max = 1000000
- net.ipv4.ip_conntrack_max = 1000000
- net.ipv4.netfilter.ip_conntrack_max = 1000000
常识二：端口号范围限制？
操作系统上端口号1024以下是系统保留的，从1024-65535是用户使用的。每个TCP连接都要占一个端口号, 但可以创建的最大并发连接不只60000个
如何标识一个TCP连接：
系统用一个4四元组来唯一标识一个TCP连接：{local ip, local port,remote ip,remote port}。
《UNIX网络编程：卷一》第四章中对accept的讲解，第二个参数cliaddr代表了客户端的ip地址和端口号。而服务端实际只使用了bind时这一个端口，说明端口号65535并不是并发量的限制。
server最大tcp连接数：
server通常固定在某个本地端口上监听，等待client的连接请求。不考虑地址重用（unix的SO_REUSEADDR选项）的情况下，即使server端有多个ip，本地监听端口也是独占的，因此server端tcp连接4元组中只有remote ip（也就是client ip）和remote port（客户端port）是可变的，因此最大tcp连接为客户端ip数×客户端port数，对IPV4，不考虑ip地址分类等因素，最大tcp连接数约为2的32次方（ip数）×2的16次方（port数），也就是server端单机最大tcp连接数约为2的48次方。
I/O Model
最初的服务器都是基于进程/线程模型的，一个TCP连接，就需要分配1个进程（或者线程）。而进程又是操作系统最昂贵的资源，一台机器无法创建很多进程。
如果是C10K就要创建1万个进程，那么单机而言操作系统是无法承受的（往往出现效率低下甚至完全瘫痪）。
如果是采用分布式系统，维持1亿用户在线需要10万台服务器，成本巨大，也只有Facebook、Google、雅虎等巨头才有财力购买如此多的服务器。
传统的同步阻塞I/O模型都是一样的，处理的方式都是requests per second，并发10K和100的区别关键在于CPU。
创建的进程线程多了，数据拷贝频繁（缓存I/O、内核将数据拷贝到用户进程空间、阻塞）， 进程/线程上下文切换消耗大， 导致操作系统崩溃，这就是C10K问题的本质！
互联网服务端处理网络请求的原理
典型互联网服务端处理网络请求的典型过程：
由上图可以看到，主要处理步骤包括：
1）获取请求数据，客户端与服务器建立连接发出请求，服务器接受请求（1-3）；
2）构建响应，当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（4）；
3）返回数据，服务器将已构建好的响应再通过内核空间的网络 I/O 发还给客户端（5-7）。
设计服务端并发模型时，主要有如下两个关键点：
1）服务器如何管理连接，获取输入数据；
2）服务器如何处理请求。
“I/O 模型”的基本认识
阻塞调用与非阻塞调用：
- 阻塞调用是指调用结果返回之前，当前线程会被挂起，调用线程只有在得到结果之后才会返回；
- 非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。
两者的最大区别在于被调用方在收到请求到返回结果之前的这段时间内，调用方是否一直在等待。阻塞是指调用方一直在等待而且别的事情什么都不做；非阻塞是指调用方先去忙别的事情。
同步处理与异步处理：
同步处理是指被调用方得到最终结果之后才返回给调用方；异步处理是指被调用方先返回应答，然后再计算调用结果，计算完最终结果后再通知并返回给调用方。
阻塞、非阻塞和同步、异步的区别（阻塞、非阻塞和同步、异步其实针对的对象是不一样的）：
- 1）阻塞、非阻塞的讨论对象是调用者；
- 2）同步、异步的讨论对象是被调用者。
recvfrom 函数：
// FIXME 究竟什么是Socket，操作系统套接字代表的是什么
recvfrom 函数(经 Socket 接收数据)，这里把它视为系统调用。
一个输入操作通常包括两个不同的阶段：
- 1）等待数据准备好；
- 2）从内核向进程复制数据。
对于一个套接字上的输入操作，第一步通常涉及等待数据从网络中到达。当所等待分组到达时，它被复制到内核中的某个缓冲区。第二步就是把数据从内核缓冲区复制到应用进程缓冲区。
实际应用程序在系统调用完成上面的 2 步操作时，调用方式的阻塞、非阻塞，操作系统在处理应用程序请求时，处理方式的同步、异步处理的不同，可以分为 5 种 I/O 模型（下面的章节将逐个展开介绍）。（参考《UNIX网络编程卷1》）
阻塞式 I/O(blocking I/O）
在阻塞式 I/O 模型中，应用程序在从调用 recvfrom 开始到它返回有数据报准备好这段时间是阻塞的，recvfrom 返回成功后，应用进程开始处理数据报。
比喻： 一个人在钓鱼，当没鱼上钩时，就坐在岸边一直等。
优点： 程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源。
缺点： 每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较大，这种模型在实际生产中很少使用。
非阻塞式 I/O (non-blocking I/O）
应用程序把一个套接口设置为非阻塞，就是告诉内核，当所请求的 I/O 操作无法完成时，不要将进程睡眠。
而是返回一个错误，应用程序基于 I/O 操作函数将不断的轮询数据是否已经准备好，如果没有准备好，继续轮询，直到数据准备好为止。
比喻： 边钓鱼边玩手机，隔会再看看有没有鱼上钩，有的话就迅速拉杆。
优点： 不会阻塞在内核的等待数据过程，每次发起的 I/O 请求可以立即返回，不用阻塞等待，实时性较好。
缺点： 轮询将会不断地询问内核，这将占用大量的 CPU 时间，系统资源利用率较低，所以一般 Web 服务器不使用这种 I/O 模型。
I/O 多路复用(I/O multiplexing）
在 I/O 复用模型中，会用到 Select 或 Poll 函数或 Epoll 函数(Linux 2.6 以后的内核开始支持)，这两个函数也会使进程阻塞，但是和阻塞 I/O 有所不同。
这两个函数可以同时阻塞多个 I/O 操作，而且可以同时对多个读操作，多个写操作的 I/O 函数进行检测，直到有数据可读或可写时，才真正调用 I/O 操作函数。
比喻： 放了一堆鱼竿，在岸边一直守着这堆鱼竿，没鱼上钩就玩手机。
优点： 可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程)，这样可以大大节省系统资源。
缺点： 当连接数较少时效率相比多线程+阻塞 I/O 模型效率较低，可能延迟更大，因为单个连接处理需要 2 次系统调用，占用时间会有增加。
众所周之，Nginx这样的高性能互联网反向代理服务器大获成功的关键就是得益于Epoll。
信号驱动式 I/O （signal-driven I/O)
在信号驱动式 I/O 模型中，应用程序使用套接口进行信号驱动 I/O，并安装一个信号处理函数，进程继续运行并不阻塞。
当数据准备好时，进程会收到一个 SIGIO 信号，可以在信号处理函数中调用 I/O 操作函数处理数据。
比喻： 鱼竿上系了个铃铛，当铃铛响，就知道鱼上钩，然后可以专心玩手机。
优点： 线程并没有在等待数据时被阻塞，可以提高资源的利用率。
缺点： 信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知。
信号驱动 I/O 尽管对于处理 UDP 套接字来说有用，即这种信号通知意味着到达一个数据报，或者返回一个异步错误。
但是，对于 TCP 而言，信号驱动的 I/O 方式近乎无用，因为导致这种通知的条件为数众多，每一个来进行判别会消耗很大资源，与前几种方式相比优势尽失。
异步 I/O（即AIO，全称asynchronous I/O）
由 POSIX 规范定义，应用程序告知内核启动某个操作，并让内核在整个操作（包括将数据从内核拷贝到应用程序的缓冲区）完成后通知应用程序。
这种模型与信号驱动模型的主要区别在于：信号驱动 I/O 是由内核通知应用程序何时启动一个 I/O 操作，而异步 I/O 模型是由内核通知应用程序 I/O 操作何时完成。
优点： 异步 I/O 能够充分利用 DMA 特性，让 I/O 操作与计算重叠。
缺点： 要实现真正的异步 I/O，操作系统需要做大量的工作。目前 Windows 下通过 IOCP 实现了真正的异步 I/O。
而在 Linux 系统下，Linux 2.6才引入，目前 AIO 并不完善，因此在 Linux 下实现高并发网络编程时都是以 IO 复用模型模式为主。
关于AOI的介绍，请见：《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》。
5 种 I/O 模型总结
从上图中我们可以看出，越往后，阻塞越少，理论上效率也是最优。
这五种 I/O 模型中，前四种属于同步 I/O，因为其中真正的 I/O 操作(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配。
高性能网络编程中的线程模型
传统阻塞 I/O 服务模型
特点：
1）采用阻塞式 I/O 模型获取输入数据；
2）每个连接都需要独立的线程完成数据输入，业务处理，数据返回的完整操作。
存在问题：
1）当并发数较大时，需要创建大量线程来处理连接，系统资源占用较大；
2）连接建立后，如果当前线程暂时没有数据可读，则线程就阻塞在 Read 操作上，造成线程资源浪费。
Reactor 模式
基本介绍
针对传统阻塞 I/O 服务模型的 2 个缺点，比较常见的有如下解决方案：
1）基于 I/O 复用模型：多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理；
2）基于线程池复用线程资源：不必再为每个连接创建线程，将连接完成后的业务处理任务分配给线程进行处理，一个线程可以处理多个连接的业务。
I/O 复用结合线程池，这就是 Reactor 模式基本设计思想，如下图：
Reactor 模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。
服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor 模式也叫 Dispatcher 模式。即 I/O 多了复用统一监听事件，收到事件后分发(Dispatch 给某进程)，是编写高性能网络服务器的必备技术之一。
Reactor 模式中有 2 个关键组成：
1）Reactor：Reactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对 IO 事件做出反应。 它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人；
2）Handlers：处理程序执行 I/O 事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际官员。Reactor 通过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操作。
根据 Reactor 的数量和处理资源池线程的数量不同，有 3 种典型的实现：
1）单 Reactor 单线程；
2）单 Reactor 多线程；
3）主从 Reactor 多线程。
下面详细介绍这 3 种实现方式。
单 Reactor 单线程
其中，Select 是前面 I/O 复用模型介绍的标准网络编程 API，可以实现应用程序通过一个阻塞对象监听多路连接请求，其他方案示意图类似。
方案说明：
1）Reactor 对象通过 Select 监控客户端请求事件，收到事件后通过 Dispatch 进行分发；
2）如果是建立连接请求事件，则由 Acceptor 通过 Accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后的后续业务处理；
3）如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应；
4）Handler 会完成 Read→业务处理→Send 的完整业务流程。
优点：
模型简单，没有多线程、进程通信、竞争的问题，全部都在一个线程中完成。
缺点：
性能问题，只有一个线程，无法完全发挥多核 CPU 的性能。Handler 在处理某个连接上的业务时，整个进程无法处理其他连接事件，很容易导致性能瓶颈。
可靠性问题，线程意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。
使用场景：
客户端的数量有限，业务处理非常快速，比如 Redis，业务处理的时间复杂度 O(1)。
单 Reactor 多线程
方案说明：
- 1）Reactor 对象通过 Select 监控客户端请求事件，收到事件后通过 Dispatch 进行分发；
- 2）如果是建立连接请求事件，则由 Acceptor 通过 Accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后续的各种事件；
- 3）如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应；
- 4）Handler 只负责响应事件，不做具体业务处理，通过 Read 读取数据后，会分发给后面的 Worker 线程池进行业务处理；
- 5）Worker 线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给 Handler 进行处理；
- 6）Handler 收到响应结果后通过 Send 将响应结果返回给 Client。
优点：
可以充分利用多核 CPU 的处理能力。
缺点：
多线程数据共享和访问比较复杂；Reactor 承担所有事件的监听和响应，在单线程中运行，高并发场景下容易成为性能瓶颈。
主从 Reactor 多线程
针对单 Reactor 多线程模型中，Reactor 在单线程中运行，高并发场景下容易成为性能瓶颈，可以让 Reactor 在多线程中运行。
方案说明：
- 1）Reactor 主线程 MainReactor 对象通过 Select 监控建立连接事件，收到事件后通过 Acceptor 接收，处理建立连接事件；
- 2）Acceptor 处理建立连接事件后，MainReactor 将连接分配 Reactor 子线程给 SubReactor 进行处理；
- 3）SubReactor 将连接加入连接队列进行监听，并创建一个 Handler 用于处理各种连接事件；
- 4）当有新的事件发生时，SubReactor 会调用连接对应的 Handler 进行响应；
- 5）Handler 通过 Read 读取数据后，会分发给后面的 Worker 线程池进行业务处理；
- 6）Worker 线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给 Handler 进行处理；
- 7）Handler 收到响应结果后通过 Send 将响应结果返回给 Client。
优点：
父线程与子线程的数据交互简单职责明确，父线程只需要接收新连接，子线程完成后续的业务处理。
父线程与子线程的数据交互简单，Reactor 主线程只需要把新连接传给子线程，子线程无需返回数据。
这种模型在许多项目中广泛使用，包括 Nginx 主从 Reactor 多进程模型，Memcached 主从多线程，Netty 主从多线程模型的支持。
小结
3 种模式可以用个比喻来理解：
（餐厅常常雇佣接待员负责迎接顾客，当顾客入坐后，侍应生专门为这张桌子服务）
- 1）单 Reactor 单线程，接待员和侍应生是同一个人，全程为顾客服务；
- 2）单 Reactor 多线程，1 个接待员，多个侍应生，接待员只负责接待；
- 3）主从 Reactor 多线程，多个接待员，多个侍应生。
Reactor 模式具有如下的优点：
- 1）响应快，不必为单个同步时间所阻塞，虽然 Reactor 本身依然是同步的；
- 2）编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
- 3）可扩展性，可以方便的通过增加 Reactor 实例个数来充分利用 CPU 资源；
- 4）可复用性，Reactor 模型本身与具体事件处理逻辑无关，具有很高的复用性。
Proactor 模型
在 Reactor 模式中，Reactor 等待某个事件或者可应用或者操作的状态发生（比如文件描述符可读写，或者是 Socket 可读写）。 然后把这个事件传给事先注册的 Handler（事件处理函数或者回调函数），由后者来做实际的读写操作。其中的读写操作都需要应用程序同步操作，所以 Reactor 是非阻塞同步网络模型。
如果把 I/O 操作改为异步，即交给操作系统来完成就能进一步提升性能，这就是异步网络模型 Proactor。
Proactor 是和异步 I/O 相关的，详细方案如下：
1）Proactor Initiator 创建 Proactor 和 Handler 对象，并将 Proactor 和 Handler 都通过 AsyOptProcessor（Asynchronous Operation Processor）注册到内核；
2）AsyOptProcessor 处理注册请求，并处理 I/O 操作；
3）AsyOptProcessor 完成 I/O 操作后通知 Proactor；
4）Proactor 根据不同的事件类型回调不同的 Handler 进行业务处理；
5）Handler 完成业务处理。
可以看出 Proactor 和 Reactor 的区别：
1）Reactor 是在事件发生时就通知事先注册的事件（读写在应用程序线程中处理完成）；
2）Proactor 是在事件发生时基于异步 I/O 完成读写操作（由内核完成），待 I/O 操作完成后才回调应用程序的处理器来进行业务处理。
理论上 Proactor 比 Reactor 效率更高，异步 I/O 更加充分发挥 DMA(Direct Memory Access，直接内存存取)的优势。
但是Proactor有如下缺点：
1）编程复杂性，由于异步操作流程的事件的初始化和事件完成在时间和空间上都是相互分离的，因此开发异步应用程序更加复杂。应用程序还可能因为反向的流控而变得更加难以 Debug；
2）内存使用，缓冲区在读或写操作的时间段内必须保持住，可能造成持续的不确定性，并且每个并发操作都要求有独立的缓存，相比 Reactor 模式，在 Socket 已经准备好读或写前，是不要求开辟缓存的；
3）操作系统支持，Windows 下通过 IOCP 实现了真正的异步 I/O，而在 Linux 系统下，Linux 2.6 才引入，目前异步 I/O 还不完善。
因此在 Linux 下实现高并发网络编程都是以 Reactor 模型为主。