前端开发者必备的Nginx知识及应用

50次阅读

共计 6301 个字符,预计需要花费 16 分钟才能阅读完成。

Nginx是一款自由的、开源的、高性能的 HTTP 服务器和反向代理服务器;同时也是一个 IMAPPOP3SMTP 代理服务器;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 客户端请求类型,如 GETPOST
$remote_addr 客户端的 IP 地址
$remote_port 客户端的端口
$args 请求中的参数
$content_length 请求头中的 Content-length 字段
$http_user_agent 客户端 User-Agent 信息
$http_cookie 客户端的 cookie 信息
$server_protocol 请求使用的协议,如HTTP/1.0HTTP/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.comdev.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访问 Nginxfe.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 传输 HTMLCSSJavaScript 等资源文件。

对于文本文件,gzip的效果非常明显,开启后传输所需流量大约会降至 1/4 ~ 1/3。

并不是每个浏览器都支持 gzip 的,如何知道客户端是否支持 gzip 呢,请求头中的 Accept-Encoding 来标识对压缩的支持。

启用 gzip 同时需要客户端和服务端的支持,如果客户端支持 gzip 的解析,那么只要服务端能够返回 gzip 的文件就可以启用 gzip 了, 我们可以通过 Nginx 的配置来让服务端支持 gzip。下面的responeContent-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;
}

其实 denyallowngx_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 基本配置与参数说明

正文完
 0