使用nginx作为websocket的proxy server
blog.csdn.net/zhx6044/article/details/50278765
WebSocket
WebSocket协议为创建客户端和服务器端需要实时双向通讯的webapp提供了一个选择。其为HTML5的一部分,WebSocket相较于原来开发这类app的方法来说,其能使开发更加地简单。大部分现在的浏览器都支持WebSocket,比如Firefox,IE,Chrome,Safari,Opera,并且越来越多的服务器框架现在也同样支持WebSocket。
在实际的生产环境中,要求多个WebSocket服务器必须具有高性能和高可用,那么WebSocket协议就需要一个负载均衡层,NGINX从1.3开始支持WebSocket,其可以作为一个反向代理和为WebSocket程序做负载均衡。
WebSocket协议不同于HTTP协议,但是WebSocket握手是通过HTTP来完成的,使用HTTP的Upgrade设施来升级连接从HTTP到WebSocket。这个允许WebSocket程序能够更简单地融入现有的基础设施。比如,WebSocket程序可以使用80和443标准的HTTP端口,从而允许使用存在的防火墙策略。
一个WebSocket程序持有一个长时间运行的在客户端和服务器端之间打开的连接,促进实时应用程序的开发(这个翻译有问题)。被用来升级连接从HTTP到WebSocket的HTTP Upgrade机制使用Upgrade和Connection头部来完成。在反向代理服务器支持WebSocket中,需要面临一些挑战。第一个是WebSocket是一个hop-by-hop协议,所以当代理服务器拦截来至于客服端的一个Upgrade请求时,代理服务器需要发送它自己的Upgrade请求给后端服务器,包括一些合适的头部。同样,因为WebSocket是长时间存活,相反的,HTTP连接是典型的短连接,反向代理服务器必须允许这些连接保持打开,而不是在它们看起来闲置时关闭它们。
nginx
NGINX通过允许一个在客户端和后端服务器之间建立的隧道来支持WebSocket。为了NGINX发送来至于客户端Upgrade请求到后端服务器,Upgrade和Connection头部必须被设置明确。
示例,这个例子在我前面文章中使用过–chatRobot。上次是客户端直接连的express程序,这里我们使用nginx来做代理。
upstream wsbackend { server 127.0.0.1:3000; } server { listen 8090; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; # location / { # root html; # index index.html index.htm; # } location / { proxy_pass http://wsbackend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }
我们将qt程序中的链接改一下
const char* server_url = "ws://localhost:8090";
我们的chatRobot还是一样的可以运行。
其实这只是一个简单地接合nginx和nodejs的例子。
这里我总结了几点我们为什么把nginx放在前面的。
- nodejs适合做为restful api接口和动态的页面生成,虽然也有静态资源托管模块,但是会大幅度影响nodejs的性能,但是nginx适合处理静态资源。所以让它们做自己擅长的事。
- 安全,直接在外网暴露nodejs会有很大的风险。
- 卸HTTPS,nginx与客户端连接加密,后端的nodejs和nginx处于内网环境下,可以不加密,这样省去了nodejs卸https的负载。
- nginx作为反向代理和负载均衡,方便后台nodejs的横向扩展。
使用nginx是为了更好地使用nodejs来提供服务。
赞赏码
![](https://files.cnblogs.com/files/lxwphp/zhifubao2.bmp)
![](https://files.cnblogs.com/files/lxwphp/weixin.bmp)
非学,无以致疑;非问,无以广识