首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >Nginx:反向代理WebSocket草案76

Nginx:反向代理WebSocket草案76
EN

Stack Overflow用户
提问于 2013-05-03 22:44:19
回答 1查看 882关注 0票数 1

我使用的是nginx 1.4.0,它可以很好地处理较新的WebSocket版本,但76草案是一个问题。我的后端(基于Netty的Java应用程序)似乎没有接收到握手请求,并且在nginx的错误日志中

代码语言:javascript
运行
复制
[error] 7662#0: *3720 upstream timed out (110: Connection timed out) while reading response header from upstream

我的配置($proxy_add_connection的工作方式与所描述的there相同)

代码语言:javascript
运行
复制
include proxy_params;
proxy_pass http://127.0.0.1:8001/;
proxy_http_version 1.1;
proxy_set_header Connection $proxy_add_connection;
proxy_set_header Upgrade $http_upgrade;

如果我直接连接到后端,它工作得很好。

我能做些什么来修复它吗?

EN

Stack Overflow用户

回答已采纳

发布于 2013-05-11 04:31:59

为了支持WebSocket代理,最近对Nginx的更改并不支持WebSockets本身,但允许它识别将连接从HTTP升级到另一种协议的请求。当它收到这样的请求时,它现在会建立到后端的隧道,而不是因为连接无效而丢弃连接。HTTP握手是一个标准的WebSocket协议升级请求,因此它可以使用这个新功能。

草案76/00 WebSocket握手是专门为打破不明确支持WebSockets的中介而设计的。由于Nginx所做的只是代理升级的TCP连接,它实际上并不理解WebSocket握手或正在使用的WebSocket的协议版本。因此,它无法执行草案76/00握手所需的非HTTP调整。

为了支持WebSocket 76/00版本的草案,Nginx必须实现特殊的草案76/00检测和处理逻辑。考虑到添加非HTTP逻辑的复杂性,以及76/00草案未完成的质量和可疑的安全性,代理中介不太可能支持它。

如果你的用户完全依赖2-3年前的Chrome/Safari版本,那么Flash fallback或原始TCP负载均衡可能是你最好的选择。

票数 3
EN
查看全部 1 条回答
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/16361639

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档