目录
前言
这一章是整个专栏的核心,也是后续章节的总览。这一章我们会从宏观角度上概括,解释,分析Webserver的各个部分。
分析原理,搭建网络,将一个高性能Webserver的各个部分串联起来。可以说,如果没有彻底看懂这一章的内容,那么后面的学习都如同雾里看花,甚至不知道在干嘛,唯有将框架了解清楚,才知道什么地方该填入正确的血肉。
同时,这一章内容也是面试的各大高频考点。
一.服务器编程基础框架
C/S模型
TCP/IP的最初设计理念并没有客户端和服务端的概念,主机与主机之间大多进行的是信息对等交换。
类似于人类古代的以物易物的交易方式
但随着网络的发展,有一些主机其掌握了更多的资源,其他主机想要获得资源都要去找它获取,这些主机慢慢发展壮大,成了我们今天的服务端,而其他的主机便是客户端。
类似于出现了店家,人们不再以物易物,而是去店家那获取资源
而在Linux中,客户端与服务端之间“交易方式”,如下图所示
主要框架
但很显然,上面这种交易方式并不是单独发生,当有多个客户端和服务端发生“交易”时,服务端就得好好设计一番,才能不耽误与各个客户端的“交易”过程。
于是,我们在服务端内部作好一种最基本的新体系,如下图:
- I/O处理单元:
- 接受客户连接
- 接收客户数据
- 将处理好的数据还给客户端
- 请求队列:
- 并非为真正的一个队列,而是一种单元间通信的抽象。
- 当I/O处理单元收到客户请求后,将客户请求交给逻辑单元处理
- 逻辑单元:
- 通常为一个进程或线程
- 分析客户数据,作出处理
- 将处理结果交给I/O单元(或者直接给客户端)
二.I/O模型
服务端与客户端交互的第一棒是I/O,而I/O又可以分为阻塞I/O和非阻塞I/O
阻塞I/O
基础API中,acept,send,recv,connect可能会被阻塞,而其一旦阻塞,操作系统就会将其挂起,直到其等待的事件发生为止(操作系统基础知识)。
非阻塞I/O
非阻塞I/O的系统调用总是被立刻返回,无论事件是否发生,若事件没有发生,系统调用就返回-1,并返回错误码errno,我们就要根据errno进行适当处理.
如:再试一次.
所以为了不影响非阻塞I/O的效率,非阻塞I/O就要和其他I/O通知机制配合使用,比如 I/O复用 和 SIGIO信号
I/O复用:
- 原理:应用程序通过I/O复用函数向内核注册一组事件,内核通过I/O复用函数把其中就绪的事件通知给应用程序.
- I/O复用函数
- select
- poll
- epoll_wait
C++ Webserver从零开始:基础知识(四)——I/O复用-CSDN博客
SIGIO信号:
原理:我们为目标文件描述符指定一个宿主进程,宿主进程会捕获到SIGIO信号,当目标文件描述符上有事件发生时,SIGIO信号的信号处理函数将被触发,于是在该信号处理函数中,我们就可以进行非阻塞I/O操作.
C++ Webserver从零开始:基础知识(五)——信号-CSDN博客
异步I/O
其实从理论上来说,上述的I/O模型都是同步I/O模型,因为I/O的读写操作都是在I/O事件发生后的.而真正的异步I/O模型是用户直接进行I/O读写操作,这些操作告诉内核:
1读写缓冲区的位置
2读写完成后怎么通知应用程序
所以异步I/O会"自动"进行I/O读写,不用在乎I/O事件和I/O读写的顺序.
PS:可以理解为同步I/O模型将数据的读和写操作按程序员写的代码来处理,而异步I/O模型将数据的读和写直接交给内核来处理,程序员只需要告诉内核一些注意事项即可.
三.两种高效的事件处理模式
前面我们已经了解了服务器编程的基础框架和几种不同的I/O模型,接下来我们将两者结合一下,就可以得到两种高效的事件处理模式
-
- Reactor
- Proactor
其中,同步I/O实现Reactor模式,异步I/O实现Proactor模式.
但同时,我们可以用同步I/O去模拟出Proactor处理模式.
Reactor
我们知道,服务器的内部有多个线程在工作,那么他们的结构是怎么样的呢?
一般的结构是将服务器的线程分为主线程和工作线程,其中主线程一直处于激活状态,而工作线程则可能睡眠,也可能工作.
在Reactor模式中:
- 主线程:
- 一直在监听文件描述符上是否有事件发生,有就通知工作线程
- 工作线程:
- 接受新的连接
- 读数据
- 处理客户请求
- 写数据
PS:图中工作线程并不是区分“读工作线程”和“写工作线程”,而是为了逻辑清晰而这样画,Reactor真正运行的过程中,工作线程将自己根据从请求队列取出的事件类型来决定如何处理
Proactor
Reactor是同步I/O模型的事件处理模式(只有在读/写就绪之后才能进行数据读/写操作)
而Proactor则需要异步I/O模型,即Proactor模式下,所有的I/O操作将由内核来处理,工作线程只负责业务逻辑。
Proactor模式中:
- 主线程:
- 一直在监听socket上的事件
- 向内核注册socket读完成事件,告诉内核用户读缓冲区位置,读操作完成时该怎么通知应用程序
- 内核
- 在读缓冲区上收到socket数据后,向程序发送一个信号通知,程序会根据信号处理函数选择工作线程进行处理
- 接受工作线程的写完成事件和写缓冲区位置
- 工作线程将写缓冲区的数据写入socket后,向程序发送一个信号通知,程序根据信号处理函数选择一个工作线程进行善后处理
- 工作线程:
- 处理业务逻辑
PS:主线程中的epoll仅仅用来检测 监听socket 上的连接请求事件,不能用来检测 连接socket 上的读写事件
四.模拟Proactor模式
通过观察我们发现,在Proactor模型中I/O交由内核处理,工作线程不需要进行数据的读写。因此,我们可以用主线程来完成一部分内核的功能来做到模拟Proactor模式。
即:主线程执行数据的读写操作,读写完成后,主线程向工作线程通知读写完成。这样从工作线程来看,就只需进行数据的逻辑操作了。
五.半同步/半异步的并发模式
CPU的并发可以显著提升程序的性能(操作系统基础知识),在服务器编程中,一种比较高效常见的并发编程模式是:半同步/半异步模式。
注意,这里的同步和异步与前文I/O模型的同步和异步是完全不同的概念。
在I/O模型中:
- 同步:内核向应用程序通知I/O就绪事件,由应用程序(工作线程)完成读写
- 异步:内核向应用程序通知I/O完成事件,内核自己完成读写
在并发模式中:
- 同步:代码按顺序执行
- 异步:代码可能受中断,信号等影响,交错地执行
在服务器的设计中,我们往往采用同步线程处理客户逻辑,异步线程处理I/O事件
这种并发模式结合事件处理模式和I/O模型,即可得到一种称为
半同步/半反应堆(half-sync/half-reactive)模式
从其名字可知,其采用的是Reactor的事件处理模式
该模式中,只有主线程是是异步线程,工作线程都是同步线程。
其工作流程细节:
主线程监听所有socket上的事件,如有有可读事件发生(新的连接到来),就获取其连接socket,并往epoll内核事件表中注册这个socket上的读写事件,然后将其插入请求队列。工作线程将其从中取出,进行读操作,逻辑处理,写操作等。
如何将其改成模拟Proactor事件模式:
主线程将socket的中的信息读出封装成一个任务对象,然后将这个任务对象(或指向这个任务对象的指针)插入请求队列,工作线程就只用处理,不必进行I/O操作了。
六.有限状态机
我们前面几节讨论了服务器 I/O处理单元,请求队列,逻辑单元之间协调完成任务的各种模式,现在我们来了解一下在逻辑单元内部的一种处理问题的编程方法:有限状态机。
在连接socket的数据被工作线程得到后,可以根据其应用层协议的头部类型字段的类型来进行不同的处理。其中每种不同的字段可以映射成有限状态机内的各种状态,每种状态下编写不同的处理代码。
同时,状态机还需要在不同的状态之间进行转移。
{
State cur_State = typeA;//1.初始状态
while(cur_State != typeC) {//2.当状态变成退出状态typeC时,退出循环
Package _pack = getNewPackage();
switch(cur_State) {
case type_A:
process_package_state_A(_pack);
cur_State = typeB;//3.切换状态
break;
case type_B:
process_package_state_B(_pack);
cur_State = typeC;//4.切换到退出状态
break;
}
}
七.其他提高服务器性能的方法
前面的内容组成了一个高性能Web服务器的基础框架,下面我们再简要介绍其他几个方面:池,数据复制,上下文切换和锁
池
现代计算机的硬件资源大都十分充裕,所以我们可以用算法里的一个基本的思想来提高效率:用空间换时间。在Web服务器里,其具象化为池。
所谓池是一组资源的集合,这组资源在服务器启动的时候就已经初始化好了,当服务器进入正式运行阶段,需要某些资源,就不需要花费大量时间去动态申请,使用,释放,而直接从池里取出用即可,这就极大提高了服务器的运行效率。
池思想面临的困难:
我们不知道预先应该分配多少资源,应该怎么办?
解决方法:
- 分配非常多的资源,在大多数情况下不可能用完(不现实)
- 根据使用场景预估分配足够多的资源,如果不够用了,可以自动再扩充池
常用池:线程池,进程池,内存池,连接池。
数据复制
高性能服务器应该避免不必要的数据复制操作,且要善用零拷贝,共享内存等方式。
例如:FTP服务器,当客户请求一个文件时,服务器只需要检测目标文件是否存在,用户是否有读取它的权限即可,不必关心文件内的内容。所以FTP服务器无需将目标文件的内容完整地读到应用程序缓冲区中并调用send来进行发送,而是可以直接使用“零拷贝”函数send将其直接发给客户端。
上下文切换和锁
在web服务器地模型中,有人也许回想:我为每一个客户连接都创建一个工作线程可行吗?
答案是:不行。
因为这样会创建非常多的工作线程,而CPU的数量是有限的。而CPU在并发的工作模式下,会在同的线程之间进行切换,这种切换会消耗CPU资源,而处理业务逻辑的时间就会减少,如果线程太多,CPU就会频繁切换上下文而真正有意义的工作将大大减少。
我们提高服务器运行效率的其中一个重要方法是共享内存,但共享内存同时也会带来许多安全隐患问题,为了防止这些隐患,我们需要使用锁。而锁也会占用一定的系统资源,这种时候我们需要考虑使用粒度更小的锁,如读写锁等来提高性能。
八.一些废话
这篇文章我写了两天,算是自己对Web服务器框架的梳理。很显然,它并不完美也不全面,但是对于初学者来说应该已经够用了,在服务器基础框架这里有许多光看十分难理解的内容。比如:Reactor和Proactro处理模式到底是怎么搞得。这部分基本上要结合后面的实践才能有更深的理解。但是它也足够重要。写这篇文章的时候我腱鞘炎又犯了,写的非常痛苦。但好在写完了,在自己梳理一遍以后对服务器框架会更加清晰,这是光靠看所不能达到的。我推荐每一个做Web服务器的同学,都能自己去梳理一遍框架,这会对你对这个项目的理解更加深刻。
后面会尽快出I/O复用和信号的文章,讲解epoll和信号的有关内容。