Nginx 服务器调优

SunnyFan大约 21 分钟约 6174 字

Nginx 服务器调优

Nginx 的系统结构

Nginx 包含一个单一的 master 进程和多个 worker 进程。所有的这些进程都是单线程，并且设计为同时处理成千上万个连接。worker 进程是处理连接的地方，它用于处理客户端请求。master 进程负责读取配置文件、处理套接字、派生 worker 进程、打开日志文件等。总之， master 进程是一个可以通过处理信号响应来管理请求的进程。

Nginx 性能参数调优

常规参数讲解

进入 /etc/nginx 文件夹，编辑 nginx.conf ，可以看到下面的参数。简单介绍下：

# nginx进程数，建议按照cpu数目来指定，一般跟cpu核数相同或为它的倍数。
worker_processes 8;

# 每个worker 进程的最大连接数
worker_connections 1024;

#为每个进程分配cpu，上例中将8个进程分配到8个cpu，当然可以写多个，或者将一个进程分配到多个cpu。
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

# 作用于event的I/O多路复用模型
use epoll;

#收到新连接通知后接受尽可能多的连接，作用于event
multi_accept on;

epoll 接口作为 poll 接口的变体在 Linux 内核 2.5 中被引入。相比 select 实现的多路复用 I/O 模型，epoll 最大的好处在于它不会随着被监控描述符数目的增长而导致效率急速下降。

worker_processes number;

每个worker进程都是单线程的进程，它们会调用各个模块以实现多种多样的功能。如果这些模块确认不会出现阻塞式的调用，那么，有多少CPU内核就应该配置多少个进程；反之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。例如，如果业务方面会致使用户请求大量读取本地磁盘上的静态资源文件，而且服务器上的内存较小，以至于大部分的请求访问静态资源文件时都必须读取磁盘（磁头的寻址是缓慢的），而不是内存中的磁盘缓存，那么磁盘I/O调用可能会阻塞住worker进程少量时间，进而导致服务整体性能下降。

每个worker 进程的最大连接数

语法：worker_connections number;

默认：worker_connections 1024;

worker_cpu_affinity cpumask[cpumask……]

绑定Nginx worker进程到指定的CPU内核

为什么要绑定worker进程到指定的CPU内核呢？假定每一个worker进程都是非常繁忙的，如果多个worker进程都在抢同一个CPU，那么这就会出现同步问题。反之，如果每一个worker进程都独享一个CPU，就在内核的调度策略上实现了完全的并发。

例如，如果有4颗CPU内核，就可以进行如下配置：

worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;

注意 worker_cpu_affinity配置仅对Linux操作系统有效。

查看当前机器cpu

# 查看当前机器物理cpu数量
cat /proc/cpuinfo|grep "physical id"|sort|uniq|wc -l
# 1
# 查看当前机器物理cpu核心数量
cat /proc/cpuinfo|grep "cpu cores"|uniq
#cpu cores : 2

Nginx worker 进程优先级设置

语法：worker_priority nice;

默认：worker_priority 0;

优先级由静态优先级和内核根据进程执行情况所做的动态调整（目前只有±5的调整）共同决定。nice值是进程的静态优先级，它的取值范围是–20～+19，–20是最高优先级，+19是最低优先级。因此，如果用户希望Nginx占有更多的系统资源，那么可以把nice值配置得更小一些，但不建议比内核进程的nice值（通常为–5）还要小

Nginx worker进程可以打开的最大句柄描述符个数

语法： worker_rlimit_nofile limit;

默认：空

更改worker进程的最大打开文件数限制。如果没设置的话，这个值为操作系统的限制。设置后你的操作系统和Nginx可以处理比“ulimit -a”更多的文件，所以把这个值设高，这样nginx就不会有“too many open files”问题了。

是否打开accept锁

语法：accept_mutex[on|off]

默认：accept_mutext on;

accept_mutex是Nginx的负载均衡锁，当某一个worker进程建立的连接数量达到worker_connections配置的最大连接数的7/8时，会大大地减小该worker进程试图建立新TCP连接的机会，accept锁默认是打开的，如果关闭它，那么建立TCP连接的耗时会更短，但worker进程之间的负载会非常不均衡，因此不建议关闭它。

使用accept锁后到真正建立连接之间的延迟时间

语法：accept_mutex_delay Nms;

默认：accept_mutex_delay 500ms;

在使用accept锁后，同一时间只有一个worker进程能够取到accept锁。这个accept锁不是堵塞锁，如果取不到会立刻返回。如果只有一个worker进程试图取锁而没有取到，他至少要等待accept_mutex_delay定义的时间才能再次试图取锁。

Nginx 高速缓存实战

案例分析

某电商平台商品详情页需要实现 700+ QPS，如何着手去做？

对于商品详情页涉及了如下主要服务：

商品详情页HTML页面渲染
价格服务
促销服务
库存状态/配送至服务
广告词服务
预售/秒杀服务
评价服务
试用服务
推荐服务
商品介绍服务
各品类相关的一些特殊服务

解决方案：

采用Ajax 动态加载价格、广告、库存等服务
采用key value 缓存详情页主体html。

方案架构：

问题：

当达到500QPS 的时候很难继续压测上去。

分析原因：

一个详情页html 主体达平均150 kb 那么在500QPS 已接近千M局域网宽带极限。必须减少内网通信。

基于Nginx 静态缓存的解决方案：

缓存配置

配置步骤

客户端、代理请求缓存
设置缓存空间，存储缓存文件
在 location 中使用缓存空间
打开文件的缓存配置

#客户端请求主体的缓冲区大小
client_body_buffer_size 512k;
#客户端请求头部的缓冲区大小，这个可以根据系统分页大小来设置
client_header_buffer_size 4k;
client_max_body_size 512k;
large_client_header_buffers 2 8k;
proxy_buffer_size 16k;
proxy_buffers 4 64k;
proxy_busy_buffers_size 128k;
proxy_temp_file_write_size 128k;
#指定在何种情况下一个失败的请求应该被发送到下一台后端服务器
proxy_next_upstream http_502 http_504 http_404 error timeout invalid_header;

#设置缓存空间，存储缓存文件
proxy_cache_path /usr/local/nginx/cache levels=1:2 keys_zone=nginx-cache:20m max_size=50g inactive=168h;

#在location中使用缓存空间，pathname是项目的目录，请自定义
location /pathname { 
	proxy_set_header X-Real-IP $remote_addr;
	proxy_cache nginx-cache;
	proxy_cache_valid 200 304 302 5d;
	proxy_cache_valid any 5d;
	proxy_cache_key '$host:$server_port$request_uri';
	add_header X-Cache '$upstream_cache_status from $host';
	proxy_set_header X-Real-IP $remote_addr;
	proxy_pass http://localhost/pathname;
}

#打开文件的缓存配置
#为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。
open_file_cache max=65535 inactive=60s;

#文件描述符一直是在缓存中打开的，如果有一个文件在inactive时间内一次没被使用，它将被移除。
open_file_cache_min_uses 1;

#指定多长时间检查一次缓存的有效信息。
open_file_cache_valid 80s;

缓存参数详细说明

父元素	名称	描述
http	proxy_cache_path	指定缓存区的根路径
	levels	缓存目录层级最高三层，每层1~2个字符表示。如1:1:2 表示三层。
	keys_zone	缓存块名称及内存块大小。如 cache_item:500m 。表示声明一个名为cache_item 大小为500m。超出大小后最早的数据将会被清除。
	inactive	最长闲置时间如:10d 如果一个数据被闲置10天将会被清除
	max_size	缓存区硬盘最大值。超出闲置数据将会被清除
location	proxy_cache	指定缓存区，对应keys_zone 中设置的值
	proxy_cache_key	通过参数拼装缓存key 如：hosthosthosturiisargsis_argsisargsargs 则会以全路径md5值做做为Key
	proxy_cache_valid	为不同的状态码设置缓存有效期

查看缓存目录

上述配置的结果，重启生效后，我们可以看到生成了很多缓存文件在缓存存储路径为：/usr/local/nginx/cache，levels=1:2代表缓存的目录结构为2级目录如下图，缓存会在/usr/local/nginx/cache目录下生成，包含2级目录，在之下就是缓存文件，测试的时候可以到该目录下查看缓存文件是否生成。

我们打开其中一个文件看看，会发现一些蹊跷，这里存储了请求头的信息。当我们处理一个 HTTP 请求的时候，它会先从这里读取。

缓存的清除

该功能可以采用第三方模块 ngx_cache_purge 实现。**为nginx 添加 ngx_cache_purge 模块**

#下载ngx_cache_purge 模块包 ,这里nginx 版本为1.6.2 purge 对应2.0版
wget http://labs.frickle.com/files/ngx_cache_purge-2.3.tar.gz
#查看已安装模块
./sbin/nginx -V
#进入nginx安装包目录 重新安装 --add-module为模块解压的全路径
./configure --prefix=/root/svr/nginx --with-http_stub_status_module --with-http_ssl_module --add-module=/root/svr/nginx/models/ngx_cache_purge-2.0
#重新编译
make
#拷贝 安装目录/objs/nginx 文件用于替换原nginx 文件
#检测查看安装是否成功
nginx -t

清除配置：

location ~ /clear(/.*) {
  #允许访问的IP
   allow           127.0.0.1;
   allow           192.168.0.193;
   #禁止访问的IP
   deny            all;
   #配置清除指定缓存区和路径(与proxy_cache_key一至)
   proxy_cache_purge    cache_item '$host:$server_port$request_uri';
}

配置好以后直接访问：这里 192.168.0.193 域名设置为 www.test.comopen in new window

# 访问生成缓存文件
http://www.test.com/?a=1
# 清除生成的缓存,如果指定缓存不存在 则会报404 错误。
http://www.test.com/clear/?a=1

指定不缓存页面

配置语法:

proxy_no_cache
语法	proxy_no_cache string …

| 默认 | — |

| 作用域 | http,server,location |

| 备注 | |

例子:

 ...

# 判断当前路径是否是指定的路径
if($request_uri ~ ^/(url3|login|register|password\/reset)) {
		#设置一个变量用来存储是否是需要缓存
  	set $cookie_nocache 1;
}

location / {
 		...

    proxy_no_cache $cookie $arg_nocache $arg_comment;

    ...
}

缓存命中分析

在http header上增加命中显示

Nginx 提供了 $upstream_cache_status 这个变量来显示缓存的状态，我们可以在配置中添加一个http头来显示这一状态，达到类似squid的效果。

 location  / {
        proxy_redirect          off;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_connect_timeout   180;
        proxy_send_timeout      180;
        proxy_read_timeout      180;
        proxy_buffer_size       128k;
        proxy_buffers           4 128k;
        proxy_busy_buffers_size 128k;
        proxy_temp_file_write_size 128k;
        proxy_cache nginx-cache;
        proxy_cache_valid 200 304 1h;
        proxy_cache_valid 404 1m;
        proxy_cache_key '$host:$server_port$request_uri';
        add_header  Nginx-Cache "$upstream_cache_status";
        proxy_pass http://backend;
    }

而通过curl或浏览器查看到的header如下：

HTTP/1.1 200 OK
Date: Mon, 22 Apr 2013 02:10:02 GMT
Server: nginx
Content-Type: image/jpeg
Content-Length: 23560
Last-Modified: Thu, 18 Apr 2013 11:05:43 GMT
Nginx-Cache: HIT
Accept-Ranges: bytes
Vary: User-Agent

$upstream_cache_status 包含以下几种状态：

MISS 未命中，请求被传送到后端
HIT 缓存命中
EXPIRED 缓存已经过期请求被传送到后端
UPDATING 正在更新缓存，将使用旧的应答
STALE 后端将得到过期的应答

Nginx cache命中率统计

即然nginx为我们提供了$upstream_cache_status函数，自然可以将命中状态写入到日志中。具体可以如下定义日志格式：

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"'
                  '"$upstream_cache_status"';

命中率统计方法：用HIT的数量除以日志总量得出缓存命中率：

了解了原理以后，也可以通过crontab脚本将每天的命中率统计到一个日志中，以备查看。

# crontab -l
1 0 * * * /opt/&lt;a href="http://www.test.com/" title="shell"target="_blank"&gt;shell&lt;/a&gt;/nginx_cache_hit &gt;&gt; /usr/local/nginx/logs/hit

访脚本的内容为：

#!/bin/bash
LOG_FILE='/usr/local/nginx/logs/access.log.1'
LAST_DAY=$(date +%F -d "-1 day")
awk '{if($NF==""HIT"") hit++} END {printf "'$LAST_DAY': %d %d %.2f%n", hit,NR,hit/NR}' $LOG_FILE

Nginx 其他优化措施

动静分离

将静态文件存储到 /usr/share/nginx/html 文件夹中，配置静态文件拦截规则。单个项目可以直接放在 /usr/share/nginx/html 根目录下，如果是多个项目，则要根据项目的根目录创建文件夹来保存静态文件。

配置拦截规则如下：

location ~ .*\.(eot|svg|ttf|woff|jpg|jpeg|gif|png|ico|cur|gz|svgz|mp4|ogg|ogv|webm)$ {
	#所有静态文件直接读取硬盘
	root /usr/share/nginx/html;
	expires 30d; #缓存30天
}

location ~ .*\.(js|css)?{
	#所有静态文件直接读取硬盘
	root /usr/share/nginx/html;
	expires      12h;
}


server {
	listen 9090;
	server_name 192.168.3.245 localhost 127.0.0.1;
	
	location ~ .*\.(eot|svg|ttf|woff|jpg|jpeg|gif|png|ico|cur|gz|svgz|mp4|ogg|ogv|webm|js|css)$ {
		#所有静态文件直接读取硬盘
		root html;
		expires 30d; #缓存30天
	}
	
	location / {
		try_files /usr/local/nginx/html/search.html $uri $uri/index.html $uri.html @mongrel;
	}

	location @mongrel {
		proxy_pass http://192.168.3.205:5016;
	}
}

结果：整个网站的访问速度都会减少，大部分内容都将从静态文件目录或者硬盘中读取。

连接超时

长时间占着连接资源不释放，最终会导致请求的堆积，Nginx 处理请求效率大大降低。所以我们对连接的控制都要注意设置超时时间，通过超时机制自动回收资源、避免资源浪费。

#客户端、服务端设置
server_names_hash_bucket_size 128;
server_names_hash_max_size 512;
# 长连接超时配置
keepalive_timeout  65;
client_header_timeout 15s;
client_body_timeout 15s;
send_timeout 60s;

#代理设置
#与后端服务器建立连接的超时时间。注意这个一般不能大于75秒
proxy_connect_timeout 30s;
proxy_send_timeout 120s;
#从后端服务器读取响应的超时
proxy_read_timeout 120s;

GZIP 压缩

在我们进行 gzip 打包压缩之前，最好将一些静态文件先进行压缩为 min 文件，请求的时候合并为同一文件。再通过 gzip 压缩后，你会发现网站加载又加速了。

#开启gzip,减少我们发送的数据量
gzip on;
#允许压缩的最小字节数
gzip_min_length 1k;
#4个单位为16k的内存作为压缩结果流缓存
gzip_buffers 4 16k;
#设置识别HTTP协议版本，默认是1.1
gzip_http_version 1.1;
#gzip压缩比，可在1~9中设置，1压缩比最小，速度最快，9压缩比最大，速度最慢，消耗CPU
gzip_comp_level 4;
#压缩的类型
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; 
#给代理服务器用的，有的浏览器支持压缩，有的不支持，所以避免浪费不支持的也压缩，所以根据客户端的HTTP头来判断，是否需要压缩
gzip_vary on;
#禁用IE6以下的gzip压缩，IE6的某些版本对gzip的压缩支持很不好
gzip_disable "MSIE [1-6].";

访问限流

我们构建网站是为了让用户访问它们，我们希望用于合法访问。所以不得不采取一些措施限制滥用访问的用户。这种滥用指的是从同一IP每秒到服务器请求的连接数。因为这可能是在同一时间内，世界各地的多台机器上的爬虫机器人多次尝试爬取网站的内容。

#限制用户连接数来预防DOS攻击
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;
#限制同一客户端ip最大并发连接数
limit_conn perip 2;
#限制同一server最大并发连接数
limit_conn perserver 20;
#限制下载速度，根据自身服务器带宽配置
limit_rate 300k;

高效数据传输配置

#开启文件的高效传输模式。tcp_nopush和tcp_nodelay可防止网络及磁盘i/o阻塞，提升nginx工作效率;
sendfile on;
#数据包不会马上传送出去，等到数据包最大时，一次性的传输出去，这样有助于解决网络堵塞。
tcp_nopush on;
#只要有数据包产生，不管大小多少，就尽快传输
tcp_nodelay on;

内核参数的优化

编辑 /etc/sysctl.conf 文件，根据需要调整参数配置。

#如果想把timewait降下了就要把tcp_max_tw_buckets值减小，默认是180000
net.ipv4.tcp_max_tw_buckets = 5000

#开启重用功能，允许将TIME-WAIT状态的sockets重新用于新的TCP连接
net.ipv4.tcp_tw_reuse = 1

#系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，孤儿连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单的DoS攻击
net.ipv4.tcp_max_orphans = 262144

#当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时。我们可以调短时间跨度
net.ipv4.tcp_keepalive_time = 30

日志配置

日志文件对于我们日常运维至关重要，如果没有日志排查问题，你将很难判断异常的所在，要解决问题无异于大海捞针。日志的保存时必要的，不可缺少的，我们来看下怎么配置有利于排查问题？

关键字：其中关键字 access_log，error_log 不能改变
error_log 错误日志级别：[debug | info | notice | warn | error | crit | alert | emerg]，级别越高记录的信息越少。不要配置 info 等级较低的级别，会带来大量的磁盘 I/O 消耗。

error_log 生产场景一般是 warn | error | crit 这三个级别之一

#定义日志模板
log_format 日志模板名称 日志格式;

#访问日志
access_log   path      format        gzip[=level]              [buffer=size]          [flush=time];
关键字     存放的路径   日志格式模板   gzip压缩,level指压缩级别   存放缓存日志的缓存大小   保存在缓存中的最长时间

#错误日志
error_log  <FILE>    <LEVEL>;
关键字     日志文件   错误日志级别

#示例
log_format main '$remote_addr - $remote_user [$time_local] "$request"'
                        '$status $body_bytes_sent "$http_referer"'
                        '"$http_user_agent" "$http_x_forwarded_for"';

Http2协议配置

**TCP 连接数限制**

对于同一个域名，浏览器最多只能同时创建 6~8 个 TCP 连接 (不同浏览器不一样)。

在HTTP1.1的环境下，在图中可以看到每新建了六个 TCP 连接，每次新建连接 DNS 解析需要时间(几 ms 到几百 ms 不等)、TCP 慢启动也需要时间、TLS 握手又要时间，而且后续请求都要等待队列调度

**线头阻塞问题**

每个 TCP 连接同时只能处理一个请求 - 响应，浏览器按 FIFO 原则处理请求，如果上一个响应没返回，后续请求 - 响应都会受阻。

Header 内容多，而且每次请求 Header 不会变化太多，没有相应的压缩传输优化方案
为了尽可能减少请求数，需要做合并文件、雪碧图、资源内联等优化工作，但是这无疑造成了单个请求内容变大延迟变高的问题，且内嵌的资源不能有效地使用缓存机制
明文传输不安全

那么如何解决这些问题？

HTTP2 的优势:

二进制分帧：

在二进制分帧层上，HTTP 2.0 会将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码，其中HTTP1.x的首部信息会被封装到Headers帧，而我们的request body则封装到Data帧里面。

多路复用：

代替原来的序列和阻塞机制。HTTP2只需要通过一次TCP连接将并发请求全部发出，而HTTP1.1则每并发一次请求就需要建立一次TCP连接,当前浏览器为了控制资源，会对单个域名有 6-8个的TCP链接请求限制，如果遇到某一个资源加载耗时较久，就会拖累整个站点的加载速度。

头部压缩：

HTTP 2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键-值对。通过对称加密的方式客户端和服务端之前的通信只需用一个更短的‘’暗号“来匹配之间的需要通信的内容，如果首部发生变化了，那么只需要发送变化了数据在Headers帧里面，新增或修改的首部帧会被追加到“首部表”，首部表在 HTTP 2的连接存续期内始终存在,由客户端和服务器共同渐进地更新。将大大节省消息头占用的网络的流量

服务器推送：

HTTP1.1的方式，客户端浏览器解析到哪里需要什么资源再加载什么资源，在HTTP2中，服务端可以主动推送，结合业务场景，服务端可以先把关键的首要的资源首先推送给客户端。只需要一次HTTP请求，浏览器就得到了首要资源，页面性能大大提升。

如何使用HTTP2 ：

由于目前主流浏览器，chrome、火狐等都已经公开宣布只支持加密的HTTP2，所以HTTP2基本都是基于HTTPS协议的，HTTP升级成HTTPS需要SSL证书，可以到阿里云免费申请，这边以自己的博客nginx配置作为参考

注：升级openssl1.1.x+、 Nginx 1.9.5

server {
    #这里配置https和http2协议
	listen 443 ssl http2;
	server_name blog.reviosky.com;
    ssl on;
	root /data/blog/admin/dist/;
	try_files $uri /index.html;
    #下面配置ssl证书路径
	ssl_certificate /etc/nginx/conf.d/cert/7218208_blog.reviosky.com.pem;  
	ssl_certificate_key /etc/nginx/conf.d/cert/7218208_blog.reviosky.com.key;
	ssl_session_timeout 5m;
	ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_prefer_server_ciphers on;   
	location / {
        root /data/blog/admin/dist/;
		try_files $uri /index.html;
		proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        add_header Access-Control-Allow-Origin *;
        add_header Access-Control-Allow-Headers X-Requested-With;
        add_header Access-Control-Allow-Methods GET,POST,OPTIONS,PUT,DELETE;
        #用于强制取消浏览器缓存
		if ($uri ~* "html$") {
				add_header 'Cache-Control' 'no-cache';
			}
    }

    location /api/ {
		proxy_pass http://127.0.0.1:7001/admin/;
		proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	}
}

server {
    listen       80;
    server_name  blog.reviosky.com;
    rewrite ^(.*)$ https://$host$1 permanent; #把http的域名请求转成https
    charset      utf-8;
	autoindex off;
	proxy_set_header Host $host;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	add_header Access-Control-Allow-Origin *;
	add_header Access-Control-Allow-Headers X-Requested-With;
	add_header Access-Control-Allow-Methods GET,POST,OPTIONS,PUT,DELETE;

	if ($request_method = OPTIONS ) { 
		return 200; 
	}


    location / {
        root /data/blog/admin/dist/;
		try_files $uri /index.html;
		proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        add_header Access-Control-Allow-Origin *;
        add_header Access-Control-Allow-Headers X-Requested-With;
        add_header Access-Control-Allow-Methods GET,POST,OPTIONS,PUT,DELETE;
        #用于强制取消浏览器缓存
		if ($uri ~* "html$") {
				add_header 'Cache-Control' 'no-cache';
			}
    }

    location /api/ {
		proxy_pass http://127.0.0.1:7001/admin/;
		proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	}
}

HTTP1.1升级HTTP2后前后对比：

使用前

使用后

可以看到tcp连接数由多个转变成一个，加载完所有图片的速度得到了提升

附录

这里我下载的是Stable version，linux环境的

安装nginx：这里我的环境是腾讯云centos7

1、去官网nginx: download下载对应的nginx包，推荐使用稳定版本

2、上传到linux系统

3、安装依赖环境

（1）安装gcc环境

yum install gcc-c++ pcre pcre-devel zlib zlib-devle openssl openssl-devel

（2）安装PCRE库，用于解析正则表达式

yum  install -y pcre pcre-devel

（3）zlib压缩和解压缩依赖

yum install -y zlib zlib-devle

（4）SSL安全加密的套接字协议层，用于HTTP安全传输，也就是https

yum install -y openssl openssl-devel

4、解压

tar -zxvf  nginx-1.21.6.tar.gz

5、编译之前，先创建nginx临时目录，如果不创建，在启动nginx的过程中会报错

mkdir /var/temp/nginx -p

6、在nginx的目录，输入如下命令进行配置，目的是为了创建Makefile文件

./configure \
--prefix=/usr/local/nginx \
--pid-path=/var/run/nginx/nginx.pid \
--lock-path=/var/lock/nginx.lock \
--error-log-path=/var/log/nginx/error.log \
--http-log-path=/var/log/nginx/access.log \
--with-http_gzip_static_module \
--http-client-body-temp-path=/var/temp/nginx/client \
--http-proxy-temp-path=/var/temp/nginx/proxy \
--http-fastcgi-temp-path=/var/temp/nginx/fastcgi \
--http-uwsgi-temp-path=/var/temp/nginx/uwsgi \
--http-scgi-temp-path=/var/temp/nginx/scgi
注：\代表在命令中换行，用于提高可读性
配置命令：
命令	解释
--prefix	指定nginx安装目录
--pid-path	指向nginx的pid
--lock-path	锁定安装文件，防止被恶意篡改或误操作
--error-log-path	错误日志
--http-log-path	http日志
--with-http_gzip_static_module	启用gzip模块，在线实时压缩输出数据流
--http-client-body-temp-path=	设定客户端请求的临时目录
--http-proxy-temp-path	设定http代理临时目录
--http-fastcgi-temp-path	设定fastcgi临时目录
--http-uwsgi-temp-path	设定uwsgi临时目录
--http-scgi-temp-path	设定scgi临时目录
 

--prefix=/usr/local/nginx \
--pid-path=/var/run/nginx/nginx.pid \
--lock-path=/var/lock/nginx.lock \
--error-log-path=/var/log/nginx/error.log \
--http-log-path=/var/log/nginx/access.log \
--with-http_gzip_static_module \
--http-client-body-temp-path=/var/temp/nginx/client \
--http-proxy-temp-path=/var/temp/nginx/proxy \
--http-fastcgi-temp-path=/var/temp/nginx/fastcgi \
--http-uwsgi-temp-path=/var/temp/nginx/uwsgi \
--http-scgi-temp-path=/var/temp/nginx/scgi

7、make编译

make

8、安装

make install

9、进入sbin目录启动nginx

./nginx

停止：

./nginx -s stop

重新加载

./nginx -s reload

查看配置文件是否正确

./nginx -t

查看nginx安装的目录

whereis nginx

10、打开浏览器，访问nginx服务器地址ip即可打开nginx默认页面

Nginx 服务器调优

# Nginx 服务器调优

# Nginx 的系统结构

# Nginx 性能参数调优

# 常规参数讲解

# worker_processes number;

# 每个worker 进程的最大连接数

# worker_cpu_affinity cpumask[cpumask……]

# Nginx worker 进程优先级设置

# Nginx worker进程可以打开的最大句柄描述符个数

# 是否打开accept锁

# 使用accept锁后到真正建立连接之间的延迟时间

# Nginx 高速缓存实战

# 案例分析

# 解决方案：

# 方案架构：

# 问题：

# 分析原因：

# 基于Nginx 静态缓存的解决方案：

# 缓存配置

# 配置步骤

# 缓存参数详细说明

# 查看缓存目录

# 缓存的清除

# 清除配置：

# 指定不缓存页面

# 缓存命中分析

# Nginx cache命中率统计

# Nginx 其他优化措施

# 动静分离

# 连接超时

# GZIP 压缩

# 访问限流

# 高效数据传输配置

# 内核参数的优化

# 日志配置

# Http2协议配置

# HTTP2 的优势:

# 如何使用HTTP2 ：

# HTTP1.1升级HTTP2后前后对比：

# 附录

Nginx 服务器调优

Nginx 的系统结构

Nginx 性能参数调优

常规参数讲解

worker_processes number;

每个worker 进程的最大连接数

worker_cpu_affinity cpumask[cpumask……]

Nginx worker 进程优先级设置

Nginx worker进程可以打开的最大句柄描述符个数

是否打开accept锁

使用accept锁后到真正建立连接之间的延迟时间

Nginx 高速缓存实战

案例分析

解决方案：

方案架构：

问题：

分析原因：

基于Nginx 静态缓存的解决方案：

缓存配置

配置步骤

缓存参数详细说明

查看缓存目录

缓存的清除

清除配置：

指定不缓存页面

缓存命中分析

Nginx cache命中率统计

Nginx 其他优化措施

动静分离

连接超时

GZIP 压缩

访问限流

高效数据传输配置

内核参数的优化

日志配置

Http2协议配置

HTTP2 的优势:

如何使用HTTP2 ：

HTTP1.1升级HTTP2后前后对比：

附录