什么是 Nginx
概述
Nginx 是一款高性能的 HTTP 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器。由俄罗斯的程序设计师 Igor Sysoev 所开发,官方测试 Nginx 能够支支撑 5 万并发链接,并且 CPU、内存等资源消耗却非常低,运行非常稳定。
Nginx 的应用场景
- HTTP 服务器:Nginx 是一个 HTTP 服务可以独立提供 HTTP 服务。可以做网页静态服务器。
- 虚拟主机:可以实现在一台服务器虚拟出多个网站。例如个人网站使用的虚拟主机。
- 反向代理,负载均衡:当网站的访问量达到一定程度后,单台服务器不能满足用户的请求时,需要用多台服务器集群可以使用 Nginx 做反向代理。并且多台服务器可以平均分担负载,不会因为某台服务器负载高宕机而某台服务器闲置的情况。
Nginx 虚拟主机
概述
我们使用 Docker 来安装和运行 Nginx,docker-compose.yml
配置如下:
version: '3.1'
services:
nginx:
restart: always
image: nginx
container_name: nginx
ports:
- 81:80
volumes:
- ./conf/nginx.conf:/etc/nginx/nginx.conf
- ./wwwroot:/usr/share/nginx/wwwroot
什么是虚拟主机?
虚拟主机是一种特殊的软硬件技术,它可以将网络上的每一台计算机分成多个虚拟主机,每个虚拟主机可以独立对外提供 www 服务,这样就可以实现一台主机对外提供多个 web 服务,每个虚拟主机之间是独立的,互不影响的。
通过 Nginx 可以实现虚拟主机的配置,Nginx 支持三种类型的虚拟主机配置
- 基于 IP 的虚拟主机
- 基于域名的虚拟主机
- 基于端口的虚拟主机
Nginx 配置文件的结构
# ...
events {
# ...
}
http {
# ...
server{
# ...
}
# ...
server{
# ...
}
}
注: 每个 server 就是一个虚拟主机
基于端口的虚拟主机配置
需求
- Nginx 对外提供 80 和 8080 两个端口监听服务
- 请求 80 端口则请求 html80 目录下的 html
- 请求 8080 端口则请求 html8080 目录下的 html
创建目录及文件
在 /usr/local/docker/nginx/wwwroot
目录下创建 html80
和 html8080
两个目录,并分辨创建两个 index.html 文件
配置虚拟主机
修改 /usr/local/docker/nginx/conf
目录下的 nginx.conf 配置文件:
# 启动进程,通常设置成和 CPU 的数量相等
worker_processes 1;
events {
# epoll 是多路复用 IO(I/O Multiplexing) 中的一种方式
# 但是仅用于 linux2.6 以上内核,可以大大提高 nginx 的性能
use epoll;
# 单个后台 worker process 进程的最大并发链接数
worker_connections 1024;
}
http {
# 设定 mime 类型,类型由 mime.type 文件定义
include mime.types;
default_type application/octet-stream;
# sendfile 指令指定 nginx 是否调用 sendfile 函数(zero copy 方式)来输出文件,对于普通应用,
# 必须设为 on,如果用来进行下载等应用磁盘 IO 重负载应用,可设置为 off,以平衡磁盘与网络 I/O 处理速度,降低系统的 uptime.
sendfile on;
# 连接超时时间
keepalive_timeout 65;
# 设定请求缓冲
client_header_buffer_size 2k;
# 配置虚拟主机 192.168.75.145
server {
# 监听的ip和端口,配置 192.168.75.145:80
listen 80;
# 虚拟主机名称这里配置ip地址
server_name 192.168.75.145;
# 所有的请求都以 / 开始,所有的请求都可以匹配此 location
location / {
# 使用 root 指令指定虚拟主机目录即网页存放目录
# 比如访问 http://ip/index.html 将找到 /usr/local/docker/nginx/wwwroot/html80/index.html
# 比如访问 http://ip/item/index.html 将找到 /usr/local/docker/nginx/wwwroot/html80/item/index.html
root /usr/share/nginx/wwwroot/html80;
# 指定欢迎页面,按从左到右顺序查找
index index.html index.htm;
}
}
# 配置虚拟主机 192.168.75.245
server {
listen 8080;
server_name 192.168.75.145;
location / {
root /usr/share/nginx/wwwroot/html8080;
index index.html index.htm;
}
}
}
基于域名的虚拟主机配置
需求
- 两个域名指向同一台 Nginx 服务器,用户访问不同的域名显示不同的网页内容
- 两个域名是
admin.service.itoken.funtl.com
和admin.web.itoken.funtl.com
- Nginx 服务器使用虚拟机 192.168.75.145
配置 Windows Hosts
文件
- 通过 host 文件指定
admin.service.itoken.funtl.com
和admin.web.itoken.funtl.com
对应 192.168.75.145 虚拟机: - 修改 window 的 hosts 文件:(C:\Windows\System32\drivers\etc)
创建目录及文件
在 /usr/local/docker/nginx/wwwroot
目录下创建 htmlservice
和 htmlweb
两个目录,并分辨创建两个 index.html 文件
配置虚拟主机
user nginx;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name admin.service.itoken.funtl.com;
location / {
root /usr/share/nginx/wwwroot/htmlservice;
index index.html index.htm;
}
}
server {
listen 80;
server_name admin.web.itoken.funtl.com;
location / {
root /usr/share/nginx/wwwroot/htmlweb;
index index.html index.htm;
}
}
}
Nginx 反向代理
什么是代理服务器?
代理服务器,客户机在发送请求时,不会直接发送给目的主机,而是先发送给代理服务器,代理服务接受客户机请求之后,再向主机发出,并接收目的主机返回的数据,存放在代理服务器的硬盘中,再发送给客户机。
为什么要使用代理服务器?
提高访问速度
由于目标主机返回的数据会存放在代理服务器的硬盘中,因此下一次客户再访问相同的站点数据时,会直接从代理服务器的硬盘中读取,起到了缓存的作用,尤其对于热门站点能明显提高请求速度。
防火墙作用
由于所有的客户机请求都必须通过代理服务器访问远程站点,因此可在代理服务器上设限,过滤某些不安全信息。
通过代理服务器访问不能访问的目标站点
互联网上有许多开放的代理服务器,客户机在访问受限时,可通过不受限的代理服务器访问目标站点,通俗说,我们使用的翻墙浏览器就是利用了代理服务器,虽然不能出国,但也可直接访问外网。
什么是正向代理?
正向代理,架设在客户机与目标主机之间,只用于代理内部网络对 Internet 的连接请求,客户机必须指定代理服务器,并将本来要直接发送到 Web 服务器上的 Http 请求发送到代理服务器中。
什么是反向代理?
反向代理服务器架设在服务器端,通过缓冲经常被请求的页面来缓解服务器的工作量,将客户机请求转发给内部网络上的目标服务器;并将从服务器上得到的结果返回给 Internet 上请求连接的客户端,此时代理服务器与目标主机一起对外表现为一个服务器。
反向代理有哪些主要应用?
现在许多大型 web 网站都用到反向代理。除了可以防止外网对内网服务器的恶性攻击、缓存以减少服务器的压力和访问安全控制之外,还可以进行负载均衡,将用户请求分配给多个服务器。
使用 Nginx 反向代理 Tomcat
需求
- 两个 tomcat 服务通过 nginx 反向代理
- nginx 服务器:192.168.75.145:80
- tomcat1 服务器:192.168.75.145:9090
- tomcat2 服务器:192.168.75.145:9091
启动 Tomcat 容器
启动两个 Tomcat 容器,映射端口为 9090 和 9091,docker-compose.yml 如下:
version: '3'
services:
tomcat1:
image: tomcat
container_name: tomcat1
ports:
- 9090:8080
tomcat2:
image: tomcat
container_name: tomcat2
ports:
- 9091:8080
修改 /usr/local/docker/nginx/conf
目录下的 nginx.conf 配置文件:
user nginx;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
# 配置一个代理即 tomcat1 服务器
upstream tomcatServer1 {
server 192.168.75.145:9090;
}
# 配置一个代理即 tomcat2 服务器
upstream tomcatServer2 {
server 192.168.75.145:9091;
}
# 配置一个虚拟主机
server {
listen 80;
server_name admin.service.itoken.funtl.com;
location / {
# 域名 admin.service.itoken.funtl.com 的请求全部转发到 tomcat_server1 即 tomcat1 服务上
proxy_pass http://tomcatServer1;
# 欢迎页面,按照从左到右的顺序查找页面
index index.jsp index.html index.htm;
}
}
server {
listen 80;
server_name admin.web.itoken.funtl.com;
location / {
# 域名 admin.web.itoken.funtl.com 的请求全部转发到 tomcat_server2 即 tomcat2 服务上
proxy_pass http://tomcatServer2;
index index.jsp index.html index.htm;
}
}
}
注意:新版 Nginx 的 upstream
配置中的名称不可以有下划线(“_”),否则会报 400
错误
Nginx 负载均衡
什么是负载均衡
负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡,英文名称为 Load Balance,其意思就是分摊到多个操作单元上进行执行,例如 Web 服务器、FTP 服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。
Nginx 实现负载均衡
- nginx 作为负载均衡服务器,用户请求先到达 nginx,再由 nginx 根据负载配置将请求转发至 tomcat 服务器
- nginx 负载均衡服务器:192.168.75.145:80
- tomcat1 服务器:192.168.75.145:9090
- tomcat2 服务器:192.168.75.145:9091
Nginx 配置负载均衡
修改 /usr/local/docker/nginx/conf
目录下的 nginx.conf 配置文件:
user nginx;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
upstream myapp1 {
server 192.168.75.145:9090 weight=10;
server 192.168.75.145:9091 weight=10;
}
server {
listen 80;
server_name nginx.funtl.com;
location / {
proxy_pass http://myapp1;
index index.jsp index.html index.htm;
}
}
}
相关配置说明
# 定义负载均衡设备的 Ip及设备状态
upstream myServer {
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
}
在需要使用负载的 Server 节点下添加
proxy_pass http://myServer;
upstream
:每个设备的状态:down
:表示当前的server
暂时不参与负载weight
:默认为 1weight
越大,负载的权重就越大。max_fails
:允许请求失败的次数默认为 1 当超过最大次数时,返回proxy_next_upstream
模块定义的错误fail_timeout
:max_fails
次失败后,暂停的时间。backup
:其它所有的非backup
机器down
或者忙的时候,请求backup
机器。所以这台机器压力会最轻
使用 Nginx 解决跨域问题
概述
在浏览器端进行 Ajax 请求时会出现跨域问题,那么什么是跨域,如何解决跨域呢?先看浏览器端出现跨域问题的现象,如下图所示
什么是跨域问题?
跨域,指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的,是浏览器对 JavaScript 施加的安全限制。
什么是同源?
所谓同源是指,域名,协议,端口均相同
- http://www.funtl.com --> http://admin.funtl.com 跨域
- http://www.funtl.com --> http://www.funtl.com 非跨域
- http://www.funtl.com --> http://www.funtl.com:8080 跨域
- http://www.funtl.com --> https://www.funtl.com 跨域
如何解决跨域问题?
使用 CORS(跨资源共享)解决跨域问题
CORS 是一个 W3C 标准,全称是"跨域资源共享"(Cross-origin resource sharing)。它允许浏览器向跨源服务器,发出 XMLHttpRequest
请求,从而克服了 AJAX 只能同源使用的限制。
CORS 需要浏览器和服务器同时支持。目前,所有浏览器都支持该功能,IE 浏览器不能低于 IE10。整个 CORS 通信过程,都是浏览器自动完成,不需要用户参与。对于开发者来说,CORS 通信与同源的 AJAX 通信没有差别,代码完全一样。浏览器一旦发现 AJAX 请求跨源,就会自动添加一些附加的头信息,有时还会多出一次附加的请求,但用户不会有感觉。因此,实现 CORS 通信的关键是服务器。只要服务器实现了 CORS
接口,就可以跨源通信(在 header
中设置:Access-Control-Allow-Origin
)
使用 JSONP 解决跨域问题
JSONP(JSON with Padding)是 JSON 的一种“使用模式”,可用于解决主流浏览器的跨域数据访问的问题。由于同源策略,一般来说位于 server1.example.com
的网页无法与 server2.example.com
的服务器沟通,而 HTML 的 <script>
元素是一个例外。利用 <script>
元素的这个开放策略,网页可以得到从其他来源动态产生的 JSON 资料,而这种使用模式就是所谓的 JSONP。用 JSONP 抓到的资料并不是 JSON,而是任意的 JavaScript
,用 JavaScript
直译器执行而不是用 JSON 解析器解析(需要目标服务器配合一个 callback
函数)。
CORS 与 JSONP 的比较
CORS 与 JSONP 的使用目的相同,但是比 JSONP 更强大。
JSONP 只支持 GET 请求,CORS 支持所有类型的 HTTP 请求。JSONP 的优势在于支持老式浏览器,以及可以向不支持 CORS 的网站请求数据。
使用 Nginx 反向代理解决跨域问题
以上跨域问题解决方案都需要服务器支持,当服务器无法设置 header
或提供 callback
时我们就可以采用 Nginx
反向代理的方式解决跨域问题。
Nginx 配置跨域案例,在 nginx.conf
的 location
中增加如下配置:
add_header Access-Control-Allow-Origin *或域名;
add_header Access-Control-Allow-Headers X-Requested-With;
add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
以下为文件上传的跨域配置方案:
user nginx;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name upload.myshop.com;
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
location / {
proxy_pass http://192.168.0.104:8888;
if ($request_method = 'OPTIONS') {
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers X-Requested-With;
add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,PATCH,OPTIONS;
# 解决假请求问题,如果是简单请求则没有这个问题,但这里是上传文件,首次请求为 OPTIONS 方式,实际请求为 POST 方式
# Provisional headers are shown.
# Request header field Cache-Control is not allowed by Access-Control-Allow-Headers in preflight response. add_header Access-Control-Allow-Headers DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range;
return 200;
}
}
}
}