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

时间  2019-11-07
标签 前端 开发者 必备 nginx 知识 应用 栏目 职业生涯 繁體版
原文   原文链接
Nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器；同时也是一个 IMAP、 POP3、 SMTP代理服务器； Nginx能够做为一个 HTTP服务器进行网站的发布处理，另外 Nginx能够做为反向代理进行负载均衡的实现。

Nginx如今几乎是众多大型网站的必用技术，大多数状况下，咱们不须要去详细的配置它，可是了解它在应用程序中所担当的角色，以及如何解决这些问题是很是有必要的。下面就从基本概念开始介绍:javascript

正向代理与反向代理

代理是在服务器和客户端之间架设的一层服务器，代理将接收客户端的请求并将它转发给服务器，而后将服务器的响应转发给客户端。css

不论是正向代理仍是反向代理，实现的都是上面的功能。html

正向代理

位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并制定目标(原始服务器)，而后代理向原始服务器 转交请求并将得到的内容返回给客户端。

正向代理是为客户端服务的，客户端能够根据正向代理访问到它自己没法访问到的服务器资源。前端

正向代理对客户端是透明的，对服务端是非透明的，即服务端并不知道本身接收到的是来自代理的访问仍是来自真实客户端的访问。
正向代理java

反向代理

反向代理( Reverse Proxy)方式是值以代理服务器来接收链接请求，而后将请求转发给内部网络上的服务器，并将从服务器上获得结构返回给请求链接的客户端，此时代理服务器对外表现为一个反向代理服务器。

反向代理是为服务端服务的，反向代理能够帮助服务器接收来自客户端的请求，帮助服务器作请求的转发、负载均衡等。nginx

反向代理对服务端是透明的，对客户端是非透明的，即客户端并不知道本身访问的是代理服务器，而服务器知道反向代理在为它服务。
反向代理web

基本配置

配置结构

下面是Nginx配置文件的基本结构
Nginx配置结构json

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施加的安全限制。api

同源定义

若是两个页面的协议、端口、域名都相同，则这两个页面同源。

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

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程