다음을 통해 공유

如何将 Azure SignalR 与反向代理集成

  • 아티클

反向代理服务器可以在 Azure SignalR 服务前使用。 位于客户端与 Azure SignalR 服务和其他服务之间的反向代理服务器可在各种场景下提供帮助。 例如，反向代理服务器可以将不同的客户端请求负载均衡到不同的后端服务，通常，你可以为不同的客户端请求配置不同的路由规则，并为访问不同后端服务的用户提供无缝的用户体验。 它们还可以通过集中式保护控制来保护后端服务器免受常见漏洞的影响。 Azure 应用程序网关、Azure API 管理 或 Akamai 等服务可以充当反向代理服务器。

将反向代理服务器与 Azure SignalR 配合使用的常见体系结构如下所示：

Diagram that shows the architecture using Azure SignalR with a reverse proxy server.

一般做法

在 SignalR 服务前面使用反向代理时，需要遵循一些一般做法。

  • 请确保使用 Azure SignalR 服务 URL（例如 https://demo.signalr.azure.cn）重写传入的 HTTP HOST 标头。 Azure SignalR 是一项多租户服务，它依赖于 HOST 标头解析到正确的终结点。 例如，为 Azure SignalR 配置应用程序网关时，对于“使用新主机名替代”选项，请选择“是”。

  • 如果客户端通过反向代理访问 Azure SignalR，请将 ClientEndpoint 设置为反向代理 URL。 当客户端与中心服务器协商时，中心服务器将返回在 ClientEndpoint 中定义的 URL 以便客户端进行连接。 查看此处了解更多详细信息。

    有两种方法可以配置 ClientEndpoint：

    • 将 ClientEndpoint 部分添加到 ConnectionString：Endpoint=...;AccessKey=...;ClientEndpoint=<reverse-proxy-URL>

    • 调用 AddAzureSignalR 时配置 ClientEndpoint：

      services.AddSignalR().AddAzureSignalR(o =>
{
    o.Endpoints = new Microsoft.Azure.SignalR.ServiceEndpoint[1]
    {
        new Microsoft.Azure.SignalR.ServiceEndpoint("<azure-signalr-connection-string>")
        {
            ClientEndpoint = new Uri("<reverse-proxy-URL>")
        }
    };
})

  • 如果客户端通过反向代理访问 Azure SignalR，则有两种类型的请求：

    • 对 <reverse-proxy-URL>/client/negotiate/ 的 HTTP post 请求，我们称之为“协商请求”
    • 对 <reverse-proxy-URL>/client/ 的 WebSocket/SSE/LongPolling 连接请求（具体取决于你的传输类型），我们称之为“连接请求”。

    请确保反向代理对 /client/ 子路径支持这两种传输类型。 例如，当传输类型为 WebSocket 时，请确保反向代理对 /client/ 子路径支持 HTTP 和 WebSocket。

    如果在反向代理后面配置了多个 SignalR 服务，请确保将具有相同 asrs_request_id 查询参数的 negotiate 请求和 connect 请求（意味着它们针对的是同一连接）路由到同一 SignalR 服务实例。

  • 使用反向代理时，可以进一步保护 SignalR 服务，具体方式是禁用公用网络访问并使用专用终结点，以便仅允许通过 VNet 从反向代理到 SignalR 服务的专用访问。

后续步骤