web请求处理机制

1. 基本知识概念

1. 吞吐率（Requests per second）

• 概念：服务器并发处理能力的量化描述，单位是reqs/s，指的是某个并发用户数下单位时间内处理的请求数。
• 某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。
• 计算公式：总请求数 / 处理完成这些请求数所花费的时间，即
  Request per second = Complete requests / Time taken for tests

2. 并发连接数（The number of concurrent connections）

• 概念：某个时刻服务器所接受的请求数目，简单的讲，就是一个会话。

3. 并发用户数（The number of concurrent users，Concurrency Level）

• 概念：要注意区分这个概念和并发连接数之间的区别，一个用户可能同时会产生多个会话，也即连接数。

4. 用户平均请求等待时间（Time per request）

• 计算公式：处理完成所有请求数所花费的时间/ （总请求数 / 并发用户数），即
  Time per request = Time taken for tests /（ Complete requests / Concurrency Level）

5. 服务器平均请求等待时间（Time per request: across all concurrent requests）

• 计算公式：处理完成所有请求数所花费的时间 / 总请求数，即
  Time taken for / testsComplete requests
  可以看到，它是吞吐率的倒数。
  同时，它也=用户平均请求等待时间/并发用户数，即
  Time per request / Concurrency Level

2. web请求处理机制

2.1 一个Web请求的处理过程

（1）客户发起请求到服务器网卡
（2）服务器网卡接受到请求后转交给内核处理；
（3） 内核根据请求对应的套接字，将请求交给工作在用户空间的Web服务器进程
（4）Web服务器进程根据用户请求，向内核进行系统调用，申请获取相应资源（如index.html）
（5）内核发现web服务器进程请求的是一个存放在硬盘上的资源，因此通过驱动程序连接磁盘
（6）内核调度磁盘，获取需要的资源
（7）内核将资源存放在自己的缓冲区中，并通知Web服务器进程
（8）Web服务器进程通过系统调用取得资源，并将其复制到进程自己的缓冲区中 Web服务器进程形成响应，通过系统调用再次发给内核以响应用户请求
（9） 内核将响应发送至网卡
（10）网卡发送响应给用户

简单来说就是：

用户请求–>送达到用户空间–>系统调用–>内核空间–>内核到磁盘上读取网页资源->返回到用户空间->响应给用户。

在这个过程中，有两个I/O过程，一个就是客户端请求的网络I/O，另一个就是Web服务器请求页面的磁盘I/O

用户空间 / 内核空间

现在操作系统都是采用虚拟存储器，那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核（kernel），保证内核的安全，操作系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间

2.2 web请求处理方式

2.2.1 多线程与多进程

1、多进程方式： 服务器每接受到一个客户端请求就有服务器的主进程生成一个子进程响应客户端，直到用户关闭连接，

• （优缺点）这样的优势是处理速度快，子进程之间相互独立，但是如果访问过大会导致服务器资源耗尽而无法提供请求

2、多线程方式： 与多进程方式类似，但是服务器每收到一个客户端请求会有服务进程派生出一个线程来个客户方进行交互

• （优点） 一个线程的开销远远小于一个进程，因此多线程方式在很大程度减轻了web服务器对系统资源的要求

• （缺点）但是多线程也有自己的缺点，即当多个线程位于同一个进程内工作的时候，可以相互访问同样的内存地址空间，所以他们相互影响，一旦主进程挂掉则所有子线程都不能工作了，IIS服务器使用了多线程的方式，需要间隔一段时间就重启一次才能稳定

2.2.2 同步和异步

同步与异步：主要是针对应用程序与内核的交互方式而言的

• 同步：进程发出数据后，等内核返回响应以后才继续下一个请求，即如果内核一直不返回数据，那么进程就一直等，直到天荒地老，死机error。

• 异步：进程发出数据后，不等内核返回响应，接着处理下一个请求(Nginx是异步的)

2.2.3 阻塞与非阻塞

可以理解为内核与IO设备的交互方式， 当内核收到进程请求IO数据时候的处理方式;也可以简单理解为内核需要做一件事能不能立即得到返回应答，如果不能立即获得返回，需要等待，那就阻塞了，否则就可以理解为非阻塞

• 阻塞：IO调用不能立即返回结果，即一个进程发起的IO请求不能得到立即满足时，进程就要一直等到内核响应，内核要把数据从IO设备复制到内核空间，再返回给进程，这是阻塞。
• 非阻塞：IO调用可以立即返回结果，一个进程发起的IO进程不能立即满足时，不在等待，而是一遍一遍的轮训查看IO是否完成

2.2.4 I/O多路复用

如果一个I/O流进来，我们就开启一个进程处理这个I/O流。那么假设现在有一百万个I/O流进来，那我们就需要开启一百万个进程一一对应处理这些I/O流（——这就是传统意义下的多进程并发处理）。思考一下，一百万个进程，你的CPU占有率会多高，这个实现方式及其的不合理。

所以人们提出了I/O多路复用这个模型，一个线程，通过记录I/O流的状态来同时管理多个I/O，可以提高服务器的吞吐能力

（1）阻塞型IO

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。对于network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候kernel就要等待足够的数据到来。 而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。

（2）非阻塞型IO

当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。 从用户进程角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是用户就可以在本次到下次再发起read询问的时间间隔内做其他事情，或者直接再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存（这一阶段仍然是阻塞的），然后返回。

（3）多路复用IO

a.select/epoll

如果我说select/epoll，大概就都能明白了。有些地方也称这种IO方式为事件驱动IO(event driven IO)。我们都知道，select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程

b.epoll
epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

举例说明：

1.阻塞I/O模型

老李去火车站买票，排队三天买到一张退票。

耗费：在车站吃喝拉撒睡 3天，其他事一件没干。

2.非阻塞I/O模型

老李去火车站买票，隔12小时去火车站问有没有退票，三天后买到一张票。耗费：往返车站6次，路上6小时，其他时间做了好多事。

3.I/O复用模型

1.select/poll

老李去火车站买票，委托黄牛，然后每隔6小时电话黄牛询问，黄牛三天内买到票，然后老李去火车站交钱领票。

耗费：打电话

2.epoll

老李去火车站买票，委托黄牛，黄牛买到后即通知老李去领，然后老李去火车站交钱领票。

耗费：无需打电话