56-Ubuntu-Web服务基础

---

早期的web服务端-Apace：

Apace官⽅⽹站

---

Apache三大模型

prefork模型：
预派⽣模式，有⼀个主控制进程，然后⽣成多个⼦进程，使⽤select模型，最⼤并发1024，每个⼦进程有⼀个独⽴的线程响应⽤⼾请求，相对⽐较占⽤内存，但是⽐较稳定，可以设置最⼤和最⼩进程数，是最古⽼的⼀种模式，也是最稳定的模式，适⽤于访问量不是很⼤的场景

优点：稳定
缺点：⼤量⽤⼾访问慢，占⽤资源，1024个进程不适⽤于⾼并发场景

---

woker模型：
⼀种多进程和多线程混合的模型，有⼀个控制进程，启动多个⼦进程，每个⼦进程⾥⾯包含固定的线程，使⽤线程程来处理请求，当线程不够使⽤的时候会再启动⼀个新的⼦进程，然后在进程⾥⾯再启动线程处理请求，由于其使⽤了线程处理请求，因此可以承受更⾼的并发

优点：相⽐prefork 占⽤的内存较少，可以同时处理更多的请求
缺点：使⽤keepalive的⻓连接⽅式，某个线程会⼀直被占据，即使没有传输数据，也需要⼀直等待到超时才会被释放。如果过多的线程，被这样占据，也会导致在⾼并发场景下的⽆服务线程可⽤。（该问题在prefork模式下，同样会发⽣）

---

event模型：
Apache中最新的模式，2012年发布的apache 2.4.X系列正式⽀持event 模型，属于事件驱动模型(epoll)，每个进程响应多个请求，在现在版本⾥的已经是稳定可⽤的模式。它和worker模式很像，最⼤的区别在于，它解决了keepalive场景下，⻓期被占⽤的线程的资源浪费问题（某些线程因为被keepalive，空挂在哪⾥等待，中间⼏乎没有请求过来，甚⾄等到超时）。event MPM中，会有⼀个专⻔的线程来管理这些keepalive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执⾏完毕后，⼜允许它释放。这样增强了⾼并发场景下的请求处理能⼒。

优点：单线程响应多请求，占据更少的内存，⾼并发下表现更优秀，会有⼀个专⻔的线程来管理keep-alive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执⾏完毕后，⼜允许它释放
缺点：没有线程安全控制

---

基于Nginx的访问流程：

---

应⽤程序⼯作模式 ：

httpd MPM（Multi-Processing Module，多进程处理模块）模式：

prefork：进程模型，两级结构，主进程master负责⽣成⼦进程，每个⼦进程负责响应⼀个请求
worker：线程模型，三级结构，主进程master负责⽣成⼦进程，每个⼦进程负责⽣成多个线程，每个线程响应⼀个请求
event：线程模型，三级结构,主进程master负责⽣成⼦进程，每个⼦进程⽣成多个线程，每个线程响应⼀个请求，但是增加了⼀个监听线程，⽤于解决在设置了keep-alived场景下线程的空等待问题。

Nginx（Master+Worker）模式：

主进程
⼯作进程 #直接处理客⼾的请求

线程验证⽅式：
cat /proc/PID/status
pstree -p PID

---

服务端I/O：

I/O在计算机中指Input/Output， IOPS (Input/Output Per Second)即每秒的输⼊输出量(或读写次数)，是衡量磁盘性能的主要指标之⼀。IOPS是指的是在单位时间内系统能处理的I/O请求数量，⼀般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。

机械磁盘的寻道时间、旋转延迟和数据传输时间：
寻道时间：是指磁头移动到正确的磁道上所花费的时间，寻道时间越短则I/O处理就越快，⽬前磁盘的寻道时间⼀般在3-15毫秒左右

旋转延迟：是指将磁盘⽚旋转到数据所在的扇区到磁头下⾯所花费的时间，旋转延迟取决于磁盘的转速，通常使⽤磁盘旋转⼀周所需要时间的1/2之⼀表⽰，⽐如7200转的磁盘平均训传延迟⼤约为60*1000/7200/2=4.17毫秒，公式的意思为 （每分钟60秒*1000毫秒每秒/7200转每分钟/2），如果是15000转的则为60*1000/15000/2=2毫秒。

数据传输时间：指的是读取到数据后传输数据的时间，主要取决于传输速率，这个值等于数据⼤⼩除以传输速率，⽬前的磁盘接⼝每秒的传输速度可以达到600MB，因此忽略不计

常⻅的机械磁盘平均寻道时间值：
7200转/分的磁盘平均物理寻道时间：9毫秒
10000转/分的磁盘平均物理寻道时间：6毫秒
15000转/分的磁盘平均物理寻道时间：4毫秒

常⻅磁盘的平均延迟时间：
7200转的机械盘平均延迟：60*1000/7200/2 = 4.17ms
10000转的机械盘平均延迟：60*1000/10000/2 = 3ms
15000转的机械盘平均延迟：60*1000/15000/2 = 2ms

每秒最⼤IOPS的计算⽅法：
7200转的磁盘IOPS计算⽅式：1000毫秒/(9毫秒的寻道时间+4.17毫秒的平均旋转延迟时间)=1000/13.13=75.9 IOPS
10000转的磁盘的IOPS计算⽅式：1000毫秒/(6毫秒的寻道时间+3毫秒的平均旋转延迟时间)=1000/9=111 IOPS
15000转的磁盘的IOPS计算⽅式：1000毫秒/(4毫秒的寻道时间+2毫秒的平均旋转延迟时间)=1000/6=166.6 IOPS

⼀次完整的I/O是⽤⼾空间的进程数据与内核空间的内核数据的报⽂的完整交换，但是由于内核空间与⽤⼾空间是严格隔离的，所以其数据交换过程中不能由⽤⼾空间的进程直接调⽤内核空间的内存数据，⽽是需要经历⼀次从内核空间中的内存数据copy到⽤⼾空间的进程内存当中，所以简单说I/O就是把数据从内核空间中的内存数据复制到⽤⼾空间中进程的内存当中。
⽽⽹络通信就是⽹络协议栈到⽤⼾空间进程的IO就是⽹络IO

磁盘I/O是进程向内核发起系统调⽤，请求磁盘上的某个资源⽐如是⽂件或者是图⽚，然后内核通过相应的驱动程序将⽬标图⽚加载到内核的内存空间，加载完成之后把数据从内核内存再复制给进程内存，如果是⽐较⼤的数据也需要等待时间

每次IO，都要经由两个阶段：
第⼀步：将数据从磁盘⽂件先加载⾄内核内存空间（缓冲区），此步骤需要等待数据准备完成，时间较⻓
第⼆步：将数据从内核缓冲区复制到⽤⼾空间的进程的内存中，时间较短

---

同步/异步：关注的是事件处理的消息通信机制，即在等待⼀件事情的处理结果时，被调⽤者是否提供完成通知。
同步：synchronous，调⽤者等待被调⽤者返回消息后才能继续执⾏，如果被调⽤者不提供消息返回则为同步，同步需要调⽤者主动询问事情是否处理完成。
异步：asynchronous，被调⽤者通过状态、通知或回调机制主动通知调⽤者被调⽤者的运⾏状态

同步：进程发出请求调⽤后，等内核返回响应以后才继续下⼀个请求，即如果内核⼀直不返回数据，那么进程就⼀直等。
异步：进程发出请求调⽤后，不等内核返回响应，接着处理下⼀个请求,Nginx是异步的。

阻塞/⾮阻塞：关注调⽤者在等待结果返回之前所处的状态
阻塞：blocking，指IO操作需要彻底完成后才返回到⽤⼾空间，调⽤结果返回之前，调⽤者被挂起，⼲不了别的事情。
⾮阻塞：nonblocking，指IO操作被调⽤后⽴即返回给⽤⼾⼀个状态值，⽆需等到IO操作彻底完成，最终的调⽤结果返回之前，调⽤者不会被挂起，可以去做别的事情。

---

同步阻塞型IO模型（blocking IO）：

阻塞IO模型是最简单的IO模型，⽤⼾线程在内核进⾏IO操作时被阻塞 ⽤⼾线程通过系统调⽤read发起IO读操作，由⽤⼾空间转到内核空间。内核等到数据包到达后，然后将接收的数据拷⻉到⽤⼾空间，完成read操作 ⽤⼾需要等待read将数据读取到buffer后，才继续处理接收的数据。整个IO请求的过程中，⽤⼾线程是被阻塞的，这导致⽤⼾在发起IO请求时，不能做任何事情，对CPU的资源利⽤率不够 优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占⽤ CPU 资源 缺点：每个连接需要独⽴的进程/线程单独处理，当并发请求量⼤时为了维护程序，内存、线程切换开销较⼤，apache 的preforck使⽤的是这种模式。

同步阻塞：程序向内核发送IO请求后⼀直等待内核响应，如果内核处理请求的IO操作不能⽴即返回,则进程将⼀直等待
并不再接受新的请求，并由进程轮训查看IO是否完成，完成后进程将IO结果返回给Client，在IO没有返回期间进程不
能接受其他客⼾的请求，⽽且是有进程⾃⼰去查看IO是否完成，这种⽅式简单，但是⽐较慢，⽤的⽐较少。

---

同步⾮阻塞型I/O模型(nonblocking IO)：

⽤⼾线程发起IO请求时⽴即返回。但并未读取到任何数据，⽤⼾线程需要不断地发起IO请求，直到数据到达后，才真正读取到数据，继续执⾏。即 “轮询”机制存在两个问题：如果有⼤量⽂件描述符都要等，那么就得⼀个⼀个的read。这会带来⼤量的Context Switch（read是系统调⽤，每调⽤⼀次就得在⽤⼾态和核⼼态切换⼀次）。轮询的时间不好把握。这⾥是要猜多久之后数据才能到。等待时间设的太⻓，程序响应延迟就过⼤；设的太短，就会造成过于频繁的重试，⼲耗CPU⽽已，是⽐较浪费CPU的⽅式，⼀般很少直接使⽤这种模型，⽽是在其他IO模型中使⽤⾮阻塞IO这⼀特性。

同步⾮阻塞：程序向内核发送请IO求后⼀直等待内核响应，如果内核处理请求的IO操作不能⽴即返回IO结果，进程将不再等待，⽽且继续处理其他请求，但是仍然需要进程隔⼀段时间就要查看内核IO是否完成。

---

IO多路复⽤型(IO multiplexing)：

IO multiplexing就是我们说的select，poll，epoll，有些地⽅也称这种IO⽅式为event driven IO。
select/poll/epoll的好处就在于单个process就可以同时处理多个⽹络连接的IO。它的基本原理就是select，poll，epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知⽤⼾进程。 当⽤⼾进程调⽤了select，那么整个进程会被block，⽽同时，kernel会“监视”所有select负责的socket，当任何⼀个socket中的数据准备好了，select就会返回。这个时候⽤⼾进程再调⽤read操作，将数据从kernel拷⻉到⽤⼾进程。

Apache prefork是此模式的主进程+多进程/单线程+select，work是主进程+多进程/多线程+poll模式

---

信号驱动式IO(signal-driven IO):

信号驱动IO：signal-driven I/O ⽤⼾进程可以通过sigaction系统调⽤注册⼀个信号处理程序，然后主程序可以继续向下执⾏，当有IO操作准备就绪时，由内核通知触发⼀个SIGIO信号处理程序执⾏，然后将⽤⼾进程所需要的数据从内核空间拷⻉到⽤⼾空间， 此模型的优势在于等待数据报到达期间进程不被阻塞。⽤⼾主程序可以继续执⾏，只要等待来⾃信号处理函数的通知。 优点：线程并没有在等待数据时被阻塞，内核直接返回调⽤接收信号，不影响进程继续处理其他请求因此可以提⾼资源的利⽤率 缺点：信号 I/O 在⼤量 IO 操作时可能会因为信号队列溢出导致没法通知

异步阻塞：程序进程向内核发送IO调⽤后，不⽤等待内核响应，可以继续接受其他请求，内核收到进程请求后进⾏的IO如果不能⽴即返回，就由内核等待结果，直到IO完成后内核再通知进程，apache event模型就是主进程+多进程/多线程+信号驱动

---

异步(⾮阻塞) IO(asynchronous IO)：

相对于同步IO，异步IO不是顺序执⾏。⽤⼾进程进⾏aio_read系统调⽤之后，⽆论内核数据是否准备好，都会直接返回给⽤⼾进程，然后⽤⼾态进程可以去做别的事情。等到socket数据准备好了，内核直接复制数据给进程，然后从内核向进程发送通知。IO两个阶段，进程都是⾮阻塞的。Linux提供了AIO库函数实现异步，但是⽤的很少。⽬前有很多开源的异步IO库，例如libevent、libev、libuv。异步过程如下图所⽰：

异步⾮阻塞：程序进程向内核发送IO调⽤后，不⽤等待内核响应，可以继续接受其他请求，内核调⽤的IO如果不能⽴即返回，内核会继续处理其他事物，直到IO完成后将结果通知给内核，内核在将IO完成的结果返回给进程，期间进程可以接受新的请求，内核也可以处理新的事物，因此相互不影响，可以实现较⼤的同时并实现较⾼的IO复⽤，因此异步⾮阻塞使⽤最多的⼀种通信⽅式，nginx是异步⾮阻塞。

---

IO对⽐差异：

这五种⽹络 I/O 模型中，越往后，阻塞越少，理论上效率也是最优前四种属于同步 I/O，因为其中真正的 I/O 操作(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配。

---

Nginx⽀持在多种不同的操作系统实现不同的事件驱动模型，但是其在不同的操作系统甚⾄是不同的系统版本上⾯的实现⽅式不尽相同，主要有以下实现⽅式：

1、select：
select库是在linux和windows平台都基本⽀持的 事件驱动模型库，并且在接⼝的定义也基本相同，只是部分参数的含义略有差异，最⼤并发限制1024，是最早期的事件驱动模型。
2、poll：
在Linux 的基本驱动模型，windows不⽀持此驱动模型，是select的升级版，取消了最⼤的并发限制，在编译nginx的时候可以使⽤–with-poll_module和–without-poll_module这两个指定是否编译select库。
3、epoll：
epoll是库是Nginx服务器⽀持的最⾼性能的事件驱动库之⼀，是公认的⾮常优秀的事件驱动模型，它和select和poll有很⼤的区别，epoll是poll的升级版，但是与poll的效率有很⼤的区别.
epoll的处理⽅式是创建⼀个待处理的事件列表，然后把这个列表发给内核，返回的时候在去轮训检查这个表，以判断事件是否发⽣，epoll⽀持⼀个进程打开的最⼤事件描述符的上限是系统可以打开的⽂件的最⼤数，同时epoll库的IO效率不随描述符数⽬增加⽽线性下降，因为它只会对内核上报的“活跃”的描述符进⾏操作。
4、rtsig：
不是⼀个常⽤事件驱动，最⼤队列1024，不是很常⽤
5、kqueue：
⽤于⽀持BSD系列平台的⾼校事件驱动模型，主要⽤在FreeBSD 4.1及以上版本、OpenBSD 2.0级以上版本，NetBSD级以上版本及Mac OS X 平台上，该模型也是poll库的变种，因此和epoll没有本质上的区别，都是通过避免轮训操作提供效率。
6、/dev/poll:
⽤于⽀持unix衍⽣平台的⾼效事件驱动模型，主要在Solaris 平台、HP/UX，该模型是sun公司在开发Solaris系列
平台的时候提出的⽤于完成事件驱动机制的⽅案，它使⽤了虚拟的/dev/poll设备，开发⼈员将要⻅识的⽂件描述符加⼊这个设备，然后通过ioctl()调⽤来获取事件通知，因此运⾏在以上系列平台的时候请使⽤/dev/poll事件驱动机制。
7、eventport：
该⽅案也是sun公司在开发Solaris的时候提出的事件驱动库，只是Solaris 10以上的版本，该驱动库看防⽌内核崩溃等情况的发⽣。
8、Iocp：
Windows系统上的实现⽅式，对应第5种（异步I/O）模型。

---

常⽤模型汇总：

---

常⽤模型对⽐:

⽔平触发-- 多次通知，需要关⼼数据是否取完以避免重复通知，效率较低。
边缘触发-- ⼀次通知，需要关⼼数据是否取⾛以避免数据丢失，效率较⾼。

Select：
POSIX所规定，⽬前⼏乎在所有的平台上⽀持，其良好跨平台⽀持也是它的⼀个优点，本质上是通过设置或者检查存放fd标志位的数据结构来进⾏下⼀步处理
缺点
单个进程能够监视的⽂件描述符的数量存在最⼤限制，在Linux上⼀般为1024，可以通过修改宏定义FD_SETSIZE，再重新编译内核实现，但是这样也会造成效率的降低
单个进程可监视的fd数量被限制，默认是1024，修改此值需要重新编译内核
对socket是线性扫描，即采⽤轮询的⽅法，效率较低
select 采取了内存拷⻉⽅法来实现内核将 FD 消息通知给⽤⼾空间，这样⼀个⽤来存放⼤量fd的数据结构，这样会使得⽤⼾空间和内核空间在传递该结构时复制开销⼤

poll：
本质上和select没有区别，它将⽤⼾传⼊的数组拷⻉到内核空间，然后查询每个fd对应的设备状态其没有最⼤连接数的限制，原因是它是基于链表来存储的
⼤量的fd的数组被整体复制于⽤⼾态和内核地址空间之间，⽽不管这样的复制是不是有意义
poll特点是“⽔平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd

epoll：
在Linux 2.6内核中提出的select和poll的增强版本
⽀持⽔平触发LT和边缘触发ET，最⼤的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就需态，并且只会通知⼀次使⽤“事件”的就绪通知⽅式，通过epoll_ctl注册fd，⼀旦该fd就绪，内核就会采⽤类似callback的回调机制来激活该fd，epoll_wait便可以收到通知
优点:
没有最⼤并发连接的限制：能打开的FD的上限远⼤于1024(1G的内存能监听约10万个端⼝)，具体查看/proc/sys/fs/file-max，此值和系统内存⼤⼩相关
效率提升：⾮轮询的⽅式，不会随着FD数⽬的增加⽽效率下降；只有活跃可⽤的FD才会调⽤callback函数，即epoll最⼤的优点就在于它只管理“活跃”的连接，⽽跟连接总数⽆关
内存拷⻉，利⽤mmap(Memory Mapping)加速与内核空间的消息传递；即epoll使⽤mmap减少复制开销