共计 7072 个字符,预计需要花费 18 分钟才能阅读完成。
@toc
Nginx 概念
-
Nginx 是一款高性能的 HTTP 服务器, 反向代理服务器及电子邮件 (IMAP/POPP3) 代理服务器. 由俄罗斯的 Igor Sysoev 所开发,Nginx 可能撑持 5 万并发链接, 并且 CPU, 内存等资源耗费非常低, 运行十分稳固
Nginx 利用场景
- HTTP 服务器, 虚拟主机: Nginx 是一个 HTTP 服务能够独立提供 HTTP 服务, 能够做网页动态服务器, 能够实现在一台服务器上虚构出多个网站, 例如集体网站应用的虚拟主机
- 反向代理: 当网站的访问量达到肯定水平后, 单台服务器不能满足用户申请时, 须要用多台服务器集群时能够应用 Nginx 做反向代理
-
负载平衡: 多台服务器能够均匀分担负载, 不会因为某台服务器负载高宕机而某台服务器闲置的状况
HTTP 服务器, 虚拟主机
-
应用 Docker 装置运行 Nginx, 在./conf 里创立 nginx.conf 文件, 配置docker-compose.yml
version: '3.1' services: nginx: restart: always image: nginx container_name: nginx ports: - 80:80 volumes: - ./conf/nginx.conf:/etc/nginx/nginx.conf - ./wwwroot:/usr/share/nginx/wwwroot
- 虚拟主机: 虚拟主机是一种非凡的软硬件技术. 能够将网络上每一台计算机分成多个虚拟主机, 每个虚拟主机能够独立对外提供 www 服务, 这样就能实现一台主机对外提供多个 web 服务, 每个虚拟主机之间是独立的, 互不影响的
-
通过 Nginx 能够实现虚拟主机的配置,Nginx 反对三种类型的虚拟主机的配置:
- 基于 IP 的虚拟主机
- 基于域名的虚拟主机
- 基于端口的虚拟主机
-
Nginx 配置文件构造: 其中每个 server 就是一个主机
events { } http {server{} server{}}
基于域名的虚拟主机配置
-
需要:
- 两个域名指向同一台 Nginx 服务器, 用户拜访不同的域名显示不同的网页内容
- 两个域名是 admin.service.itoken.oxford.com 和 admin.web.itoken.oxford.com
- Nginx 服务器应用虚拟机 192.168.32.255
-
配置 Windows Hosts 文件:
- 批改 window 的 hosts 文件(C:/Windows/System32/drivers/etc)-SwitchHosts
- 通过 host 文件指定 admin.service.itoken.oxford.com 和 admin.web.itoken.oxford.com 对应 192.168.32.255 虚拟机
- 创立目录及文件: 在 /usr/local/docker/nginx/wwwroot目录下创立 htmlservice 和htmlweb两个目录, 并别离创立 index.html 文件
-
配置虚拟主机: 批改 /usr/local/docker/nginx/conf目录下的 nginx.conf 配置文件
user nginx; worker_processes 1; events {worker_connections 1024;} http{ include mime.type; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server{ listen 80; server_name admin.service.itoken.oxford.com # 所有的申请都是以 / 开始, 所有的申请都能够匹配此 location location / { root /usr/local/docker/nginx/wwwroot/htmlservice; # 指定欢送页面, 按从左到右程序查找 index index.html index.htm; } } server{ listen 80; server_name admin.web.itoken.oxford.com location / { root /usr/share/nginx/wwwroot/htmlweb; index index.html index.htm; } } }
基于端口的虚拟主机配置
-
需要:
- 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 配置文件
worker_processes 1; events {worker_connections 1024;} http{ include mime.type; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # 配置虚拟主机 192.168.32.255 server{ # 监听的 IP 和端口, 配置 192.168.32.255:80 listen 80; # 虚拟主机名称, 这里配置 IP 地址 server_name 192.168.32.255; # 所有的申请都是以 / 开始, 所有的申请都能够匹配此 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.32.255 server{ listen 8080; server_name 192.168.32.255; location / { root /usr/share/nginx/wwwroot/html8080; index index.html index.htm; } } }
Nginx 反向代理
代理服务器
客户端在发送申请时, 不会间接发送给目标主机. 而是先发给代理服务器, 代理服务器接管客户端申请后, 再向主机收回, 并接管目标主机返回的数据, 寄存在代理服务器的硬盘中, 再发送给客户机
代理服务器作用
- 进步访问速度: 因为指标主机返回的数据寄存在代理服务器的硬盘中, 因而下一次客户在拜访雷同的站点数据时, 会间接从代理服务器的硬盘中读取, 起到了缓存的作用, 尤其对于热门站点能明显提高申请速度
- 防火墙作用: 因为所有客户机申请都必须通过代理服务器拜访近程站点, 因而可在代理服务器上设限, 过滤掉某些不平安信息
-
通过代理服务器访问不能拜访的指标站点: 互联网上有许多凋谢的代理服务器, 客户机在拜访受限时, 可通过不受限的代理服务器拜访指标站点
正向代理
架设在客户机和指标主机之间, 只用于代理外部网络对 Internet 的连贯申请, 客户机必须指定代理服务器, 并将原本要间接发送到 web 服务器上的 http 申请发送到代理服务器中
反向代理
反向代理服务器架设在服务器端, 通过缓冲常常被申请的页面来缓解服务器的工作量, 将客户机申请转发给外部网络上的指标服务器, 并将从服务器上失去的后果返回给 Internet 上申请连贯的客户端, 此时代理服务器与指标主机一起对外体现为一个服务器
反向代理利用
- 避免外网对内网服务器的恶性攻打
- 缓存以缩小服务器压力
- 拜访安全控制
-
进行负载平衡, 将用户申请调配给多个服务器
Nginx 反向代理 Tomcat
-
启动 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
-
配置 Nginx 反向代理: 批改 /usr/local/docker/nginx/conf 目录下的 nginx.conf 配置文件
user nginx; worker_processes 1; events {worker_connection 1024;} http { include mime.type; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # 配置一个 tomcat1 代理服务器 upstream tomcat_server1 {server 192.168.32.255:9090;} # 配置一个 tomcat2 代理服务器 upstream tomcat_server2{server 192.168.32.255:9091;} server { listen 80; server_name admin.service.itoken.oxford.com # 所有的申请都是以 / 开始, 所有的申请都能够匹配此 location location / { # 域名 admin.service.itoken.oxford.com 的申请全副转发到 tomcat_server1, 即 tomcat1 服务器上 proxy_pass http://tomcat_server1; # 欢送页面, 依照从左到右的程序查找页面 index index.jsp index.html index.htm; } } server{ listen 80; server_name admin.web.itoken.oxford.com location / { # 域名 admin.web.itoken.oxford.com 的申请全副转发到 tomcat_server2, 即 tomcat2 服务器上 proxy_pass http://tomcat_server2; index index.jsp index.html index.htm; } } }
Nginx 负载平衡
负载平衡
- 负载平衡建设在现有网络结构之上, 提供了一种便宜无效通明的办法扩大网络设备和服务器的带宽, 减少吞吐量, 增强网络数据处理能力, 进步网络的灵活性和可用性
-
负载平衡(Load Balance), 摊派到多个操作单元上进行执行, 例如 Web 服务器,FTP 服务器, 企业要害应用服务器和其它要害工作服务器等, 从而共同完成工作工作
Nginx 实现负载平衡
-
需要:
- nginx 作为负载平衡服务器, 用户申请先达到 nginx, 再由 nginx 依据负载平衡配置将申请转发到 tomcat 服务器
- nginx 负载平衡服务器:192.168.32.255:80
- tomcat 服务器:192.168.32.255:9090
-
Nginx 配置负载平衡: 批改 /usr/local/docker/nginx/conf下的 nginx.conf 配置文件
user nginx; worker_processes 1; events {worker_connection 1024;} http { include mime.type; default_type application/octet-stream; sendfile on; keepalive_timeout 65; upstream myapp { server 192.168.32.255:9090 weight=10; server 192.168.32.255:9091 weight=10; } server{ listen 80; server_name nginx.oxford.com; location / { proxy_pass http://myapp; index index.jsp index.html index.htm; } } }
Nginx 解决跨域问题
跨域问题
- 在浏览器端进行 Ajax 申请时会呈现跨域问题
-
跨域: 浏览器不能执行其它网站的脚本. 是因为浏览器的同源策略造成的, 是浏览器对 JavaScript 施加的平安限度
同源
-
同源: 域名, 协定, 端口 均雷同
解决跨域问题形式
应用 CORS(跨资源共享)解决跨域问题
- CORS 是 W3C 规范, 全称 ” 跨资源共享 ”(Cross-origin resource sharing), 容许浏览器向跨源服务器收回 XMLHttpRequest 申请, 从而克服了 Ajax 只能同源应用的限度
- CORS 须要浏览器和服务器同时反对
- 目前, 所有浏览器都反对该性能,IE 浏览器不能低于 IE10.
- 整个 CORS 通信过程, 都是通过浏览器主动实现, 不须要用户参加. 对于开发者来说,CORS 通信与同源 Ajax 通信没有差异, 代码齐全一样.
- 浏览器一旦发现 Ajax 申请跨源, 就会主动增加一些附加的头信息, 有时还会多出一次附加 的申请, 但用户不会有感觉
- 实现 CORS 通信的要害是服务器, 只有服务器实现了 CORS 接口, 就能够跨域通信
-
在 header 中设置:Access-Control-Allow-Origin(在服务器申请控制器中的 controller 类标注 @CrossOrigin(value=”*”) 注解)
应用 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 与 JSON 应用的目标雷同, 然而比 JSONP 更弱小
- CORS 反对所有类型的 HTTP 申请
-
JSONP 只反对 GET 申请, JSON 的劣势在于反对老式浏览器, 以及能够向不反对 CORS 的网站申请数据
Nginx 反向代理解决跨域问题
-
当服务器无奈设置 header 或提供 callback 函数时就能够采纳 Nginx 反向代理解决跨域问题
Nginx 配置跨域
-
在 /usr/local/docker/nginx/conf中的 nginx.conf 里的 location 中减少配置(Get: 字体跨域):
add_header Access-Control-Allow-Origin * 或域名; add_header Access-Control-Allow-Headers X-Requested-with; add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
-
配置 /usr/local/docker/nginx/conf中的 nginx.conf 配置文件(POST: 上传文件):
user nginx; worker_processes 1; events {worker_connection 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.32.255: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 形式 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; } } } }