要点

1.服务器程序通常需要处理三类事件：I/O事件，信号及定时事件。有两种事件处理模式：

• Reactor模式：要求主线程（I/O处理单元）只负责监听文件描述符上是否有事件发生（可读、可写），若有，则立即通知工作线程（逻辑单元），将socket可读可写事件放入请求队列，交给工作线程处理。
• Proactor模式：将所有的I/O操作都交给主线程和内核来处理（进行读、写），工作线程仅负责处理逻辑，如主线程读完成后users[sockfd].read()，选择一个工作线程来处理客户请求 pool->append(users + sockfd)。

2.通常使用同步I/O模型（如epoll_wait）实现Reactor，使用异步I/O（如aio_read和aio_write）实现Proactor。但在此项目中，使用的是同步I/O模拟的Proactor事件处理模式。

• 同步（阻塞）I/O：在一个线程中，CPU执行代码的速度极快，然而，一旦遇到IO操作，如读写文件、发送网络数据时，就需要等待IO操作完成，才能继续进行下一步操作。这种情况称为同步IO。
• 异步（非阻塞）I/O：当代码需要执行一个耗时的IO操作时，它只发出IO指令，并不等待IO结果，然后就去执行其他代码了 一段时间后，当IO返回结果时，再通知CPU进行处理。

同步I/O模型的工作流程如下（epoll_wait为例）：

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

3.Linux下有三种IO复用方式：epoll，select和poll，为什么用epoll，它和其他两个有什么区别？为什么一般情况下epoll性能更好？

• 对于select和poll来说，所有文件描述符都是在用户态被加入其文件描述符集合的，每次调用都需要将整个集合拷贝到内核态；epoll则将整个文件描述符集合维护在内核态，每次添加文件描述符的时候都需要执行一个系统调用。系统调用的开销是很大的，在有很多短期活跃连接的情况下，epoll可能会慢于select和poll由于这些大量的系统调用开销。
• select使用线性表描述文件描述符集合，文件描述符有上限；poll使用链表来描述；epoll底层通过红黑树来描述，并且维护一个ready list，将事件表中已经就绪的事件添加到这里，在使用epoll_wait调用时，仅观察这个list中有没有数据即可。
• select和poll的最大开销来自内核判断是否有文件描述符就绪这一过程：每次执行select或poll调用时，它们会采用遍历的方式，遍历整个文件描述符集合去判断各个文件描述符是否有活动；epoll则不需要去以这种方式检查，当有活动产生时，会自动触发epoll回调函数通知epoll文件描述符，然后内核将这些就绪的文件描述符放到之前提到的ready list中等待epoll_wait调用后被处理。
• select和poll都只能工作在相对低效的LT模式下，而epoll同时支持LT和ET模式。

综上，当监测的fd数量较小，且各个fd都很活跃的情况下，建议使用select和poll；当监听的fd数量较多，且单位时间仅部分fd活跃的情况下，使用epoll会明显提升性能。

4.epoll对文件操作符的操作有两种模式：LT（水平触发）和ET（边沿触发），二者的区别在于当你调用epoll_wait的时候内核里面发生了什么：

• LT（水平触发）：类似select，LT会去遍历在epoll事件表中每个文件描述符，来观察是否有我们感兴趣的事件发生，如果有（触发了该文件描述符上的回调函数），epoll_wait就会以非阻塞的方式返回。若该epoll事件没有被处理完（没有返回EWOULDBLOCK），该事件还会被后续的epoll_wait再次触发。
• ET（边缘触发）：ET在发现有我们感兴趣的事件发生后，立即返回，并且sleep这一事件的epoll_wait，不管该事件有没有结束。

在使用ET模式时，必须要保证该文件描述符是非阻塞的（确保在没有数据可读时，该文件描述符不会一直阻塞）；并且每次调用read和write的时候都必须等到它们返回EWOULDBLOCK（确保所有数据都已读完或写完）。

5.GET和POST的区别

• GET 请求通常用于从服务器请求数据，POST 请求用于向服务器提交数据。
• 最直观的区别就是GET把参数包含在URL中，POST通过request body传递参数。
• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
• GET请求在URL中传送的参数是有长度限制。（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。
• GET产生一个TCP数据包；POST产生两个TCP数据包。对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100（指示信息—表示请求已接收，继续处理）continue，浏览器再发送data，服务器响应200 ok（返回数据）。

6.五种I/O模型

• 阻塞IO：调用者调用了某个函数，等待这个函数返回，期间什么也不做，不断去检查这个函数有没有返回，必须等这个函数返回才能进行下一步动作。
• 非阻塞IO：非阻塞等待，每隔一段时间就去检测IO事件是否就绪，若没有就绪就可以先做其他事。非阻塞I/O执行系统调用总是立即返回，不管事件是否已经发生。若事件没有发生，则返回-1，此时可以根据errno区分这两种情况，对于accept，recv和send，事件未发生时，errno通常被设置成eagain。
• 信号驱动IO：linux用套接口进行信号驱动IO，安装一个信号处理函数，进程继续运行并不阻塞，当IO时间就绪，进程收到SIGIO信号，然后处理IO事件。
• IO复用：linux用select/poll函数实现IO复用模型，这两个函数也会使进程阻塞，但是和阻塞IO所不同的是这两个函数可以同时阻塞多个IO操作。而且可以同时对多个读操作、写操作的IO函数进行检测，知道有数据可读或可写时，才真正调用IO操作函数。
• 异步IO：在linux中，可以调用aio_read函数告诉内核描述字缓冲区指针和缓冲区的大小、文件偏移及通知的方式，然后立即返回，当内核将数据拷贝到缓冲区后，再通知应用程序。

注意：阻塞I/O，非阻塞I/O，信号驱动I/O和I/O复用都是同步I/O。

• 同步I/O是指内核向应用程序通知的是就绪事件，即某个I/O操作可以执行了，但数据的实际读写需要应用程序自行完成。
• 异步I/O是指内核向应用程序通知的是完成事件，即应用程序不需要主动执行I/O，而是由内核完成I/O操作。内核通知完成事件，即 I/O 操作已经完成。

7.线程池分析

该项目线程池的设计模式为半同步/半反应堆，其中反应堆具体为Proactor事件处理模式。

半反应堆的体现：

• 主线程监听 epoll 事件，当 socket 可读时：
  1. 主线程调用 read() 读取请求报文数据。
  2. 读取的数据被封装成请求对象，然后插入到请求队列。

半同步的体现：

• 工作线程（线程池）同步处理请求：
  1. 线程池中的工作线程 同步地 从请求队列取出任务。
  2. 解析 HTTP 请求、访问数据库、生成响应数据。
  3. 处理完成后，再调用 write() 同步写回数据 给客户端。

这个模式的核心是：

• 主线程异步监听事件，并处理 read() 读数据。
• 工作线程同步取任务，处理业务逻辑。

• 主线程充当异步线程，负责监听所有socket上的事件
• 若有新请求到来，主线程接收之以得到新的连接socket，然后往epoll内核事件表中注册该socket上的读写事件
• 如果连接socket上有读写事件发生，主线程从socket上接收数据，并将数据封装成请求对象插入到请求队列中
• 所有工作线程睡眠在请求队列上，当有任务到来时，通过竞争（如互斥锁）获得任务的接管权，从请求队列中取出任务，完成读写数据的处理。

8.http报文处理流程

浏览器端发出http连接请求，主线程创建http对象接收请求并将所有数据读入对应buffer，将该对象插入任务队列，工作线程从任务队列中取出一个任务进行处理。

工作线程取出任务后，调用process_read函数，通过主、从状态机对请求报文进行解析。

解析完之后，跳转do_request函数生成响应报文，通过process_write写入buffer，返回给浏览器端。

9.HTTP报文格式

HTTP报文分为请求报文和响应报文两种，每种报文必须按照特有格式生成，才能被浏览器端识别。

其中，浏览器端向服务器发送的为请求报文，服务器处理后返回给浏览器端的为响应报文。

请求报文

HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。

其中，请求分为两种，GET和POST，具体的：

GET：

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host:img.mukewang.com
User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept:image/webp,image/*,*/*;q=0.8
Referer:http://www.imooc.com/
Accept-Encoding:gzip, deflate, sdch
Accept-Language:zh-CN,zh;q=0.8
空行
请求数据为空

POST：

POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive
空行
name=Professional%20Ajax&publisher=Wiley

• 请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本。
  GET说明请求类型为GET，/562f25980001b1b106000338.jpg(URL)为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。
• 请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息。
  • HOST，给出请求资源所在服务器的域名。
  • User-Agent，HTTP客户端程序的信息，该信息由你发出请求使用的浏览器来定义,并且在每个请求中自动发送等。
  • Accept，说明用户代理可处理的媒体类型。
  • Accept-Encoding，说明用户代理支持的内容编码。
  • Accept-Language，说明用户代理能够处理的自然语言集。
  • Content-Type，说明实现主体的媒体类型。
  • Content-Length，说明实现主体的大小。
  • Connection，连接管理，可以是Keep-Alive或close。
• 空行，请求头部后面的空行是必须的即使第四部分的请求数据为空，也必须有空行。
• 请求数据也叫主体，可以添加任意的其他数据。

响应报文

HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8
空行
<html>
      <head></head>
      <body>
            <!--body goes here-->
      </body>
</html>

• 状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成。
  第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为OK。
• 消息报头，用来说明客户端要使用的一些附加信息。
  第二行和第三行为消息报头，Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html),编码类型是UTF-8。
• 空行，消息报头后面的空行是必须的。
• 响应正文，服务器返回给客户端的文本信息。空行后面的html部分为响应正文。

10.HTTP状态码

HTTP有5种类型的状态码，具体的：

• 1xx：指示信息–表示请求已接收，继续处理。
• 2xx：成功–表示请求正常处理完毕。
  • 200 OK：客户端请求被正常处理。
  • 206 Partial content：客户端进行了范围请求。
• 3xx：重定向–要完成请求必须进行更进一步的操作。
  • 301 Moved Permanently：永久重定向，该资源已被永久移动到新位置，将来任何对该资源的访问都要使用本响应返回的若干个URI之一。
  • 302 Found：临时重定向，请求的资源现在临时从不同的URI中获得。
• 4xx：客户端错误–请求有语法错误，服务器无法处理请求。
  • 400 Bad Request：请求报文存在语法错误。
  • 403 Forbidden：请求被服务器拒绝。
  • 404 Not Found：请求不存在，服务器上找不到请求的资源。
• 5xx：服务器端错误–服务器处理请求出错。
  • 500 Internal Server Error：服务器在执行请求时出现错误。

11.定时器

服务器主循环为每一个连接创建一个定时器，并对每个连接进行定时。另外，利用升序时间链表容器将所有定时器串联起来，若主循环接收到定时通知，则在链表中依次执行定时任务。

Linux下提供了三种定时的方法：

• socket选项SO_RECVTIMEO和SO_SNDTIMEO
• SIGALRM信号
• I/O复用系统调用的超时参数

三种方法没有一劳永逸的应用场景，也没有绝对的优劣，本项目使用的是SIGALRM信号。

具体的，利用alarm函数周期性地触发SIGALRM信号，信号处理函数利用管道通知主循环，主循环接收到该信号后对升序链表上所有定时器进行处理，若该段时间内没有交换数据，则将该连接关闭，释放所占用的资源。

这个基于升序双向链表实现的定时器存在着其固有缺点：

• 每次遍历添加和修改定时器的效率偏低(O(n))，使用最小堆结构可以降低时间复杂度降至(O(logn))。
• 每次以固定的时间间隔触发SIGALRM信号，调用tick函数处理超时连接会造成一定的触发浪费，举个例子，若当前的TIMESLOT=5，即每隔5ms触发一次SIGALRM，跳出循环执行tick函数，这时如果当前即将超时的任务距离现在还有20ms，那么在这个期间，SIGALRM信号被触发了4次，tick函数也被执行了4次，可是在这4次中，前三次触发都是无意义的。对此，我们可以动态的设置TIMESLOT的值，每次将其值设置为当前最先超时的定时器与当前时间的时间差，这样每次调用tick函数，超时时间最小的定时器必然到期，并被处理，然后在从时间堆中取一个最先超时的定时器的时间与当前时间做时间差，更新TIMESLOT的值。

这两个缺点在新项目-协程库均已优化

12.统一事件源

统一事件源，是指将信号事件与其他事件一样被处理。

具体的，信号处理函数使用管道将信号传递给主循环，信号处理函数往管道的写端写入信号值，主循环则从管道的读端读出信号值，使用I/O复用系统调用来监听管道读端的可读事件，这样信号事件与其他文件描述符都可以通过epoll来监测，从而实现统一处理。

服务器首先创建定时器容器链表，然后用统一事件源将异常事件，读写事件和信号事件统一处理，根据不同事件的对应逻辑使用定时器。

具体的，

• 浏览器与服务器连接时，创建该连接对应的定时器，并将该定时器添加到链表上
• 处理异常事件时，执行定时事件，服务器关闭连接，从链表上移除对应定时器
• 处理定时信号时，将定时标志设置为true
• 处理读事件时，若某连接上发生读事件，将对应定时器向后移动，否则，执行定时事件
• 处理写事件时，若服务器通过某连接给浏览器发送数据，将对应定时器向后移动，否则，执行定时事件

13.信号处理机制

每个进程之中，都存着一个表，里面存着每种信号所代表的含义，内核通过设置表项中每一个位来标识对应的信号类型。

• 信号的接收
  • 接收信号的任务是由内核代理的，当内核接收到信号后，会将其放到对应进程的信号队列中，同时向进程发送一个中断，使其陷入内核态。注意，此时信号还只是在队列中，对进程来说暂时是不知道有信号到来的。
• 信号的检测
  • 进程从内核态返回到用户态前进行信号检测
  • 进程在内核态中，从睡眠状态被唤醒的时候进行信号检测
  • 进程陷入内核态后，有两种场景会对信号进行检测
  • 当发现有新信号时，便会进入下一步，信号的处理。
• 信号的处理
  • ( 内核 )信号处理函数是运行在用户态的，调用处理函数前，内核会将当前内核栈的内容备份拷贝到用户栈上，并且修改指令寄存器（eip）将其指向信号处理函数。
  • ( 用户 )接下来进程返回到用户态中，执行相应的信号处理函数。
  • ( 内核 )信号处理函数执行完成后，还需要返回内核态，检查是否还有其它信号未处理。
  • ( 用户 )如果所有信号都处理完成，就会将内核栈恢复（从用户栈的备份拷贝回来），同时恢复指令寄存器（eip）将其指向中断前的运行位置，最后回到用户态继续执行进程。

简单来说：

1. 当内核接收到信号后，会将其放到对应进程的信号队列中，同时向进程发送一个中断，使其陷入内核态
2. 进程从内核态返回到用户态前进行信号检测
3. 进程返回到用户态中，执行相应的信号处理函数
4. 信号处理函数执行完成后，还需要返回内核态，检查是否还有其它信号未处理
5. 如果所有信号都处理完成，就会将内核栈恢复（从用户栈的备份拷贝回来），同时恢复指令寄存器（eip）将其指向中断前的运行位置，最后回到用户态继续执行进程

至此，一个完整的信号处理流程便结束了，如果同时有多个信号到达，上面的处理流程会在第2步和第3步骤间重复进行。

14.日志模块

本项目中，使用单例模式创建日志系统，对服务器运行状态、错误信息和访问数据进行记录，该系统可以实现按天分类，超行分类功能，可以根据实际情况分别使用同步和异步写入两种方式。

其中异步写入方式，将生产者-消费者模型封装为阻塞队列，创建一个写线程，工作线程将要写的内容push进队列，写线程从队列中取出内容，写入日志文件。

写入方式通过初始化时是否设置队列大小（表示在队列中可以放几条数据）来判断，若队列大小为0，则为同步，否则为异步。

15.单例模式

单例模式作为最常用的设计模式之一，保证一个类仅有一个实例，并提供一个访问它的全局访问点，该实例被所有程序模块共享。

实现思路：私有化它的构造函数，以防止外界创建单例类的对象；使用类的私有静态指针变量指向类的唯一实例，并用一个公有的静态方法获取该实例。

单例模式有两种实现方法：懒汉和饿汉模式。懒汉模式，不用的时候不去初始化，所以在第一次被使用时才进行初始化；饿汉模式，在程序开始运行时立即初始化。

其中，经典的线程安全懒汉模式，使用双检测锁模式。另一种更优雅的单例模式实现，使用函数内的局部静态对象，这种方法不用加锁和解锁操作（C++11以后，使用局部变量懒汉不用加锁，本项目就使用该方法）

饿汉模式不需要用锁，就可以实现线程安全。原因在于，在程序运行时就定义了对象，并对其初始化。之后，不管哪个线程调用成员函数getinstance()，都只不过是返回一个对象的指针而已。所以是线程安全的，不需要在获取实例的成员函数中加锁。

16.压力测试

Webbench是什么，介绍一下原理
父进程fork若干个子进程，每个子进程在用户要求时间或默认的时间内对目标web循环发出实际访问请求，父子进程通过管道进行通信，子进程通过管道写端向父进程传递在若干次请求访问完毕后记录到的总信息，父进程通过管道读端读取子进程发来的相关信息，子进程在时间到后结束，父进程在所有子进程退出后统计并给用户显示最后的测试结果，然后退出。

17.数据库连接池

什么是数据库连接池？

池是一组资源的集合，这组资源在服务器启动之初就被完全创建好并初始化。通俗来说，池是资源的容器，本质上是对资源的复用。

顾名思义，连接池中的资源为一组数据库连接，由程序动态地对池中的连接进行使用，释放。

当系统开始处理客户请求的时候，如果它需要相关的资源，可以直接从池中获取，无需动态分配；当服务器处理完一个客户连接后,可以把相关的资源放回池中，无需执行系统调用释放资源。

数据库访问的一般流程是什么？

当系统需要访问数据库时，先系统创建数据库连接，完成数据库操作，然后系统断开数据库连接。

为什么要创建连接池？

从一般流程中可以看出，若系统需要频繁访问数据库，则需要频繁创建和断开数据库连接，而创建数据库连接是一个很耗时的操作，也容易对数据库造成安全隐患。

在程序初始化的时候，集中创建多个数据库连接，并把他们集中管理，供程序使用，可以保证较快的数据库读写速度，更加安全可靠。

池可以看做资源的容器，所以多种实现方法，比如数组、链表、队列等。本项目使用单例模式和链表创建数据库连接池，实现对数据库连接资源的复用。

本项目使用局部静态变量懒汉模式创建连接池。

优化

将定时器的实现从双向链表升级为小根堆，性能上有所提升
比如插入新定时器链表时间复杂度为O(n)，小根堆为O(log n)