Nginx与前端开发
Nginx与node.js
“Nginx是一款轻量级的HTTP服务器，采用事件驱动的异步非阻塞处理方式框架，这让其具有极好的IO性能，时常用于服务端的反向代理和负载均衡。”
作为前端开发，即使没用过Nginx，但一定听说过上面这句话。这句经典的话，基本构成了所有人对Nginx的第一印象。 Nginx发布于2004年，经过初期几年的沉淀之后，迅速蹿升为“网红”，成为了当年互联网技术圈最火的词汇和技术。然而经过多年的发展，到现在，当年的网红早已“过气”。因为如今基本上所有的大型网站都搭建在Nginx之上，Nginx不再是一个什么新词，而是互联网网站搭建的必选技术之一。看到这里，“HTTP服务器”、“事件驱动”、“异步非阻塞”以及Nginx的网红经历，是不是让前端童鞋们想到了Nodejs?
对于大部分前端童鞋，更倾向于用Nodejs来搭建服务器，进而实现一些需求，对Nginx有天然的抗拒感。的确，Nginx中的绝大部分功能，如果单纯的使用Node.js也可以满足和实现。但实际上，Nginx和Node.js并不冲突，都有自己擅长的领域：
Nginx更擅长于底层服务器端资源的处理（静态资源处理转发、反向代理，负载均衡等），Node.js更擅长于上层具体业务逻辑的处理。两者可以实现完美组合，助力前端开发
反向代理
什么是反向代理？ 互联网应用基本都基于CS基本结构，即client端和server端。代理其实就是在client端和真正的server端之前增加一层提供特定服务的服务器，即代理服务器。
-
正向代理
反向代理不好理解，正向代理大家总有用过，工具其实就是一个正向代理工具。它会把 们访问墙外服务器server的网页请求，代理到一个可以访问该网站的代理服务器proxy，这个代理服务器proxy把墙外服务器server上的网页内容获取，再转发给客户。具体的流程如下图。
概括说：就是客户端和代理服务器可以直接相互访问，属于一个LAN(局域网)，代理对用户是非透明的，即用户需要自己操作或者感知得到自己的请求被发送到代理服务器； 代理服务器通过代理用户端的请求来向域外服务器请求响应内容。
-
反向代理
反向代理正好相反，先看流程图。
在反向代理中（事实上，这种情况基本发生在所有的大型网站的页面请求中），客户端发送的请求，想要访问server服务器上的内容。但将被发送到一个代理服务器proxy，这个代理服务器将把请求代理到和自己属于同一个LAN下的内部服务器上，而用户真正想获得的内容就储存在这些内部服务器上。看到区别了吗，这里proxy服务器代理的并不是客户，而是服务器，即向外部客户端提供了一个统一的代理入口，客户端的请求，都先经过这个proxy服务器，至于在内网真正访问哪台服务器内容，由这个proxy去控制。一般代理是指代理客户端，而这里代理的对象是服务器，这就是“反向”这个词的意思。
Nginx就是来充当这个proxy的作用。 概括说：就是代理服务器和真正server服务器可以直接互相访问，属于一个LAN（服务器内网）；代理对用户是透明的，即无感知。 不论加不加这个反向代理，用户都是通过相同的请求进行的，且不需要任何额外的操作；代理服务器通过代理内部服务器接受域外客户端的请求，并将请求发送到对应的内部服务器上。
-
-
为什么要Nginx反向代理
1.安全及权限 : 使用反向代理后，用户端将无法直接通过请求访问真正的内容服务器，而必须首先通过Nginx。可以通过在Nginx层上将危险或者没有权限的请求内容过滤掉，从而保证了服务器的安全。
2.负载均衡 : 例如一个网站的内容被部署在若干台服务器上，可以把这些机子看成一个集群，那么Nginx可以将接收到的客户端请求“均匀地”分配到这个集群中所有的服务器上（内部模块提供了多种负载均衡算法），从而实现服务器压力的负载均衡
此外，nginx还带有健康检查功能（服务器心跳检查），会定期轮询向集群里的所有服务器发送健康检查请求，来检查集群中是否有服务器处于异常状态，一旦发现某台服务器异常，那么在以后代理进来的客户端请求都不会被发送到该服务器上（直到后面的健康检查发现该服务器恢复正常），从而保证客户端访问的稳定性。
前端可以用Nginx做些什么?
-
快速实现简单的访问限制
经常会遇到希望网站让某些特定用户的群体（比如只让公司内网）访问，或者控制某个uri不让人访问。Nginx配置如下：
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地址表，已内置）配合使用。
-
解决跨域
在众多的解决跨域方式中， 都不可避免的都需要服务端进行支持， 使用Nginx可以纯前端解决请求跨域问题。 特别是在前后端分离调试时， 经常需要在本地起前端工程， 接口希望拉取服务端的实际数据而不是本地的mock。 而如果本地程序直接访问远程接口， 肯定会遇到跨域问题。现在前端成熟的做法，一般是把node proxy server集成进来。事实上，用Nginx同样可以解决问题，甚至可以应用于线上 .
#请求跨域，这里约定代理请求url path是以/apis/开头
location ^~/apis/ {
# 这里重写了请求，将正则匹配中的第一个()中$1的path，拼接到真正的请求后面，并用break停止后续匹配
rewrite ^/apis/(.*)$ /$1 break;
proxy_pass https://www.kaola.com/;
}
-
适配PC与移动环境
现在很多网站都存在PC站和H5站两个站点，因此根据用户的浏览环境自动切换站点是很常见的需求。Nginx可以通过内置变量$http_user_agent，获取到请求客户端的userAgent，从而知道用户处于移动端还是PC，进而控制重定向到H5站还是PC站, pc端Nginx配置如下：
location / {
# 移动、pc设备适配
if ($http_user_agent ~* '(Android|webOS|iPhone|iPod|BlackBerry)') {
set $mobile_request '1';
}
if ($mobile_request = '1') {
rewrite ^.+ http://mysite-base-H5.com;
}
}
复制代码
-
合并请求
-
图片处理
-
页面内容修改
项目开发中的Nginx配置不当引发的问题
- 图片、文件上传失败（请求报413 Request Entity Too Large）
没有配置server的上传大小限制，会导致上传图片失败的问题，因为nginx默认的配置大小为1M，超过这个限制之后上传会报错：
client_max_body_size 1m;
因此需要修改nginx.conf配置文件如下所示：
server {
......
client_body_buffer_size 1m;
client_max_body_size 100m;
......
}
让后重新加载配置文件：
/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf
-
大批量导入数据时（接口请求连接超时）
因为nginx默认的连接存活时间为60秒，但是大批量导入数据会超过这个时间，报超时，因此需要修改默认的请求存活时间，单位为秒，proxy_connect_timeout的时间要略大于proxy_read_timeout、proxy_send_timeout。
location /test {
......
proxy_connect_timeout 3600s;
proxy_read_timeout 1800s;
proxy_send_timeout 1800s;
......
}