这两天服务器和客户端进行了webscoket的联调,在和C#的webscoket实现联调的过程中,发现一些有趣的事情。
在我自己C++的实现中,webscoket对上层应用而言是完全透明的,webscoket 只是一个传输协议,用户对此不需要有任何关注,一切都自动进行,包括连接,握手升级,帧切割,帧拼合,控制帧管理,心跳这些,对外完全透明。
微软.net 中的webscoket实现就显得非常难以理解,握手需要用户主动去调用,这个从HTTP升级的操作还能理解:
public class WebSocketController : ControllerBase
{
[Route("/ws")]
public async Task Get()
{
if (HttpContext.WebSockets.IsWebSocketRequest)
{
using var webSocket = await HttpContext.WebSockets.AcceptWebSocketAsync();
await Echo(webSocket);
}
else
{
HttpContext.Response.StatusCode = StatusCodes.Status400BadRequest;
}
}
}
但是到了发送和接收阶段,先看看这两个函数的示例代码:
private async Task Echo(HttpContext context, WebSocket webSocket)
{
var buffer = new byte[1024 * 4];
WebSocketReceiveResult result = await webSocket.ReceiveAsync(new ArraySegment<byte>(buffer), CancellationToken.None);
while (!result.CloseStatus.HasValue)
{
await webSocket.SendAsync(new ArraySegment<byte>(buffer, 0, result.Count), result.MessageType, result.EndOfMessage, CancellationToken.None);
result = await webSocket.ReceiveAsync(new ArraySegment<byte>(buffer), CancellationToken.None);
}
await webSocket.CloseAsync(result.CloseStatus.Value, result.CloseStatusDescription, CancellationToken.None);
}
首先,接受函数需要指定一个缓冲区,由缓冲区来接受webscoket上传输的数据,这个属于常规操作,继续看发送函数, 你会发现在参数中,有两个参数:MessageType 和 EndOfMessage,看看微软怎么描述的:
参数
buffer
ArraySegment<Byte>
要通过连接发送的缓冲区。
messageType
WebSocketMessageTyp
指示应用程序是发送二进制消息还是发送文本消息。
endOfMessage
Boolean
指示“缓冲区”中的数据是否是消息的最后一部分。
cancellationToken
CancellationToken
传播有关应取消操作的通知的标记。
关于 WebSocketMessageType
Binary 1 消息采用二进制格式。
Close 2 因为收到关闭的消息,接受已完成。
Text 0 该消息是明文形式。
如果看过RFC6455是不是感到有些似曾相识?微软做了一次封装,但是也混淆了一些概念,把本应由WebSocket 内部处理的逻辑暴露给外部的调用。我暂时还没想明白微软为啥要这么设计,在我理想的模型里面,包括数据切割分段发送这些事情,不应该是WebScoket的实现自动处理吗?特别是endOfMessage这个布尔值,更让人费解。这个参数对应的opcode 中的 Fin 位?文档中没有说明。客户端在写代码的时候,暂时没有改变这个值,直接设置的 true。
而且关于subprotocol,微软也没有给出一个明确的框架,只是给出一个string,作为subprotocol的标志。我猜想,微软把这个暴露出来,也许就是为subprotocol留下可操作的空间,但文档里面没有明确的说明。在我看来,一个好的设计,应该保持某种程度的兼容性,比如和Scoket的SendAsync保持某种程度的一致。subprotocol应该设计成WebSocket的一个子对象,微软提供一个标准的调用接口,将所有协议细节都放在子协议接口之中,而不是像这样暴露出来。
另外还有一个问题,就是WebScoket的ping / pong心跳检测机制。我翻遍了微软提供的文档,只是这么提到ping和pong:
处理客户端连接断开
当客户端由于失去连接而断开连接时,不会自动向服务器发送通知。 服务器只有在客户端发送通知时才会收到断开连接消息,而此操作无法在失去 Internet 连接的情况下进行。 如果想要在发生此情况时采取某个操作,在特定时间范围内未收到来自客户端的任何消息后设置超时。
如果客户端并非总是发送消息,并且你不希望仅由于连接进入空闲状态就设置超时,则让客户端使用一个计时器并每隔 X 秒发送一条 ping 消息。 在服务器上,如果某条消息在上一条消息发出后的 2*X 秒内尚未到达,则终止连接并报告客户端已断开连接。 等待两次预测的时间间隔,以便为可能延迟 ping 消息的网络延迟提供额外的时间。
备注
如果
KeepAliveInterval
选项(默认为 30 秒 (TimeSpan.FromSeconds(30)
))大于零,则内部 ManagedWebSocket 将隐式处理 Ping/Pong 帧,以使连接保持活动状态。
可以看到,微软是实现了心跳检测的,KeepAliveInterval那个选项我经过测试,确定为心跳包的间隔时间,经过测试,发现微软的Ping控制帧是没有附带Payload的,客户端发送到服务器,包括掩码一共6个字节,服务器返回Pong给客户端是两个字节,如果服务器发送附带Payload的Ping帧,微软的WebScoket可以原封不动的把Payload通过Pong帧给服务器返回。文章来源:https://www.toymoban.com/news/detail-849825.html
测试中,发现了一个比较棘手的问题,即客户端虽然会发送Ping帧给服务器,但如果服务器不返回任何Pong帧,微软的WebSocket不会有任何动作,不会抛异常,虽然RFC6455没有明确规定心跳帧无法检测的情况该如何处理,但好歹抛一个异常或则事件通知我们?而且关于这一点,微软倒是明确说了:在服务器上,如果某条消息在上一条消息发出后的 2*X 秒内尚未到达,则终止连接并报告客户端已断开连接,那客户端呢?RFC6455是允许双向检测心跳的,既然检测到心跳失败,那么怎么就不留个通知的方法?文章来源地址https://www.toymoban.com/news/detail-849825.html
到了这里,关于.net 实现的 Webscoket 对象的一些细节和疑问的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!