Nignx的编译安装:
下载地址:http://nginx.org/download/nginx-1.16.1.tar.gz
cd /usr/local/src
wget http://nginx.org/download/nginx-1.16.1.tar.gz
tar zxvf nginx-1.16.1.tar.gz
cd nginx-1.16.1/
执行编译安装命令:
./configure --prefix=/usr/local/nginx
错误信息:
checking for OS
+ Linux 3.10.0-327.el7.x86_64 x86_64
checking for C compiler ... not found
./configure: error: C compiler cc is not found
解决方法:安装gcc
yum -y install gcc
错误信息:
./configure: error: the HTTP rewrite module requires the PCRE library.
解决方法:安装pcre-devel
yum install pcre-devel
错误信息:
./configure: error: the HTTP gzip module requires the zlib library.
解决方法:安装zlib-devel
yum install zlib-devel
再次执行
./configure --prefix=/usr/local/nginx
然后执行 :
make && make install
现在在/usr/local下就有了nginx安装目录
如何启动nginx呢?
cd /usr/local/nignx
启动nginx:
./sbin/nginx
cd /usr/local/nignx
会发现nginx安装目录下会发现有四个目录其中
conf:配置目录
html 网页文件
logs 日志文件
sbin 主要的二进制程序文件
启动nginx的时候可能会遇到很多问题 比如80端口被占用 可以通过:
netstat -antp 查看是哪个程序占用了80
然后
kill -9 进程PID 杀死进程 或者
pkill -9 httpd 杀死该程序的所有进程 我这里模拟的杀死httpd的所有进程
也有可能出现80端口没有开放的事情 如何查看80是否开放?
firewall-cmd --query-port=80/tcp 返回no说明80端口没开放
firewall-cmd --add-port=80/tcp 开放80端口号
如何重启nginx呢? ps aux | grep nginx //首先查看一下nginx的进程有哪些
你会发现怎么两个nginx 第一个是master主进程 第二个是子进程 真正干活的是第二个worker子进程
master负责管理这些子进程!
重启nginx我们可以使用nginx当中的信号量
第一种:-INT
ps aux | grep nginx
可以看到nginx的主进程的PID
kill -INT 7450 //直接干死nginx主进程 直截了当
然后进入到usr/local/nginx当中执行
./sbin/nginx
完成nginx的重启工作!
这种方式很暴力 万一用户在下单 刚付完钱 但是数据没入库 就歇菜了!太暴力了!
第二种:quit
优雅的关闭进程 即等请求结束后再关闭
ps aux | grep nginx
可以看到nginx的主进程PID
kill -quit 7450 //优雅的杀掉主进程 等到请求结束再关闭
然后进入到usr/local/nginx当中执行
./sbin/nginx
完成nginx的重启工作
这种方式比较优雅!等请求结束后再杀死nginx的主进程!
第三种:hup
hup是你改了nginx的配置文件 重读配置文件 它会实现平滑重启
假设nginx的主进程还是7450
这个时候你修改了配置文件 需要重新启动
只需执行:
kill -hup 7450 //会平滑重启 在完成前边请求的前提下重新取读取配置文件 完成平滑重启 客户无感知!
整个过程不断线 nginx的主进程PID不变 因为没杀死进程啊!平滑的去重读了nginx的配置文件而已
其他的重启 关闭 nginx的方式:
进入nginx的安装目录 cd /usr/local/nginx ./sbin/nginx -s stop //关闭nginx服务
./sbin/nginx -s reload //相当于重读配置文件 其他类似 自己去试试吧!
./sbin/nginx -t //这条命令会告诉你 你的nginx配置文件是否配置正确 不正确又错在了哪里
nginx的配置文件路径 usr/local/nginx/conf/nginx.conf 还没有和php结合哈 静态的 静态的 还没讲到
后边我会写进来的 别着急
#user nobody;
worker_processes 1;//默认有1个工作的子进程 可以自行修改 但是太大无溢 会争夺cpu 一般设置为cpu数*核叔 2个cpu 一个cpu是8核心 那么最大就是2*8=16 通过ps aux | grep nginx 你也会发现就一个worker进程在工作
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
//events一般是配置nginx的链接的特性
events {
//如一个woker能同时允许多少链接
worker_connections 1024;//这是指 一个子进程最大允许链接1024个连接 比如上边说的2个cpu一个cpu是8核 那就最大16个子进程跑 一个进程1024个连接 那么这台服务最大链接数就是16*1026
}
//http这里才是配置http服务器的主要段
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
//虚机主机配置 基于域名的
//本地修改host 10.10.16.111 z.com
//访问z.com 或者 10.10.16.111会默认找80端口
server {
listen 80; //监听的端口 此端口要开放
server_name z.com;//虚拟域名
location / {
root z.com;//站点目录 根目录相对于usr/local/nginx 可以写其他的绝对路径 一个样
index index.html index.htm;//默认访问的是 index.html....
}
}
//虚机主机配置 基于域名:端口号的
//本地修改host 10.10.16.111 z.com
//访问z.com:8001 记得开放8001端口
server {
listen 8001; //监听的端口 此端口要开放
server_name z.com;//虚拟域名
location / {
root z.com;//站点目录 根目录相对于usr/local/nginx 可以写其他的绝对路径 一个样
index index.html index.htm;//默认访问的是index index.html....
}
}
//虚机主机配置 基于IP:端口号的
//访问10.10.16.111:8001 记得开放8001端口
server {
listen 8001; //监听的端口 此端口要开放
server_name 10.10.16.111::8001;//虚拟域名
location / {
root z.com;//站点目录 根目录相对于usr/local/nginx 可以写其他的绝对路径 一个样
index index.html index.htm;//默认访问的是index index.html....
}
}
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root html;
index index.html index.htm;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
# listen 8000;
# listen somename:8080;
# server_name somename alias another.alias;
# location / {
# root html;
# index index.html index.htm;
# }
#}
# HTTPS server
#
#server {
# listen 443 ssl;
# server_name localhost;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 5m;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
}
如何配置nginx的日志 配置nginx的日志我们一般都是给站点去配置访问日志和错误日志 也就是access_log 以及 error_log日志
如下图所示 在配置access_log的时候格式是main 所以我们需要将log_format main的三行注释去掉
另外access_log访问日志 后边加上日志的路径 error_log日志也是一样的道理
为什么要做nginx的日志切割? 当然这是运维应该干的事情!比如我们的网站访问量特别的大 这样的话访问记录都会存放到一个日志文件里面
时间长了会很大 也不方便我们进行管理 比如你要查询上个月的日志 你只能一行一行的巴拉着看 但是有了日志切割
可以将每个月或者每个周的日志放到同一个文件夹下去 这样也方便我们后期的管理和查看!
实现的方式就是 linux里面的定时任务去执行shell脚本 完成日志的分割 定时任务就不说了 看一下日志分割的脚本是怎么实现的吧:
#!/bin/bash LOGPATH=/usr/local/nginx/logs/z.com1.log BASEPATH=/data bak=$BASEPATH/$(date -d yesterday +%Y%m%d%H%M).zcom.access.log #首先得要创建好/data 777权限 mv移动nginx下的日志到指定位置 mv $LOGPATH $bak #nginx下重新生成一个日志文件 touch $LOGPATH #这里很重要 使用的是-USR1 我们上边讲过nginx的重启的时候要么INT 要么HUP 这里还有一个 #就是USR1 表示你修改了日志名称之后会重新取找新的日志文件往里面写入 kill -USR1 `cat /usr/local/nginx/logs/nginx.pid` ``` 脚本执行就完事了!
有时候吧我们修改nginx的配置文件并且保存了 导致nginx服务器起不来咋办呢? 没办法了 在你实在修改不成的情况下
只能删除掉这个nginx.conf配置文件了 然后进入到你之前下载好的nginx的目录里面 之前都已经执行过make && make
install了对吧 现在你只需要执行以下 make install即可 那么就会重新给你生成一份全新的nginx.conf配置文件
你之前的那些站点就全都没了哈!坑爹吧?坑啊!
访问nginx,首先要匹配location中的uri规则,也就是location,匹配是有先后顺序的!
那么首先你得搞明白location的分类 分为三种
a.精准匹配
比如
location = / {
root /sur/html;
index index.html index.htm
}
b.普通匹配
比如:
location /index.html {
root /var/www/html;
index index.html index.htm
}
c.正则表达式匹配
比如:
location ~ \.php$ {
root /data/www/html;
index index.php index.html
}
比如你直接访问www.ss.com 那么首先会进行精准匹配 会找到 =/ 的location里面 结合root与index指令
去sur/html里面寻找index.html 看是否存在 如果不存在会找sur/html/index.htm 如果存在那么就会继续匹配
就会去找普通匹配去 假设在精准匹配当中找到了index.html 那么又在普通匹配当中也匹配到了 /index.html
那么就会直接请求 /var/www/html/index.html去!完成一次请求!假设第一精准匹配没找到的话 就会默认去找nginx安装目录下的html里面的index.html也就是nginx的欢迎界面!
来个实例吧:
server {
listen 80;
server_name example.org www.example.org;
location / {
root /data/www;
index index.html index.php;
}
location ~ \.php$ {
root /data/www/test;
}
}
上面的例子中,如果你使用example.org或www.example.org直接发起请求,那么首先会访问到“/”的location,结合root与index指令,会先判断/data/www/index.html是否存在,如果不,则接着查看
/data/www/index.php
,如果存在,则使用/index.php发起内部重定向,就像从客户端再一次发起请求一样,Nginx会再一次搜索location,毫无疑问匹配到第二个~
.php$,从而访问到/data/www/test/index.php
location当中匹配的顺序就是 先精准匹配再普通匹配最后正则匹配
location [=|||^~|@] /uri/ { … } 分为两种location: 正则location 和
普通location 一: 正则location: “~ ”和“~ ”前缀表示正则location, “~ ”区分大小写,“~*
”不区分大小写; 二: 普通location: 其他前缀(包括:“=”,“^~ ”和“@ ”)和无任何前缀的都属于普通location 。普通location 和 正则location 匹配规则是:先匹配普通location (再匹配正则表达式) 普通location
之间匹配规则 --> 最大前缀匹配 例如:location /prefix/mid/ {} 和 location /prefix/ {} ,
对于HTTP 请求/prefix/mid/t.html ,(首先看是两个普通location比较,所以是最大前缀匹配规则;)
前缀匹配的话两个location 都满足,选哪个?原则是:the most specific match ,于是选的是location
/prefix/mid/ {} )。“正则location ”与“正则location”内部的匹配规则是: 按照正则location
在配置文件中的物理顺序(编辑顺序)匹配的,并且只要匹配到一条正则location ,就不再考虑后面的“普通location ”的最大前缀匹配结果与继续搜索的“正则location ”匹配结果的决策关系。 如果继续搜索的“正则location
”也有匹配上的,那么“正则location ”覆盖 “普通location ”的最大前缀匹配通常的规则是,匹配完了“普通location ”指令,还需要继续匹配“正则location ”,但是你也可以告诉Nginx :
匹配到了“普通location ”后,不再需要继续匹配“正则location ”了,要做到这一点只要在“普通location
”前面加上“^~ ”符号(^ 表示“非”,~ 表示“正则”,字符意思是:不要继续匹配正则)。 “^~ ”和“=
”都能阻止继续搜索正则location 的话,区别: 共同点是它们都能阻止继续搜索正则location ,不同点是“^~
”依然遵守“最大前缀”匹配规则,然而“= ”不是“最大前缀”,而是必须是严格匹配(exact match )。
1.符号解释:
^~ 标识符匹配后面跟-一个字符串。匹配字符串后将停止对后续的正则表达式进行匹配,如location ^~ /images/ ,
在匹配了/images/这个字符串后就停止对后续的正则匹配
= 精准匹配,如location=/,只会匹配url为/的请求。~ 区分大小写的匹配。 ~* 不区分大小写的匹配。 !~ 对区分大小写的匹配取非。 !~*
对不区分大小写的匹配取非。 / 通用匹配,如果没有其它匹配,任何请求都会被匹配到匹配顺序优先级: (location =)> (location 完整路径)> (location ^~ 路径) > (location
,*正则顺序) >(location 部分起始位置) > (/)2、正则表达式
*:重复前面的字符0次或多次 ?:重复前面的字符0次或1次
+:重复前面的字符1次或多次 .:匹配除换行符以外的任意一个字符 (a|b):匹配a或b ^:以…开头 $:以…结尾 {n}:重复前面的字符n次 {n,}:重复前面的字符n次或更多次 {n,m}:重复前面的字符n-m次
*?:重复前面的字符0次或多次,但尽可能少重复
+?:重复前面的字符1次或多次,但尽可能少重复 ??:重复前面的字符0次或1次,但尽可能少重复 {n,m}?:重复前面的字符n-m次,但尽可能少重复 {n}?:重复前面的字符n次以上,但尽可能少重复 3、正则表达式补充
\W:匹配任意不是字母,数字,下划线,汉字的字符(特殊符号) \S:匹配任意不是空白符的字符 \D:匹配任意非数字的字符
\B:匹配任意不是单词开头或结尾的位置 [a]:匹配单个字符a [a-z]:匹配a-z小写字符的任意一个 [^a]:匹配除了a以外的任意字符
[^abc]:匹配除了abc这几个字母以外的任意字符
location = / {
# 精确匹配 / ,主机名后面不能带任何字符串
[ configuration A ]
}
location / {
# 因为所有的地址都以 / 开头,所以这条规则将匹配到所有请求
# 但是正则和最长字符串会优先匹配
[ configuration B ]
}
location /documents/ {
# 匹配任何以 /documents/ 开头的地址,匹配符合以后,还要继续往下搜索
# 只有后面的正则表达式没有匹配到时,这一条才会采用这一条
[ configuration C ]
}
location ~ /documents/Abc {
# 匹配任何以 /documents/ 开头的地址,匹配符合以后,还要继续往下搜索
# 只有后面的正则表达式没有匹配到时,这一条才会采用这一条
[ configuration CC ]
}
location ^~ /images/ {
# 匹配任何以 /images/ 开头的地址,匹配符合以后,停止往下搜索正则,采用这一条。
[ configuration D ]
}
location ~* \.(gif|jpg|jpeg)$ {
# 匹配所有以 gif,jpg或jpeg 结尾的请求
# 然而,所有请求 /images/ 下的图片会被 config D 处理,因为 ^~ 到达不了这一条正则
[ configuration E ]
}
location /images/ {
# 字符匹配到 /images/,继续往下,会发现 ^~ 存在
[ configuration F ]
}
location /images/abc {
# 最长字符匹配到 /images/abc,继续往下,会发现 ^~ 存在
# F与G的放置顺序是没有关系的
[ configuration G ]
}
location ~ /images/abc/ {
# 只有去掉 config D 才有效:先最长匹配 config G 开头的地址,继续往下搜索,匹配到这一条正则,采用
[ configuration H ]
}
已 = 开头表示精确匹配
如 A 中只匹配根目录结尾的请求,后面不能带任何字符串。
^~ 开头表示uri以某个常规字符串开头,不是正则匹配
~ 开头表示区分大小写的正则匹配;
~* 开头表示不区分大小写的正则匹配
/ 通用匹配, 如果没有其它匹配,任何请求都会匹配到
https://www.cnblogs.com/liujunjun/p/11943672.html
1.先判断精准命中 如果命中 立即返回结果并结束解析过程
2.判断普通命中 如果有多个命中 记录下来最长的命中结果(记录占不返回占不结束)
3.继续判断正则表达式的解析结果,按照配置里面的正则表达式的顺序 由上到下开始匹配 一旦匹配成功一个立即返回结果并结束解析过程。如果没有匹配成功则去找到普通命中里面记录下来的最长的命中结果返回并结束解析过程 普通命中
延伸分析: 顺序无所谓 是因为按命中的长短来确定的 正则命中,顺序有所谓,是因为从前往后命中的
if语句
if语句的书写方式 if后边空格 严格按照下图方式来写就OK:
日志当中的几个关键点要注意:
就比如我们要获取用户访问的ip地址一样 $remote_addr就是
可以参考下边两图知道都是什么意思
break的使用:
比如这 我们判断只要是IE内核的浏览器访问 则直接走rewrite 所有的请求 都指向了 ie.html 但是你想想啊 在IE里面访问 再次重写到ie.html 那还是在IE浏览器里面跳转啊 反反复复都是IE内核 就会陷入死循环 最终报错500 你可以去看error.log日志文件;
那怎么办呢?
break一下呗 就是跳转一次就ok啦 不要重复的反反复复的跳转!那样不好玩!
讲一讲 break和last的区别:
break则是在一个请求处理过程中将原来的url(包括uri和args)改写之后,在继续进行后面的处理,这个重写之后的请求始终都是在同一个location中处理
last其实就相当于一个新的url,对nginx进行了一次请求,需要走一遍大多数的处理过程,最重要的是会做一次find
config,提供了一个可以转到其他location的配置中处理的机会
举个具体的例子吧 我们之前经常使用的thinkphp5.1 如果搭建在nginx上 因为nginx是不支持pathinfo访问模式的 所以 我们需要在nginx的配置文件当中重写路由:
location /
{ if (!-e $request_filename)
{
rewrite ^(.*)$ /index.php?s=$1 last; break;
}
}
^(.*)$ 正则表达式 ()里面表示一个分组 取的是你分组 (xxx)/(xxx) 一个小括号就是一个分组 ,分表用$1
$2 以此类推 .*表示任意字符 $1 表示匹配正则表达式里面的第一个()分组
-e $request_filename 如果我们访问的文件存在的话 当着这里取反的话意思就是说 我们访问的文件不存在的时候!if (!-e $request_filename) 我们知道 tp5当中都是模块/控制器/方法/参数 那么绝对的-e
$request_filename是false 所以取反 进入if判断 通过rewrite重写路由 这里使用的是last
ast其实就相当于一个新的url,对nginx进行了一次请求,需要走一遍大多数的处理过程,最重要的是会做一次find
重新请求的时候是带上了index.php文件的 那么就会正常请求到index.php文件当中去 走正常的url请求了!
实例:
rewrite goods-([\d]+)\.html$ /ecshop/goods.php?id=$1;
rewrite article-([\d]+)\.html$ /ecshop/article.php?id=$1;
rewrite category-(\d+)-b(\d+)\.html /ecshop/category.php?id=$1&brand=$2;
我们可以在一个location里面 写多个rewrite重写规则 比如上边就可以放到location /ecshop { 里面去 }
cd /usr/local/src
wget https://github.com/openresty/echo-nginx-module/archive/v0.62rc1.tar.gz
tar -zxvf v0.62rc1.tar.gz
然后重新编译nginx
停止掉nginx的服务 扩展nginx的功能需要从新编译,编译前必须停止服务;如果服务不停止,则无法用新生成的nginx二级制程序替代原有程序
./configure --prefix=/usr/local/nginx --add-module=/usr/local/src/echo-nginx-module-0.62rc1
make && make install
现在你就可以打印nginx里面的这些变量啦:
但是都有哪些变量可以打印呢?
网上一大堆 我们在上边讲过的$request_filename就是一个 还有很多 比如访问来源等等 我们可以打印出来 看看 方便我们rewrite重写路由
https://www.cnblogs.com/dandeliongogo/p/6704163.html
在apache当中php是一个模块嵌入到了apache服务器
在nginx当中php和nginx是平级的 nginx一看是php文件会传递过php去处理再将结果返回给nginx php默认会占用9000端口 独立起一个进程在那等着来活就干!
安装php可以通过yum或者编译安装 网上很多教程 这里只介绍nginx和php是怎么结合工作的
我们需要配置location 凡是.php的请求 进行如下配置 啥意思呢?
fastcgi_pass 127.0.0.1:9000 我们说过php默认占用9000端口 这里直接去找php去处理去表示
fastcgi_index index.php 默认找index.php文件
fastcig_param SCRPT… 表示比如你请求的是test.php 这了就指定了去哪里找这个test.php文件去
$fastcgi_script_name其实就是你访问的.php文件名
include fastcgi_params 表示的是请求的时候带的各种参数 你可以/usr/local/nginx/conf/fastcgi_params当中查看具体都有哪些参数
打开浏览器F12可以看到 accept-encoding:gzip…表示浏览器支持的压缩方式
content-length:3439 表示网页实际接收到的内容大小
再把页面另存下来,观察,约10W字节,实际传输的36093字节
原因-------就在于gzip压缩上.
原理: 浏览器—请求----> 声明可以接受 gzip压缩 或 deflate压缩 或compress 或 sdch压缩
从http协议的角度看–请求头 声明 acceopt-encoding: gzip deflate sdch
(是指压缩算法,其中sdch是google倡导的一种压缩方式,目前支持的服务器尚不多)
服务器–>回应—把内容用gzip方式压缩---->发给浏览器
浏览<-----解码gzip-----接收gzip压缩内容----
推算一下节省的带宽:
假设 news.163.com PV 2亿
210^8 * 910^4 字节 ==
210^8 * 9 * 10^4 * 10^-9 = 12K*G = 18T
节省的带宽是非常惊人的
/usr/local/nginx/conf/mime.types
nginx当中的gzip的参数如下所示:
gzip配置的常用参数
gzip on|off; #是否开启gzip
gzip_buffers 32 4K| 16 8K #缓冲(压缩在内存中缓冲几块? 每块多大?)
gzip_comp_level [1-9] #推荐6 压缩级别(级别越高,压的越小,越浪费CPU计算资源)
gzip_disable #正则匹配UA 什么样的Uri不进行gzip
gzip_min_length 200 # 开始压缩的最小长度(再小就不要压缩了,意义不在)
gzip_http_version 1.0|1.1 # 开始压缩的http协议版本(可以不设置,目前几乎全是1.1协议)
gzip_proxied # 设置请求者代理服务器,该如何缓存内容
gzip_types text/plain application/xml # 对哪些类型的文件用压缩 如txt,xml,html ,css
gzip_vary on|off # 是否传输gzip压缩标志
一般情况下 nginx的gzip可以配置在server location if 或者http下都可以 我们一般都配置到server下边
gzip_types 都有哪些类型 在nginx的配置当中都有 具体查看:/usr/local/nginx/conf/mime.types
可以查看头信息里面 返回的头信息里面gzip transfer encoding:chunked 分块显示的!
gzip主要针对 js css html xml等 但是图片视频就必要压缩了 因为压缩比例很小!对于大的网站访问量较多的情况下可以很好的节省带宽 带宽节省了那么延迟就少 访问当然也就越快不卡!
nginx的缓存设置,提高网站性能
对于网站的图片 尤其是新闻站 图片一般发布改动的可能是非常小的 我们希望 能否在用户访问一次后 图片缓存在用户的浏览器端,而且时间比较长的缓存
可以用到nginx的expires设置
在location或者if段里面书写
格式为:
expires 30s
expires 30m
expires 2h
expires 30d
我们发现很多时候多次请求一个地址的时候网站返回的是304 这也是一种很好的缓存手段
原理是:
服务器响应文件内容是,同时响应etag标签(内容的签名,内容一变,他也变), 和 last_modified_since 2个标签值
浏览器下次去请求时,头信息发送这两个标签, 服务器检测文件有没有发生变化,如无,直接头信息返回 etag,last_modified_since
浏览器知道内容无改变,于是直接调用本地缓存.
这个过程,也请求了服务器,但是传着的内容极少.
对于变化周期较短的,如静态html,js,css,比较适于用这个方式
但是我们使用了expires之后 告诉了浏览器缓存的时间是多少 那么在规定的缓存时间范围内 响应的图片请求或者js请求就不回去请求服务器 而是直接读取浏览器缓存里面的内容 大大减少了对服务器的请求!
一般情况下 我们建议是对图片设置expires过期时间! 下边两个都可以 一个是只要是images目录下的就epires一下
location ^~ /images/ {
root html;//root表示nginx的家目录 就是nginx/html目录 这里表示的是html/images下的图片
expires 1d;//表示缓存一天
}
location ~* \.(gif|jpg|jpeg)$ {
root html;//root表示nginx的家目录 就是nginx/html目录 这里表示的是html/images下的图片
expires 1d;//表示缓存一天
}
这样的效果在浏览器当中的体现是
第一次请求的时候图片或者其他返回的是200 第二次的时候 直接什么都没有返回 空的 0个请求
单每个浏览器的显示不同 有的显示from cache 返回码是200 但是从缓存当中读取的!
(服务器的日期要准确 如果服务器的日期落后于实际日期 则可能导致缓存失效!)
图片expires成功的标志就是响应头信息里面有expires的头信息,如果html也有expires说明你的location里面的正则不够严谨哦 快快去检查吧!