WebSocket 代理

为了将客户端和服务器之间的连接从 HTTP/1.1 转换为 WebSocket,使用了 HTTP/1.1 中可用的协议切换机制。

然而,有一个微妙之处:由于“Upgrade”是一个逐跳首部(hop-by-hop),它不会从客户端传递到代理服务器。通过正向代理,客户端可以使用 CONNECT 方法来规避此问题。然而,这不适用于反向代理,因为客户端不知道任何代理服务器,并且需要在代理服务器上进行特殊处理。

从1.3.13 版本开始,nginx 实现了一种特殊的操作模式,允许在客户端和代理服务器之间建立一个隧道,如果代理服务器返回一个代码101(切换协议)的响应,并且客户端通过请求中的“Upgrade”头请求协议切换。

如上所述,包括“Upgrade”和“Connection”在内的每一跳的报头都不会从客户端传递到代理服务器。因此,为了让代理服务器知道客户端想要切换到 WebSocket 协议的意图,这些报头必须被显式传递:

location /chat/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

还有一个更复杂的例子,一个请求到代理服务器的“Connection”报头字段的值取决于客户端请求报头中的“Upgrade”字段的存在:

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }
    server {
        # ...
        location /chat/ {
            proxy_pass http://backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
        }
    }
}

默认情况下,如果代理服务器在 60 秒内没有传输任何数据,连接将被关闭。这个超时可以通过 proxy_read_timeout 指令来增加。或者,可以将代理服务器配置为定期发送 WebSocket ping 帧以重置超时并检查连接是否仍然活跃。

说说我的看法
全部评论(
没有评论
关于
本网站专注于 Java、数据库(MySQL、Oracle)、Linux、软件架构及大数据等多领域技术知识分享。涵盖丰富的原创与精选技术文章,助力技术传播与交流。无论是技术新手渴望入门,还是资深开发者寻求进阶,这里都能为您提供深度见解与实用经验,让复杂编码变得轻松易懂,携手共赴技术提升新高度。如有侵权,请来信告知:hxstrive@outlook.com
公众号