nginx详解+实操_04

[TOC]

HTTPS 介绍

HTTPS（全称：HyperText Transfer Protocol over Secure Socket Layer），其实 HTTPS 并不是一个新鲜协议，Google 很早就开始启用了，初衷是为了保证数据安全。 近些年，Google、Baidu、Facebook 等这样的互联网巨头，不谋而合地开始大力推行 HTTPS， 国内外的大型互联网公司很多也都已经启用了全站 HTTPS，这也是未来互联网发展的趋势。

HTTPS是基于HTTP的安全版。以下是HTTPS的一些关键特点：

1. 保密性：通过SSL/TLS协议和加密算法，HTTPS保证了数据在传输过程中的保密性，防止数据被窃听。
2. 完整性：HTTPS确保数据在传输过程中不被篡改，保持数据的完整性。
3. 认证：通过数字证书，HTTPS能够验证通信双方的身份，防止身份伪造。
4. 加密算法：HTTPS使用了混合加密算法，即结合了对称加密和非对称加密的优势。。
5. 握手过程：在数据传输开始前，HTTPS会进行一个SSL/TLS握手过程，以确保通信双方协商一致的加密参数和密钥。
6. 性能影响：虽然HTTPS提供了更高的安全性，但它也可能会对性能产生一定影响，比如增加数据传输的开销。然而，随着技术的进步，这种影响正在逐渐减小。

HTTPS是一个重要的网络安全措施，它通过加密和身份验证机制来保护数据的安全，防止数据泄露和中间人攻击。随着技术的发展和安全需求的增加，HTTPS已经成为互联网通信的标准做法。

1、加密算法

1.1 对称加密

A要给B发送数据--->A做一个对称密钥--->使用密钥给文件加密--->发送加密以后的文件和钥匙--->B拿钥匙解密--->加密和解密都是使用的同一个密钥。

对称加密的过程涉及使用相同的密钥进行数据的加密和解密。

首先，对称加密也称为私钥加密，是一种加密方法，其中发送方和接收方使用同一个密钥来进行数据的加密和解密。这种方法的算法是公开的，而密钥则是保密的，需要通过安全的方式共享给通信的双方。其具有以下特点：

• 加密过程：在加密阶段，发送方会使用特定的加密算法和共享的密钥（私钥）将明文（原始数据）转换成密文（加密后的数据）。这个过程可以表示为：明文 + 加密算法 + 私钥 => 密文。
• 解密过程：接收方在收到密文后，使用相同的解密算法和密钥将密文还原成明文。解密过程可以表示为：密文 + 解密算法 + 私钥 => 明文。

此外，由于加密和解密使用的是同一个密钥，因此这种加密方式称为对称加密。这种方法的优点是加密和解密速度快，适合对大量数据进行加密。然而，它的缺点在于密钥的安全管理较为困难，因为如果密钥被泄露，那么加密的数据就可能被破解。

1.2 非对称加密 —- 公钥加密，私钥解密

A要给B发送数据--->B做一对非对称的密钥（公钥、私钥）--->发送公钥给A--->A拿公钥对数据进行加密--->发送加密后的数据给B--->B拿私钥解密

非对称加密的过程涉及使用一对密钥，即公钥和私钥，其中公钥用于加密数据，私钥用于解密数据。以下是非对称加密的主要步骤：

1. 密钥生成：需要生成一对密钥，通常通过计算得到一个公钥和一个私钥。私钥必须保密，而公钥可以安全地公开分发给客户端。
2. 加密过程：当需要向某人发送加密信息时，发送方会使用接收方的公钥对信息进行加密。这意味着只有拥有对应私钥的接收方才能解密这些信息。
3. 解密过程：接收方收到加密信息后，将使用其私钥对其进行解密，从而获得原始信息。由于私钥是保密的，因此即使信息在传输过程中被拦截，没有私钥的人也无法读取内容。
4. 安全性：非对称加密的一个关键优势是解决了密钥配送问题，即不需要通过不安全的通道发送密钥给对方。这是因为即使公钥被泄露，没有对应的私钥也无法解密信息。
5. 性能考虑：非对称加密的处理速度通常远低于对称加密，因此它不适合用于加密大量数据。

非对称加密提供了一种在不安全的环境中安全交换信息的方法，尽管它的性能不如对称加密，但其在保护数据传输的安全性方面发挥着至关重要的作用。

1.3 哈希算法

将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多。它将任意长度的输入数据映射为固定长度输出的数学计算机程序，具有不可逆性、唯一性和高效性等特点。

例如：/etc/shadow文件中的用户密码

• 随机性：看起来是随机的，以减少潜在的模式识别攻击。
• 固定长度：无论输入数据的长度如何，输出的散列值长度总是固定的。

例如：MD5 等

1.4 数字签名

数字签名是一种电子签名技术，它利用非对称加密和数字摘要技术来验证信息的真实性和完整性。简单认为人民币上的一道防伪线。

数字签名的核心在于使用一对非对称密钥，即公钥和私钥。私钥用于生成签名，而公钥用于验证签名。这种机制确保了信息的发送者身份可以被验证，并且信息在传输过程中未被篡改。以下是数字签名的主要特点和功能：

首先，数字签名能够验证消息或信息确实来自于发送方。在HTTPS中，当客户端与服务器进行通信时，服务器会提供一个包含数字签名的证书。这个证书由受信任的第三方机构（如证书颁发机构）签发，并且包含了服务器的公钥和身份信息。客户端会使用证书颁发机构的公钥来验证服务器证书的数字签名，确保证书未被篡改，并且确实是由证书颁发机构授权的服务器所发出的。

其次，数字签名还用于确保数据在传输过程中的完整性。当数据在网络中传输时，可能会被第三方截获并篡改。通过使用哈希函数对数据生成摘要，并用私钥加密这个摘要，形成了数字签名。接收方在收到数据后，会用同样的哈希函数计算数据摘要，并用发送方的公钥解密数字签名得到原始摘要，通过比对这两个摘要，可以确认数据是否在传输过程中被篡改。

此外，数字签名的使用还有助于防止中间人攻击，即攻击者试图在客户端和服务器之间插入自己的通信，以截获或篡改信息。HTTPS协议通过结合数字签名和SSL/TLS协议，为客户端和服务器之间的通信提供了加密通道，确保了数据传输的安全性。

数字签名在HTTPS协议中扮演着至关重要的角色，它不仅帮助用户验证他们正在与正确的服务器通信，而且还确保了数据在传输过程中的安全和完整。这些机制共同作用，使得HTTPS成为一种安全可靠的通信协议。

---

2、HTTPS 协议介绍

HTTP 协议（Hyper Text 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 Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层为数据通讯进行加密提供安全支持。

  SSL协议可分为两层：

• SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。相当于连接

• SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 相当于通信

SSL协议的工作原理是：

• 在传输层对数据进行加密，以保护所有应用层协议的数据传输安全。
• 使用公开密钥和私有密钥两种加密方法，其中公钥用于加密数据，私钥用于解密数据。
• 在应用层协议通信之前完成加密算法、通信密钥的协商以及服务器认证工作，之后应用层协议所传送的数据都会被加密。

SSL协议提供的服务主要有：

• 身份认证和数据加密。保证数据完整性；
• 认证用户和服务器，确保数据发送到正确的客户机和服务器；
• 加密数据以防止数据中途被窃取后，数据泄露和篡改；
• 维护数据的完整性，确保数据在传输过程中不被改变。

3、HTTPS 原理

3.1 HTTP 访问过程

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

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

所以 HTTP 传输面临的风险有：

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

3.2 Https访问流程

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

（1）首先浏览器读取证书中的证书所有者、有效期等信息进行校验

（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发

（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。

（4）如果找到，那么浏览器就会从操作系统中取出颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密

（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比

（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充

（7）此时浏览器就可以读取证书中的公钥，用于后续加密了

(8）client与web协商对称加密算法，client生成一个对称加密密钥并使用web公钥加密，发送给web服务器，web服务器使用web私钥解密

(9)使用对称加密密钥传输数据，并校验数据的完整性

3.3 HTTPS相比HTTP的优势

相比HTTP，HTTPS 传输更加安全， 所有信息都是加密传播，黑客无法窃听。具有校验机制，一旦被篡改，通信双方会立刻发现。 配备身份证书，防止身份被冒充。

3.4 HTTPS 总结

综上所述，相比 HTTP 协议，HTTPS 协议增加了很多握手、加密解密等流程，虽然过程很复杂，但其可以保证数据传输的安全。

3.5 HTTPS 缺点

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

4、Nginx 性能优化

当我需要进行性能优化时，说明我们服务器无法满足日益增长的业务。性能优化是一个比较大的课题，需要从以下几个方面进行探讨

• 当前系统结构瓶颈
• 了解业务模式
• 性能与安全

4.1 当前系统结构瓶颈

首先需要了解的是当前系统瓶颈，用的是什么，跑的是什么业务。里面的服务是什么样子，每个服务最大支持多少并发。比如针对Nginx而言，我们处理静态资源效率最高的瓶颈是多大？

可以通过查看当前cpu负荷，内存使用率，进程使用率来做简单判断。还可以通过操作系统的一些工具来判断当前系统性能瓶颈，如分析对应的日志，查看请求数量。也可以通过nginx http_stub_status_module模块来查看对应的连接数，总握手次数，总请求数。也可以对线上进行压力测试，来了解当前的系统的性能，并发数，做好性能评估。

4.2 了解业务模式

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

4.3 性能与安全

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

4.4 系统与Nginx性能优化

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

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

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

4.4.1 文件句柄

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

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

4.4.2 设置方式

• 系统全局性修改
• 用户局部性修改
• 进程局部性修改

4.4.3 系统全局性修改和用户局部性修改

[root@nginx-server ~]# vim /etc/security/limits.conf

#*               soft    core            0
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#@student        -       maxlogins       4

#root只是针对root这个用户来限制，soft只是发提醒，操作系统不会强制限制,一般的站点设置为一万左右就ok了
# 单个用户配置
root soft nofile 65535
root hard nofile 65535
nginx soft nofile 65535
nginx hard nofile 65535
# *代表通配符 所有的用户
*    soft nofile 25535
*    hard nofile 25535

可以看到root和*，root代表是root用户，*代表的是所有用户，后面的数字就是文件句柄大小。大家可以根据个人业务来进行设置。

4.4.4 进程局部性修改

[root@nginx-server ~]# vim /etc/nginx/nginx.conf
user  nginx;
worker_processes  1; aut

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

worker_rlimit_nofile 65535; #进程限制

events {
    worker_connections  1024; #最大连接数
}

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

    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; 

    keepalive_timeout  65; 

    #gzip  on; 

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

• worker_rlimit_nofile 是在进程上面进行限制。

  是用来设置 NGINX 工作进程打开的文件描述符的限制。文件描述符是操作系统用来跟踪已打开文件的一种机制。这个设置用来确保 NGINX 工作进程能够处理足够数量的并发连接和文件操作。
  要设置合适的 worker_rlimit_nofile，你可以参考以下步骤：
  了解系统默认限制：首先，了解你的操作系统默认的文件描述符限制。你可以通过命令 ulimit -n 来查看。如果默认值已经足够高，你可能不需要进行额外的设置。
  考虑 NGINX 的工作负载：根据你的 NGINX 应用程序的工作负载和预期的并发连接数，决定是否需要增加文件描述符的限制。如果你的 NGINX 应用程序会频繁地打开和关闭文件，或者处理大量的并发连接，可能需要增加限制。
  设置合适的值：根据系统和应用程序的需求，设置一个合适的值。通常情况下，可以将 worker_rlimit_nofile 设置为操作系统默认限制的两倍或者更高，以确保 NGINX 能够处理预期的并发连接和文件操作。但是，不要将其设置得太高以至于超过操作系统的最大限制。
  例如，如果你的操作系统默认限制是1024，而你的 NGINX 应用程序预期处理的并发连接数较高，你可以将 worker_rlimit_nofile 设置为 1048 或更高。

• worker_connections是 NGINX 用来限制单个工作进程所能处理的最大并发连接数。

  这个设置应该根据你的服务器硬件配置、预期的并发连接数以及 NGINX 所处理的工作负载来进行调整。
  一般来说，你可以通过以下步骤来设置合适的 worker_connections：
  了解硬件配置和预期负载：首先要了解你的服务器硬件配置，包括 CPU、内存和网络带宽。另外，需要预估你的网站或应用程序的预期并发连接数。这可以通过历史数据、用户量估算或者负载测试来确定。
  计算最大并发连接数：结合你的硬件配置和预期负载，可以计算出你的服务器可以支持的最大并发连接数。这个计算并不是精确的，但是可以给你一个大致的指导。
  设置合适的 worker_connections：根据你的计算结果和 NGINX 的最佳实践，设置 worker_connections。通常来说，这个值应该略高于你预期的并发连接数，以留有一定的余地，但也不要设置得太高以至于超过服务器硬件的承载能力。
  例如，如果你的服务器配置为4核8线程CPU，16GB内存，预期的并发连接数为1000个，你可以设置 worker_connections 为 1024 或者稍高一些，比如 2048。但是如果你的服务器硬件配置较低，比如双核CPU和较少内存，你可能需要将 worker_connections 设置得更低一些，以避免性能问题。

4.5 cpu的亲和配置

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

查看cpu核心数

[root@nginx-server ~]# cat /proc/cpuinfo|grep "cpu cores"|uniq

查看cpu使用率

[root@nginx-server ~]#top  回车后按 1

4.5.1 配置worker_processes

[root@nginx-server ~]# vim /etc/nginx/nginx.conf

将刚才查看到自己cpu * cpu核心就是worker_processes
worker_processes 2; #根据自己cpu核心数配置/这里也可以设置为auto

假设 配置是2cpu，每个cpu是8核，配置如下：

worker_processes 16;
worker_cpu_affinity 1010101010101010 0101010101010101;

在nginx 1.9版本之后，就帮我们自动绑定了cpu;

worker_cpu_affinity auto;

4.6 nginx通用配置优化

#将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; # 或者1024的倍数
#事件模型
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;   #如果做静态资源服务器可以打开

    keepalive_timeout  65; 

    ########
    #Gzip module
    gzip  on;    #文件压缩默认可以打开

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

• tcp_nopush 是一个 NGINX 配置指令，用于控制 TCP 连接的数据传输方式。当设置为 on 时，它告诉 NGINX 在发送 HTTP 响应时尽可能快地发送响应头部，并且在发送响应体时尽量避免发送小数据包，尽量等待更多的数据再发送。这样做可以减少数据包的数量，提高传输效率。

• sendfile 是一个 NGINX 配置指令，用于控制 NGINX 是否使用 sendfile 系统调用来发送文件。当设置为 on 时，它告诉 NGINX 使用 sendfile 系统调用来直接在内核空间和文件系统之间传输文件，而不需要将文件数据从内核复制到用户空间再发送，这样可以提高文件传输的效率。sendfile 是一种零拷贝（Zero-Copy）技术，它允许操作系统直接从磁盘读取文件并发送到网络，而无需将文件数据在内核空间和用户空间之间复制。这种方法可以减少 CPU 和内存的使用，提高文件传输的效率，并且减少了系统调用的次数。在高负载和高并发的情况下，使用 sendfile on; 可以显著提高 NGINX 的性能和吞吐量。但是，需要注意的是，sendfile 对于小文件的传输可能并不总是最有效的，因为它可能会导致内存碎片和额外的内核开销。总的来说，通常情况下将 sendfile on; 设置为 on 是推荐的做法，特别是在处理大文件和高并发的网络环境下可以提高性能。

• keepalive_timeout 是 NGINX 的一个配置指令，用于设置 HTTP Keep-Alive 连接的超时时间。HTTP Keep-Alive 是一种机制，它允许客户端和服务器之间的 TCP 连接在处理完一个请求后保持打开状态一段时间，以便在该时间段内发送更多的请求。

  当设置 keepalive_timeout 时，你指定了 NGINX 在收到一个 HTTP 请求后，等待客户端发出下一个请求的最长时间。如果在指定的时间内没有收到新的请求，则 NGINX 将关闭该连接。

  在高并发的网络环境中，使用 HTTP Keep-Alive 可以减少 TCP 连接的建立和关闭次数，从而降低服务器的负载，并提高客户端和服务器之间的响应速度。

  通常来说，将 keepalive_timeout 设置为一个合理的值可以有效地平衡服务器资源和客户端响应时间之间的关系。如果设置得太短，可能会导致客户端频繁地重新建立连接，增加了服务器的负载；而设置得太长，则可能会占用服务器资源，导致服务器无法及时释放不再使用的连接。

  根据实际情况，你可以根据以下几点来决定 keepalive_timeout 的值：

  1. 网站或应用程序的性能需求：根据你的网站或应用程序的性能需求来调整超时时间。如果你的网站需要快速响应客户端请求，你可能需要将超时时间设置得较短；如果你的网站或应用程序是一个长期交互的应用，你可以将超时时间设置得更长一些。
  2. 客户端和网络条件：考虑客户端和网络条件。如果你的用户处于高延迟或不稳定的网络环境中，你可能需要将超时时间设置得更长，以确保他们有足够的时间发出下一个请求。
  3. 服务器资源：考虑你的服务器资源情况。如果你的服务器资源有限，你可能需要将超时时间设置得较短，以释放不再使用的连接并释放资源。

• gzip on; 是 NGINX 的一个配置指令，用于启用 HTTP 响应内容的压缩功能。当设置为 on 时，NGINX 将会对 HTTP 响应的内容进行压缩，以减小传输过程中的数据量，提高网站的加载速度，并降低网络带宽的使用。

  启用 gzip 压缩功能可以带来以下好处：

  1. 减小文件大小：通过压缩 HTTP 响应的内容，可以显著减小传输过程中的数据量，尤其对于文本文件（如 HTML、CSS、JavaScript）效果更为明显。
  2. 提高网站加载速度：减小文件大小意味着客户端需要下载的数据量更少，从而可以加快网站的加载速度，改善用户体验。
  3. 降低网络带宽的使用：通过减小传输的数据量，可以降低服务器和网络带宽的使用，节省服务器资源和网络成本。

  虽然启用 gzip 压缩功能可以提高网站的性能和用户体验，但也需要注意以下几点：

  • CPU 资源消耗：对内容进行压缩需要消耗一定的 CPU 资源，特别是在高流量的网络环境中，可能会对服务器的 CPU 负载产生一定影响。因此，在启用 gzip 压缩功能时，需要根据服务器的 CPU 资源和实际负载来进行评估和调整。
  • 压缩级别：NGINX 默认使用适中的压缩级别来平衡压缩比和 CPU 消耗。

5、ab接口压力测试工具(扩展)

ab是Apache超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒可以处理多少个请求。

[root@nginx-server ~]# yum install httpd-tools -y
[root@nginx-server ~]# ab -n 2000 -c 2 http://127.0.0.1/
-n 总的请求数
-c 并发数

1、参数选项

-n：即requests，用于指定压力测试总共的执行次数
-c：即concurrency，用于指定的并发数
-t：即timelimit，等待响应的最大时间(单位：秒)
-b：即windowsize，TCP发送/接收的缓冲大小(单位：字节)
-p：即postfile，发送POST请求时需要上传的文件，此外还必须设置-T参数
-u：即putfile，发送PUT请求时需要上传的文件，此外还必须设置-T参数
-T：即content-type，用于设置Content-Type请求头信息，例如：application/x-www-form-urlencoded，默认值为text/plain
-v：即verbosity，指定打印帮助信息的冗余级别
-w：以HTML表格形式打印结果
-i：使用HEAD请求代替GET请求
-x：插入字符串作为table标签的属性
-y：插入字符串作为tr标签的属性
-z：插入字符串作为td标签的属性
-C：添加cookie信息，例如："Apache=1234"(可以重复该参数选项以添加多个)
-H：添加任意的请求头，例如："Accept-Encoding: gzip"，请求头将会添加在现有的多个请求头之后(可以重复该参数选项以添加多个)
-A：添加一个基本的网络认证信息，用户名和密码之间用英文冒号隔开
-P：添加一个基本的代理认证信息，用户名和密码之间用英文冒号隔开
-X：指定使用的和端口号，例如:"126.10.10.3:88"
-V：打印版本号并退出
-k：使用HTTP的KeepAlive特性
-d：不显示百分比
-S：不显示预估和警告信息
-g：输出结果信息到gnuplot格式的文件中
-e：输出结果信息到CSV格式的文件中
-r：指定接收到错误信息时不退出程序
-H：显示用法信息，其实就是ab -help

2、内容解释

Server Software:        nginx/1.10.2 (服务器软件名称及版本信息)
Server Hostname:        192.168.1.106(服务器主机名)
Server Port:            80 (服务器端口)

Document Path:          /index1.html. (供测试的URL路径)
Document Length:        3721 bytes (供测试的URL返回的文档大小)

Concurrency Level:      1000 (并发数)
Time taken for tests:   2.327 seconds (压力测试消耗的总时间)
Complete requests:      5000 (的总次数)
Failed requests:        688 (失败的请求数)
Write errors:           0 (网络连接写入错误数)
Total transferred:      17402975 bytes (传输的总数据量)
HTML transferred:       16275725 bytes (HTML文档的总数据量)
Requests per second:    2148.98 [#/sec] (mean) (平均每秒的请求数) 这个是非常重要的参数数值，服务器的吞吐量 
Time per request:       465.338 [ms] (mean) (所有并发用户(这里是1000)都请求一次的平均时间)
Time  request:       	0.247 [ms] (mean, across all concurrent requests) (单个用户请求一次的平均时间)
Transfer rate:          7304.41 [Kbytes/sec] received 每秒获取的数据长度 (传输速率，单位：KB/s)
...
Percentage of the requests served within a certain time (ms)
  50%    347  ## 50%的请求在347ms内返回 
  66%    401  ## 60%的请求在401ms内返回 
  75%    431
  80%    516
  90%    600
  95%    846
  98%   1571
  99%   1593
  100%   1619 (longest request)

3、示例演示

注意事项

● 测试机与被测试机要分开

● 不要对线上的服务器做压力测试

● 观察测试工具ab所在机器，以及被测试的机器的CPU、内存、网络等都不超过最高限度的75%

[root@nginx-server ~]# ab -n 50 -c 2 http://www.testpm.cn/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.testpm.cn (be patient).....done


Server Software:        nginx/1.16.0
Server Hostname:        www.testpm.cn
Server Port:            80

Document Path:          /
Document Length:        612 bytes

Concurrency Level:      2
Time taken for tests:   2.724 seconds
Complete requests:      50
Failed requests:        0
Write errors:           0
Total transferred:      42250 bytes
HTML transferred:       30600 bytes
Requests per second:    18.35 [#/sec] (mean)
Time per request:       108.968 [ms] (mean)
Time per request:       54.484 [ms] (mean, across all concurrent requests)
Transfer rate:          15.15 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       42   52  17.3     46     137
Processing:    43   54  20.8     47     170
Waiting:       42   53  20.7     47     170
Total:         84  106  28.9     93     219

Percentage of the requests served within a certain time (ms)
  50%     93
  66%     96
  75%    101
  80%    130
  90%    153
  95%    161
  98%    219
  99%    219
 100%    219 (longest request)