如何使用nginx代理ws或是wss的请求
作者：daiyunchao
遇到的问题: 如何使用nginx代理ws或是wss的请求
起因是,为了降本增效要做服务器合并的需求,但两个服务器之间的进程存在对外连接的端口冲突,如果我们改了端口,客户端也会涉及到修改,但客户端的版本太旧了,想改变和重新发版流程会拉的很长,所以我们尝试别的方法来解决端口修改的问题
因为服务器的时间比较旧了,所以客户端并没有先连负载均衡再连服务器 针对这个问题我们提供了下面两个方案
- 多网卡,比如之前A服务器的启动的监听端口都在IPA的,原B服务器迁移进来后监听的端口都在IPB上,这样就实现了一台服务器上,监听了多个重复端口的问题,我们只要将IPA和IPB分别绑定到不同的域名上即可实现客户端无感的服务器迁移
- 使用nginx做端口映射
最终我们选择了成本更低的nginx端口映射的做法 具体的代码如下:
server {
listen 7865 ssl; #监听的端口(客户端连接的原端口)
server_name a.b.com; #监听的域名,非必须
ssl_certificate /etc/nginx/a.pem; #证书
ssl_certificate_key /etc/nginx/a.key; #证书
ssl_session_timeout 20m;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_verify_client off;
location / {
proxy_pass https://127.0.0.1:7899; # 新的端口,这里有一个关键点,如果我们是ssl的,这里使用https的连接,如果没有ssl,这里需要设置为http
proxy_http_version 1.1; # 必须使用 HTTP 1.1
proxy_redirect off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
这里我们可以把nginx的这层反向代理看着是透明的,因为客户端和nginx建立长连接,而nginx和后端服务器也会建立长连接,一旦我们的后端进程重启了,客户端还是会感知到.
拓展1: 负载均衡分类
我们按照起作用的ISO7层模式的层来区分的话,可以分为4层负载均衡和7层负载均衡
4层负载均衡
例如LVS或是AWS的NLB就是4层负载均衡 它的原理: 分别获取包中的源IP地址和端口和目标IP地址和端口,对后端做负载均衡(算法可能是轮询或是权重等)后修改包中的目标IP地址和端口,使其流量能得到转发
请求的路径是:
- 客户端发出情况,数据包被送到负载均衡器
- 负载均衡通过源IP地址+端口和目标IP+端口确定请求最后转发到哪一台后端服务器
- 负载均衡器通过修改目标IP和端口
- 数据包被转发到指定的后端服务器
响应的路径是:
- 后端程序进行业务处理
- 如果负载均衡器做了NAT(为了让后端进程透明,目的是隐藏后端服务器,原理就是将源IP地址和源端口修改成负载均衡器的IP地址和端口),数据包会回到负载均衡器中
- 返回给客户端
如果负载均衡器没有NAT功能,或是配置为直连的方式,则响应的数据包是不会经过负载均衡器的,这个可以通过分析流量包的源IP地址和端口来确认
4层负载均衡器的好处 4层负载均衡器不会解传输数据包,只会解header包从而获取IP地址和端口,所以相对来说速度更快 什么时候我们需要使用4层负载均衡呢
- 非HTTP的时候
- 需要较高的性能
- 场景简单
7层负载均衡
例如nginx IIS就是7层的负载均衡
主要用于处理HTTP/HTTPS等应用层协议。它不仅可以基于传输层信息（如IP地址和端口）进行负载均衡，还可以深入解析应用层数据，提供更灵活和高级的流量管理。
原理: 7层负载均衡器可以解析和检查HTTP头、URL、cookie、SSL信息等应用层数据。这使得它能根据这些内容做出智能的流量路由决策。 因为比较上层,所以可以做的事情比较多
- 基于内容转发: 可以根据特定的URL路径、域名、HTTP方法或其他应用层数据，将请求定向到不同的服务器池。例如，将所有以"/images"结尾的请求路由到图片服务器
- session保持: 通过使用cookie或其他机制，确保来自同一客户端的所有请求都被转发到同一个后端服务器，从而维护用户会话的连续性
- 请求重定向: 能够修改请求内容或路径，或将请求重定向到其他资源或服务器
- 数据压缩和缓存: 处理请求时，可以对响应内容进行压缩，减少传输的数据量。同时，还能缓存常见请求的响应，降低后端服务器负担
请求路径:
- 客户端发送请求到负载均衡器
- 负载均衡器通过分析内容进行转发
- 请求达到具体的后端进程
响应路径:
- 后端处理业务逻辑
- 响应经过负载均衡器
- 负载均衡器做一些优化处理 例如缓存/压缩等
- 响应给客户端
可以发现,响应是会经过负载均衡器的,实际上客户端和nginx建立了连接,nginx和后端进程建立了连接实现了请求的转发和请求的响应
拓展2: 还有哪些负载均衡
使用rabbitMQ多个消费者也可以实现负载均衡的作用
grpc+etcd实现的负载均衡
到此这篇关于如何使用nginx代理ws或是wss的请求的文章就介绍到这了,更多相关nginx代理ws或wss内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！