通过

ASP.NET Core SignalR 的安全注意事项

  • 项目

作者：Andrew Stanton-Nurse

本文提供有关如何保护 SignalR 的信息。

跨源资源共享

跨源资源共享 (CORS) 可以用于允许浏览器中的跨源 SignalR 连接。 如果 JavaScript 代码托管在与 SignalR 应用不同的另一个域中，则必须启用 CORS 中间件以允许 JavaScript 连接到 SignalR 应用。 仅允许来自你信任或控制的域的跨源请求。 例如：

  • 网站托管在 http://www.example.com 上
  • SignalR 应用托管在 http://signalr.example.com 上

应在 SignalR 应用中配置 CORS 以仅允许源 www.example.com。

有关配置 CORS 的详细信息，请参阅启用跨源请求 (CORS)。 SignalR需要以下 CORS 策略：

  • 允许特定的预期来源。 允许任何来源是可行的，但不安全或不推荐使用。
  • 必须允许使用 HTTP 方法 GET 和 POST。
  • 为了使基于 cookie 的粘滞会话正常工作，必须允许使用凭据。 即使未使用身份验证，也必须启用它们。

但是，在 5.0 中，我们在 TypeScript 客户端中提供了一个不使用凭据的选项。 只有在 100% 确定应用中不需要 Cookie 之类的凭据时（为粘滞会话使用多个服务器时，Azure 应用服务会使用 Cookie），才应使用不使用凭据的选项。

例如，以下突出显示的 CORS 策略允许 https://example.com 中托管的 SignalR 浏览器客户端访问托管在 https://signalr.example.com 上的 SignalR 应用：

using SignalRChat.Hubs;

var MyAllowSpecificOrigins = "_myAllowSpecificOrigins";

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy(name: MyAllowSpecificOrigins,
                      policy =>
                      {
                          policy.WithOrigins("http://example.com");
                          policy.WithMethods("GET", "POST");
                          policy.AllowCredentials();
                      });
});

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddSignalR();

var app = builder.Build();

app.MapHub<ChatHub>("/chatHub");

在前面的示例中，已将 CORS 策略自定义为允许特定源、方法和凭据。 有关在 ASP.NET Core 中自定义 CORS 策略和中间件的详细信息，请参阅 CORS 中间件：具有命名策略和中间件的 CORS。

WebSocket 源限制

CORS 提供的保护不适用于 WebSocket。 有关 WebSocket 上的源限制，请阅读 WebSocket 源限制。

ConnectionId

如果 SignalR 服务器或客户端版本为 ASP.NET Core 2.2 或更早版本，则公开 ConnectionId 可能会导致恶意的模拟行为。 如果 SignalR 服务器和客户端版本为 ASP.NET Core 3.0 或更高版本，则更应该对 ConnectionToken（而不是 ConnectionId）进行保密。 任何 API 中均未故意公开 ConnectionToken。 确保较旧的 SignalR 客户端未连接到服务器可能较为困难，因此即使 SignalR 服务器版本为 ASP.NET Core 3.0 或更高版本，也不应公开 ConnectionId。

访问令牌日志记录

使用 WebSocket 或服务器发送的事件时，浏览器客户端会在查询字符串中发送访问令牌。 通常，通过查询字符串接收访问令牌与使用标准 Authorization 标头一样安全。 请始终使用 HTTPS 以确保在客户端和服务器之间实现安全的端到端连接。 许多 Web 服务器会记录每个请求的 URL（包括查询字符串）。 记录 URL 时可能也会记录访问令牌。 默认情况下，ASP.NET Core 会记录每个请求的 URL（包括查询字符串）。 例如：

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

如果担心将此数据记录在服务器日志中，可以通过将 Microsoft.AspNetCore.Hosting 日志记录器配置为 Warning 级别或更高级别（这些消息将在 Info 级别写入）。 有关详细信息，请参阅在代码中应用日志筛选规则。 如果仍想记录某些请求信息，可以编写中间件来记录所需的数据，并筛选出 access_token 查询字符串值（如果存在）。

异常

异常消息通常被认为是不应透露给客户端的敏感数据。 默认情况下，SignalR 不会将由中心方法引发的异常的详细信息发送给客户端。 客户端将收到指示出现错误的一般消息。 可以使用 EnableDetailedErrors 替代（例如在开发或测试中）向客户端发送的异常消息。 异常消息不应在生产应用中向客户端公开。

缓冲区管理

SignalR 使用每个连接缓冲区管理传入消息和传出消息。 默认情况下，SignalR 将这些缓冲区的大小限制为 32 KB。 客户端或服务器可以发送的最大消息大小为 32 KB。 消息连接使用的最大内存为 32 KB。 如果消息始终小于 32 KB，则可以降低限制，从而：

  • 阻止客户端发送更大的消息。
  • 服务器绝不需要分配大型缓冲区来接受消息。

如果消息大小超过 32 KB，则可以提高限制。 提高此限制意味着：

  • 客户端可能会导致服务器分配大型内存缓冲区。
  • 大型缓冲区的服务器分配可能会减少并发连接的数量。

传入消息和传出消息均有限制，两者均可在 MapHub 中配置的 HttpConnectionDispatcherOptions 对象上配置：

  • ApplicationMaxBufferSize 表示服务器从客户端缓存的最大字节数。 如果客户端尝试发送比此限制更大的消息，则可能会关闭该连接。
  • TransportMaxBufferSize 表示服务器可以发送的最大字节数。 如果服务器尝试发送比此限制更大的消息（包括从中心方法返回的值），则将引发异常。

将限制设置为 0 可以禁用限制。 通过删除该限制，客户端可以发送任意大小的消息。 发送较大消息的恶意客户端可能会导致分配过多的内存。 过多的内存使用量会显著减少并发连接数。

本文提供有关如何保护 SignalR 的信息。

跨源资源共享

跨源资源共享 (CORS) 可以用于允许浏览器中的跨源 SignalR 连接。 如果 JavaScript 代码托管在与 SignalR 应用不同的另一个域中，则必须启用 CORS 中间件以允许 JavaScript 连接到 SignalR 应用。 仅允许来自你信任或控制的域的跨源请求。 例如：

  • 网站托管在 http://www.example.com 上
  • SignalR 应用托管在 http://signalr.example.com 上

应在 SignalR 应用中配置 CORS 以仅允许源 www.example.com。

有关配置 CORS 的详细信息，请参阅启用跨源请求 (CORS)。 SignalR需要以下 CORS 策略：

  • 允许特定的预期来源。 允许任何来源是可行的，但不安全或不推荐使用。
  • 必须允许使用 HTTP 方法 GET 和 POST。
  • 为了使基于 cookie 的粘滞会话正常工作，必须允许使用凭据。 即使未使用身份验证，也必须启用它们。

但是，在 5.0 中，我们在 TypeScript 客户端中提供了一个不使用凭据的选项。 只有在 100% 确定应用中不需要 Cookie 之类的凭据时（为粘滞会话使用多个服务器时，Azure 应用服务会使用 Cookie），才应使用不使用凭据的选项。

例如，以下突出显示的 CORS 策略允许 https://example.com 中托管的 SignalR 浏览器客户端访问托管在 https://signalr.example.com 上的 SignalR 应用：

using SignalRChat.Hubs;

var MyAllowSpecificOrigins = "_myAllowSpecificOrigins";

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy(name: MyAllowSpecificOrigins,
                      policy =>
                      {
                          policy.WithOrigins("http://example.com");
                          policy.WithMethods("GET", "POST");
                          policy.AllowCredentials();
                      });
});

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddSignalR();

var app = builder.Build();

app.MapHub<ChatHub>("/chatHub");

在前面的示例中，已将 CORS 策略自定义为允许特定源、方法和凭据。 有关在 ASP.NET Core 中自定义 CORS 策略和中间件的详细信息，请参阅 CORS 中间件：具有命名策略和中间件的 CORS。

WebSocket 源限制

CORS 提供的保护不适用于 WebSocket。 有关 WebSocket 上的源限制，请阅读 WebSocket 源限制。

ConnectionId

如果 SignalR 服务器或客户端版本为 ASP.NET Core 2.2 或更早版本，则公开 ConnectionId 可能会导致恶意的模拟行为。 如果 SignalR 服务器和客户端版本为 ASP.NET Core 3.0 或更高版本，则更应该对 ConnectionToken（而不是 ConnectionId）进行保密。 任何 API 中均未故意公开 ConnectionToken。 确保较旧的 SignalR 客户端未连接到服务器可能较为困难，因此即使 SignalR 服务器版本为 ASP.NET Core 3.0 或更高版本，也不应公开 ConnectionId。

访问令牌日志记录

使用 WebSocket 或服务器发送的事件时，浏览器客户端会在查询字符串中发送访问令牌。 通常，通过查询字符串接收访问令牌与使用标准 Authorization 标头一样安全。 请始终使用 HTTPS 以确保在客户端和服务器之间实现安全的端到端连接。 许多 Web 服务器会记录每个请求的 URL（包括查询字符串）。 记录 URL 时可能也会记录访问令牌。 默认情况下，ASP.NET Core 会记录每个请求的 URL（包括查询字符串）。 例如：

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

如果担心将此数据记录在服务器日志中，可以通过将 Microsoft.AspNetCore.Hosting 日志记录器配置为 Warning 级别或更高级别（这些消息将在 Info 级别写入）。 有关详细信息，请参阅在代码中应用日志筛选规则。 如果仍想记录某些请求信息，可以编写中间件来记录所需的数据，并筛选出 access_token 查询字符串值（如果存在）。

异常

异常消息通常被认为是不应透露给客户端的敏感数据。 默认情况下，SignalR 不会将由中心方法引发的异常的详细信息发送给客户端。 客户端将收到指示出现错误的一般消息。 可以使用 EnableDetailedErrors 替代（例如在开发或测试中）向客户端发送的异常消息。 异常消息不应在生产应用中向客户端公开。

缓冲区管理

SignalR 使用每个连接缓冲区管理传入消息和传出消息。 默认情况下，SignalR 将这些缓冲区的大小限制为 32 KB。 客户端或服务器可以发送的最大消息大小为 32 KB。 消息连接使用的最大内存为 32 KB。 如果消息始终小于 32 KB，则可以降低限制，从而：

  • 阻止客户端发送更大的消息。
  • 服务器绝不需要分配大型缓冲区来接受消息。

如果消息大小超过 32 KB，则可以提高限制。 提高此限制意味着：

  • 客户端可能会导致服务器分配大型内存缓冲区。
  • 大型缓冲区的服务器分配可能会减少并发连接的数量。

传入消息和传出消息均有限制，两者均可在 MapHub 中配置的 HttpConnectionDispatcherOptions 对象上配置：

  • ApplicationMaxBufferSize 表示服务器从客户端缓存的最大字节数。 如果客户端尝试发送比此限制更大的消息，则可能会关闭该连接。
  • TransportMaxBufferSize 表示服务器可以发送的最大字节数。 如果服务器尝试发送比此限制更大的消息（包括从中心方法返回的值），则将引发异常。

将限制设置为 0 可以禁用限制。 通过删除该限制，客户端可以发送任意大小的消息。 发送较大消息的恶意客户端可能会导致分配过多的内存。 过多的内存使用量会显著减少并发连接数。

本文提供有关如何保护 SignalR 的信息。

跨源资源共享

跨源资源共享 (CORS) 可以用于允许浏览器中的跨源 SignalR 连接。 如果 JavaScript 代码托管在与 SignalR 应用不同的另一个域中，则必须启用 CORS 中间件以允许 JavaScript 连接到 SignalR 应用。 仅允许来自你信任或控制的域的跨源请求。 例如：

  • 网站托管在 http://www.example.com 上
  • SignalR 应用托管在 http://signalr.example.com 上

应在 SignalR 应用中配置 CORS 以仅允许源 www.example.com。

有关配置 CORS 的详细信息，请参阅启用跨源请求 (CORS)。 SignalR需要以下 CORS 策略：

  • 允许特定的预期来源。 允许任何来源是可行的，但不安全或不推荐使用。
  • 必须允许使用 HTTP 方法 GET 和 POST。
  • 为了使基于 cookie 的粘滞会话正常工作，必须允许使用凭据。 即使未使用身份验证，也必须启用它们。

但是，在 5.0 中，我们在 TypeScript 客户端中提供了一个不使用凭据的选项。 只有在 100% 确定应用中不需要 Cookie 之类的凭据时（为粘滞会话使用多个服务器时，Azure 应用服务会使用 Cookie），才应使用不使用凭据的选项。

例如，以下突出显示的 CORS 策略允许 https://example.com 中托管的 SignalR 浏览器客户端访问托管在 https://signalr.example.com 上的 SignalR 应用：

using SignalRChat.Hubs;

var MyAllowSpecificOrigins = "_myAllowSpecificOrigins";

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy(name: MyAllowSpecificOrigins,
                      policy =>
                      {
                          policy.WithOrigins("http://example.com");
                          policy.WithMethods("GET", "POST");
                          policy.AllowCredentials();
                      });
});

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddSignalR();

var app = builder.Build();

app.MapHub<ChatHub>("/chatHub");

在前面的示例中，已将 CORS 策略自定义为允许特定源、方法和凭据。 有关在 ASP.NET Core 中自定义 CORS 策略和中间件的详细信息，请参阅 CORS 中间件：具有命名策略和中间件的 CORS。

WebSocket 源限制

CORS 提供的保护不适用于 WebSocket。 有关 WebSocket 上的源限制，请阅读 WebSocket 源限制。

ConnectionId

如果 SignalR 服务器或客户端版本为 ASP.NET Core 2.2 或更早版本，则公开 ConnectionId 可能会导致恶意的模拟行为。 如果 SignalR 服务器和客户端版本为 ASP.NET Core 3.0 或更高版本，则更应该对 ConnectionToken（而不是 ConnectionId）进行保密。 任何 API 中均未故意公开 ConnectionToken。 确保较旧的 SignalR 客户端未连接到服务器可能较为困难，因此即使 SignalR 服务器版本为 ASP.NET Core 3.0 或更高版本，也不应公开 ConnectionId。

访问令牌日志记录

使用 WebSocket 或服务器发送的事件时，浏览器客户端会在查询字符串中发送访问令牌。 通常，通过查询字符串接收访问令牌与使用标准 Authorization 标头一样安全。 请始终使用 HTTPS 以确保在客户端和服务器之间实现安全的端到端连接。 许多 Web 服务器会记录每个请求的 URL（包括查询字符串）。 记录 URL 时可能也会记录访问令牌。 默认情况下，ASP.NET Core 会记录每个请求的 URL（包括查询字符串）。 例如：

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

如果担心将此数据记录在服务器日志中，可以通过将 Microsoft.AspNetCore.Hosting 日志记录器配置为 Warning 级别或更高级别（这些消息将在 Info 级别写入）。 有关详细信息，请参阅在代码中应用日志筛选规则。 如果仍想记录某些请求信息，可以编写中间件来记录所需的数据，并筛选出 access_token 查询字符串值（如果存在）。

异常

异常消息通常被认为是不应透露给客户端的敏感数据。 默认情况下，SignalR 不会将由中心方法引发的异常的详细信息发送给客户端。 客户端将收到指示出现错误的一般消息。 可以使用 EnableDetailedErrors 替代（例如在开发或测试中）向客户端发送的异常消息。 异常消息不应在生产应用中向客户端公开。

缓冲区管理

SignalR 使用每个连接缓冲区管理传入消息和传出消息。 默认情况下，SignalR 将这些缓冲区的大小限制为 32 KB。 客户端或服务器可以发送的最大消息大小为 32 KB。 消息连接使用的最大内存为 32 KB。 如果消息始终小于 32 KB，则可以降低限制，从而：

  • 阻止客户端发送更大的消息。
  • 服务器绝不需要分配大型缓冲区来接受消息。

如果消息大小超过 32 KB，则可以提高限制。 提高此限制意味着：

  • 客户端可能会导致服务器分配大型内存缓冲区。
  • 大型缓冲区的服务器分配可能会减少并发连接的数量。

传入消息和传出消息均有限制，两者均可在 MapHub 中配置的 HttpConnectionDispatcherOptions 对象上配置：

  • ApplicationMaxBufferSize 表示服务器从客户端缓存的最大字节数。 如果客户端尝试发送比此限制更大的消息，则可能会关闭该连接。
  • TransportMaxBufferSize 表示服务器可以发送的最大字节数。 如果服务器尝试发送比此限制更大的消息（包括从中心方法返回的值），则将引发异常。

将限制设置为 0 可以禁用限制。 通过删除该限制，客户端可以发送任意大小的消息。 发送较大消息的恶意客户端可能会导致分配过多的内存。 过多的内存使用量会显著减少并发连接数。

本文提供有关如何保护 SignalR 的信息。

跨源资源共享

跨源资源共享 (CORS) 可以用于允许浏览器中的跨源 SignalR 连接。 如果 JavaScript 代码托管在与 SignalR 应用不同的另一个域中，则必须启用 CORS 中间件以允许 JavaScript 连接到 SignalR 应用。 仅允许来自你信任或控制的域的跨源请求。 例如：

  • 网站托管在 http://www.example.com 上
  • SignalR 应用托管在 http://signalr.example.com 上

应在 SignalR 应用中配置 CORS 以仅允许源 www.example.com。

有关配置 CORS 的详细信息，请参阅启用跨源请求 (CORS)。 SignalR需要以下 CORS 策略：

  • 允许特定的预期来源。 允许任何来源是可行的，但不安全或不推荐使用。
  • 必须允许使用 HTTP 方法 GET 和 POST。
  • 为了使基于 cookie 的粘滞会话正常工作，必须允许使用凭据。 即使未使用身份验证，也必须启用它们。

但是，在 5.0 中，我们在 TypeScript 客户端中提供了一个不使用凭据的选项。 只有在 100% 确定应用中不需要 Cookie 之类的凭据时（为粘滞会话使用多个服务器时，Azure 应用服务会使用 Cookie），才应使用不使用凭据的选项。

例如，以下 CORS 策略允许 https://example.com 中托管的 SignalR 浏览器客户端访问托管在 https://signalr.example.com 上的 SignalR 应用：

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ... other middleware ...

    // Make sure the CORS middleware is ahead of SignalR.
    app.UseCors(builder =>
    {
        builder.WithOrigins("https://example.com")
            .AllowAnyHeader()
            .WithMethods("GET", "POST")
            .AllowCredentials();
    });

    // ... other middleware ...
    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHub<ChatHub>("/chathub");
    });

    // ... other middleware ...
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ... other middleware ...

    // Make sure the CORS middleware is ahead of SignalR.
    app.UseCors(builder =>
    {
        builder.WithOrigins("https://example.com")
            .AllowAnyHeader()
            .WithMethods("GET", "POST")
            .AllowCredentials();
    });

    // ... other middleware ...

    app.UseSignalR(routes =>
    {
        routes.MapHub<ChatHub>("/chathub");
    });

    // ... other middleware ...
}

WebSocket 源限制

CORS 提供的保护不适用于 WebSocket。 有关 WebSocket 上的源限制，请阅读 WebSocket 源限制。

CORS 提供的保护不适用于 WebSocket。 浏览器不会：

  • 执行 CORS 预检请求。
  • 在发出 WebSocket 请求时，遵守 Access-Control 标头中指定的限制。

但是，浏览器在发出 WebSocket 请求时会发送 Origin 标头。 应将应用程序配置为验证这些标头，以确保只允许来自预期来源的 WebSocket。

在 ASP.NET Core 2.1 和更高版本中，可以通过使用放置在 UseSignalR 之前的自定义中间件和放置在 Configure 中的身份验证中间件来实现标头验证：


// In Startup, add a static field listing the allowed Origin values:
private static readonly HashSet<string> _allowedOrigins = new HashSet<string>()
{
    // Add allowed origins here. For example:
    "https://www.mysite.com",
    "https://mysite.com",
};

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ... other middleware ...

    // Validate Origin header on WebSocket requests to prevent unexpected cross-site 
    // WebSocket requests.
    app.Use((context, next) =>
    {
        // Check for a WebSocket request.
        if (string.Equals(context.Request.Headers["Upgrade"], "websocket"))
        {
            var origin = context.Request.Headers["Origin"];

            // If there is an origin header, and the origin header doesn't match 
            // an allowed value:
            if (!string.IsNullOrEmpty(origin) && !_allowedOrigins.Contains(origin))
            {
                // The origin is not allowed, reject the request
                context.Response.StatusCode = (int) HttpStatusCode.Forbidden;
                return Task.CompletedTask;
            }
        }

        // The request is a valid Origin or not a WebSocket request, so continue.
        return next();
    });

    // ... other middleware ...

    app.UseSignalR(routes =>
    {
        routes.MapHub<ChatHub>("/chathub");
    });

    // ... other middleware ...
}

注意

与 Referer 标头一样，Origin 标头由客户端控制，并可以伪造。 这些标头不应用作身份验证机制。

ConnectionId

如果 SignalR 服务器或客户端版本为 ASP.NET Core 2.2 或更早版本，则公开 ConnectionId 可能会导致恶意的模拟行为。 如果 SignalR 服务器和客户端版本为 ASP.NET Core 3.0 或更高版本，则更应该对 ConnectionToken（而不是 ConnectionId）进行保密。 任何 API 中均未故意公开 ConnectionToken。 确保较旧的 SignalR 客户端未连接到服务器可能较为困难，因此即使 SignalR 服务器版本为 ASP.NET Core 3.0 或更高版本，也不应公开 ConnectionId。

访问令牌日志记录

使用 WebSocket 或服务器发送的事件时，浏览器客户端会在查询字符串中发送访问令牌。 通常，通过查询字符串接收访问令牌与使用标准 Authorization 标头一样安全。 请始终使用 HTTPS 以确保在客户端和服务器之间实现安全的端到端连接。 许多 Web 服务器会记录每个请求的 URL（包括查询字符串）。 记录 URL 时可能也会记录访问令牌。 默认情况下，ASP.NET Core 会记录每个请求的 URL（包括查询字符串）。 例如：

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

如果担心将此数据记录在服务器日志中，可以通过将 Microsoft.AspNetCore.Hosting 日志记录器配置为 Warning 级别或更高级别（这些消息将在 Info 级别写入）。 有关详细信息，请参阅在代码中应用日志筛选规则。 如果仍想记录某些请求信息，可以编写中间件来记录所需的数据，并筛选出 access_token 查询字符串值（如果存在）。

异常

异常消息通常被认为是不应透露给客户端的敏感数据。 默认情况下，SignalR 不会将由中心方法引发的异常的详细信息发送给客户端。 客户端将收到指示出现错误的一般消息。 可以使用 EnableDetailedErrors 替代（例如在开发或测试中）向客户端发送的异常消息。 异常消息不应在生产应用中向客户端公开。

缓冲区管理

SignalR 使用每个连接缓冲区管理传入消息和传出消息。 默认情况下，SignalR 将这些缓冲区的大小限制为 32 KB。 客户端或服务器可以发送的最大消息大小为 32 KB。 消息连接使用的最大内存为 32 KB。 如果消息始终小于 32 KB，则可以降低限制，从而：

  • 阻止客户端发送更大的消息。
  • 服务器绝不需要分配大型缓冲区来接受消息。

如果消息大小超过 32 KB，则可以提高限制。 提高此限制意味着：

  • 客户端可能会导致服务器分配大型内存缓冲区。
  • 大型缓冲区的服务器分配可能会减少并发连接的数量。

传入消息和传出消息均有限制，两者均可在 MapHub 中配置的 HttpConnectionDispatcherOptions 对象上配置：

  • ApplicationMaxBufferSize 表示服务器从客户端缓存的最大字节数。 如果客户端尝试发送比此限制更大的消息，则可能会关闭该连接。
  • TransportMaxBufferSize 表示服务器可以发送的最大字节数。 如果服务器尝试发送比此限制更大的消息（包括从中心方法返回的值），则将引发异常。

将限制设置为 0 可以禁用限制。 通过删除该限制，客户端可以发送任意大小的消息。 发送较大消息的恶意客户端可能会导致分配过多的内存。 过多的内存使用量会显著减少并发连接数。