nginx/nginx优化.md
2025-03-10 19:27:21 +08:00

17 KiB
Raw Permalink Blame History

Nginx 优化


Nginx 监控

1. 简介

nginx的基础监控

- 进程监控
- 端口监控

注意: 这两个是必须要加在zabbix监控加触发器有问题及时告警。

nginx 提供了 ngx_http_stub_status_modulengx_http_reqstat_module模块这个模块提供了基本的监控功能。

2. 监控指标

基本指标:

  • Accepts接受、Handled已处理、Requests请求数是一直在增加的计数器。
  • Active活跃、Waiting等待、Reading、Writing随着请求量而增减。
  • AcceptsNginx所接受的客户端连接数。
  • Handled成功的客户端连接数。

每秒请求数 -- QPS

通过持续的 QPS 监控,可以立刻发现是否被恶意攻击或对服务的可用性进行评估。虽然当问题发生时,通过 QPS 不能定位到确切问题的位置,但是他却可以在第一时间提醒你环境可能出问题了。

服务器错误率:

通过监控固定时间间隔内的错误代码4XX代码表示客户端错误5XX代码表示服务器端错误

请求处理时间:

请求处理时间也可以被记录在 access log 中,通过分析 access log统计请求的平均响应时间通过持续观察可以发现上游服务器的问题。 ----$request_time 变量

3. 指标搜索

通过在编译时加入 nginx 的 ngx_http_stub_status_module 模块我们可以实时监控以下基本的指标。

检查是否安装模块:

[root@test ~]# nginx -V

如果没有此模块,需要重新安装,编译命令如下:

[root@test ~]# ./configure --with-http_stub_status_module 

修改配置文件:

[root@test ~]# vim /etc/nginx/conf.d/status.conf
server {
	listen 80;
	server_name localhost;
	
	location /nginx-status {
		stub_status on;
		access_log on;
	}
}

获取数据:

配置完成后在浏览器中输入http://10.0.105.207/nginx-status 查看

Active connections: 1 
server accepts handled requests
 2 2 4 
Reading: 0 Writing: 1 Waiting: 0

参数解释:

Active connections:2    #当前nginx处理请求的数目(活跃的连接数)
server   accepts    handled     requests                   26             26                 48 
nginx总共处理了26个连接成功创建26次握手也就是成功的连接数connection.  总共处理了48个请求 
失败连接=(总连接数-成功连接数)(相等表示中间没有失败的),    
Reading  nginx读取到客户端的Header信息数。请求头   -----速度快。 
Writing nginx返回给客户端的Header信息数。响应头       
Waiting 开启keep-alive的情况下意思就是Nginx说已经处理完正在等候下一次请求指令的驻留连接

HTTPS 技术

1. 简介

HTTPS全称HyperText Transfer Protocol over Secure Socket Layer其实 HTTPS 并不是一个新鲜协议Google 很早就开始启用了,初衷是为了保证数据安全。 近些年Google、Baidu、Facebook 等这样的互联网巨头,不谋而合地开始大力推行 HTTPS 国内外的大型互联网公司很多也都已经启用了全站 HTTPS这也是未来互联网发展的趋势。数据在传输的过程中没有进行加密的处理利用第三黑客软件kali 中间人),可以进行数据的窃听/盗取明文传输https 在数据传输的过程中进行加密处理,然后在去进行传输 电商 政府。

2. 加密算法

对称加密A要给B发送数据

  • A做一个对称密钥。
  • 使用密钥给文件加密。
  • 发送加密以后的文件和钥匙。
  • B拿钥匙解密

注意:加密和解密都是使用的同一个密钥

非对称加密 ---- 公钥加密,私钥解密 A要给B发送数据

  • B做一对非对称的密钥
  • 发送公钥给A
  • A拿公钥对数据进行加密
  • 发送加密后的数据给B
  • B拿私钥解密

总结:

Alice 在盒子里放有信息盒子上有挂锁她有钥匙。通过邮局她把这个盒子寄给Bob。Bob收到盒子后用相同的钥匙打开盒子钥匙之前就得到了可能是Alice面对面给他的。然后Bob可以用同样的方法回复。

Bob和Alice各有自己的盒子。Alice要跟Bob秘密通信她先让Bob把开着的盒子通过邮局发给她。Alice拿到盒子后放入信息锁上然后发给Bob。Bob就可以用他自己的钥匙打开了。回复的话就用同样的方法。信息接受者有两把钥匙一把“公匙”一把“私匙”。公匙是给信息发送者用来加密的私匙是自己用来解密的不必通过不安全的渠道发送私密的东西。公匙本来就是给别人用的不用藏好。你的私匙在你产生私匙的电脑里保存着。

3. 哈希算法

将任意长度的信息转换为较短的固定长度的值,通常其长度要比信息小得多。

例如MD5、SHA-1、SHA-2、SHA-256 、SM9 等

4. 数字签字

签名就是在信息的后面再加上一段内容信息经过hash后的值可以证明信息没有被修改过。hash值一般都会加密后也就是签名再和信息一起发送以保证这个hash值不被修改。

5. https 协议

  • HTTP 协议HyperText Transfer Protocol超文本传输协议是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。

  • HTTPS 协议HyperText Transfer Protocol over Secure Socket Layer可以理解为HTTP+SSL/TLS 即 HTTP 下加入 SSL 层HTTPS 的安全基础是 SSL因此加密的详细内容就需要 SSL用于安全的 HTTP 数据传输。

    如上图所示 HTTPS 相比 HTTP 多了一层 SSL/TLS

  • SSL/TLS :SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全Transport Layer SecurityTLS是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层为数据通讯进行加密提供安全支持

    1. SSL握手协议SSL Handshake Protocol它建立在SSL记录协议之上用于在实际的数据传输开始前通讯双方进行身份认证、协商加密算法、交换加密密钥等。---相当于连接
    2. SSL记录协议SSL Record Protocol它建立在可靠的传输协议如TCP之上为高层协议提供数据封装、压缩、加密等基本功能的支持。 ---相当于通信
  • SSL协议提供的服务

    1. 认证用户和服务器,确保数据发送到正确的客户机和服务器
    2. 加密数据以防止数据中途被窃取
    3. 维护数据的完整性,确保数据在传输过程中不被改变

HTTPS 工作原理

1. 简介

  • HTTP请求过程中客户端与服务器之间没有任何身份确认的过程数据全部明文传输“裸奔”在互联网上所以容易遭到黑客的攻击。

  • 客户端发出的请求很容易被黑客截获,如果此时黑客冒充服务器,则其可返回任意信息给客户端,而不被客户端察觉。

2. http 缺点

  • 窃听风险:黑客可以获知通信内容。
  • 篡改风险:黑客可以修改通信内容。
  • 冒充风险:黑客可以冒充他人身份参与通信。

3. ssl 证书

那有没有一种方式既可以安全的获取公钥,又能防止黑客冒充呢? 那就需要用到终极武器了SSL 证书(申购)。

  • 证书:.crt, .pem
  • 私钥:.key
  • 证书请求文件:.csr

4. 工作原理

服务器发送了一个SSL证书给客户端SSL 证书中包含的具体内容有:

  • 证书的发布机构CA
  • 证书的有效期
  • 公钥
  • 证书所有者
  • 签名就可以理解为是钞票里面的一个防伪标签

客户端在接受到服务端发来的SSL证书时会对证书的真伪进行校验以浏览器为例说明如下

  • 首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
  • 浏览器开始查找操作系统中已内置的受信任的证书发布机构CA与服务器发来的证书中的颁发者CA比对校验是否为合法机构颁发
  • 如果找不到,浏览器就会报错,说明服务器发来的证书是不可信任的
  • 如果找到,那么浏览器就会从操作系统中取出 颁发者CA 的公钥,然后对服务器发来的证书里面的签名进行解密
  • 浏览器使用相同的hash算法计算出服务器发来的证书的hash值将这个计算的hash值与证书中签名做对比
  • 对比结果一致,则证明服务器发来的证书合法,没有被冒充
  • 此时浏览器就可以读取证书中的公钥,用于后续加密了
  • client与web协商对称加密算法client生成对称加密密钥并使用web公钥加密发送给web服务器web服务器使用web私钥解密
  • 使用对称加密密钥传输数据,并校验数据的完整性

所以通过发送SSL证书的形式既解决了公钥获取问题又解决了黑客冒充问题一箭双雕HTTPS加密过程也就此形成

5. CA 机构

CA介绍

CACertificate Authority证书颁发机构主要负责证书的颁发、管理以及归档和吊销。证书内包含了拥有证书者的姓名、地址、电子邮件帐号、公钥、证书有效期、发放证书的CA、CA的数字签名等信息。证书主要有三大功能加密、签名、身份验证。

CA中心申请证书的流程

  • web服务器,生成一对非对称加密密钥web公钥web私钥
  • web服务器使用 web私钥 生成 web服务器的证书请求并将证书请求发给CA服务器
  • CA服务器使用 CA的私钥对web 服务器的证书请求,进行数字签名得到 web服务器的数字证书并将数字证书颁发给web服务器
  • client访问web服务器请求https连接下载web数字证书
  • client下载 CA数字证书CA身份信息CA公钥由上一级CA颁发也可自签名颁发验证 web数字证书

6. https 优点

  • 所有信息都是加密传播,黑客无法窃听
  • 具有校验机制,一旦被篡改,通信双方会立刻发现
  • 配备身份证书,防止身份被冒充

7. https 缺点

  • SSL 证书费用很高,以及其在服务器上的部署、更新维护非常繁琐
  • HTTPS 降低用户访问速度(多次握手)
  • 网站改用HTTPS 以后由HTTP 跳转到 HTTPS 的方式增加了用户访问耗时
  • HTTPS 涉及到的安全算法会消耗 CPU 资源需要增加大量机器https访问过程需要加解密

四:性能优化

1. 简介

当我需要进行性能优化时,说明我们服务器无法满足日益增长的业务。性能优化是一个比较大的课题,需要从以下几个方面进行探讨:当前系统结构瓶颈、了解业务模式、性能与安全。

2. 方向

  • 服务器本身
  • 服务本身

当前系统结构瓶颈:

首先需要了解的是当前系统瓶颈用的是什么跑的是什么业务。里面的服务是什么样子每个服务最大支持多少并发。比如针对nginx而言我们处理静态资源效率最高的瓶颈是多大可以通过查看当前cpu负荷内存使用率进程使用率来做简单判断。还可以通过操作系统的一些工具来判断当前系统性能瓶颈如分析对应的日志查看请求数量也可以通过nginx http_stub_status_module模块来查看对应的连接数总握手次数总请求数。也可以对线上进行压力测试来了解当前的系统能性能并发数做好性能评估。

了解业务模式:

虽然我们是在做性能优化,但还是要熟悉业务,最终目的都是为业务服务的。我们要了解每一个接口业务类型是什么样的业务,比如电子商务抢购模式,这种情况平时流量会很小,但是到了抢购时间,流量一下子就会猛涨。也要了解系统层级结构,每一层在中间层做的是代理还是动静分离,还是后台进行直接服务。需要我们对业务接入层和系统层次要有一个梳理。

性能与安全:

性能与安全也是一个需要考虑的因素,往往大家注重性能忽略安全或注重安全又忽略性能。比如说我们在设计防火墙时,如果规则过于全面肯定会对性能方面有影响。如果对性能过于注重在安全方面肯定会留下很大隐患。所以大家要评估好两者的关系,把握好两者的孰重孰轻,以及整体的相关性。权衡好对应的点。

系统与nginx性能优化

大家对相关的系统瓶颈及现状有了一定的了解之后,就可以根据影响性能方面做一个全体的评估和优化。

  • 网络(网络流量、是否有丢包,网络的稳定性都会影响用户请求)
  • 系统(系统负载、饱和、内存使用率、系统的稳定性、硬件磁盘是否有损坏)
  • 服务连接优化、内核性能优化、http服务请求优化都可以在nginx中根据业务来进行设置
  • 程序(接口性能、处理请求速度、每个程序的执行效率)
  • 数据库、底层服务

上面列举出来每一级都会有关联也会影响整体性能这里主要关注的是nginx服务这一层

3. 文件句柄数

在linux/unix操作系统中一切皆文件我们的设备是文件文件是文件文件夹也是文件。当我们用户每发起一次请求就会产生一个文件句柄。文件句柄可以简单的理解为文件句柄就是一个索引。文件句柄就会随着请求量的增多,进程调用频繁增加,那么产生的文件句柄也就会越多。

系统默认对文件句柄是有限制的不可能会让一个进程无限制的调用句柄。因为系统资源是有限的所以我们需要限制每一个服务能够使用多大的文件句柄。操作系统默认使用的文件句柄是1024个句柄。

设置方式:

  • 系统全局性修改
  • 用户局部性修改
  • 进程局部性修改(服务)

系统全局性修该和用户局部性修改:

ulimit -n 65535

参数解释:

-a  显示目前资源限制的设定。
-c <core文件上限>  设定core文件的最大值单位为区块。
-d <数据节区大小>  程序数据节区的最大值单位为KB。
-f <文件大小>  shell所能建立的最大文件单位为区块。
-H  设定资源的硬性限制,也就是管理员所设下的限制。
-m <内存大小>  指定可使用内存的上限单位为KB。
-n <文件数目>  指定同一时间最多可开启的文件数。
-p <缓冲区大小>  指定管道缓冲区的大小单位512字节。
-s <堆叠大小>  指定堆叠的上限单位为KB。
-S  设定资源的弹性限制。
-t <CPU时间>  指定CPU使用时间的上限单位为秒。
-u <程序数目>  用户最多可开启的程序数目。
-v <虚拟内存大小>  指定可使用的虚拟内存上限单位为KB

4. cpu 亲和力

cpu的亲和能够使nginx对于不同的work工作进程绑定到不同的cpu上面去。就能够减少在work间不断切换cpu把进程通常不会在处理器之间频繁迁移进程迁移的频率小来减少性能损耗。

查看物理cpu
[root@test ~]#  cat /proc/cpuinfo | grep "physical id" | sort|uniq | wc -l
查看cpu核心数
[root@test ~]#  cat /proc/cpuinfo | grep "cpu cores"|wc -l
查看cpu使用率
[root@test ~]#  top  回车后按 1
[root@test ~]# vim /etc/nginx/nginx.conf
worker_cpu_affinity auto;

5. work_processes

[root@test ~]# vim /etc/nginx/nginx.conf
将刚才查看到自己cpu * cpu核心就是worker_processes
worker_processes 2; #根据自己cpu核心数配置/这里也可以设置为auto

6. 通用配置

#将nginx进程设置为普通用户为了安全考虑
user nginx; 

#当前启动的worker进程官方建议是与系统核心数一致
worker_processes 2;
#方式一,就是自动分配绑定
worker_cpu_affinity auto;

#日志配置成warn
error_log /var/log/nginx/error.log warn; 
pid /var/run/nginx.pid;

#针对 nginx 句柄的文件限制
worker_rlimit_nofile 35535;
#事件模型
events {
    #使用epoll内核模型
    use epoll;
    #每一个进程可以处理多少个连接,如果是多核可以将连接数调高 worker_processes * 1024
    worker_connections 10240;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    charset utf-8;  #设置字符集

    #设置日志输出格式,根据自己的情况设置
    log_format  main  '$http_user_agent' '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" '
                      '"$args" "$request_uri"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;   #对静态资源的处理比较有效
    #tcp_nopush     on;   #如果做静态资源服务器可以打开
    #tcp_nodeny     on;   #当nginx做动态的服务时可以选择打开

    keepalive_timeout  65; 

    ########
    #Gzip module
    gzip  on;    #文件压缩默认可以打开
    gzip_disable "MSIE [1-6]\."; #对于有些浏览器不能识别压缩需要过滤如ie6
    gzip_http_version 1.1;

    include /etc/nginx/conf.d/*.conf;
}