原标题：深入理解kestrel的应用

1 前言

之所以写本文章，是因为在我停止维护多年前写的NetworkSocket组件两年多来，还是有一些开发者在关注这个项目，我希望有类似需求的开发者明白为什么要停止更新，可以使用什么更好的方式来替换(其实很大原因是我把时间花在开发WebApiClient上面了)。那时.netcore还没有生下来，asp.net除了蜗居在iis里处理http，其它什么也不能干，而NetworkSocket是这样定义的：

NetworkSocket是一个以中间件(middleware)扩展通讯协议，以插件(plug)扩展服务器功能的支持SSL安全传输的通讯框架；目前支持http、websocket、fast、flex策略与silverlight策略协议。2 Kestrel是什么

谈到asp.netcore，人们自然就想到它的默认服务器kestrel，在很多场景中，人们甚至认为kestrel等于Web服务器，或者说它只能处理http和http之上的东西。本文先在此下个定义：Kestrel是一款基于中间件来处理tcp连接的服务器，并内置了http(包含websocket、SignalR)解析中间件。也就是说，我们完全可以给kestrel添加其它中间件，用来处理非http的连接的业务场景，让kestrel使用一个端口支持多种协议或多协议一个端口一种协议的要求。

2.1 Kestrel的中间件是什么

在asp.netcore的Startup里，我们使用app.UseXXX的扩展方法来应用各种中间件，比如UseRouting、UseStaticFiles等等，它本质上还是调用了 IApplicationBuilder.Use(Func middleware) ，也就说 Func 就是一个中间件。

对应的，在kestrel世界里，也有一个 IConnectionBuilder.Use(Func middleware) ， Func 就是kestrel的中间件，我们可以如下安装kestrel的中间件：

kestrel.ListenAnyIP(port: 80, listen =>

{

listen. Use(next => context =>

{

if( true)

{

// 中间件1的逻辑

} else

{

returnnext(context);

}

})

. Use(next => context =>

{

if( true)

{

// 中间件2的逻辑

} else

{

returnnext(context);

}

});

});

值得注意的是，kestrel的最后一个中间处理者是http中间件，以上代码，实际的kestrel已经包含3种处理者(文章后部分有中间件的篇幅，然后就容易理解了)，逻辑1、逻辑2和http解析，我们可以简单理解为Startup的app对象，对应kestrel的内置的那个最后中间件。

2.2 Kestrel的ConnectionContext

在kestrel中间件里，最重要的对象就是ConnectionDelegate，它等同于 Func ，我们可以理解为它就是一个Hanlder，传入连接上下文，剩下就是我们要干的工作了，而中间件是除了这个Handler之外，我们还能拿到一个叫next的Handler，我们可以选择是否调用它，如果不调用，流程终止。

ConnectionContext是kestrel的一个Tcp连接抽象，其核心属性是Transport，表示双工传输层的操作对象，另外提供Abort方法用于服务端主动关闭连接。基于ConnectionContext，很容易实现一个自定义协议的tcp双工通讯服务器，相比从Socket写起，我们可能可以减少100倍代码量，而得到的是更高性能的服务。

3 基于Kestrel的SignalR+Redis的推送服务 3.1 协议与ConnectionContext的关系

在我们的这个应用里，一个连接不允许同时使用SignalR和Redis并存协议，也就是说，一个连接在发起第一个请求里，就确定了它整个生命周期里的协议。所以，我们需要分析连接读取到的第一个数据包，确定它是否为Redis协议，如果不是redis协议，我们要将ConnectionContext传达到下一个中间件(即http中间件)。

3.2 使用Redis中间件

如下代码，Use里面就是Redis中间件，里面的个协议分析逻辑：

kestrel.ListenAnyIP(options.Port, listen =>

{

listen.Use(next => asynccontext =>

{

if( awaitProtocol.IsRedisAsync(context))

{

logger.LogDebug( $"{context.RemoteEndPoint} { nameof(ClientType.Redis)} 连接");

awaitredis.HandleAsync(context);

logger.LogDebug( $"{context.RemoteEndPoint} { nameof(ClientType.Redis)} 断开");

}

else

{

logger.LogDebug( $"{context.RemoteEndPoint} { nameof(ClientType.SignalR)} 连接");

awaitnext(context);

logger.LogDebug( $"{context.RemoteEndPoint} { nameof(ClientType.SignalR)} 断开");

}

});

});

Protocol类

///

///连接的协议判断

///

publicstaticclassProtocol

{

///

///返回连接是否为redis协议

///

///

///

publicstaticasyncTask< bool> IsRedisAsync(ConnectionContext connection)

{

varresult = awaitconnection.Transport.Input.ReadAsync;

varstate = IsRedis(result);

connection.Transport.Input.AdvanceTo(result.Buffer.Start);

returnstate;

}

///

///返回数据是否为redis协议

///这里不必严格检查，只要能区分是http还是redis就行

///

///

///

privatestaticboolIsRedis(ReadResult result)

{

if(result.Buffer.IsEmpty)

{

returnfalse;

}

varspan = result.Buffer.FirstSpan;

returnspan.Length > 0 && span[0] == '*';

}

}

3.3 RedisConnectionHandler

在3.2代码里，有一个await redis.HandleAsync(context);这个redis就是RedisConnectionHandler实例，它的功能是处理一个redis连接从建立成功之后到断开的所有逻辑。

既然kestrel基于连接处理中间件，上层的asp.netcore也是基于请求处理中间件，我们完全也可以也依葫芦画瓢，造一个Redis命令中间件Builder，最后将所有Redis中间件串起来，Buid得一个Redis处理委托。

varbuilder = newPipelineBuilder(appServices, context=>

{

// 没有handler来处理

returncontext.Client.ResponseAsync(RedisResponse .Error( "unsupported cmd"));

})

.Use(( context, next) =>

{

this.logger.LogDebug( context.ToString);

// 验证客户端是否已授权

returncontext.Cmd.Name!= RedisCmdName .Auth&& context.Client.IsAuthed== false

? context.Client.ResponseAsync(RedisResponse .Error( "need auth password"))

: next;

});

// 添加各个cmd对应的handler条件分支

appServices

.GetServices

.ForEach(item => builder .When(item .CanHandle, item .HandleAsync));

this.handler= builder .Build;

在RedisConnectionHandler，每收一个Redis命令，将命令包装为RedisContext，然后使用build出来的handler对象来处理这个RedisContext就行。剩下的工作，就是我们一个命令实现一个IRedisCmdHanler对象就行，逻辑完全分开。

IRedisCmdHanler接口：

///

///定义redis命令处理者

///

interfaceIRedisCmdHanler

{

///

///返回是否可以处理

///

///

///

boolCanHandle(RedisContext context);

///

///处理

///

///

///

Task HandleAsync(RedisContext context);

}

3.4 统一Redis和Signal客户端操作接口 ///

///定义客户端的接口

///

publicinterfaceIClient

{

///

///获取唯一标识

///

stringId { get; }

///

///获取连接时间

///

DateTime ConnectedTime { get; }

///

///获取客户端类型

///

[ JsonConverter(typeof(JsonStringEnumConverter))]

ClientType ClientType { get; }

///

///发送消息

///

///

///

Task< bool> SendMessageAsync(Message message);

}

3.5 IClient管理器 3.6 SignalR部分

由于SignalR的内容非常简单，官方文档细节齐全，这里将不作任何讲解了。

4 总结

由于要讲解的内部比较多，篇幅和时间都有限，本文就只从思路上大概讲解Kestrel在多协议连接的场景的使用方式。一句话，中间件的使用，使得这些场景变得简单，那问题来了，什么是中间件，你理解了吗？返回搜狐，查看更多

责任编辑：