Nginx应用以及配置

时间:2023-03-23 20:05:28

Nginx应用以及配置

本文大纲
一、Nginx概述
二、Nginx应用场景

三、Nginx虚拟主机
3.1.Docker安装和运行Nginx
3.2.Nginx虚拟主机方式
3.3.Nginx配置文件的结构
3.4.基于端口的虚拟主机配置
3.5.基于域名的虚拟主机配置

四、Nginx反向代理
4.1.代理服务器概述
4.2.代理服务器作用
4.3.正向代理
4.4.反向代理
4.5.反向代理作用
4.6.Nginx反向代理Tomcat

五、Nginx负载均衡
5.1.负载均衡概述
5.2.Nginx 实现负载均衡
5.3.Nginx 配置负载均衡

六、Nginx解决跨域问题
6.1.跨域概述
6.2.如何解决跨域问题
6.3.使用 Nginx 反向代理解决跨域问题

一、Nginx概述

Nginx 是一款高性能的 HTTP 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器。官方测试 Nginx 能够支支撑 5 万并发链接,并且 CPU、内存等资源消耗却非常低,运行非常稳定。

二、Nginx应用场景

1.HTTP 服务器:Nginx 是一个 HTTP 服务可以独立提供 HTTP 服务。可以做网页静态服务器。

2.虚拟主机:可以实现在一台服务器虚拟出多个网站。例如个人网站使用的虚拟主机。

3.反向代理,负载均衡:当网站的访问量达到一定程度后,单台服务器不能满足用户的请求时,需要用多台服务器集群可以使用 Nginx 做反向代理。并且多台服务器可以平均分担负载,不会因为某台服务器负载高宕机而某台服务器闲置的情况。

三、Nginx虚拟主机

3.1.Docker安装和运行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

3.2.Nginx虚拟主机方式

虚拟主机是一种特殊的软硬件技术,它可以将网络上的每一台计算机分成多个虚拟主机,每个虚拟主机可以独立对外提供 www 服务,这样就可以实现一台主机对外提供多个 web 服务,每个虚拟主机之间是独立的,互不影响的。

通过 Nginx 可以实现虚拟主机的配置,Nginx 支持三种类型的虚拟主机配置
1.基于 IP 的虚拟主机

2.基于域名的虚拟主机

3.基于端口的虚拟主机

3.3.Nginx配置文件的结构

# ...
events {
	# ...
}
http {
	# ...
	server{
		# ...
	}
	
	# ...
	server{
		# ...
	}
}

注: 每个 server 就是一个虚拟主机

3.4.基于端口的虚拟主机配置

需求

  • Nginx 对外提供 80 和 8080 两个端口监听服务
  • 请求 80 端口则请求 html80 目录下的 html
  • 请求 8080 端口则请求 html8080 目录下的 html

1.创建目录及文件

在 /usr/local/docker/nginx/wwwroot 目录下创建 html80 和 html8080 两个目录,并分辨创建两个 index.html 文件

2.配置虚拟主机

修改 /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;
        }
    }
}

3.5.基于域名的虚拟主机配置

需求

  • 两个域名指向同一台 Nginx 服务器,用户访问不同的域名显示不同的网页内容
  • 两个域名是 admin.service.itoken.funtl.com 和 admin.web.itoken.funtl.com
  • Nginx 服务器使用虚拟机 192.168.75.145

1.配置 Windows Hosts 文件

修改 window 的 hosts 文件:(C:\Windows\System32\drivers\etc)
通过 host 文件指定 admin.service.itoken.funtl.com 和 admin.web.itoken.funtl.com 对应 192.168.75.145 虚拟机:

2.创建目录及文件

在 /usr/local/docker/nginx/wwwroot 目录下创建 htmlservice 和 htmlweb 两个目录,并分辨创建两个 index.html 文件

3.配置虚拟主机

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反向代理

4.1.代理服务器概述

代理服务器,客户机在发送请求时,不会直接发送给目的主机,而是先发送给代理服务器,代理服务接受客户机请求之后,再向主机发出,并接收目的主机返回的数据,存放在代理服务器的硬盘中,再发送给客户机。

4.2.代理服务器作用

1.提高访问速度

由于目标主机返回的数据会存放在代理服务器的硬盘中,因此下一次客户再访问相同的站点数据时,会直接从代理服务器的硬盘中读取,起到了缓存的作用,尤其对于热门站点能明显提高请求速度。

2.防火墙作用

由于所有的客户机请求都必须通过代理服务器访问远程站点,因此可在代理服务器上设限,过滤某些不安全信息。

3.通过代理服务器访问不能访问的目标站点

互联网上有许多开放的代理服务器,客户机在访问受限时,可通过不受限的代理服务器访问目标站点,通俗说,我们使用的*浏览器就是利用了代理服务器,虽然不能出国,但也可直接访问外网。

4.3.正向代理

正向代理,架设在客户机与目标主机之间,只用于代理内部网络对 Internet 的连接请求,客户机必须指定代理服务器,并将本来要直接发送到 Web 服务器上的 Http 请求发送到代理服务器中。

4.4.反向代理

反向代理服务器架设在服务器端,通过缓冲经常被请求的页面来缓解服务器的工作量,将客户机请求转发给内部网络上的目标服务器;并将从服务器上得到的结果返回给 Internet 上请求连接的客户端,此时代理服务器与目标主机一起对外表现为一个服务器。

4.5.反向代理作用

大型 web 网站都用到反向代理。除了可以防止外网对内网服务器的恶性攻击、缓存以减少服务器的压力和访问安全控制之外,还可以进行负载均衡,将用户请求分配给多个服务器。

4.6.Nginx反向代理Tomcat

需求

  • 两个 tomcat 服务通过 nginx 反向代理
  • nginx 服务器:192.168.75.145:80
  • tomcat1 服务器:192.168.75.145:9090
  • tomcat2 服务器:192.168.75.145:9091

1.启动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

2.修改 /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负载均衡

5.1.负载均衡概述

负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

负载均衡,英文名称为 Load Balance,其意思就是分摊到多个操作单元上进行执行,例如 Web 服务器、FTP 服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。

5.2.Nginx 实现负载均衡

  • nginx 作为负载均衡服务器,用户请求先到达 nginx,再由 nginx 根据负载配置将请求转发至 tomcat 服务器
  • nginx 负载均衡服务器:192.168.75.145:80
  • tomcat1 服务器:192.168.75.145:9090
  • tomcat2 服务器:192.168.75.145:9091

5.3.Nginx 配置负载均衡

1.修改 /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;
		}
	}
}

2.相关配置说明

# 定义负载均衡设备的 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;
}

3.在需要使用负载的 Server 节点下添加

proxy_pass http://myServer;
  • upstream:每个设备的状态:
  • down:表示当前的 server 暂时不参与负载
  • weight:默认为 1 weight 越大,负载的权重就越大。
  • max_fails:允许请求失败的次数默认为 1 当超过最大次数时,返回 proxy_next_upstream 模块定义的错误
  • fail_timeout:max_fails 次失败后,暂停的时间。
  • backup:其它所有的非 backup 机器 down 或者忙的时候,请求 backup 机器。所以这台机器压力会最轻

六、Nginx解决跨域问题

6.1.跨域概述

1.什么是跨域问题

跨域,指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的,是浏览器对 JavaScript 施加的安全限制。

2.什么是同源

所谓同源是指,域名,协议,端口均相同

  • 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 跨域

6.2.如何解决跨域问题

1.使用 CORS(跨资源共享)解决跨域问题

CORS 是一个 W3C 标准,全称是"跨域资源共享"(Cross-origin resource sharing)。它允许浏览器向跨源服务器,发出 XMLHttpRequest 请求,从而克服了 AJAX 只能同源使用的限制。

CORS 需要浏览器和服务器同时支持。目前,所有浏览器都支持该功能,IE 浏览器不能低于 IE10。整个 CORS 通信过程,都是浏览器自动完成,不需要用户参与。对于开发者来说,CORS 通信与同源的 AJAX 通信没有差别,代码完全一样。

浏览器一旦发现 AJAX 请求跨源,就会自动添加一些附加的头信息,有时还会多出一次附加的请求,但用户不会有感觉。

因此,实现 CORS 通信的关键是服务器。只要服务器实现了 CORS 接口,就可以跨源通信(在 header 中设置:Access-Control-Allow-Origin)

2.使用 JSONP 解决跨域问题

JSONP(JSON with Padding)是 JSON 的一种“使用模式”,可用于解决主流浏览器的跨域数据访问的问题。

由于同源策略,一般来说位于 server1.example.com 的网页无法与 server2.example.com 的服务器沟通,
而 HTML 的 <script> 元素是一个例外。利用 <script> 元素的这个开放策略,网页可以得到从其他来源动态产生的 JSON 资料,而这种使用模式就是所谓的 JSONP。

用 JSONP 抓到的资料并不是 JSON,而是任意的 JavaScript,用 JavaScript 直译器执行而不是用 JSON 解析器解析(需要目标服务器配合一个 callback 函数)。

3.CORS 与 JSONP 的比较

CORS 与 JSONP 的使用目的相同,但是比 JSONP 更强大。

JSONP 只支持 GET 请求,CORS 支持所有类型的 HTTP 请求。JSONP 的优势在于支持老式浏览器,以及可以向不支持 CORS 的网站请求数据。

6.3.使用 Nginx 反向代理解决跨域问题

以上跨域问题解决方案都需要服务器支持,当服务器无法设置 header 或提供 callback 时我们就可以采用 Nginx 反向代理的方式解决跨域问题。

1.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;

2.以下为文件上传的跨域配置方案:

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;
            }
        }
    }
}