文章目录
一. 基本知识
影响用户体验的几个因素
客户端
硬件配置
网络速率
服务端距离:最短,为最优
服务端
网络速率:服务器,出口带宽
硬件配置:机械硬盘
架构设计
应用程序工作模式
并发数量:
响应文件大小及数量:磁盘IO,网络
I/O压力
Httpd MPM多处理模型
prefork:进程模型,两级结构,主进程master负责生成子进程,每个子进程负责响应一个请求
worker:线程模型,三级结构,主进程master负责生成子进程,每个子进程负责生成多个线程,每个线程响应一个请求
event:线程模型,三级结构,主进程master负责生成子进程,每个子进程响应多个请求(有一个监控线程)监听线程(没有安全性)
服务端处理网络请求过程
I/O在计算机中指Input/Output, IOPS
(Input/Output Per Second)即每秒的输入输出量(或读写次数),是衡量磁 盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量,一般以每秒处理的I/O请求数量为单位, I/O请求通常为读或写数据操作请求。
获取请求数据
,客户端与服务器建立连接发出请求,服务器接受请求(1-3)
构建响应
,当服务器接收完请求,并在用户空间处理客户端的请求,直到构建响应完成(4)
返回数据
,服务器将已构建好的响应再通过内核空间的网络 I/O 发还给客户端(5-7)
线程验证方式(注意:花括号是线程,中括号是进程)
cat /proc/PID/status
pstree -p PID
二. I/O介绍
I/O:
网络IO:本质是socket文件读取
磁盘IO:
每次IO,都要经由两个阶段:
第一步:将数据从文件先加载至内核内存空间
(缓冲区),等待数据准备完成,时间较长
第二步:将数据从内核缓冲区复制到用户空间
的进程的内存中,时间较短
I/O模型
(调用者:应用程序,被调用者:内核)
同步/异步:关注的被调用者是否提供通知机制
同步
:synchronous,调用者等待被调用者返回消息,才能继续执行(调用者自己去问
)
异步
:asynchronous,被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态(被调用者主动通知调用者
)nginx
阻塞/非阻塞:关注调用者在等待结果返回之前所处的状态
阻塞
:blocking,指IO操作需要彻底完成后才返回到用户空间,调用结果返回之前,调用者被挂起(不能做任何事
)
非阻塞
:nonblocking,指IO操作被调用后立即返回给用户一个状态值,无需等到IO操作彻底完成,最终的调用结果返回之前,调用者不会被挂起(调用者可以做其他的事情
)
I/O模型:
阻塞型、非阻塞型、复用型、信号驱动型、异步
1.阻塞IO模型
相当于一个人去钓鱼,一直等待鱼上钩
阻塞IO模型是最简单的IO模型,用户线程在内核进行IO操作时被阻塞
用户线程通过系统调用read发起IO读操作,由用户空间转到内核空间。内核等到数据包到达后,然后将接收的数据拷贝到用户空间,完成read操作
用户需要等待read将数据读取到buffer后,才继续处理接收的数据。整个IO请求的过程中,用户线程是被阻塞的,这导致用户在发起IO请求时,不能做任何事情
,对CPU的资源利用率不够
优点
:程序简单,在阻塞等待数据期间进程/线程挂起,基本不会占用 CPU 资源
缺点
:每个连接需要独立的进程/线程单独处理,当并发请求量大时为了维护程序,内存、线程切换开销较大,这种模型在实际生产中很少使用
对于单线程的网络服务,这样做就会有卡死
的问题。因为当等待时,整个线程会被挂起,无法执行,也无法做其他的工作。这种Block是不会影响同时运行的其他程序(进程)的,因为现代操作系统都是多任务的,任务之间的切换是抢占式的。这里Block只是指Block当前的进程
虽可通过线程池技术既能并发的处理请求,又不会产生大量线程。但这样会限制最大并发的连接数。
当调用read接受网络请求时,有数据到了就处理,没数据到时,实际上是可以干别的。之所以使用大量线程,仅仅是因为Block发生
2.非阻塞IO模型
相当于一个人去钓鱼,时不时的去看鱼是否上钩(提供消息通知)
同步非阻塞IO模型
用户线程发起IO请求时立即返回。但并未读取到任何数据,用户线程需要不断地发起IO请求
,直到数据到达后,才真正读取到数据,继续执行。即 “轮询
”机制
存在两个问题:如果有大量文件描述符都要等,那么就得一个一个的read。这会带来大量的Context Switch(read是系统调用,每调用一次就得在用户态和核心态切换一次)。轮询的时间不好把握。这里是要猜多久之后数据才能到。等待时间设的太长,程序响应延迟就过大;设的太短,就会造成过于频繁的重试,干耗CPU而已
是比较浪费CPU
的方式,一般很少使用
这种模型,而是在其他IO模型中使用非阻塞IO这一特性
3.IO多路复用模型
相当于雇佣了一个人,然后自己去监视这个人给你钓鱼
Apache prefork是此模式的select,work是poll模式
有一个select代理
IO多路复用(IO Multiplexing) :是一种机制,程序注册一组socket文件描述符给操作系统,表示“我要监视这些fd是否有IO事件发生,有了就告诉程序处理”
IO多路复用是要和NIO一起使用的。NIO和IO多路复用是相对独立的。NIO仅仅是指IO API总是能立刻返回,不会被Blocking;而IO多路复用仅仅是操作系统提供的一种便利的通知机制。操作系统并不会强制这俩必须得一起用,可以只用IO多路复用 + BIO,这时还是当前线程被卡住。IO多路复用和NIO是要配合一起使用才有实际意义
IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取,就通知该进程
多个连接共用一个等待机制,本模型会阻塞进程,但是进程是阻塞在select
或者poll这两个系统调用上,而不是阻塞在真正的IO操作上
用户首先将需要进行IO操作添加到select中,同时等待select系统调用返回。当数据到达时,IO被激活,select函数返回。用户线程正式发起read请求,读取数据并继续执行
从流程上来看,使用select函数
进行IO请求和同步阻塞模型没有太大的区别,甚至还多了添加监视IO
,以及调用select函数的额外操作,效率更差。并且阻塞了两次,但是第一次阻塞在select上时,select可以监控多个IO上是否已有IO操作准备就绪,即可达到在同一个线程内同时处理多个IO请求的目的
。而不像阻塞IO那种,一次只能监控一个IO
虽然上述方式允许单线程内处理多个IO请求,但是每个IO请求的过程还是阻塞的(在select函数上阻塞),平均时间甚至比同步阻塞IO模型还要长。如果用户线程只是注册自己需要的IO请求,然后去做自己的事情,等到数据到来时再进行处理,则可以提高CPU的利用率
IO多路复用是最常使用的IO模型
,但是其异步程度还不够“彻底”,因它使用了会阻塞线程的select系统调用。因此IO多路复用只能称为异步阻塞IO模型
,而非真正的异步IO
4. 信号驱动IO模型
相当于雇佣了一个人去监视钓鱼的人,
异步阻塞:程序进程向内核发送IO调用后,不用等待内核响应,可以继续接受其他请求,内核收到进程请求后进 行的IO如果不能立即返回,就由内核等待结果,直到IO完成后内核再通知进程,apache event是此模式
信号驱动IO:signal-driven I/O
用户进程可以通过sigaction系统调用注册一个信号处理程序,然后主程序可以继续向下执行,当有IO操作准备就绪时,由内核通知触发一个SIGIO信号处理程序执行,然后将用户进程所需要的数据从内核空间拷贝到用户空间
此模型的优势在于等待数据报到达期间进程不被阻塞
(可以做其他的事)。用户主程序可以继续执行,只要等待来自信号处理函数的通知
对于 TCP 而言,信号驱动的 I/O 方式近乎无用,因为导致这种通知的条件为数众多,每一个来进行判别会消耗很大资源,与前几种方式相比优势尽失
优点
:线程并没有在等待数据时被阻塞,可以提高资源的利用率
缺点
:信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知
5.异步IO模型
相当于自动化过程
异步IO与信号驱动IO最主要的区别是信号驱动IO是由内核通知应用程序何时可以进行IO操作,而异步IO则是由内核告诉用户线程IO操作何时完成。信号驱动IO当内核通知触发信号处理程序时,信号处理程序还需要阻塞在从内核空间缓冲区拷贝数据到用户空间缓冲区这个阶段,而异步IO直接是在第二个阶段完成后,内核直接通知用户线程可以进行后续操作了
由 POSIX 规范定义,应用程序告知内核启动某个操作,并让内核在整个操作(包括将数据从内核拷贝到应用程序的缓冲区)完成后通知应用程序
优点
:异步 I/O 能够充分利用 DMA 特性,让 I/O 操作与计算重叠
缺点
:要实现真正的异步 I/O,操作系统需要做大量的工作。目前 Windows 下通过 IOCP 实现了真正的异步 I/O,在 Linux 系统下,Linux 2.6才引入,目前AIO 并不完善,因此在 Linux 下实现高并发网络编程时以 IO 复用模型模式+多线程任务的架构基本可以满足需求
五种I/O模型
左同步,又异步
三. I/O模型的具体实现
这五种 I/O 模型中,越往后,阻塞越少,理论上效率也是最优前四种属于同步I/O,因为其中真正的 I/O 操作(recvfrom)将阻塞进程/线程,只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配
主要实现方式:
Select:Linux实现对应,I/O复用模型,BSD4.2最早实现,POSIX标准,一般操作系统均有实现
Poll:Linux实现,对应I/O复用模型,System V unix
最早实现
Epoll:Linux特有,对应I/O复用模型,具有信号驱动I/O模型的某些特性
select/poll/epoll
遍历:轮寻性的
回调:通知性的
apache用的是select
nginx用的是epool
水平触发–单次通知 边缘触发–多次通知
Select:POSIX所规定,目前几乎在所有的平台上支持
,其良好跨平台支持也是它的一个优点,本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理
缺点
1.单个进程能够监视的文件描述符的数量存在最大限制,在Linux上一般为1024,可以通过修改宏定义FD_SETSIZE
,再重新编译内核
实现,但是这样也会造成效率的降低
find linux/ -type f |xargs grep “FD_SETSIZE”
2.单个进程可监视的fd数量被限制,默认是1024,修改此值需要重新编译内核
3.对socket是线性扫描,即采用轮询
的方法,效率较低
4.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便可以收到通知
优点
:
1.没有最大并发连接的限制
:能打开的FD的上限远大于1024(1G的内存能监听约10万个端口),具体查看/proc/sys/fs/file-max,此值和系统内存大小相关
2.效率提升
:非轮询的方式,不会随着FD数目的增加而效率下降;只有活跃可用的FD才会调用callback函数,即epoll最大的优点就在于它只管理“活跃”的连接,而跟连接总数无关
3.内存拷贝
,利用mmap(Memory Mapping)加速与内核空间的消息传递;即epoll使用mmap减少复制开销
零拷贝
传统Linux中 I/O 的问题
传统的 Linux 系统的标准 I/O 接口(read、write)是基于数据拷贝的,也就是数据都是 copy_to_user 或者 copy_from_user,这样做的好处是,通过中间缓存的机制,减少磁盘 I/O 的操作,但是坏处也很明显,大量数据的拷贝,用户态和内核态的频繁切换,会消耗大量的 CPU 资源
,严重影响数据传输的性能,统计表明,在Linux协议栈中,数据包在内核态和用户态之间的拷贝所用的时间甚至占到了数据包整个处理流程时间的57.1%
什么是零拷贝
零拷贝就是上述问题的一个解决方案,通过尽量避免拷贝操作来缓解 CPU 的压力
。零拷贝并没有真正做到“0”拷贝,它更多是一种思想,很多的零拷贝技术都是基于这个思想去做的优化
原始数据拷贝操作
MMAP内存映射
MMAP:Memory Mapping加速与内核空间的消息传递
内存映射
SENDFILE
sendfile如果硬盘是通过网络挂载的不能使用
DMA 辅助的 SENDFILE