Come integrare Azure SignalR con proxy inversi

È possibile usare un server proxy inverso davanti a Servizio Azure SignalR. I server proxy inversi si trovano tra i client e il servizio Azure SignalR e altri servizi possono essere utili in vari scenari. Ad esempio, i server proxy inversi possono bilanciare il carico di richieste client diverse a servizi back-end diversi, in genere è possibile configurare regole di routing diverse per richieste client diverse e offrire agli utenti un'esperienza utente senza problemi di accesso a servizi back-end diversi. Possono anche proteggere i server back-end da vulnerabilità di exploit comuni con il controllo centralizzato della protezione. I servizi come app Azure lication Gateway, Azure Gestione API o Akamai possono fungere da server proxy inverso.

Un'architettura comune che usa un server proxy inverso con Azure SignalR è la seguente:

Procedure generali

Esistono diverse procedure generali da seguire quando si usa un proxy inverso davanti a Servizio SignalR.

Le stringa di connessione non elaborate vengono visualizzate in questo articolo solo a scopo dimostrativo. Negli ambienti di produzione proteggere sempre le chiavi di accesso. Usare Azure Key Vault per gestire e ruotare le chiavi in modo sicuro e proteggere i stringa di connessione usando Microsoft Entra ID e autorizzare l'accesso con Microsoft Entra ID.

• Assicurarsi di riscrivere l'intestazione HTTP HOST in ingresso con l'URL del servizio Azure SignalR, ad esempio https://demo.service.signalr.net. Azure SignalR è un servizio multi-tenant e si basa sull'intestazione per risolvere l'endpoint HOST corretto. Ad esempio, quando si configura gateway applicazione per Azure SignalR, selezionare Sì per l'opzione Esegui override con nuovo nome host.

• Quando il client passa attraverso il proxy inverso ad Azure SignalR, impostare ClientEndpoint come URL del proxy inverso. Quando il client negoziacon il server hub, il server hub restituirà l'URL definito in ClientEndpoint per consentire al client di connettersi. Per altri dettagli, vedere qui.

  Esistono due modi per configurare ClientEndpoint:

  • Aggiungere una ClientEndpoint sezione a ConnectionString: Endpoint=...;AccessKey=...;ClientEndpoint=<reverse-proxy-URL>

  • Configurare ClientEndpoint quando si chiama AddAzureSignalR:

    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>")
            }
        };
    })
    

• Quando un client passa attraverso il proxy inverso ad Azure SignalR, esistono due tipi di richieste:

  • Richiesta post HTTP a <reverse-proxy-URL>/client/negotiate/, chiamata come richiesta negoziata
  • Richiesta di connessione WebSocket/SSE/LongPolling a seconda del tipo di trasporto a <reverse-proxy-URL>/client/, chiamato come richiesta di connessione.

  Assicurarsi che il proxy inverso supporti entrambi i tipi di trasporto per /client/ subpath. Ad esempio, quando il tipo di trasporto è WebSocket, assicurarsi che il proxy inverso supporti sia HTTP che WebSocket per /client/ subpath.

  Se sono stati configurati più servizi SignalR dietro il proxy inverso, assicurarsi che negotiate la richiesta e connect la richiesta con lo stesso asrs_request_id parametro di query (vale a dire che siano per la stessa connessione) vengano indirizzati alla stessa istanza del servizio SignalR.

• Quando si usa il proxy inverso, è possibile proteggere ulteriormente il servizio SignalR disabilitando l'accesso alla rete pubblica e usando endpoint privati per consentire solo l'accesso privato dal proxy inverso al servizio SignalR tramite la rete virtuale.

Passaggi successivi

• Informazioni su come usare gateway applicazione.

• Informazioni su come usare Gestione API.

• Altre informazioni sugli elementi interni di Azure SignalR.