ASP.NET Core SignalR 连接令牌存储机制解析

SignalR 作为 ASP.NET Core 的实时通信库，其连接建立过程涉及一个关键的安全机制——连接令牌验证。本文将深入探讨这一机制的工作原理及其对部署架构的影响。

连接建立的两阶段过程

SignalR 的连接建立采用两阶段验证机制：

1. 协商阶段：客户端首先向服务器发起 negotiate 请求，服务器生成并返回一个唯一的连接令牌，同时将该令牌存储在服务器内存中
2. 连接阶段：客户端使用此令牌发起 WebSocket 连接，服务器验证令牌是否存在于内存存储中

这种设计确保了只有通过合法 negotiate 请求的客户端才能建立连接，防止未经授权的访问。

粘性会话的必要性

由于连接令牌默认存储在服务器内存中，这导致了一个重要限制：negotiate 请求和后续连接请求必须路由到同一台服务器。在负载均衡环境下，这通常需要通过以下方式实现：

• 基于 IP 的会话保持
• Cookie 会话亲和性
• 其他粘性会话机制

架构影响与替代方案

这种设计对部署架构产生了显著影响：

1. 横向扩展限制：必须确保连接请求始终路由到正确的服务器
2. 故障转移复杂性：服务器故障可能导致已协商但未建立的连接失败

SignalR 团队提供了两种替代方案：

1. 跳过协商阶段：通过配置 SkipNegotiation 选项，直接使用 WebSocket 连接，但需要注意：

   • 仅适用于 WebSocket 传输
   • 需要自行实现认证机制
   • 无法使用状态恢复功能

2. 自定义认证：结合 JWT 等标准认证机制，在连接时通过查询字符串传递令牌

深入技术考量

为什么 SignalR 不默认支持分布式令牌存储？这涉及多方面技术因素：

1. 状态同步复杂性：除连接令牌外，连接状态和组信息也需要同步
2. 性能考量：内存访问速度远高于分布式存储
3. 传输协议多样性：非 WebSocket 传输（如长轮询）需要更复杂的状态管理

最佳实践建议

根据实际需求选择适当方案：

1. 需要完整功能：使用粘性会话 + 默认协商流程
2. 仅需 WebSocket：跳过协商 + 自定义认证
3. 高可用需求：考虑结合 Redis 等分布式存储的自定义实现

理解这些底层机制有助于设计更健壮的实时通信系统架构，在安全性和可用性之间取得适当平衡。