共计 15669 个字符，预计需要花费 40 分钟才能阅读完成。
Nginx 介绍
如果听说过 Apache 软件那么对于 Nginx 也会很快就熟悉的和 Apache 一样 nginx 是开源的支持高性能高并发的 WWW 服务、代理服务软件以及电子邮件代理服务器并在一个 BSD-like 协议下发行由俄罗斯 Igor Sysoev 所开发开始供俄国大型的入口网址及搜索引擎 Rambler 使用。
Nginx 占有内存小并发能力强特别是静态资源且功能丰富而流行起来。从软件的功能应用方面 Nginx 不但是一个优秀的 Web 服务软件还可以具有反向代理负载均衡能和缓存服务功能。代理方面类似专业的 LVS 负载以及 Happroxy 软件缓存服务功能方面又类似 squid 专业缓存软件。
Nginx 可以运行在 Unix、Linux、BSD 等操作系统中最近 LNMP 比较流行。
Nginx 特点
- 可针对静态资源高速高并发及缓存
- 可使用反向代理加速并且可进行数据缓存
- 具有简单负载均衡、节点健康检查和容错的功能
- 支持远程 FastCGI 服务的缓存加速
- 支持 FastCGI Uwsgi SCGI、and Memcached Servers 的加速和缓存
- 支持 ssl、tls、sni
- 具有模块的架构过滤器包括 gzip 压缩、ranges 支持、chunked 响应、XSLT、SSI 及图像缩放等功能。在 SSI 过滤器中一个包含多个 SSI 的页面如果经由 FastCGI 或反向代理出来可被并行处理
它所具备的其他 WWW 服务特性如下
- 支持基于名字、端口以及 IP 的多虚拟主机的站点
- 支持 Keep-alive 和 pipelined 的连接
- 可进行简单、方便、灵活的配置和管理
- 支持 Nginx 配置并且在代码上线时可平滑重启不中断业务访问
- 可自定义访问日志格式临时缓冲写日志操作快速日志轮询及通过 rsyslog 除了日志
- 可利用信号控制 Nginx 进程
- 支持 3xx-5xx http 状态码重定向
- 支持 rewrite 模块支持 URI 重写及正则表达式匹配
- 支持基于客户端 IP 地址和 HTTP 基本认知的访问控制
Nginx 作为 Web 主要的应用场景
使用 Nginx 运行 HTML\JS\CSS, 小图片等静态数据类似 lighttpd 软件
Nginx 结合 FastCGI 运行 PHP 等动态程序
Nginx 结合 tomcat/resin 等支持 Java 动态程序
Nginx、Apache 和 Lighttpd 软件的优缺点
Apache 软件的特点
2.2 版本非常稳定强大官方说其 2.4 版本性能更强
Prefork 模式取消进程创建开销性能很高
处理动态业务数据时因管理到后端的引擎和数据库瓶颈不在于 Apache 本身上
高并发时消耗系统资源相对多一些
基于传统的 select 模型高并发能力有限
支持扩展库可通过 DSO、apxs 方法编译安装额外的插件功能不需要重新编译 Apache
功能多更稳当更安全插件也多
Nginx 软件的特点
基于异步网络 I / O 模型 epoll、kqueue)
具备支持高性能高并发的特性并发连接可大数万
对小文件小于 1MB 的静态文件高并发支持很好性能很高
不支持类似 Apache 的 DSO 模式扩展库必须编译进主程序缺点
进程占用系统资源比较低
支持 Web、反向 proxy、cache 三大重点功能并且都很优秀
市场份额在昨年快速增加
Lighttpd 软件特点
基于异步网络 I / O 模型性能并发都和 Nginx 相近
扩展库是 SO 模式比 Nginx 灵活
目前国内使用率比较低安全性没有 Apache 和 Nginx 好
通过插件 mod_secdownload 可实现文件 URL 地址加密有点
社区不活跃市场份额较低
下面对各类 web 服务器在动态数据性能上的对比从下图中科院看出在出来动态数据时三者的差距不大 Apache 更有优势一点。这是英文处理动态数据的能力取决于 PHPJava 和后端的数据库提供的服务能力也就是说瓶颈不在 web 服务器上。一般情况下普通 PHP 引擎支持的并发连接参考值为 300-1000Java 引擎的并发连接参考值为 300-1500 而数据库的并发连接参考值为 300-1500. 业务场景及网站架构不通并发连接数也会有上下浮动。这些数字可供初学参考
为什么 Nginx 总体性能比 Apache 高
Nginx 使用最新的 epoll 和 kqueue 异步网络 I / O 模型而 Apache 则使用 select 模型目前 Linux 能承受的高并发访问的 squid 和 memcached 都是采用的 epoll 模型
下面使用比喻来说明此问题
第一个比喻
假设你在大学读书住的宿舍楼有很多间房间你的朋友要来找你 select 版宿管大妈就会带着你的朋友挨个房间去找直到找到你的朋友为止。而 epoll 版宿管大妈会先记下每位入住同学的房间号你的朋友来找你是只要告诉你朋友你在那个房间即可不用亲自带着你的朋友满宿舍找人了。如果同时来了 100 个人。都要找自己住这个宿舍楼的同学时 select 版和 epoll 版宿管大妈谁的效率高。显而易见
第二个比喻
select 的调用复杂度是线性的即 0n。举个例子一个保姆照看一群孩子如果有孩子是否需要袅袅比作网络 I / O 事件 select 的作用就好比这个保姆挨个询问每个孩子你要尿尿吗如果孩子回答是保姆则把孩子领出来放到一个地方。当所有孩子询问完自后则保姆领着这些要尿尿的孩子去上厕所处理网络 I / O 事件
还是以保姆照看孩子为例在 epoll 机制下保姆不再需要挨个询问每个孩子是否要尿尿。取而代之的是每个孩子如果自己需要尿尿的时候自己主动的站到事先约好的地方而保姆职责就是查看事先约定好的地方是否有孩子如果有小孩则带着孩子去上测试网络事件处理因此 epoll 的这种机制能够高效的处理成千上万的并发连接而且性能不会随着连接数目的增加而下降太多
业务场景如何选用 Web 软件
静态业务若是高并发场景尽量采用 Nginx 或 Lighttpd 首选 Nginx
动态业务理论上采用 Nginx 和 Apache 均可建议选择 Nginx 要避免相同业务服务软件多样化额外增加维护成本。动态业务可以用 Nginx 兼做前端代理再更加页面元素的类型或目录向后转发到后端相应的服务器进行处理
如果既有静态业务又有动态业务就采用 Nginx
Nginx 的安装
系统环境
[root@web01 ~]# cat /etc/RedHat-release
CentOS 6.7
[root@web01 ~]# uname -rm
2.6.32-573.el6.x86_64 x86_64
Nginx 所需要的库环境
[root@web01 ~]# yum install pcre-devel openssl-devle -y
[root@web01 ~]# rpm -aq pcre-deve pcre openssl-devel openssl
pcre-7.8-7.el6.x86_64
openssl-1.0.1e-42.el6.x86_64
Nginx 软件包下载安装
获取 nginx 在 nginx.org 官网上可以获得 nginx 的各种版本
mkdir /home/oldboy/tools
cd /home/oldboy/tools/
wgethttp://nginx.org/download/nginx-1.6.3.tar.gz
tar xf nginx-1.6.3.tar.gz
tar xf nginx-1.6.3.tar.gz
useradd -M -s /sbin/nologin nginx
./configure –prefix=/application/nginx-1.6.3 –user=nginx –group=nginx –with-http_ssl_module –with-http_stub_status_module
make
make install
ln -s /application/nginx-1.6.3/ /application/nginx
[root@web01 nginx-1.6.3]# ss -lntup|grep nginx
[root@web01 nginx-1.6.3]# /application/nginx/sbin/nginx
[root@web01 nginx-1.6.3]# ss -lntup|grep nginx
tcp LISTEN 0 128 *:80 *:* users:((“nginx”,4804,6),(“nginx”,4805,6))
使用浏览器输入服务器 ip 地址验证是否安装启动成功
也可以在服务器本机上使用 curl 命令进行测试如下
[root@web01 nginx-1.6.3]# curl -I 10.0.0.8
HTTP/1.1 200 OK
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2017-04/142479p2.htm
Nginx 的配置
在 conf 目录下面有配置文件过滤掉 default 的如下
[root@web01 conf]# pwd
/application/nginx/conf
[root@web01 conf]# tree|grep -v default
.
├── fastcgi.conf
├── fastcgi_params
├── koi-utf
├── koi-win
├── mime.types
├── nginx.conf
├── scgi_params
├── uwsgi_params
└── win-utf
这里除了 nginx.conf 其他的配置文件保持默认即可
Nginx.conf 文件介绍
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {#server{}定义了虚拟主机
listen 80;# 监听端口
server_name localhost;# 监听的域名
location / {#location{}是用来为匹配的 URI 进行配置 URI 即语法中的 ”/uri/” location / 匹配任何查询因为任何查询都是以 / 开头
root html; #知道对应的 uri 的资源查找路径这 html 为相对路径完整路径为 /application/nginx/html/
index index.html index.htm; #指定 index 文件的名称可以配置多个以空格分开如果有多个按照顺序查找
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
Nginx 基于域名服务配置
[root@web01 conf]# cat nginx.conf
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name www.linuxidc.com;
location / {
root html/www;
index index.html index.htm;
}
}
server {
listen 80;
server_name bbs.linuxidc.com;
location / {
root html/bbs;
index index.html index.htm;
}
}
server {
listen 80;
server_name blog.linuxidc.com;
location / {
root html/blog;
index index.html index.htm;
}
}
}
创建域名目录和主页文件 index.html
[root@web01 conf]# mkdir ../html/{bbs,www,blog}
[root@web01 conf]# ls ../html/
50x.html bbs blog index.html www
[root@web01 conf]# for i in bbs www blog;do echo $i >../html/$i/index.html;done
[root@web01 conf]# tree ../html/
../html/
├── 50x.html
├── bbs
│ └── index.html
├── blog
│ └── index.html
├── index.html
└── www
└── index.html
3 directories, 5 files
[root@web01 conf]# cat ../html/blog/index.html
Blog
重启 nginx 服务
[root@web01 conf]# ../sbin/nginx -t
nginx: the configuration file /application/nginx-1.6.3/conf/nginx.conf syntax is ok
nginx: configuration file /application/nginx-1.6.3/conf/nginx.conf test is successful
[root@web01 conf]# ../sbin/nginx -s reload
本机测试 nginx 服务器域名访问
[root@web01 conf]# curl www.linuxidc.com
www
[root@web01 conf]# curl bbs.linuxidc.com
bbs
[root@web01 conf]# curl blog.linuxidc.com
blog
[root@web01 conf]# cat /etc/hosts
10.0.0.8 www.linuxidc.combbs.linuxidc.org blog.linuxidc.com
也可以在 widows 上给 hosts 做解析使用浏览器访问域名来测试。这里不列出
安装错误 & 解决方法
模块介绍
Nginx 介绍
如果听说过 Apache 软件那么对于 Nginx 也会很快就熟悉的和 Apache 一样 nginx 是开源的支持高性能高并发的 WWW 服务、代理服务软件以及电子邮件代理服务器并在一个 BSD-like 协议下发行由俄罗斯 Igor Sysoev 所开发开始供俄国大型的入口网址及搜索引擎 Rambler 使用。
Nginx 占有内存小并发能力强特别是静态资源且功能丰富而流行起来。从软件的功能应用方面 Nginx 不但是一个优秀的 Web 服务软件还可以具有反向代理负载均衡能和缓存服务功能。代理方面类似专业的 LVS 负载以及 Happroxy 软件缓存服务功能方面又类似 squid 专业缓存软件。
Nginx 可以运行在 Unix、Linux、BSD 等操作系统中最近 LNMP 比较流行。
Nginx 特点
- 可针对静态资源高速高并发及缓存
- 可使用反向代理加速并且可进行数据缓存
- 具有简单负载均衡、节点健康检查和容错的功能
- 支持远程 FastCGI 服务的缓存加速
- 支持 FastCGI Uwsgi SCGI、and Memcached Servers 的加速和缓存
- 支持 ssl、tls、sni
- 具有模块的架构过滤器包括 gzip 压缩、ranges 支持、chunked 响应、XSLT、SSI 及图像缩放等功能。在 SSI 过滤器中一个包含多个 SSI 的页面如果经由 FastCGI 或反向代理出来可被并行处理
它所具备的其他 WWW 服务特性如下
- 支持基于名字、端口以及 IP 的多虚拟主机的站点
- 支持 Keep-alive 和 pipelined 的连接
- 可进行简单、方便、灵活的配置和管理
- 支持 Nginx 配置并且在代码上线时可平滑重启不中断业务访问
- 可自定义访问日志格式临时缓冲写日志操作快速日志轮询及通过 rsyslog 除了日志
- 可利用信号控制 Nginx 进程
- 支持 3xx-5xx http 状态码重定向
- 支持 rewrite 模块支持 URI 重写及正则表达式匹配
- 支持基于客户端 IP 地址和 HTTP 基本认知的访问控制
Nginx 作为 Web 主要的应用场景
使用 Nginx 运行 HTML\JS\CSS, 小图片等静态数据类似 lighttpd 软件
Nginx 结合 FastCGI 运行 PHP 等动态程序
Nginx 结合 tomcat/resin 等支持 Java 动态程序
Nginx、Apache 和 Lighttpd 软件的优缺点
Apache 软件的特点
2.2 版本非常稳定强大官方说其 2.4 版本性能更强
Prefork 模式取消进程创建开销性能很高
处理动态业务数据时因管理到后端的引擎和数据库瓶颈不在于 Apache 本身上
高并发时消耗系统资源相对多一些
基于传统的 select 模型高并发能力有限
支持扩展库可通过 DSO、apxs 方法编译安装额外的插件功能不需要重新编译 Apache
功能多更稳当更安全插件也多
Nginx 软件的特点
基于异步网络 I / O 模型 epoll、kqueue)
具备支持高性能高并发的特性并发连接可大数万
对小文件小于 1MB 的静态文件高并发支持很好性能很高
不支持类似 Apache 的 DSO 模式扩展库必须编译进主程序缺点
进程占用系统资源比较低
支持 Web、反向 proxy、cache 三大重点功能并且都很优秀
市场份额在昨年快速增加
Lighttpd 软件特点
基于异步网络 I / O 模型性能并发都和 Nginx 相近
扩展库是 SO 模式比 Nginx 灵活
目前国内使用率比较低安全性没有 Apache 和 Nginx 好
通过插件 mod_secdownload 可实现文件 URL 地址加密有点
社区不活跃市场份额较低
下面对各类 web 服务器在动态数据性能上的对比从下图中科院看出在出来动态数据时三者的差距不大 Apache 更有优势一点。这是英文处理动态数据的能力取决于 PHPJava 和后端的数据库提供的服务能力也就是说瓶颈不在 web 服务器上。一般情况下普通 PHP 引擎支持的并发连接参考值为 300-1000Java 引擎的并发连接参考值为 300-1500 而数据库的并发连接参考值为 300-1500. 业务场景及网站架构不通并发连接数也会有上下浮动。这些数字可供初学参考
为什么 Nginx 总体性能比 Apache 高
Nginx 使用最新的 epoll 和 kqueue 异步网络 I / O 模型而 Apache 则使用 select 模型目前 Linux 能承受的高并发访问的 squid 和 memcached 都是采用的 epoll 模型
下面使用比喻来说明此问题
第一个比喻
假设你在大学读书住的宿舍楼有很多间房间你的朋友要来找你 select 版宿管大妈就会带着你的朋友挨个房间去找直到找到你的朋友为止。而 epoll 版宿管大妈会先记下每位入住同学的房间号你的朋友来找你是只要告诉你朋友你在那个房间即可不用亲自带着你的朋友满宿舍找人了。如果同时来了 100 个人。都要找自己住这个宿舍楼的同学时 select 版和 epoll 版宿管大妈谁的效率高。显而易见
第二个比喻
select 的调用复杂度是线性的即 0n。举个例子一个保姆照看一群孩子如果有孩子是否需要袅袅比作网络 I / O 事件 select 的作用就好比这个保姆挨个询问每个孩子你要尿尿吗如果孩子回答是保姆则把孩子领出来放到一个地方。当所有孩子询问完自后则保姆领着这些要尿尿的孩子去上厕所处理网络 I / O 事件
还是以保姆照看孩子为例在 epoll 机制下保姆不再需要挨个询问每个孩子是否要尿尿。取而代之的是每个孩子如果自己需要尿尿的时候自己主动的站到事先约好的地方而保姆职责就是查看事先约定好的地方是否有孩子如果有小孩则带着孩子去上测试网络事件处理因此 epoll 的这种机制能够高效的处理成千上万的并发连接而且性能不会随着连接数目的增加而下降太多
业务场景如何选用 Web 软件
静态业务若是高并发场景尽量采用 Nginx 或 Lighttpd 首选 Nginx
动态业务理论上采用 Nginx 和 Apache 均可建议选择 Nginx 要避免相同业务服务软件多样化额外增加维护成本。动态业务可以用 Nginx 兼做前端代理再更加页面元素的类型或目录向后转发到后端相应的服务器进行处理
如果既有静态业务又有动态业务就采用 Nginx
Nginx 的安装
系统环境
[root@web01 ~]# cat /etc/RedHat-release
CentOS 6.7
[root@web01 ~]# uname -rm
2.6.32-573.el6.x86_64 x86_64
Nginx 所需要的库环境
[root@web01 ~]# yum install pcre-devel openssl-devle -y
[root@web01 ~]# rpm -aq pcre-deve pcre openssl-devel openssl
pcre-7.8-7.el6.x86_64
openssl-1.0.1e-42.el6.x86_64
Nginx 软件包下载安装
获取 nginx 在 nginx.org 官网上可以获得 nginx 的各种版本
mkdir /home/oldboy/tools
cd /home/oldboy/tools/
wgethttp://nginx.org/download/nginx-1.6.3.tar.gz
tar xf nginx-1.6.3.tar.gz
tar xf nginx-1.6.3.tar.gz
useradd -M -s /sbin/nologin nginx
./configure –prefix=/application/nginx-1.6.3 –user=nginx –group=nginx –with-http_ssl_module –with-http_stub_status_module
make
make install
ln -s /application/nginx-1.6.3/ /application/nginx
[root@web01 nginx-1.6.3]# ss -lntup|grep nginx
[root@web01 nginx-1.6.3]# /application/nginx/sbin/nginx
[root@web01 nginx-1.6.3]# ss -lntup|grep nginx
tcp LISTEN 0 128 *:80 *:* users:((“nginx”,4804,6),(“nginx”,4805,6))
使用浏览器输入服务器 ip 地址验证是否安装启动成功
也可以在服务器本机上使用 curl 命令进行测试如下
[root@web01 nginx-1.6.3]# curl -I 10.0.0.8
HTTP/1.1 200 OK
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2017-04/142479p2.htm
Nginx 基于端口的虚拟主机
基于端口的虚拟主机在生产环境中不多见偶尔会用到一般是为了公司内网提供访问的如 OA 系统、网站程序后台、CMS 发布后台、MySQL 的 web 客户端。使用特殊端口多是从安全上考虑的
配置虚拟主机监听的端口
[root@web01 conf]# vim nginx.conf
sendfile on;
keepalive_timeout 65;
server {
listen 8001;
server_name bbs.linuxidc.com;
location / {
root html/bbs;
index index.html index.htm;
}
}
server {
listen 8002;
server_name www.linuxidc.com;
location / {
root html/www;
index index.html index.htm;
}
}
server {
listen 8003;
server_name blog.linuxidc.com;
location / {
root html/blog;
“nginx.conf” 34L, 759C written
[root@web01 conf]# ../sbin/nginx -t
nginx: the configuration file /application/nginx-1.6.3/conf/nginx.conf syntax is ok
nginx: configuration file /application/nginx-1.6.3/conf/nginx.conf test is successful
[root@web01 conf]# ../sbin/nginx -s reload
[root@web01 conf]# netstat -lntup
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8001 0.0.0.0:* LISTEN 3763/nginx
tcp 0 0 0.0.0.0:8002 0.0.0.0:* LISTEN 3763/nginx
tcp 0 0 0.0.0.0:8003 0.0.0.0:* LISTEN 3763/nginx
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1317/sshd
tcp 0 0 :::22 :::* LISTEN 1317/sshd
[root@web01 conf]# curl www.linuxidc.com
curl: (6) Couldn’t resolve host ‘www.linuxidc.com’
[root@web01 conf]# curl www.linuxidc.com:8002
www.linuxidc.com
基于 Ip 的虚拟主机
server {
listen 10.0.0.9:80;
server_name www.linuxidc.com;
location / {
root html/www;
index index.html index.htm;
}
}
Nginx 别名配置
利用别名来监控集群下面的 RS 的 URL。可以在监控服务器里面配置 hosts 里面配置别名解析用来监控
server {
listen 80;
server_name www.linuxidc.com linuxidc.com
location / {
root html/www;
index index.html index.htm;
}
}
在 hosts 解析里面配置 linuxidc.com 解析重启服务即可
第二种方法就是 rewrite 重定向
Nginx 的配置文件优化
[root@web01 conf]# cat nginx.conf
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
include extra/www.conf;
include extra/blog.conf;
include extra/bbs.conf;
}
创建 extra 目录
[root@web01 conf]# mkdir extra
创建配置文件
[root@web01 conf]#sed -n ‘18,25p’ nginx.conf.name >>extra/www.conf
[root@web01 conf]#sed -n ‘10,17p’ nginx.conf.name >extra/bbs.conf
[root@web01 conf]#sed -n ‘26,33p’ nginx.conf.name >>extra/blog.conf
测试结果
[root@web01 conf]# ../sbin/nginx -t
nginx: the configuration file /application/nginx-1.6.3/conf/nginx.conf syntax is ok
nginx: configuration file /application/nginx-1.6.3/conf/nginx.conf test is successful
[root@web01 conf]# ../sbin/nginx -s reload
[root@web01 conf]# curl www.linuxidc.com
www.linuxidc.com
[root@web01 conf]# curl blog.linuxidc.com
blog.linuxidc.com
[root@web01 conf]# curl bbs.linuxidc.com
bbs.linuxidc.com
Nginx 的状态模块
–with-http_stub_status_module 记录 nginx 的基本访问信息让使用者了解 nginx 的工作状态
[root@web01 conf]# ll extra/
total 16
-rw-r–r– 1 root root 185 May 30 15:06 bbs.conf
-rw-r–r– 1 root root 187 May 30 15:06 blog.conf
-rw-r–r– 1 root root 168 May 30 15:33 status.conf
-rw-r–r– 1 root root 199 May 30 15:13 www.conf
[root@web01 conf]# cat extra/status.conf
server {
listen 80;
server_name status.linuxidc.com;
location / {
stub_status on;
access_log off;
}
}
[root@web01 conf]# cat nginx.conf
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
include extra/www.conf;
include extra/blog.conf;
include extra/bbs.conf;
include extra/status.conf;
}
检查状态信息
第一个 server 表示 nginx 一共处理了 43 个连接
第二个 accepts 表示 nginx 从启动到现在成功创建了 43 次握手
请求丢失数 = 握手数 - 成功连接数可以看到这里没有丢失
第三个 handle request 表示总共处理了 27 次请求
Reading 表示 nginx 读取客户端的 Header 信息数
Writing 表示发回给客户端的 Header 信息数
Waiting 表示已经处理完正在等候下一次请求指令的驻留连接
Nginx 增加错误日志
常见的有【debug|info|notice|warn|error|crit|alert|emerg】级别越高信息量越小。工作场景一般是 warn|error|crit| 这三个级别注意不要配置 info 等低级别的会带来 I / O 消耗
error_log 默认配置为
#default:error_logs/error.log error;
可放置的标签段为
#context:main,http,server,location
Nginx 的访问日志参数
可以查看 nginx.conf.default 配置文件里面有记录日志的详细格式。
Nginx 日志格式中默认的参数配置如下
log_format main ‘$remote_addr – $remote_user [$time_local] “$request”
‘
‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent” “$http_x_forwarded_for”‘;
$server_name 虚拟主机名称。
$remote_addr 远程客户端的 IP 地址。
- 空白用一个“-”占位符替代历史原因导致还存在。
$remote_user 远程客户端用户名称用于记录浏览者进行身份验证时提供的名字如登录百度的用户名 scq2099yt 如果没有登录就是空白。
[$time_local] 访问的时间与时区比如 18/Jul/2012:17:00:01 +0800 时间信息最后的 ”+0800″ 表示服务器所处时区位于 UTC 之后的 8 小时。
$request 请求的 URI 和 HTTP 协议这是整个 PV 日志记录中最有用的信息记录服务器收到一个什么样的请求
$status 记录请求返回的 http 状态码比如成功是 200。
$uptream_statusupstream 状态比如成功是 200.
$body_bytes_sent 发送给客户端的文件主体内容的大小比如 899 可以将日志每条记录中的这个值累加起来以粗略估计服务器吞吐量。
$http_referer 记录从哪个页面链接访问过来的。
$http_user_agent 客户端浏览器信息
$http_x_forwarded_for 客户端的真实 ip 通常 web 服务器放在反向代理的后面这样就不能获取到客户的 IP 地址了通过 $remote_add 拿到的 IP 地址是反向代理服务器的 iP 地址。反向代理服务器在转发请求的 http 头信息中可以增加 x_forwarded_for 信息用以记录原有客户端的 IP 地址和原来客户端的请求的服务器地址。
rewrite 练习
http {
# 定义 image 日志格式
log_format imagelog ‘[$time_local] ‘ $image_file ‘ ‘ $image_type ‘ ‘ $body_bytes_sent ‘ ‘ $status;
# 开启重写日志
rewrite_log on;
server {
root /home/www;
location / {
# 重写规则信息
error_log logs/rewrite.log notice;
# 注意这里要用‘’单引号引起来避免{}
rewrite ‘^/images/([a-z]{2})/([a-z0-9]{5})/(.*)\.(png|jpg|gif)$’ /data?file=$3.$4;
# 注意不能在上面这条规则后面加上“last”参数否则下面的 set 指令不会执行
set $image_file $3;
set $image_type $4;
}
location /data {
# 指定针对图片的日志格式来分析图片类型和大小
access_log logs/images.log mian;
root /data/images;
# 应用前面定义的变量。判断首先文件在不在不在再判断目录在不在如果还不在就跳转到最后一个 url 里
try_files /$arg_file /image404.html;
}
location = /image404.html {
# 图片不存在返回特定的信息
return 404 “image not found\n”;
}
}
对形如 /images/ef/uh7b3/test.png 的请求重写到 /data?file=test.png 于是匹配到 location /data 先看 /data/images/test.png 文件存不存在如果存在则正常响应如果不存在则重写 tryfiles 到新的 image404 location 直接返回 404 状态码。
例 2
rewrite ^/images/(.*)_(\d+)x(\d+)\.(png|jpg|gif)$ /resizer/$1.$4?width=$2&height=$3? last;
对形如 /images/bla_500x400.jpg 的文件请求重写到 /resizer/bla.jpg?width=500&height=400 地址并会继续尝试匹配 location。
常用的正则
. 匹配除换行符以外的任意字符
? 重复 0 次或 1 次
+ 重复 1 次或更多次
* 重复 0 次或更多次
\d 匹配数字
^ 匹配字符串的开始
$ 匹配字符串的介绍
{n} 重复 n 次
{n,} 重复 n 次或更多次
[c] 匹配单个字符 c
[a-z] 匹配 a - z 小写字母的任意一个
小括号 () 之间匹配的内容可以在后面通过 $1 来引用 $2 表示的是前面第二个 () 里的内容。正则里面容易让人困惑的是 \ 转义特殊字符。
flag 标志位
last : 相当于 Apache 的[L] 标记表示完成 rewrite
break : 停止执行当前虚拟主机的后续 rewrite 指令集
redirect : 返回 302 临时重定向地址栏会显示跳转后的地址
permanent : 返回 301 永久重定向地址栏会显示跳转后的地址
因为 301 和 302 不能简单的只返回状态码还必须有重定向的 URL 这就是 return 指令无法返回 301,302 的原因了。
这里 last 和 break 区别有点难以理解
last 一般写在 server 和 if 中而 break 一般使用在 location 中
last 不终止重写后的 url 匹配即新的 url 会再从 server 走一遍匹配流程而 break 终止重写后的匹配
break 和 last 都能组织继续执行后面的 rewrite 指令
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-04/142479.htm
