.NET 4.5 WebSockets 与 SignalR答案

【问题标题】：.NET 4.5 WebSockets vs SignalR.NET 4.5 WebSockets 与 SignalR
【发布时间】：2012-03-20 10:37:02
【问题描述】：

我见过signalR vs html5 websockets for asp.net MVC chat application，但它并没有 100% 回答我的问题，因为它基于 HTML5 WebSockets，Microsoft 可能在 .NET 4.5 中使用他们的 WebSocket 对象对其进行了扩展。

我想知道 WebSocket 功能是否真的与 SignalR 一样，并在 WebSocket 不可用时回退到长轮询？ Microsoft 肯定会在他们的技术方法中实施与 SignalR 相同的技术吗？

编辑：

对于其他对此感到疑惑的人，我发现此评论最有助于理解该场景以及我将使用 SignalR 的原因：

嗯，他们不是真的。到目前为止，IIS 和 ASP.NET 还没有支持 WebSocket 的任何内置内容，因此 SignalR 项目必须自己建造。现在微软正在提供管道 SignalR 可以轻松切换到使用 Microsoft 的实现，要么补充，要么代替自己。 SignalR 是一个对实现细节的抽象，WebScockets 类是实现细节

【问题讨论】：

正如答案中最初提到的，SignalR 的计划是成为 .NET 的一部分，这确实发生了，因为它现在是 ASP.NET asp.net/signalr 的官方部分 - 我更新了我的答案以添加您可能想知道的链接和想法。
啊，太棒了！感谢@MohamedMeligy 的更新，在核心库中看到 SignalR 真的很不错。

标签： asp.net websocket signalr

【解决方案1】：

我认为 SignalR 是要走的路，并且无论如何都会成为 .NET 本身的一部分（并且可能扩展/合并/替换 web-sockets 支持）。它在受支持时使用 Web 套接字，而在不受支持时使用一致的客户端轮询 hack，因此，这是要走的路。

更新：

由于此答案仍在获得支持，因此值得一提的是，SignalR 现在已正式成为 ASP.NET 的一部分。

查看http://asp.net/signalr

更新：.NET Core

正如@yazanpro 在 cmets 中指出的那样，SignalR 也被添加到 .NET Core。

in .NET Core 2.1 可用，official documentation 也可用。

【讨论】：

尽管我尊重您在这里的回答，但您知道 WebSockets 现在是否不这样做吗？如果我要使用 SignalR，如果有潜在的技术合并 - 考虑到这一点，现在使用 SignalR 库是否明智？
我对此的笔记来自微软的 Justin King 几天前在悉尼 ALT.NET 上展示 SignalR 时的最新笔记。我知道 SignalR 在 .NET 核心中的合并将由 SignalR 人自己完成，因此可能与当前产品相比几乎没有变化。
令人难以置信的是，他们没有在 Win7 和 Server 2008 中添加 SignalR 对 websockets 的支持。真是令人发指......
这不是 SignalR 的东西，它是 IIS 的东西，signalR 可以利用它。 IIS 8 中添加了 Websocket 支持 iis.net/learn/get-started/whats-new-in-iis-8/…
那么它们对 IIS 和套接字人员来说是坏事。实际上，我在几个小时内就已经在我的网站上实现了一个基本的 SignalR 机制，因此对 SignalR 团队表示敬意。它在 Chrome 上使用 SSE，并且可能在 IE10 上使用长轮询，但至少我最初的尝试立即奏效。到目前为止，SignalR 看起来真的很不错！

【解决方案2】：

我想知道 WebSocket 功能是否真的与 SignalR 做同样的事情，并在 WebSocket 不可用时回退到长轮询？

WebSockets 是一种独立于其他通信技术的新协议。来自 RFC

这项技术的目标是提供一种基于浏览器的机制需要与服务器进行双向通信的应用程序 不要依赖打开多个 HTTP 连接（例如使用 XMLHttpRequest 或 s 和 长轮询）。
微软肯定会在他们的技术方法中实施与 SignalR 相同的技术吗？

如果他们想符合规范，他们就不会。当然，没有什么能阻止微软开发类似于 SignalR 的更高级别的 API，它可以抽象出通信细节并提供优雅的回退。然而，假设的 API 可能会构建在 WebSocket 类之上，而不是替换它。

【讨论】：

我认为 OP 指的是这个：msdn.microsoft.com/en-us/library/…
是的，我是免费的！抱歉，如果我的问题 RomanArmy 不清楚。
@thedixon 我知道，我也是这么理解的。我认为 RFC 的一部分说 不依赖 ... 表示 WebSockets 的规范不会退回到长轮询。因此，如果微软想要符合规范，他们也不会让他们的 WebSocket 类回退到长轮询。
那么，在这方面，如果他们计划使 WebSocket 符合 Web 规范，他们甚至在开始使用这项技术之前就落后于 SignalR 一步，这是在自取其辱？试图弄清楚微软的未来计划到底是什么。
@thedixon 好吧，他们不是真的。到目前为止，IIS 和 ASP.NET 没有内置任何支持 WebSockets 的东西，因此 SignalR 项目必须自己构建它。既然微软正在提供管道 SignalR，可以很容易地切换到使用微软的实现，除了他们自己的实现之外，也可以代替他们自己的实现。 SignalR 是对实现细节的抽象，WebScockets 类是实现细节。

【解决方案3】：

SignalR 使用 OWIN，如果浏览器支持 Web 套接字，它将使用 WebSockets 连接；如果浏览器不支持 WebSockets，则使用长轮询。

【讨论】：