Hospedaje e implementación de Blazor Server

Artículo
11/09/2021
10 minutos para leer

Valores de configuración de host

Las aplicaciones Blazor Server pueden aceptar valores de configuración de host genérico.

Implementación

Con el modelo de hospedaje de Blazor Server, Blazor se ejecuta en el servidor desde una aplicación ASP.NET Core. Las actualizaciones de la interfaz de usuario, el control de eventos y las llamadas de JavaScript se controlan mediante una conexión SignalR.

Se requiere un servidor web que pueda hospedar una aplicación ASP.NET Core. Visual Studio incluye la plantilla de proyecto Aplicación Blazor Server (plantilla blazorserver cuando se usa el comando dotnet new). Para obtener más información sobre las plantillas de proyectos de Blazor, consulte Estructura del proyecto de Blazor de ASP.NET Core.

Escalabilidad

Planee una implementación para hacer el mejor uso de la infraestructura disponible para una aplicación Blazor Server. Consulte los siguientes recursos para abordar la escalabilidad de las aplicaciones Blazor Server:

Servidor de implementación

A la hora de considerar la escalabilidad de un solo servidor (escalado vertical), la memoria disponible para una aplicación es probablemente el primer recurso que la aplicación agotará a medida que la demanda de los usuarios aumente. La memoria disponible en el servidor afecta a lo siguiente:

Número de circuitos activos que un servidor puede admitir.
Latencia de la interfaz de usuario en el cliente.

Para obtener instrucciones sobre la creación de aplicaciones Blazor Server seguras y escalables, consulte Guía de mitigación de amenazas para ASP.NET Core Blazor Server.

Cada circuito utiliza aproximadamente 250 KB de memoria para una aplicación mínima de estilo Hola mundo. El tamaño de un circuito depende del código de la aplicación y de los requisitos de mantenimiento del estado asociados a cada componente. Se recomienda que mida la demanda de recursos durante el desarrollo de la aplicación y la infraestructura, pero la línea de base siguiente puede ser un punto de partida para planear el destino de implementación: Si espera que la aplicación admita 5000 usuarios simultáneos, considere la posibilidad de presupuestar al menos 1,3 GB de memoria del servidor en la aplicación (o ~273 KB por usuario).

Configuración de SignalR

Las aplicaciones Blazor Server usan ASP.NET Core SignalR para comunicarse con el explorador. Las condiciones de hospedaje y escalabilidad de SignalR se aplican a las aplicaciones Blazor Server.

Blazor funciona mejor cuando se usa WebSockets como transporte de SignalR debido a su menor latencia, su mayor confiabilidad y su seguridad mejorada. SignalR usa el sondeo largo cuando WebSockets no está disponible o cuando la aplicación está configurada explícitamente para usarlo. Al implementar en Azure App Service, configure la aplicación para usar WebSockets en la configuración de Azure Portal del servicio. Para más información sobre la configuración de la aplicación para Azure App Service, consulte las SignalRdirectrices de publicación de.

Blazor Server emite una advertencia de consola si detecta que se usa el sondeo largo:

No se pudo conectar a través de WebSockets mediante el transporte de reserva de sondeo largo. Esto puede deberse a que una VPN o un proxy bloquean la conexión. Para solucionar este problema, visite https://aka.ms/blazor-server-using-fallback-long-polling.

Azure SignalR Service

Se recomienda usar Azure SignalR Service para las aplicaciones Blazor Server. El servicio funciona junto con el centro Blazor de la aplicación para escalar verticalmente una aplicación Blazor Server a un gran número de conexiones de SignalR simultáneas. Además, los centros de datos de alto rendimiento y alcance global de SignalR Service son de gran ayuda a la hora de reducir la latencia ocasionada por la geografía.

Importante

Cuando los WebSockets están deshabilitados, Azure App Service simula una conexión en tiempo real mediante el sondeo prolongado de HTTP. El sondeo prolongado de HTTP es notablemente más lento que la ejecución con los WebSockets habilitados, que no usa el sondeo para simular una conexión cliente-servidor.

Se recomienda usar WebSockets para las aplicaciones Blazor Server implementadas en Azure App Service. Azure SignalR Service usa WebSockets de forma predeterminada. Si la aplicación no usa Azure SignalR Service, consulte Publicar una aplicación ASP.NET Core SignalR para Azure App Service.

Para más información, consulte:

Configuración

A fin de configurar una aplicación para Azure SignalR Service, la aplicación debe admitir sesiones permanentes, en las que se devuelve a los clientes al mismo servidor durante la representación previa. La opción ServerStickyMode o el valor de configuración se establecen en Required. Normalmente, una aplicación crea la configuración mediante UNO de los enfoques siguientes:

Program.cs:

builder.Services.AddSignalR().AddAzureSignalR(options =>
{
    options.ServerStickyMode = 
    Microsoft.Azure.SignalR.ServerStickyMode.Required;
});

Configuración (use UNO de los enfoques siguientes):
- En appsettings.json:
```
"Azure:SignalR:StickyServerMode": "Required"
```
- El valor Configuración > Configuración de la aplicación de la instancia de App Service en Azure Portal (Nombre: Azure__SignalR__StickyServerMode, Valor: Required). Este enfoque se adopta automáticamente para la aplicación si se aprovisiona Azure SignalR Service.

Aprovisionamiento de Azure SignalR Service

A fin de aprovisionar Azure SignalR Service para una aplicación en Visual Studio, haga lo siguiente:

Cree un perfil de publicación de aplicaciones de Azure en Visual Studio para la aplicación Blazor Server.
Agregue la dependencia de Azure SignalR Service al perfil. Si la suscripción de Azure no tiene una instancia de Azure SignalR Service para asignarla a la aplicación, seleccione Crear una instancia de Azure SignalR Service para aprovisionar una nueva instancia de servicio.
Publicación de la aplicación en Azure.

El aprovisionamiento de Azure SignalR Service en Visual Studio habilita sesiones permanentes de forma automática y agrega la cadena de conexión SignalR a la configuración de App Service.

Azure App Service

Esta sección solo se aplica a las aplicaciones que no usan Azure SignalR Service.

Cuando no se usa Azure SignalR Service, App Service requiere configurar la afinidad de enrutamiento de solicitudes de aplicaciones (ARR) y WebSockets. Los clientes conectan sus WebSockets directamente a la aplicación, no a Azure SignalR Service.

Use las instrucciones siguientes para configurar la aplicación:

IIS

Al usar IIS, habilite:

Kubernetes

Cree una definición de entrada con las siguientes anotaciones de Kubernetes para sesiones permanentes:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: <ingress-name>
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "affinity"
    nginx.ingress.kubernetes.io/session-cookie-expires: "14400"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "14400"

Linux con Nginx

Para que los WebSockets de SignalR funcionen correctamente, confirme que los encabezados Upgrade y Connection del proxy estén establecidos en los valores siguientes y que $connection_upgrade esté asignado a uno de los siguientes elementos:

Valor del encabezado Upgrade de forma predeterminada.
close cuando falte o esté vacío el encabezado Upgrade.

http {
    map $http_upgrade $connection_upgrade {
        default Upgrade;
        ''      close;
    }

    server {
        listen      80;
        server_name example.com *.example.com
        location / {
            proxy_pass         http://localhost:5000;
            proxy_http_version 1.1;
            proxy_set_header   Upgrade $http_upgrade;
            proxy_set_header   Connection $connection_upgrade;
            proxy_set_header   Host $host;
            proxy_cache_bypass $http_upgrade;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Proto $scheme;
        }
    }
}

Para obtener más información, vea los artículos siguientes:

Linux con Apache

Para hospedar una aplicación de Blazor en Apache en Linux, configure ProxyPass para el tráfico HTTP y WebSockets.

En el ejemplo siguiente:

El servidor de Kestrel se está ejecutando en el equipo host.
La aplicación escucha el tráfico en el puerto 5000.

ProxyRequests       On
ProxyPreserveHost   On
ProxyPassMatch      ^/_blazor/(.*) http://localhost:5000/_blazor/$1
ProxyPass           /_blazor ws://localhost:5000/_blazor
ProxyPass           / http://localhost:5000/
ProxyPassReverse    / http://localhost:5000/

Habilite los siguientes módulos:

a2enmod   proxy
a2enmod   proxy_wstunnel

Busque errores de WebSockets en la consola del explorador. Errores de ejemplo:

Firefox no puede establecer una conexión con el servidor en ws://nombre-del-dominio.tld/_blazor?id=XXX.
Error: No se pudo iniciar el transporte 'WebSockets': Error: Error en el transporte.
Error: No se pudo iniciar el transporte 'LongPolling': Tipo de error: this.transport no definido
Error: No se puede conectar con el servidor con ninguno de los transportes disponibles. Error de WebSockets
Error: No se pueden enviar datos si la conexión no está en estado 'Conectado'.

Para más información, vea la documentación de Apache.

Medición de la latencia de red

La interoperabilidad de JS se puede usar para medir la latencia de red, como se muestra en el ejemplo siguiente:

@inject IJSRuntime JS

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

Para una experiencia de interfaz de usuario razonable, se recomienda una latencia de interfaz de usuario sostenida de 250 ms o menos.

Valores de configuración de host

Las aplicaciones Blazor Server pueden aceptar valores de configuración de host genérico.

Implementación

Escalabilidad

Servidor de implementación

Número de circuitos activos que un servidor puede admitir.
Latencia de la interfaz de usuario en el cliente.

Para obtener instrucciones sobre la creación de aplicaciones Blazor Server seguras y escalables, consulte Guía de mitigación de amenazas para ASP.NET Core Blazor Server.

Configuración de SignalR

Las aplicaciones Blazor Server usan ASP.NET Core SignalR para comunicarse con el explorador. Las condiciones de hospedaje y escalabilidad de SignalR se aplican a las aplicaciones Blazor Server.

Blazor funciona mejor cuando se usa WebSockets como transporte de SignalR debido a su menor latencia, confiabilidad y seguridad. SignalR usa el sondeo largo cuando WebSockets no está disponible o cuando la aplicación está configurada explícitamente para usarlo. Al implementar en Azure App Service, configure la aplicación para usar WebSockets en la configuración de Azure Portal del servicio. Para más información sobre la configuración de la aplicación para Azure App Service, consulte las SignalRdirectrices de publicación de.

Azure SignalR Service

Importante

Para más información, consulte:

Configuración

Startup.ConfigureServices:

services.AddSignalR().AddAzureSignalR(options =>
{
    options.ServerStickyMode = 
    Microsoft.Azure.SignalR.ServerStickyMode.Required;
});

Configuración (use UNO de los enfoques siguientes):
- En appsettings.json:
```
"Azure:SignalR:StickyServerMode": "Required"
```
- El valor Configuración > Configuración de la aplicación de la instancia de App Service en Azure Portal (Nombre: Azure__SignalR__StickyServerMode, Valor: Required). Este enfoque se adopta automáticamente para la aplicación si se aprovisiona Azure SignalR Service.

Aprovisionamiento de Azure SignalR Service

A fin de aprovisionar Azure SignalR Service para una aplicación en Visual Studio, haga lo siguiente:

Cree un perfil de publicación de aplicaciones de Azure en Visual Studio para la aplicación Blazor Server.
Agregue la dependencia de Azure SignalR Service al perfil. Si la suscripción de Azure no tiene una instancia de Azure SignalR Service para asignarla a la aplicación, seleccione Crear una instancia de Azure SignalR Service para aprovisionar una nueva instancia de servicio.
Publicación de la aplicación en Azure.

El aprovisionamiento de Azure SignalR Service en Visual Studio habilita sesiones permanentes de forma automática y agrega la cadena de conexión SignalR a la configuración de App Service.

Azure App Service

Esta sección solo se aplica a las aplicaciones que no usan Azure SignalR Service.

Use las instrucciones siguientes para configurar la aplicación:

IIS

Al usar IIS, habilite:

Kubernetes

Cree una definición de entrada con las siguientes anotaciones de Kubernetes para sesiones permanentes:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: <ingress-name>
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "affinity"
    nginx.ingress.kubernetes.io/session-cookie-expires: "14400"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "14400"

Linux con Nginx

Valor del encabezado Upgrade de forma predeterminada.
close cuando falte o esté vacío el encabezado Upgrade.

http {
    map $http_upgrade $connection_upgrade {
        default Upgrade;
        ''      close;
    }

    server {
        listen      80;
        server_name example.com *.example.com;
        location / {
            proxy_pass         http://localhost:5000;
            proxy_http_version 1.1;
            proxy_set_header   Upgrade $http_upgrade;
            proxy_set_header   Connection $connection_upgrade;
            proxy_set_header   Host $host;
            proxy_cache_bypass $http_upgrade;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Proto $scheme;
        }
    }
}

Para obtener más información, vea los artículos siguientes:

Linux con Apache

Para hospedar una aplicación de Blazor en Apache en Linux, configure ProxyPass para el tráfico HTTP y WebSockets.

En el ejemplo siguiente:

El servidor de Kestrel se está ejecutando en el equipo host.
La aplicación escucha el tráfico en el puerto 5000.

ProxyRequests       On
ProxyPreserveHost   On
ProxyPassMatch      ^/_blazor/(.*) http://localhost:5000/_blazor/$1
ProxyPass           /_blazor ws://localhost:5000/_blazor
ProxyPass           / http://localhost:5000/
ProxyPassReverse    / http://localhost:5000/

Habilite los siguientes módulos:

a2enmod   proxy
a2enmod   proxy_wstunnel

Busque errores de WebSockets en la consola del explorador. Errores de ejemplo:

Firefox no puede establecer una conexión con el servidor en ws://nombre-del-dominio.tld/_blazor?id=XXX.
Error: No se pudo iniciar el transporte 'WebSockets': Error: Error en el transporte.
Error: No se pudo iniciar el transporte 'LongPolling': Tipo de error: this.transport no definido
Error: No se puede conectar con el servidor con ninguno de los transportes disponibles. Error de WebSockets
Error: No se pueden enviar datos si la conexión no está en estado 'Conectado'.

Para más información, vea la documentación de Apache.

Medición de la latencia de red

La interoperabilidad de JS se puede usar para medir la latencia de red, como se muestra en el ejemplo siguiente:

@inject IJSRuntime JS

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

Para una experiencia de interfaz de usuario razonable, se recomienda una latencia de interfaz de usuario sostenida de 250 ms o menos.

Valores de configuración de host

Las aplicaciones Blazor Server pueden aceptar valores de configuración de host genérico.

Implementación

Escalabilidad

Servidor de implementación

Número de circuitos activos que un servidor puede admitir.
Latencia de la interfaz de usuario en el cliente.

Para obtener instrucciones sobre la creación de aplicaciones Blazor Server seguras y escalables, consulte Guía de mitigación de amenazas para ASP.NET Core Blazor Server.

Configuración de SignalR

Las aplicaciones Blazor Server usan ASP.NET Core SignalR para comunicarse con el explorador. Las condiciones de hospedaje y escalabilidad de SignalR se aplican a las aplicaciones Blazor Server.

Azure SignalR Service

Importante

Para más información, consulte:

Configuración

Startup.ConfigureServices:

services.AddSignalR().AddAzureSignalR(options =>
{
    options.ServerStickyMode = 
    Microsoft.Azure.SignalR.ServerStickyMode.Required;
});

Configuración (use UNO de los enfoques siguientes):
- En appsettings.json:
```
"Azure:SignalR:StickyServerMode": "Required"
```
- El valor Configuración > Configuración de la aplicación de la instancia de App Service en Azure Portal (Nombre: Azure__SignalR__StickyServerMode, Valor: Required). Este enfoque se adopta automáticamente para la aplicación si se aprovisiona Azure SignalR Service.

Aprovisionamiento de Azure SignalR Service

A fin de aprovisionar Azure SignalR Service para una aplicación en Visual Studio, haga lo siguiente:

Cree un perfil de publicación de aplicaciones de Azure en Visual Studio para la aplicación Blazor Server.
Agregue la dependencia de Azure SignalR Service al perfil. Si la suscripción de Azure no tiene una instancia de Azure SignalR Service para asignarla a la aplicación, seleccione Crear una instancia de Azure SignalR Service para aprovisionar una nueva instancia de servicio.
Publicación de la aplicación en Azure.

El aprovisionamiento de Azure SignalR Service en Visual Studio habilita sesiones permanentes de forma automática y agrega la cadena de conexión SignalR a la configuración de App Service.

Azure App Service

Esta sección solo se aplica a las aplicaciones que no usan Azure SignalR Service.

Use las instrucciones siguientes para configurar la aplicación:

IIS

Al usar IIS, habilite:

Kubernetes

Cree una definición de entrada con las siguientes anotaciones de Kubernetes para sesiones permanentes:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: <ingress-name>
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "affinity"
    nginx.ingress.kubernetes.io/session-cookie-expires: "14400"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "14400"

Linux con Nginx

Valor del encabezado Upgrade de forma predeterminada.
close cuando falte o esté vacío el encabezado Upgrade.

http {
    map $http_upgrade $connection_upgrade {
        default Upgrade;
        ''      close;
    }

    server {
        listen      80;
        server_name example.com *.example.com
        location / {
            proxy_pass         http://localhost:5000;
            proxy_http_version 1.1;
            proxy_set_header   Upgrade $http_upgrade;
            proxy_set_header   Connection $connection_upgrade;
            proxy_set_header   Host $host;
            proxy_cache_bypass $http_upgrade;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Proto $scheme;
        }
    }
}

Para obtener más información, vea los artículos siguientes:

Linux con Apache

Para hospedar una aplicación de Blazor en Apache en Linux, configure ProxyPass para el tráfico HTTP y WebSockets.

En el ejemplo siguiente:

El servidor de Kestrel se está ejecutando en el equipo host.
La aplicación escucha el tráfico en el puerto 5000.

ProxyRequests       On
ProxyPreserveHost   On
ProxyPassMatch      ^/_blazor/(.*) http://localhost:5000/_blazor/$1
ProxyPass           /_blazor ws://localhost:5000/_blazor
ProxyPass           / http://localhost:5000/
ProxyPassReverse    / http://localhost:5000/

Habilite los siguientes módulos:

a2enmod   proxy
a2enmod   proxy_wstunnel

Busque errores de WebSockets en la consola del explorador. Errores de ejemplo:

Firefox no puede establecer una conexión con el servidor en ws://nombre-del-dominio.tld/_blazor?id=XXX.
Error: No se pudo iniciar el transporte 'WebSockets': Error: Error en el transporte.
Error: No se pudo iniciar el transporte 'LongPolling': Tipo de error: this.transport no definido
Error: No se puede conectar con el servidor con ninguno de los transportes disponibles. Error de WebSockets
Error: No se pueden enviar datos si la conexión no está en estado 'Conectado'.

Para más información, vea la documentación de Apache.

Medición de la latencia de red

La interoperabilidad de JS se puede usar para medir la latencia de red, como se muestra en el ejemplo siguiente:

@inject IJSRuntime JS

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

Para una experiencia de interfaz de usuario razonable, se recomienda una latencia de interfaz de usuario sostenida de 250 ms o menos.

Hospedaje e implementación de Blazor Server

Valore su experiencia

Valores de configuración de host

Implementación

Escalabilidad

Servidor de implementación

Configuración de SignalR

Azure SignalR Service

Configuración

Aprovisionamiento de Azure SignalR Service

Azure App Service

IIS

Kubernetes

Linux con Nginx

Linux con Apache

Medición de la latencia de red

Valores de configuración de host

Implementación

Escalabilidad

Servidor de implementación

Configuración de SignalR

Azure SignalR Service

Configuración

Aprovisionamiento de Azure SignalR Service

Azure App Service

IIS

Kubernetes

Linux con Nginx

Linux con Apache

Medición de la latencia de red

Valores de configuración de host

Implementación

Escalabilidad

Servidor de implementación

Configuración de SignalR

Azure SignalR Service

Configuración

Aprovisionamiento de Azure SignalR Service

Azure App Service

IIS

Kubernetes

Linux con Nginx

Linux con Apache

Medición de la latencia de red