hehehechen 2019-09-08
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 | 服务器端口号 |
跨域指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的,是浏览器对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) |
例如:
现在在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
是规定的三种标准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
模块off
on
/ off
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
。
1
1-9
Content-length
小于该值的请求将不会被压缩。0
1000
以上MIME
类型)text/html
(默认不压缩js/css
)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
需要转发的服务端列表,并没有指定分配策略。
默认情况下采用的策略,将所有客户端请求轮询分配给服务端。这种策略是可以正常工作的,但是如果其中某一台服务器压力太大,出现延迟,会影响所有分配在这台服务器下的用户。
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
的请求永远只分配一台服务器,有效解决了动态网页存在的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站和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反向代理来来解决这些问题。比如现在我们用mirror.example.com镜像www.baidu.com,以下是详细操作。