nginx笔记

一:nginx介绍及安装

安装准备: nginx依赖于pcre库,要先安装pcre，pcre-devel（rewrite需要pcre(正则)）

看到如下4个目录
. ....conf 配置文件
... html 网页文件
...logs 日志文件
...sbin 主要二进制程序

二:nginx信号量

　　当我们设置全局命令后，想知道nginx启动的时候是引用哪一个配置文件，或者配置文件的路径，可以使用nginx -t选项，是检测nginx配置文件的语法是否正确，同时会告诉我们配置文件的路径。apache的话我们使用httpd -V

nginx 信号量

QUIT Graceful shutdown 优雅的关闭进程,即等请求结束后再关闭

HUP 改变配置文件,平滑的重读配置文件

USR1 重读日志,在日志按月/日分割时有用

USR2 平滑的升级

WINCH 优雅关闭旧的进程(配合USR2来进行升级)

具体语法:
Kill -信号选项 nginx的主进程号
Kill -HUP 4873

Kill -信号控制 `cat /xxx/path/log/nginx.pid`

Kil; -USR1 `cat /xxx/path/log/nginx.pid`

三:Nginx配置段

// 全局区
worker_processes 1; // 有1个工作的子进程,可以自行修改,但太大无益,因为要争夺CPU,一般设置为 CPU数*核数

Event {
// 一般是配置nginx连接的特性
// 如1个word能同时允许多少连接
worker_connections 1024; // 这是指一个子进程最大允许连1024个连接
}

http { //这是配置http服务器的主要段
Server1 { // 这是虚拟主机段

Location { //定位,把特殊的路径或文件再次定位 ,如image目录单独处理
} /// 如.php单独处理

}

Server2 {
}
}

例子1: 基于域名的虚拟主机
server {
listen 80; #监听端口
server_name a.com; #监听域名

location / {
root /var/www/a.com; #根目录定位
index index.html;
}
}

例子2: 基于端口的虚拟主机配置

server {
listen 8080;
server_name 192.168.1.204;

location / {
root /var/www/html8080;
index index.html;
}
}

四:日志管理

　　我们观察nginx的server段,可以看到如下类似信息,#access_log logs/host.access.log main;这说明该server, 它的访问日志的文件是 logs/host.access.log ,使用的格式”main”格式.除了main格式,你可以自定义其他格式.

main格式是什么?
log_format main '$remote_addr - $remote_user [$time_local] "$request" '# '$status $body_bytes_sent "$http_referer" '# '"$http_user_agent" "$http_x_forwarded_for"';

main格式是我们定义好一种日志的格式,并起个名字,便于引用.以上面的例子, main类型的日志,记录的 remote_addr.... http_x_forwarded_for等选项.

1: 日志格式是指记录哪些选项
默认的日志格式: main
log_format main '$remote_addr - $remote_user [$time_local] "$request" ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent" "$http_x_forwarded_for"';

如默认的main日志格式,记录这么几项
远程IP- 远程用户/用户时间请求方法(如GET/POST) 请求体body长度 referer来源信息
http-user-agent用户代理/蜘蛛 ,被转发的请求的原始IP:http_x_forwarded_for:在经过代理时,代理把你的本来IP加在此头信息中,传输你的原始IP

nginx 日志切割（按天去切割访问日志）

实际应用: shell+定时任务+nginx信号管理,完成日志按日期存储

分析思路:

凌晨00:00:01,把昨天的日志重命名,放在相应的目录下，再USR1信息号控制nginx重新生成新的日志文件

具体的bash

#!/bin/bash
logpath=/usr/local/Cellar/nginx/1.10.3/logs/local.nginx.com.access.log;
bakpath=/data/nginxlog/$(date -v-1d +%Y%m)/;
mkdir -p $bakpath;
bak=$bakpath/$(date -v-1d +%d).access.log;
mv $logpath $bak;
touch $logpath;
kill -USR1 `cat /usr/local/Cellar/nginx/1.10.3/logs/nginx.pid`;

生成定时任务 crontab -e 1 0 * * * /usr/local/Cellar/nginx/1.10.3/logs/log.sh

五:location

location 有”定位”的意思, 根据Uri来进行不同的定位.
在虚拟主机的配置中,是必不可少的,location可以把网站的不同部分,定位到不同的处理方式上

location 的语法
location [=|~|~*|^~] patt {
}

中括号可以不写任何参数,此时称为一般匹配
也可以写参数
因此,大类型可以分为3种
location = patt {} [精准匹配]
location patt{} [一般匹配]
location ~ patt{} [正则匹配]

[精准匹配] (优先级是最高的)

location = patt {
config A
}
如果 $uri == patt,匹配成功，使用configA （千万注意：精确匹配patt不可以是目录，必须为精准的文件，否则会发生再次localtion的情况）

例子：

location = / {
root /var/www/html/;
index index.htm index.html;
}
location / {
root /usr/local/nginx/html;
index index.html index.htm;
}

如果访问　http://xxx.com/,最终会定位到哪个文件呢？

流程：

uri=/ 因为精确匹配的优先级最高，所以找到了第一段的localtion，映射的文件目录为/var/www/html/，但是服务器响应必须找到文件去执行返回给客户端，不能仅仅是一个目录，所以会去找index.htm,注意：此时的uri变成了/index.htm,会进行又一次的localtion匹配，第一段的精确匹配不上了，匹配第二段的一般匹配，所以最终执行的文件是/usr/local/nginx/html/index.htm

[正则匹配]

location / {
root /usr/local/nginx/html;
index index.html index.htm;
}

location ~ image {
root /var/www/image;
index index.html;
}

如果我们访问 http://xx.com/image/logo.png，此时, “/” 与”/image/logo.png” 匹配，同时,”image”正则与”image/logo.png”也能匹配,谁发挥作用?，正则匹配的优先级会比一般匹配高，而且匹配的字符越多，优先级越高。注意：root路径---> /,这个时候nginx就会去找 /var/www/image/image/logo.png

location / {
root /usr/local/nginx/html;
index index.html index.htm;
}

location /foo {
root /var/www/html;
index index.html;
}

我们访问 http://xxx.com/foo,对于uri “/foo”, 两个location的patt,都能匹配他们,即 ‘/’能从左前缀匹配 ‘/foo’, ‘/foo’也能左前缀匹配’/foo’,此时, 真正访问 /var/www/html/foo/index.html

原因:’/foo’匹配的更长,因此使用之.;

Location处理逻辑
1.用uri测试所有的prefix string;
2.Uri精确匹配到=定义的loacation，使用这个location，停止搜索；
3.匹配最长prefix string，如果这个最长prefix string带有^~修饰符，使用这个location，停止搜索，否则：
4.存储这个最长匹配；
5.然后匹配正则表达；
6.匹配到第一条正则表达式，使用这个location，停止搜索；
7.没有匹配到正则表达式，使用#4步存储的prefix string的location。

注意理解nginx中的root和alias

root---> /

alias ---> location中的uri

alias是一个目录别名的定义，root则是最上层目录的定义

还有一个重要的区别是alias后面必须要用“/”结束，否则会找不到文件的。。。而root则可有可无~~

location /img/ {
alias /var/www/image/;
}
#若按照上述配置的话，则访问/img/目录里面的文件时，ningx会自动去/var/www/image/目录找文件

location /img/ {
root /var/www/image;
}
#若按照这种配置的话，则访问/img/目录下的文件时，nginx会去/var/www/image/img/目录下找文件。

六:rewrite

重写中用到的指令
if (条件) {} 设定条件,再进行重写
set #设置变量
return #返回状态码
break #跳出rewrite
rewrite #重写

If 空格 (条件) {
重写模式
}

1: “=”来判断相等, 用于字符串比较
2: “~” 用正则来匹配(此处的正则区分大小写)
~* 不区分大小写的正则
3: -f -d -e来判断是否为文件,为目录,是否存在.

if ($remote_addr = 192.168.1.100) {
return 403;
}
if ($http_user_agent ~ MSIE) {
rewrite ^.*$ /ie.htm;
break; #(不break会循环重定向)
}
if (!-e $document_root$fastcgi_script_name) {
rewrite ^.*$ /404.html break;
}

注, 此处还要加break,
以 xx.com/dsafsd.html这个不存在页面为例,
我们观察访问日志, 日志中显示的访问路径,依然是GET /dsafsd.html HTTP/1.1
提示: 服务器内部的rewrite和302跳转不一样.
跳转的话URL都变了,变成重新http请求404.html, 而内部rewrite, 上下文没变,
就是说 fastcgi_script_name 仍然是 dsafsd.html,因此会循环重定向.

set 是设置变量用的, 可以用来达到多条件判断时作标志用.
达到apache下的 rewrite_condition的效果

如下: 判断IE并重写,且不用break; 我们用set变量来达到目的
if ($http_user_agent ~* msie) {
set $isie 1;
}

if ($fastcgi_script_name = ie.html) {
set $isie 0;
}

if ($isie 1) {
rewrite ^.*$ ie.html;
}

rewrite 可以用到的全局变量:

在 if, location, rewrite 指令中,可以使用以下全局变量;

$args

$content_length

$content_type

$document_root

$document_uri

$host

$http_user_agent

$http_cookie

$limit_rate

$request_body_file

$request_method

$remote_addr

$remote_port

$remote_user

$request_filename

$request_uri

$query_string

$scheme

$server_protocol

$server_addr

$server_name

$server_port

$uri

七:gzip压缩

原理:
浏览器---请求----> 声明可以接受 gzip压缩或 deflate压缩或compress 或 sdch压缩
从http协议的角度看--请求头声明 acceopt-encoding: gzip deflate sdch (是指压缩算法,其中sdch是google倡导的一种压缩方式,目前支持的服务器尚不多)
服务器-->回应---把内容用gzip方式压缩---->发给浏览器
浏览<-----解码gzip-----接收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压缩标志

注意:
图片/mp3这样的二进制文件,不必压缩
因为压缩率比较小, 比如100->80字节,而且压缩也是耗费CPU资源的.
比较小的文件不必压缩

八:nginx缓存设置

对于网站的图片,尤其是新闻站, 图片一旦发布, 改动的可能是非常小的.我们希望能否在用户访问一次后, 图片缓存在用户的浏览器端,且时间比较长的缓存，

可以, 用到 nginx的expires设置 .nginx中设置过期时间,非常简单,在location或if段里,来写.

格式 expires 30s;
expires 30m;
expires 2h;
expires 30d;
(注意:服务器的日期要准确,如果服务器的日期落后于实际日期,可能导致缓存失效)

另: 304 也是一种很好的缓存手段

原理是: 服务器响应文件内容是,同时响应etag标签(内容的签名,内容一变,他也变), 和 last_modified_since 2个标签值，浏览器下次去请求时,头信息发送这两个标签, 服务器检测文件有没有发生变化,如无,直接头信息返回 etag,last_modified_since，浏览器知道内容无改变,于是直接调用本地缓存.这个过程,也请求了服务器,但是传着的内容极少.对于变化周期较短的,如静态html,js,css,比较适于用这个方式

九:nginx反向代理服务器+负载均衡

　　　用nginx做反向代理和负载均衡非常简单,支持两个用法 1个proxy, 1个upstream,分别用来做反向代理,和负载均衡,以反向代理为例, nginx不自己处理php的相关请求,而是把php的相关请求转发给apache来处理

反向代理后端如果有多台服务器,自然可形成负载均衡,但proxy_pass如何指向多台服务器?把多台服务器用 upstream指定绑定在一起并起个组名,然后proxy_pass指向该组,默认的均衡的算法很简单,就是针对后端服务器的顺序,逐个请求.也有其他负载均衡算法,如一致性哈希,需要安装第3方模块

(upstream只写地址，不写http协议，http协议在proxy_pass写)

upstream imageserver {
　　server localhost:81 weight=1 max_fails=3 fail_timeout=3;
　　server localhost:82 weight=1 max_fails=3 fail_timeout=3;
}

location ~* \.(png|jpeg|jpg)$ {
# root tianye;
# expires 3m;
　　proxy_set_header x-forwarded-for $remote_addr;
　　proxy_pass http://imageserver;
}

反向代理导致了后端服务器的IP,为前端服务器的IP,而不是客户真正的IP,怎么办?

我们在反向代理的时候设置请求头 proxy_set_header x-forwarded-for $remote_addr 后端用$http_x_forwarded_for 接受，注意：请求头是x-forwarded-for，nginx接收用$http_x_forwarded_for,会把-转为_

posted @ 2017-04-01 20:59 tianye_guazi 阅读(173) 评论(0) 编辑收藏举报

刷新页面返回顶部

tianye_guazi

nginx笔记

公告