nginx
文章目录
nginx的工作原理
nginx以高性能的负载均衡器,缓存,和web服务器闻名。nginx由内核和模块组成,其中,内核的设计非常微小和简洁,完成的工作也非常简单,当它接到一个HTTP请求时,仅仅通过查找配置文件将客户端请求映射到一个location block(location是Nginx配置中的一个指令,用于URL匹配),而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。
因此模块可以看做nginx真正的劳动工作者。通常一个location中的指令会涉及一个handler模块和多个filter模块(当然,多个location可以复用同一个模块)。handler模块负责处理请求,完成响应内容的生成,而filter模块对响应内容进行处理。
nginx的模块直接被编译进nginx,因此属于静态编译方式。启动nginx后,nginx的模块被自动加载,不像apache,首先将模块编译为一个so文件,然后在配置文件中指定是否进行加载。在解析配置文件时,nginx的每个模块都有可能去处理某个请求,但是同一个处理请求只能由一个模块来完成。
nginx的进程架构:
启动nginx时,会启动一个master进程, 这个进程不处理任何客户端的请求,主要用来产生worker线程,一个worker线程用来处理n个request
下图展示了nginx模块一次常规的http请求和响应的过程
web服务器请求资源的过程
下图展示了基本的WEB服务请求步骤
客户端发送一个请求到Web服务器,请求首先是到网卡
网卡将请求交由内核空间的内核处理,其实就是拆包了,发现请求的是80端口
内核便将请求发给了在用户空间的Web服务器,Web服务器解包发现客户端请求的index.html页面
Web服务器便进行系统调用将请求发给内核
内核发现在请求的是一页面,便调用磁盘的驱动程序,连接磁盘
内核通过驱动调用磁盘取得的页面文件
内核将取得的页面文件保存在自己的缓存区域中便通知Web进程或线程来取相应的页面文件
Web服务器通过系统调用将内核缓存中的页面文件复制到进程缓存区域中
Web服务器取得页面文件来响应用户,再次通过系统调用将页面文件发给内核
内核进程页面文件的封装并通过网卡发送出去
当报文到达网卡时通过网络响应给客户端
1. 建立连接
建立连接:接收或拒绝连接请求:三次握手的过程
提高http连接性能:
- 并行链接:通过多条tcp连接发起并发的http请求
- 持久连接:keepalive长连接,重用TCP连接,以消除连接和关闭的时延,以事务个数和时间来决定是否关闭连接
- 管道化连接:通过共享TCP连接和发起并发的http请求
① 串行连接
② 并行连接
③ 持久连接
④ 管道化连接
2. 接收请求
接受请求:接受客户端请求报文中对某资源的一次请求的过程,请求报文
Web访问响应模型(Web I/O)
- 单进程I/O模型:启动一个进程处理用户请求,而且一次只处理一个,多个请求被串行响应,太古老了
- 多进程I/O模型:并行启动多个进程,每个进程响应一个连接请求
- 复用I/O结构:启动一个进程,同时响应N个连接请求,连接池
- 实现方法:多线程模型和事件驱动
- 多线程模型:一个进程生成N个线程,每线程响应一个连接请求
- 事件驱动:一个进程处理N个请求
- 进程:比如复制的工作,项目小组,耗资源
- 线程:比如人,轻量级
- 一个进程必有一个线程,一个进程可以有多个线程
- 复用的多进程I/O模型:启动M个进程,每个进程响应N个连接请求,同时接收M*N个请求
3. 处理请求
服务器对请求报文进行解析,并获取请求的资源及请求方法等相关信息,根据方法,资源,首部和可选的主题部分对请求进行处理
元数据:请求报文首部
HEADERS 格式 name:value
示例:
Host: www.along.com 请求的主机名称
Server: Apache/2.4.7
HTTP 常用请求方式,Method:
GET 、POST 、HEAD 、PUT 、DELETE 、TRACE 、OPTIONS
4. 访问资源
服务器获取请求报文中请求的资源web服务器,即存放了web资源的服务器,负责向请求者提供对方请求的静态资源,或动态运行后生成的资源
资源放置于本地文件系统特定的路径:DocRoot服务的根
DocRoot ——> /var/www/html
例:/var/www/html/test/1.jpg
http://www.xxx.com/test/1.jpg
5. 构建响应报文
一旦web服务器识别出了资源,就执行请求方法中描述的动作,并返回响应报文。响应报文中,包含有响应状态码、响应首部,如果生成了响应主体的话,还包括响应主题。
-
响应实体:如果事务处理产生了响应主体,就将内容放在响应报文中回送过去。响应报文中通常包括:
- 描述响应主体MIME类型 的Content-Type首部
- 描述了响应主体长度大小的Content-Length
- 实际报文的主体内容
-
URL重定向:web服务构建的响应并非客户端请求的资源,而是资源另外一个访问路径
-
MIME类型:多媒体的邮件扩展
web服务器要负责确定响应主体的MIME类型。有很多配置服务器的方法可以将MIME类型与资源管理起来
- 魔法分类(扫描首部信息):apache web服务器可以扫描每个资源的内容,并将其与一个已知模式表,首部(被称为魔法文件)进行匹配,以决定每个文件的MIME类型。这样做可能比较慢,但很方便,尤其是文件没有标准扩展名的时候
- 显式分类:可以对web服务器进行配置,使其不考虑文件的扩展名或内容,强制特定文件或目录内容拥有某个MIME类型,例如:php,apache不识别,强制识别
- 类型协商:有些web服务器经过配置,可以以多种文档格式来存储资源。在这种情况下,可以配置web服务器,使其可以通过与用户的协商来决定使用哪种格式(及最相关的MIME类型)最好
6. 发送响应报文
web服务器通过连接发送数据时也会面临与接收数据一样的问题。服务器可能有很多条到各个客户端的连接,有些是空闲的,有些在向服务器发送数据,还有一些在向客户端回送响应数据。服务器要记录连接的状态,还要特别注意对持久连接的处理。对非持久连接而言,服务器应该在发送了整条报文之后,关闭自己这一端的连接。对持久连接来说,连接可能仍保持打开状态,在这种情况下,服务器要正确地计算Content-Length首部,不然客户端就无法知道响应什么时候结束了
7. 记录日志
最后,当事务结束时,web服务器会在日志文件中添加一个条目,来描述已执行的事务
日志类型:
- 访问日志:现在愈发重要,大数据时代
- 错误日志:排错使用
nginx的配置
-t 检查配置文件语法
[root@localhost ~]# nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
-v 查看nginx版本
[root@localhost ~]# nginx -v
nginx version: nginx/1.20.1
-c 指定配置文件的路径
[root@localhost ~]# ps -ef|grep nginx
root 1679 1 0 07:45 ? 00:00:00 nginx: master process nginx
nginx 1680 1679 0 07:45 ? 00:00:00 nginx: worker process
root 1685 1525 0 07:46 pts/0 00:00:00 grep --color=auto nginx
[root@localhost ~]# nginx -s stop ;nginx -c /opt/nginx.conf //直接停掉然后启动
[root@localhost ~]# ps -ef|grep nginx
root 1679 1 0 07:45 ? 00:00:00 nginx: master process nginx -c /opt/nginx.conf
nginx 1680 1679 0 07:46 ? 00:00:00 nginx: worker process
nginx 1681 1679 0 07:46 ? 00:00:00 nginx: worker process
root 1685 1525 0 07:45 pts/0 00:00:00 grep --color=auto nginx
-s 发送服务控制信号,可选值有{stop|quit|reopen|reload}
[root@localhost ~]# nginx -s quit
[root@localhost ~]# ss -antl
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 128 [::]:22 [::]:*