9、Linux 高并发Web服务器项目实战（附代码下载地址）-编程学习网

在Linux下进行网络编程时，服务器端编程经常需要构造高性能的IO模型，常见的IO模型有五种：

同步阻塞式 I/O（BIO, Blocking IO）：
在调用该类I/O函数读取数据时，直到读取数据完毕才会返回，否则进程/线程就阻塞到当前函数，如果数据一直没有处理好，当前进程/线程一直处于阻塞状态。
同步非阻塞式I/O（Non-blocking IO, NIO）：
非阻塞等待，每隔一段时间就去检测IO事件是否就绪。非阻塞I/O执行系统调用总是立即返回，由业务上层根据返回的信息自行决定是继续等待数据还是处理其他的事情；若事件没有发生，则返回-1，此时可以根据 errno 区分这两种情况，对于accept，recv 和 send，事件未发生时，errno 通常被设置成 EAGAIN。
I/O多路复用（IO Multiplexing）：
Linux 用 select/poll/epoll 函数实现 IO 复用模型，这些函数也会使进程阻塞（可以设置非阻塞），但是和阻塞IO所不同的是这些函数可以同时阻塞多个IO操作。而且可以同时对多个读操作、写操作的 IO 函数进行检测。直到有数据可读或可写时，才真正调用 IO 操作函数。（用来检测多个事件，处理高并发还得用多线程/进程）
信号驱动式I/O（signal driven IO）：
这类IO其实是利用信号机制，当内核发现数据已经准备好了的时候，通过SIGIO 信号去“激活”相应的信号处理程序，由信号处理程序来进行数据的读取，这也是一个非阻塞的 I/O；
内核在第一个阶段是异步，在第二个阶段是同步；与非阻塞IO的区别在于它提供了消息通知机制，不需要用户进程不断的轮询检查，减少了系统API的调用次数，提高了效率。
异步I/O（Asynchronous IO, AIO）：
之前的信号驱动式I/O是内核告诉应用程序“数据已经准备好了，可以开始读取，Over”；而异步I/O则是更进一步——它直接说：“数据已经读取完毕了，Over。”
Linux中，可以调用 aio_read 函数告诉内核描述字缓冲区指针和缓冲区的大小、文件偏移及通知的方式，然后立即返回，当内核将数据拷贝到缓冲区后，再通知应用程序。

一个 Web Server 就是一个服务器软件（程序），或者是运行这个服务器软件的硬件（计算机）。其主要功能是通过 HTTP 协议与客户端（通常是浏览器 Browser）进行通信，来接收、存储、处理来自客户端的 HTTP 请求，并对其请求做出 HTTP 响应，返回给客户端其请求的内容（文件、网页等）或返回一个 Error 信息。

通常用户使用 Web 浏览器与相应服务器进行通信。在浏览器中键入“域名” 或 “ IP地址 : 端口号”，浏览器则先将你的域名解析成相应的 IP 地址或者直接根据你的IP地址向对应的 Web 服务器发送一个 HTTP 请求。这一过程首先要通过 TCP 协议的三次握手建立与目标 Web 服务器的连接，然后 HTTP 协议生成针对目标 Web 服务器的 HTTP 请求报文，通过 TCP、IP 等协议发送到目标 Web 服务器上。

3.1 概述

超文本传输协议（Hypertext Transfer Protocol，HTTP）是一个简单的请求 - 响应（Request - Response）协议，它通常运行在 TCP 之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以 ASCII 形式给出；而消息内容则具有一个类似 MIME 的格式。HTTP是万维网（WWW，World Wide Web）的数据通信的基础。

HTTP 是一个客户端终端（用户）和服务器端（网站）请求和应答的标准。通过使用网页浏览器、网络爬虫或者其它的工具，客户端发起一个HTTP请求到服务器上指定端口（默认端口 80）。我们称这个客户端为用户代理程序（user agent）。应答的服务器上存储着一些资源，比如 HTML 文件和图像。我们称这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个“中间层”，比如代理服务器、网关或者隧道（tunnel）。

尽管 TCP/IP 协议是互联网上最流行的应用，HTTP 协议中，并没有规定必须使用它或它支持的层。事实上，HTTP可以在任何互联网协议上，或其他网络上实现。HTTP 假定其下层协议提供可靠的传输。因此，任何能够提供这种保证的协议都可以被其使用。因此也就是其在 TCP/IP 协议族使用 TCP 作为其传输层。

通常，由HTTP客户端发起一个请求，创建一个到服务器指定端口（默认是80端口）的 TCP 连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如"HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误消息、或者其它信息。

3.2 工作原理

HTTP 协议定义 Web 客户端如何从 Web 服务器请求 Web 页面，以及服务器如何把 Web 页面传送给客户端。HTTP 协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

HTTP 请求/响应的步骤：

0. IP 地址解析
浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址

1. 客户端连接到 Web 服务器
一个 HTTP 客户端，通常是浏览器，与 Web 服务器的 HTTP 端口（默认为 80 ）建立一个 TCP 套接字连接。例如，http://www.baidu.com。（URL）

2. 发送 HTTP 请求
通过 TCP 套接字，客户端向 Web 服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据 4 部分组成。（请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器）

3. 服务器接受请求并返回 HTTP 响应
Web 服务器解析请求，定位请求资源。服务器将资源复本写到 TCP 套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据 4 部分组成。

4. 释放连接 TCP 连接
若 connection 模式为 close，则服务器主动关闭 TCP连接，客户端被动关闭连接，释放 TCP 连接；若connection 模式为 keep-alive，则该连接会保持一段时间，在该时间内可以继续接收请求。

5. 客户端浏览器解析 HTML 内容
客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的 HTML 文档和文档的字符集。客户端浏览器读取响应数据 HTML，根据HTML 的语法对其进行格式化，并在浏览器窗口中显示。

3.3 请求 / 响应报文格式

HTTP/1.1 协议中共定义了八种请求方法（也叫“动作”）来以不同方式操作指定的资源：

1. GET：
向指定的资源发出“显示”请求。使用 GET 方法应该只用在读取数据，而不应当被用于产生“副作用”的操作中，例如在 Web Application 中。其中一个原因是 GET 可能会被网络蜘蛛等随意访问。

2. HEAD：
与 GET 方法一样，都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部分。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中“关于该资源的信息”（元信息或称元数据）。

3. POST：
向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源，或二者皆有。

4. PUT：向指定资源位置上传其最新内容。

5. DELETE：请求服务器删除 Request-URI 所标识的资源。

6. TRACE：回显服务器收到的请求，主要用于测试或诊断。

7. OPTIONS：
这个方法可使服务器传回该资源所支持的所有 HTTP 请求方法。用'*'来代替资源名称，向 Web 服务器发送 OPTIONS 请求，可以测试服务器功能是否正常运作。

8. CONNECT：
HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的 HTTP 代理服务器）。

所有HTTP响应的第一行都是状态行，由 HTTP版本号、3位数字组成的状态代码、以及描述状态
的短语组成，彼此由空格分隔。

状态代码的第一个数字代表当前响应的类型：

虽然 RFC 2616 中已经推荐了描述状态的短语，例如"200 OK"，"404 Not Found"，但是WEB开发者仍然能够自行决定采用何种短语，用以显示本地化的状态描述或者自定义信息。

模块	功能
I/O 处理单元	处理客户连接，读写网络数据
逻辑单元	业务进程或线程
网络存储单元	数据库、文件或缓存
请求队列	各单元之间的通信方式

I/O 处理单元是服务器管理客户连接的模块。它通常要完成以下工作：等待并接受新的客户连接，接收客户数据，将服务器响应数据返回给客户端。但是数据的收发不一定在 I/O 处理单元中执行，也可能在逻辑单元中执行，具体在何处执行取决于事件处理模式。

一个逻辑单元通常是一个进程或线程。它分析并处理客户数据，然后将结果传递给 I/O 处理单元或者直接发送给客户端（具体使用哪种方式取决于事件处理模式）。服务器通常拥有多个逻辑单元，以实现对多个客户任务的并发处理。

网络存储单元可以是数据库、缓存和文件，但不是必须的。

请求队列是各单元之间的通信方式的抽象。I/O 处理单元接收到客户请求时，需要以某种方式通知一个逻辑单元来处理该请求。同样，多个逻辑单元同时访问一个存储单元时，也需要采用某种机制来协调处理竞态条件。请求队列通常被实现为池（进程池 / 线程池）的一部分。

服务器程序通常需要处理三类事件：I/O 事件、信号及定时事件。

有两种高效的事件处理模式：Reactor 和 Proactor，
同步 I/O 模型通常用于实现 Reactor 模式，
异步 I/O 模型通常用于实现 Proactor 模式。

5.1 Reactor 模式

Reactor 模式要求主线程（I/O处理单元）只负责监听文件描述符上是否有事件发生，有的话就立即将该事件通知工作线程（逻辑单元），将 socket 可读可写事件放入请求队列，交给工作线程处理。除此之外，主线程不做任何其他实质性的工作。读写数据、接受新的连接、以及处理客户请求均在工作线程中完成。

使用同步 I/O（以 epoll_wait 为例）实现的 Reactor 模式的工作流程是：
1. 主线程往 epoll 内核事件表中注册 socket 上的读就绪事件。
2. 主线程调用 epoll_wait 等待 socket 上有数据可读。
3. 当 socket 上有数据可读时， epoll_wait 通知主线程。主线程则将 socket 可读事件放入请求队列。
4. 睡眠在请求队列上的某个工作线程被唤醒，它从 socket 读取数据，并处理客户请求，然后往 epoll内核事件表中注册该 socket 上的写就绪事件。
5. 当主线程调用 epoll_wait 等待 socket 可写。
6. 当 socket 可写时，epoll_wait 通知主线程。主线程将 socket 可写事件放入请求队列。
7. 睡眠在请求队列上的某个工作线程被唤醒，它往 socket 上写入服务器处理客户请求的结果。

5.2 Proactor模式

Proactor 模式将所有 I/O 操作都交给主线程和内核来处理（进行读、写），工作线程仅仅负责业务逻辑。使用异步 I/O 模型（以 aio_read 和 aio_write 为例）实现的 Proactor 模式的工作流程是：

1. 主线程调用 aio_read 函数向内核注册 socket 上的读完成事件，并告诉内核用户读缓冲区的位置，以及读操作完成时如何通知应用程序（这里以信号为例）。
2. 主线程继续处理其他逻辑。
3. 当 socket 上的数据被读入用户缓冲区后，内核将向应用程序发送一个信号，以通知应用程序数据已经可用。
4. 应用程序预先定义好的信号处理函数选择一个工作线程来处理客户请求。工作线程处理完客户请求后，调用 aio_write 函数向内核注册 socket 上的写完成事件，并告诉内核用户写缓冲区的位置，以及写操作完成时如何通知应用程序。
5. 主线程继续处理其他逻辑。
6. 当用户缓冲区的数据被写入 socket 之后，内核将向应用程序发送一个信号，以通知应用程序数据已经发送完毕。
7. 应用程序预先定义好的信号处理函数选择一个工作线程来做善后处理，比如决定是否关闭socket。

5.3 模拟 Proactor 模式

使用同步 I/O 方式模拟 Proactor 模式。

原理是：主线程执行数据读写操作，读写完成之后，主线程向工作线程通知这一”完成事件“。那么从工作线程的角度来看，它们就直接获得了数据读写的结果，接下来要做的只是对读写的结果进行逻辑处理。

使用同步 I/O 模型（以 epoll_wait 为例）模拟出的 Proactor 模式的工作流程如下：

1. 主线程往 epoll 内核事件表中注册 socket 上的读就绪事件。
2. 主线程调用 epoll_wait 等待 socket 上有数据可读。
3. 当 socket 上有数据可读时，epoll_wait 通知主线程。主线程从 socket 循环读取数据，直到没有更多数据可读，然后将读取到的数据封装成一个请求对象并插入请求队列。
4. 睡眠在请求队列上的某个工作线程被唤醒，它获得请求对象并处理客户请求，然后往 epoll 内核事件表中注册 socket 上的写就绪事件。
5. 主线程调用 epoll_wait 等待 socket 可写。
6. 当 socket 可写时，epoll_wait 通知主线程。主线程往 socket 上写入服务器处理客户请求的结果。

在面向对象编程中，创建和销毁对象是很费时间的，因为创建一个对象要获取内存资源或者其它更多资源。所以提高服务程序效率的一个手段就是尽可能减少创建和销毁对象的次数，特别是一些很耗资源的对象创建和销毁。如何利用已有对象来服务就是一个需要解决的关键问题，其实这就是一些 "池化资源"技术 产生的原因，线程池为线程生命周期开销问题和资源不足问题提供了解决方案。

线程池维护着多个线程，等待着监督管理者分配可并发执行的任务。这避免了在处理短时间任务时创建与销毁线程的代价。线程池不仅能够保证内核的充分利用，还能防止过分调度。

线程池是由服务器预先创建的一组子线程，线程池中的线程数量应该和 CPU 数量差不多。线程池中的所有子线程都运行着相同的代码。当有新的任务到来时，主线程将通过某种方式选择线程池中的某一个子线程来为之服务。相比与动态的创建子线程，选择一个已经存在的子线程的代价显然要小得多。至于主线程选择哪个子线程来为新任务服务，则有多种方式：

主线程使用某种算法来主动选择子线程。最简单、最常用的算法是随机算法和 Round Robin（轮流选取）算法，但更优秀、更智能的算法将使任务在各个工作线程中更均匀地分配，从而减轻服务器的整体压力。
主线程和所有子线程通过一个共享的工作队列来同步，子线程都睡眠在该工作队列上。当有新的任务到来时，主线程将任务添加到工作队列中。这将唤醒正在等待任务的子线程，不过只有一个子线程将获得新任务的”接管权“，它可以从工作队列中取出任务并执行之，而其他子线程将继续睡眠在工作队列上。

创建线程池时可以设置线程池的最大线程数和最小线程数；
当任务队列当中没有任务时，线程池阻塞在条件变量上，等待任务；
当有任务进来时，条件变量发信号或者广播，唤醒线程，此时对任务队列而言属于共享资源，需要使用互斥量，避免资源冲突。

线程池的伸缩性对性能有较大的影响。
1、创建太多线程，将会浪费一定的资源，有些线程未被充分使用。
2、销毁太多线程，将导致之后浪费时间再次创建它们。
3、创建线程太慢，将会导致长时间的等待，性能变差。
4、销毁线程太慢，导致其它线程资源饥饿。

线程池的主要组成部分：
1、线程池管理器（ThreadPoolManager）：用于创建并管理线程池；
2、工作线程（WorkThread）：线程池中线程；
3、任务接口（Task）：每个任务必须实现的接口，以供工作线程调度任务的执行；
4、任务队列：用于存放没有处理的任务。提供一种缓冲机制。

线程池的应用场景：
1、需要大量的线程来完成任务，且完成任务的时间比较短；
2、对性能要求苛刻的应用；
3、接受突发性的大量请求，但不至于使服务器因此产生大量线程的应用。

线程池中的线程数量最直接的限制因素是中央处理器(CPU)的处理器(processors/cores)的数量 N：如果你的CPU是4-cores的，对于CPU密集型的任务(如视频剪辑等消耗CPU计算资源的任务)来说，那线程池中的线程数量最好也设置为4（或者+1防止其他因素造成的线程阻塞）；对于IO密集型的任务，一般要多于CPU的核数，因为线程间竞争的不是CPU的计算资源而是IO，IO的处理一般较慢，多于cores数的线程将为CPU争取更多的任务，不至在线程处理IO的过程造成CPU空闲导致资源浪费。

空间换时间，浪费服务器的硬件资源，换取运行效率。
池是一组资源的集合，这组资源在服务器启动之初就被完全创建好并初始化，这称为静态资源。
当服务器进入正式运行阶段，开始处理客户请求的时候，如果它需要相关的资源，可以直接从池中获取，无需动态分配。
当服务器处理完一个客户连接后，可以把相关的资源放回池中，无需执行系统调用释放资源。

逻辑单元内部的一种高效编程方法：有限状态机（finite state machine）。

有的应用层协议头部包含数据包类型字段，每种类型可以映射为逻辑单元的一种执行状态，服务器可以根据它来编写相应的处理逻辑。如下是一种状态独立的有限状态机：

STATE_MACHINE( Package _pack ){    PackageType _type = _pack.GetType();    switch( _type )    {    case type_A:         // 状态A            process_package_A( _pack );            break;    case type_B:         // 状态B            process_package_B( _pack );            break;    }}

这是一个简单的有限状态机，只不过该状态机的每个状态都是相互独立的，即状态之间没有相互转移。状态之间的转移是需要状态机内部驱动，如下代码：

STATE_MACHINE(){    State cur_State = type_A;    while( cur_State != type_C )    // 停止状态    {        Package _pack = getNewPackage();        switch( cur_State )        {            case type_A:    // 状态A处理 -> 状态B                    process_package_state_A( _pack );                    cur_State = type_B;    // 状态转换                    break;            case type_B:    // 状态B处理 -> 状态C                        process_package_state_B( _pack );                    cur_State = type_C;    // 状态转换                    break;        }    }}

该状态机包含三种状态：type_A、type_B 和 type_C，其中 type_A 是状态机的开始状态，type_C 是状态机的结束状态。状态机的当前状态记录在 cur_State 变量中。在一趟循环过程中，状态机先通过 getNewPackage 方法获得一个新的数据包，然后根据 cur_State 变量的值判断如何处理该数据包。数据包处理完之后，状态机通过给 cur_State 变量传递目标状态值来实现状态转移。那么当状态机进入下一趟循环时，它将执行新的状态对应的逻辑。

即使可以使用 ET 模式，一个 socket 上的某个事件还是可能被触发多次。这在并发程序中就会引起一个问题。比如一个线程在读取完某个 socket 上的数据后开始处理这些数据，而在数据的处理过程中该 socket 上又有新数据可读（EPOLLIN 再次被触发），此时另外一个线程被唤醒来读取这些新的数据。于是就出现了两个线程同时操作一个 socket 的局面。一个 socket 连接在任一时刻都只被一个线程处理，可以使用 epoll 的 EPOLLONESHOT 事件实现。

对于注册了 EPOLLONESHOT 事件的文件描述符，操作系统最多触发其上注册的一个可读、可写或者异常事件，且只触发一次，除非我们使用 epoll_ctl 函数重置该文件描述符上注册的 EPOLLONESHOT 事件。

这样，当一个线程在处理某个 socket 时，其他线程是不可能有机会操作该 socket 的。但反过来思考，注册了 EPOLLONESHOT 事件的 socket 一旦被某个线程处理完毕，该线程就应该立即重置这个 socket 上的 EPOLLONESHOT 事件，以确保这个 socket 下一次可读时，其 EPOLLIN 事件能被触发，进而让其他工作线程有机会继续处理这个 socket。

Webbench 是 Linux 上一款知名的、优秀的 web 性能压力测试工具。它是由Lionbridge公司开发。

测试处在相同硬件上，不同服务的性能以及不同硬件上同一个服务的运行状况。
展示服务器的两项内容：每秒钟响应请求数和每秒钟传输数据量。

基本原理：Webbench 首先 fork 出多个子进程，每个子进程都循环做 web 访问测试。子进程把访问的结果通过pipe 告诉父进程，父进程做最终的统计结果。

webbench -c 1000 -t 30 http://192.168.15.128:9999/index.html参数：    -c 表示客户端数    -t 表示时间

11.1 SIGPIPE

在网络编程中，SIGPIPE 这个信号是很常见的。（参考链接）

当往一个写端关闭的管道或 socket 连接中连续（第二次）写入数据时会引发 SIGPIPE 信号，引发 SIGPIPE 信号的写操作将设置 errno 为 EPIPE。

在TCP通信中，当通信的双方中的一方关闭了连接时，若另一方接着发数据，根据TCP协议的规定，会收到一个 RST 响应报文，若再往这个服务器发送数据时，系统会发出一个 SIGPIPE 信号给进程，告诉进程这个连接已经断开了，不能再写入数据。

SIGPIPE 信号的默认行为是结束进程，而我们绝对不希望因为写操作的错误而导致程序退出，尤其是作为服务器程序来说就更恶劣了。所以我们应该对这种信号加以处理，在这里，介绍两种处理SIGPIPE信号的方式：

给SIGPIPE设置 SIG_IGN 信号处理函数，忽略该信号

signal(SIGPIPE, SIG_IGN);

引发 SIGPIPE 信号的写操作将设置 errno 为 EPIPE。
所以，第二次往关闭的 socket 中写入数据时, 会返回 -1, 同时 errno 置为 EPIPE。这样，便能知道对端已经关闭，然后进行相应处理，而不会导致整个进程退出。

使用 send 函数的 MSG_NOSIGNAL 标志来禁止写操作触发 SIGPIPE 信号

send(sockfd , buf , size , MSG_NOSIGNAL);

同样，我们可以根据 send 函数反馈的 errno 来判断 socket 的读端是否已经关闭。

此外，我们也可以通过 IO 复用函数来检测管道和 socket 连接的读端是否已经关闭。以 poll 为例，当 socket 连接被对方关闭时，socket 上的 POLLRDHUP 事件将被触发。

11.2 系统中断、EINTR 与 SA_RESTART

慢系统调用就是会阻塞的函数调用，一般是IO调用或有锁的函数。如 accept, read, wait, sem_timedwait 等，这些函数可以会阻塞当前进程一段时间，所以"慢"。（参考链接）

在阻塞的这段时间里，进程可能会收到内核的一些信号，这些信号优先级高，需要优先处理的，不能等这些调用完成后才处理信号。于是系统先去处理信号，然后强制这些函数以出错的形式返回，其错误码 errno 就是 EINTR，相应的错误描述为“Interrupted system call”。这整个过程就是系统中断。

为了避免正常的信号导致程序的意外停止，我们需要对这些信号进行处理，常见的方法有：

人为重启被中断的系统调用（最可靠有效）

一些 IO 系统调用执行时，如 read 等待输入期间，如果收到一个信号，系统将中断 read，转而执行信号处理函数。处理函数返回后，原系统调用失败，并返回 -1，同时设置 errno 为 EINTR。中断了的系统调用是没有完成的调用，它的失败是临时性的，如果再次调用则可能成功，这并不是真正的失败，所以要对这种情况进行处理：

while(!stop){    int num = epoll_wait(epoll_fd, events, MAX_EVENT_SIZE, -1);     // 阻塞，返回事件数量    if(num < 0 && errno != EINTR){        // 这里忽略了返回的EINTR错误号，并往下执行        EMlog(LOGLEVEL_ERROR,"EPOLL failed.\n");        break;    }    ....}

安装信号时设置 SA_RESTART属性

从信号的角度来解决这个问题，安装信号的时候，设置 SA_RESTART 属性，那么当信号处理函数返回后， 不会让系统调用返回失败，而是让被该信号中断的系统调用将自动恢复。

举例：
闹钟信号 SIGALRM 中断 read 系统调用。安装 SIGALRM 信号时如果不设置SA_RESTART属性，信号会中断 read 系统过调用。如果设置了SA_RESTART属性，read 就能够自己恢复系统调用，不会产生 EINTR 错误。

struct sigaction action;action.sa_handler = handler_func;sigemptyset(&action.sa_mask);action.sa_flags = 0;action.sa_flags |= SA_RESTART;sigaction(SIGALRM, &action, NULL);

但注意，并不是所有的系统调用都可以自动恢复。如 msgsnd / msgrcv 以 block 方式发送/接收消息时，会因为进程收到了信号而中断。此时 msgsnd/msgrcv 将返回-1，errno被设置为 EINTR。且即使在插入信号时设置了 SA_RESTART，也无效。

忽略信号

在安装信号时，明确告诉系统不会产生该信号的中断。

struct sigaction action;action.sa_handler = SIG_IGN;sigemptyset(&action.sa_mask);sigaction(SIGALRM, &action, NULL);

11.3 EAGAIN

EAGAIN 错误码，从字面上来看，是提示再试一次。

这个错误经常出现在当应用程序进行一些非阻塞(non-blocking)操作(对文件或 socket )的时候。对非阻塞 socket 而言，EAGAIN 不是一种错误。在VxWorks和Windows上，EAGAIN 的名字叫做 EWOULDBLOCK。

// 接收一个socket连接int cfd = accept(lfd, (struct sockaddr *)&cliaddr, &len);// 设置非阻塞int flag = fcntl(cfd, F_GETFL);flag |= O_NONBLOCK;fcntl(cfd, F_SETFL, flag);

例如，以 O_NONBLOCK 的标志打开文件/socket/FIFO，如果你连续做 read 操作而没有数据可读。此时程序不会阻塞起来等待数据准备就绪返回，read 函数会返回-1，并设置 errno 为 EAGAIN，提示你的应用程序现在没有数据可读，请稍后再试。

解决办法：

对返回的结果和对应的 errno 进行判断，当数据读完时则跳过，将 socket 加入 epoll 的可读事件监听。

// 添加epoll节点，设置边沿触发epev.events = EPOLLIN | EPOLLET;    epev.data.fd = cfd;epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, &epev);while((len = read(curfd, buf, sizeof(buf))) > 0 ){  // 循环读完所有数据    printf("recv data : %s\n", buf);    write(curfd, buf, len);}if(len == -1) {    if(errno == EAGAIN) {       // socket为非阻塞且数据被读完时，会返回EAGAIN错误号        printf("data over...\n");    }else {        perror("read");        exit(-1);    }} else if(len == 0) {    printf("client closed...\n");    epoll_ctl(epfd, EPOLL_CTL_DEL, curfd, NULL);    close(curfd);}

例如，当应用程序在 socket 中设置 O_NONBLOCK 属性后，如果发送缓存被占满，send 就会返回EAGAIN 错误。

如果当 send 函数出现EAGAIN错误的时候，直到当前socket状态变成可写之前，不应该继续调用send函数发送数据。在发送数据之前，将socket的监听的事件增加 EPOLLOUT，在数据全部发送之后，再取消 EPOLLOUT 的监听。

或者当要开始向 socket 发送数据时，先将数据压入发送缓存区，并且将 socket 加入可写事件监听。当socket触发可写事件（EPOLLOUT）时，调用 socket_send函数发送数据，所有数据发送完毕，清除 EPOLLOUT 就绪状态。

例如，当一个系统调用(比如 fork )因为没有足够的资源(比如虚拟内存)而执行失败，返回 EAGAIN 提示其再调用一次(也许下次就能成功)。

技术框架：

1. 线程池 + 非阻塞 socket + epoll + 事件处理的并发模型
2. 状态机解析HTTP请求
3. 心跳机制
4. 简易日志系统

主要内容：

1. 使用 socket 实现服务器和浏览器客户端的通信；
2. 用 epoll 事件检测技术实现 IO 多路复用，提高运行效率；
3. 采用模拟 Proacto r的事件处理模式，利用线程池实现多线程机制，实现高并发通信，减少频繁创建和销毁线程带来的开销；（信号和互斥锁）
4. 主进程负责事件的读写，子线程负责业务逻辑——用有限状态机解析HTTP（GET）请求报文；生成相应的响应报文。
5. 利用链表数据结构实现心跳机制（超时检测处理）。