如何在SignalR Core中确定传输方式？

嘿，这个问题我之前也碰到过！ASP.NET Core SignalR确实把旧版里通过queryString["transport"]拿传输方式的逻辑改了，你现在用请求头判断是没问题，但其实框架已经提供了更直接、可靠的方式，不用自己去解析那些头信息~

利用ITransportFeature直接获取传输类型 #

ASP.NET Core SignalR在每个连接的特性集合里内置了ITransportFeature接口，它直接封装了当前连接使用的传输方式，完全不需要手动解析请求头或者查询字符串。

在Hub中获取传输方式 #

这是最常见的场景，在Hub方法里可以通过Context.Features直接获取：

public async Task GetCurrentTransport()
{
    // 从上下文特性中获取ITransportFeature
    var transportFeature = Context.Features.Get<ITransportFeature>();
    
    if (transportFeature != null)
    {
        // TransportType是枚举，包含WebSockets、LongPolling、ServerSentEvents三种值
        var transportType = transportFeature.TransportType;
        string transportMethod = transportType.ToString();
        
        // 比如WebSocket连接会拿到"WebSockets"，长轮询是"LongPolling"，服务器发送事件是"ServerSentEvents"
        await Clients.Caller.SendAsync("ReceiveTransportInfo", $"当前传输方式：{transportMethod}");
    }
}

在中间件中获取传输方式 #

如果需要在Hub之外（比如请求管道的中间件里）判断传输方式，也可以从HttpContext的特性集合里获取：

app.Use(async (context, next) =>
{
    var transportFeature = context.Features.Get<ITransportFeature>();
    
    if (transportFeature != null)
    {
        // 这里可以根据传输类型做自定义逻辑，比如日志记录
        Console.WriteLine($"当前连接使用的传输方式：{transportFeature.TransportType.Name}");
    }
    
    await next();
});

为什么这是更优的方案？ #

• 可靠性更高：不用自己维护请求头的判断逻辑，框架会自动处理传输方式的识别，避免因为头信息格式变化导致判断错误。
• 代码更简洁：一行代码就能拿到明确的传输类型枚举值，比解析多个请求头要直观得多。
• 扩展性更好：如果以后SignalR新增了传输方式，TransportType枚举会同步更新，你的代码不用做任何修改就能兼容。

内容的提问来源于stack exchange，提问作者Dave New