我已经看到了用于 asp.net MVC 聊天应用程序的 signalR 与 html5 websockets，但它并没有 100% 回答我的问题，因为它基于 HTML5 WebSockets，Microsoft 可能在 .NET 4.5 中使用他们的 WebSocket 对象对其进行了扩展。
我想知道 WebSocket 功能是否确实与 SignalR 一样，并且在 WebSocket 不可用时回退到长轮询？微软肯定会在他们的技术方法中实施与 SignalR 相同的技术吗？
编辑：
对于其他对此感到疑惑的人，我发现此评论最有助于理解该场景以及我将使用 SignalR 的原因：
好吧，他们不是真的。到目前为止，IIS 和 ASP.NET 没有内置任何支持 WebSockets 的东西，因此 SignalR 项目必须自己构建它。既然微软正在提供管道 SignalR，可以很容易地切换到使用微软的实现，无论是补充还是代替他们自己的实现。SignalR 是对实现细节的抽象，WebScockets 类是实现细节
我认为 SignalR 是要走的路，并且无论如何都将成为 .NET 本身的一部分（并且可能扩展/合并/替换 web-sockets 支持）。它在受支持时使用 Web 套接字，而在不受支持时使用一致的客户端轮询黑客，因此，这是要走的路。
更新：
由于此答案仍在获得支持，因此值得一提的是，SignalR 现在已正式成为 ASP.NET 的一部分。
更新：.NET 核心
正如@yazanpro 在评论中指出的那样，SignalR 也被添加到 .NET Core。
它在 .NET Core 2.1 中可用，并且也有官方文档。
我想知道 WebSocket 功能是否确实与 SignalR 一样，并且在 WebSocket 不可用时回退到长轮询？
WebSockets 是一种独立于其他通信技术的新协议。来自 RFC
该技术的目标是为基于浏览器的应用程序提供一种机制，这些应用程序需要与不依赖于打开多个 HTTP 连接的服务器进行双向通信（例如，使用 XMLHttpRequest 或 s 和长轮询）。
微软肯定会在他们的技术方法中实施与 SignalR 相同的技术吗？
如果他们想符合规范，他们就不会。当然，没有什么能阻止微软开发类似于 SignalR 的更高级别的 API，它可以抽象出通信细节并提供优雅的回退。然而，这个假设的 API 可能会构建在WebSocket类之上，而不是替换它。
SignalR 使用 OWIN，如果浏览器支持 Web 套接字，它将使用 WebSockets 连接；如果浏览器不支持 WebSockets，则使用长轮询。