Nginx
是一款自由的、开源的、高性能的 HTTP 服务器和反向代理服务器;同时也是一个IMAP
、POP3
、SMTP
代理服务器;Nginx
可以作为一个HTTP
服务器进行网站的发布处理,另外Nginx
可以作为反向代理进行负载均衡的实现。
Nginx
现在几乎是众多大型网站的必用技术,大多数情况下,我们不需要去详细的配置它,但是了解它在应用程序中所担当的角色,以及如何解决这些问题是非常有必要的。下面就从基本概念开始介绍:
正向代理与反向代理
代理 是在服务器和客户端之间架设的一层服务器,代理 将接收客户端的请求并将它转发给服务器,然后将服务器的响应转发给客户端。
不管是正向代理还是反向代理,实现的都是上面的功能。
正向代理
位于客户端和原始服务器 (origin server) 之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并制定目标 (原始服务器),然后代理向原始服务器 转交请求 并将获得的内容返回给客户端。
正向代理 是为 客户端服务的,客户端可以根据正向代理访问到它本身无法访问到的服务器资源。
正向代理 对客户端是透明的,对服务端是非透明的,即服务端并不知道自己接收到的是来自代理的访问还是来自真实客户端的访问。
反向代理
反向代理 (
Reverse Proxy
) 方式是值以代理服务器来接收连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到结构返回给请求连接的客户端,此时代理服务器对外表现为一个反向代理服务器。
反向代理 是为服务端服务的,反向代理可以帮助服务器接收来自客户端的请求,帮助服务器做请求的转发、负载均衡等。
反向代理 对服务端是透明的,对客户端是非透明的,即客户端并不知道自己访问的是代理服务器,而服务器知道反向代理在为它服务。
基本配置
配置结构
下面是 Nginx
配置文件的基本结构
events { }
http
{
server
{
location path
{...}
location path
{...}
}
server
{...}
}
-
main
: Nginx 的全局配置,对全局生效。 -
events
: 配置影响 Nginx 服务器或与用户的网络连接。 -
http
: 可以嵌套多个server
,配置代理、缓存、日志等绝大多数功能和第三方模块的配置。 -
server
: 配置虚拟主机的相关参数,一个http
中可以有多个server
。 -
location
: 配置请求的路由,以及各种页面的处理情况。 -
upstream
: 配置后端服务器的具体地址,负载均衡不可或缺的部分。
常用内置变量
下面是 Nginx
一些配置中的内置全局变量,你可以在配置的任意位置使用它们。
变量名 | 功能 |
---|---|
$host |
请求信息中的 Host ,如果请求中没有Host 行,则等于设置的服务器名 |
$request_method |
客户端请求类型,如 GET 、POST 等 |
$remote_addr |
客户端的 IP 地址 |
$remote_port |
客户端的端口 |
$args |
请求中的参数 |
$content_length |
请求头中的 Content-length 字段 |
$http_user_agent |
客户端 User-Agent 信息 |
$http_cookie |
客户端的 cookie 信息 |
$server_protocol |
请求使用的协议,如HTTP/1.0 、HTTP/1.1
|
$server_addr |
服务器地址 |
$server_name |
服务器名称 |
$server_port |
服务器端口号 |
前端可以用 Nginx 做些什么
解决跨域
跨域定义
跨域指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的,是浏览器对 JavaScript
施加的安全限制。
同源定义
如果两个页面的协议、端口、域名都相同,则这两个页面同源。
URL | 结构 | 原因 |
---|---|---|
http://clearlove.com/dir/a.html | 成功 | |
http://clearlove.com/dir2/b.html | 成功 | |
https://clearlove.com/dir/a.html | 失败 | 不同协议(http 和 https) |
http://clearlove.com:81/dir/a.html | 失败 | 不同端口(80 和 81) |
http://meiko.com/dir/a.html | 失败 | 不同域名(clearlove 和 meiko) |
Nginx 解决跨域的原理
例如:
- 前端 server 的域名为:fe.server.com
- 后端服务的域名为:dev.server.com
现在在 fe.server.com
对dev.server.com
发起请求一定会出现跨域。
现在我们只需要启动一个 Nginx 服务器,将 server_name
设置为 fe.server.com
, 然后设置相应的location
以拦截前端需要跨域的请求,最后将请求代理回dev.server.com
。如下面的配置:
server {
listen 80;
server_name fe.server.com;
location / {proxy_pass dev.server.com;}
}
这样可以完美绕过浏览器的同源策略:fe.server.com
访问 Nginx
的fe.server.com
属于同源访问,而 Nginx
对服务端转发的请求不会触发浏览器的同源策略。
请求过滤
根据状态码过滤
error_page 500 501 502 503 504 506 /50x.html;
location = /50x.html {
#将根路径改为存放 html 的路径。root /root/static/html;
}
根据请求类型过滤
if ($request_method !~ ^(GET|POST|HEAD)$ ) {return 403;}
其他
可以根据 URL
、 文件请求类型
等进行过滤。
配置 gzip
gzip
是规定的三种标准 HTTP
压缩格式之一。目前绝大多数的网站都在使用 gzip
传输 HTML
、CSS
、JavaScript
等资源文件。
对于文本文件,gzip
的效果非常明显,开启后传输所需流量大约会降至 1/4 ~ 1/3。
并不是每个浏览器都支持 gzip
的,如何知道客户端是否支持 gzip
呢,请求头中的 Accept-Encoding
来标识对压缩的支持。
启用 gzip
同时需要客户端和服务端的支持,如果客户端支持 gzip
的解析,那么只要服务端能够返回 gzip
的文件就可以启用 gzip
了, 我们可以通过 Nginx
的配置来让服务端支持 gzip
。下面的respone
中Content-Encoding: gzip
,指服务端开启了 gzip
的压缩方式。
gzip on;
gzip_http_version 1.1;
gzip_comp_level 5;
gzip_min_length 1000;
gzip_types text/csv text/xml text/css text/plain text/javascript application/javascript application/x-javascript application/json application/xml;
gzip
- 开启或者关闭
gzip
模块 - 默认值为
off
- 可配置为
on
/off
gzip_http_version
- 启用
gZip
所需的HTTP
最低版本 - 默认值为
HTTP/1.1
这里为什么默认版本不是 1.0
呢?
HTTP
运行在 TCP
连接之上,自然也有着跟 TCP
一样的三次握手、慢启动等特性。
启用持久连接情况下,服务器发出响应后让 TCP
连接继续打开着。同一对客户 / 服务器之间的后续请求和响应可以通过这个连接发送。
为了尽可能的提高 HTTP
性能,使用持久连接就显得尤为重要了。
HTTP/1.1
默认支持 TCP
持久连接,HTTP/1.0
也可以通过显式指定 Connection: keep-alive
来启用持久连接。对于 TCP
持久连接上的 HTTP
报文,客户端需要一种机制来准确判断结束位置,而在 HTTP/1.0
中,这种机制只有 Content-Length
。而在HTTP/1.1
中新增的 Transfer-Encoding: chunked
所对应的分块传输机制可以完美解决这类问题。
Nginx
同样有着配置 chunked
的属性chunked_transfer_encoding
,这个属性是默认开启的。
Nginx
在启用了 gZip
的情况下,不会等文件 gzip
完成再返回响应,而是边压缩边响应,这样可以显著提高 TTFB
(Time To First Byte,首字节时间,WEB 性能优化重要指标)。这样唯一的问题是,Nginx
开始返回响应时,它无法知道将要传输的文件最终有多大,也就是无法给出 Content-Length
这个响应头部。
所以,在 HTTP1.0
中如果利用 Nginx
启用了 gzip
,是无法获得Content-Length
的,这导致 HTTP1.0
中开启持久链接和使用 gzip
只能二选一,所以在这里 gzip_http_version
默认设置为1.1
。
gzip_comp_level
- 压缩级别,级别越高压缩率越大,当然压缩时间也就越长(传输快但比较消耗 cpu)。
- 默认值:
1
- 压缩级别取值:
1-9
gzip_min_length
- 设置允许压缩的页面最小字节数,
Content-Length
小于该值的请求将不会被压缩。 - 默认值:
0
- 当设置的值较小时,压缩后的长度可能比原文件大,建议设置
1000
以上
gzip_types
- 要采用 gzip 压缩的文件类型 (
MIME
类型) - 默认值:
text/html
(默认不压缩js/css
)
负载均衡
Nginx 如何实现负载均衡
upstream
指定后端服务器地址列表
upstream balanceServer {
server 10.1.22.33:12345;
server 10.1.22.34:12345;
server 10.1.22.35:12345;
}
在 server
中拦截响应请求,并将请求转发到 upstream
中配置的服务器列表。
server {
server_name fe.server.com;
listen 80;
location /api {proxy_pass http://balanceServer;}
}
上面的配置只是指定了 Nginx
需要转发的服务端列表,并没有指定分配策略。
Nginx 实现负载均衡的策略
轮询策略
默认情况下采用的策略,将所有客户端请求轮询分配给服务端。这种策略是可以正常工作的,但是如果其中某一台服务器压力太大,出现延迟,会影响所有分配在这台服务器下的用户。
upstream balanceServer {
server 10.1.22.33:12345;
server 10.1.22.34:12345;
server 10.1.22.35:12345;
}
最小连接数策略
将请求 优先分配给压力较小的服务器,它可以平衡每个队列的长度,并避免向压力大的服务器添加更多的请求。
upstream balanceServer {
least_conn;
server 10.1.22.33:12345;
server 10.1.22.34:12345;
server 10.1.22.35:12345;
}
最快响应时间策略
依赖于 Nginx Plus,优先分配给响应时间最短的服务器。
upstream balanceServer {
fair;
server 10.1.22.33:12345;
server 10.1.22.34:12345;
server 10.1.22.35:12345;
}
客户端 IP 绑定
来自同一个 IP
的请求永远只分配一台服务器,有效解决了动态网页存在的 session
共享问题。
upstream balanceServer {
ip_hash;
server 10.1.22.33:12345;
server 10.1.22.34:12345;
server 10.1.22.35:12345;
}
负载均衡服务器配置参数
Nginx 实现负载均衡的策略中,每一台服务器后面都可以携带的参数有:
-
down
: 当前服务器不参与负载均衡。 -
weight
: 权重,值越大,服务器的负载量就越大。 -
max_fails
: 允许请求失败的次数,默认为 1。 -
fail_timeout
:max_fails
次失败后暂停的时间。 -
backup
: 备份机,只有其它所有的非backup
机器down
或者忙时才会请求backup
机器。
如下面的配置是指:负载中有三台服务器,当请求到达时,nginx 按时间顺序和权重把请求分配给三台服务器处理,例如有 100 个请求,有 30% 是服务器 33 处理,有 50% 的请求是服务器 34 处理,有 20% 的请求是服务器 35 处理。
upstream balanceServer {
server 10.1.22.33:12345 weight=30;
server 10.1.22.34:12345 weight=50;
server 10.1.22.35:12345 weight=20;
}
如下面的配置是指:负载中有三台服务器,服务器 33 的失败超时时间为 60s,服务器 34 暂不参与负载,服务器 35 只用作备份机。
upstream balanceServer {
server 10.1.22.33:12345 fail_timeout=60s;
server 10.1.22.34:12345 down;
server 10.1.22.35:12345 backup;
}
静态资源服务器
location ~* \.(png|gif|jpg|jpeg)$ {
root /root/static/;
autoindex on;
access_log off;
expires 10h;# 设置过期时间为 10 小时
}
匹配以 png|gif|jpg|jpeg
为结尾的请求,并将请求转发到本地路径,root
中指定的路径即 Nginx
本地路径。同时也可以进行一些缓存的设置。
访问限制
经常会遇到希望网站让某些特定用户的群体(比如只让公司内网)访问,或者控制某个 url 不让人访问。配置如下:
location / {
deny 192.168.1.100;
allow 192.168.1.10/200;
allow 10.110.50.16;
deny all;
}
其实 deny
和allow
是 ngx_http_access_module
模块(已内置)中的语法。采用的是从上到下匹配方式,匹配到就跳出不再继续匹配。
上述配置的意思就是,首先禁止 192.168.1.100 访问,然后允许 192.168.1.10-200 ip 段内的访问(排除 192.168.1.100),同时允许 10.110.50.16 这个单独 ip 的访问,剩下未匹配到的全部禁止访问。实际生产中,经常和 ngx_http_geo_module
模块(可以更好地管理 ip 地址表,已内置)配合使用。
适配 PC 与移动环境
现在很多网站都存在 PC 站和 H5 站两个站点,因此根据用户的浏览环境自动切换站点是很常见的需求。
Nginx
可以通过内置变量$http_user_agent
,获取到请求客户端的userAgent
,从而知道用户处于移动端还是 PC,进而控制重定向到 H5 站还是 PC 站。比如,PC 端站点是 mysite.com,H5 端是 mysite-H5.com。配置如下:
location / {
# 移动、pc 设备适配
if ($http_user_agent ~* '(Android|webOS|iPhone|iPod|BlackBerry)') {set $mobile_request '1';}
if ($mobile_request = '1') {rewrite ^.+ http://mysite-H5.com;}
}
总结
上述只是通过一些简单的应用,希望能够引起广大前端童靴对 Niginx
的兴趣。事实上,Nginx
不仅仅局限于这些微小的工作,在实际生产中作用其实更加巨大。对于有志于“大前端”的童靴,了解和熟悉 Nginx
绝对是必修技能之一。
其他
Nginx 基本配置与参数说明