C# 那么... ASP.NET MVC 和 WebSockets？

So... ASP.NET MVC and WebSockets?

提问by bevacqua

I have an application in MVC 3 and I'm looking to add WebSockets (with fallback to Comet) to it.

我在 MVC 3 中有一个应用程序，我希望向它添加 WebSockets（后备到 Comet）。

I've researched a bit and I found out the Comet part is pretty straightforward and I'd much rather do it myself. Just AsyncControllers and a pretty plain bit of js is all that's required to handle those long-lived ajax requests.

我进行了一些研究，发现 Comet 部分非常简单，我宁愿自己做。只需要 AsyncControllers 和一些非常简单的 js 就可以处理那些长期存在的 ajax 请求。

Now, in the case of WebSocket, things start to get dirty. I've looked at a few libraries, but they mostly seem to set up a web server (therefore needing another host, or port) of their own, and listen to ws protocol requests there. This is the case for instance for SuperWebSocket, which seemed nice at first, but had this "I'm a web server" issue (which is perfectly fine of course, but I'd rather avoid).

现在，在 WebSocket 的情况下，事情开始变得肮脏。我查看了一些库，但它们似乎大多设置了自己的 Web 服务器（因此需要另一个主机或端口），并在那里侦听 ws 协议请求。例如SuperWebSocket就是这种情况，起初看起来不错，但有这个“我是一个网络服务器”的问题（这当然很好，但我宁愿避免）。

Then I looked at "PingIt" or something like that, I can't find the link now.., I do have the source on another computer though. This one DOES run on an endpoint in mvc, but I didn't quite like the way in which it handles things, like it takes an IDisposable object and through reflector it creates a javascript piece that gets rendered in the client, which is very polluted with their library's name, which I've really no interest in, plus it felt like a lot of it was being thrown in against what I might wish, which kind of goes against my view on how a page should be rendered like (specially now that I'm working on MVC which pretty much means I can code clean, unobtrusive html pages).

然后我查看了“PingIt”或类似的东西，我现在找不到链接..，不过我确实在另一台计算机上有源。这个确实在 mvc 中的端点上运行，但我不太喜欢它处理事物的方式，比如它需要一个 IDisposable 对象并通过反射器创建一个在客户端呈现的 javascript 片段，这是非常受污染的用他们图书馆的名字，我真的不感兴趣，而且感觉很多东西都被扔到了我可能希望的事情上，这违背了我对页面应该如何呈现的看法（特别是现在我正在研究 MVC，这几乎意味着我可以编写干净、不显眼的 html 页面）。

Basically what I want is my endpoints to be something like:

基本上我想要的是我的端点是这样的：

domain.com/rt/comet
domain.com/rt/socket

domain.com/rt/comet
domain.com/rt/socket

rather than

而不是

domain.com/rt/comet
domain.com:81/

domain.com/rt/comet
domain.com:81/

So: is it possible to receive websocket connections (and do handshaking and whatever needs to be done) on an endpoint within an asp.net MVC application's controller, rather than setting up a tcplistener somewhere?

那么：是否可以在 asp.net MVC 应用程序控制器内的端点上接收 websocket 连接（并进行握手和任何需要完成的操作），而不是在某处设置 tcplistener？

This would also help me keep my comet code a little closer to my websocket code

这也将帮助我让我的彗星代码更接近我的 websocket 代码

I should say I'm seriously new to the whole comet/websockets thing, so I don't really know much (or any) of the protocol, I do understand how to make comet work, but not so much in websockets, though I've read and understood the basics to get the gist of it.

我应该说我对整个 Comet/websockets 的东西真的很陌生，所以我真的不知道很多（或任何）协议，我知道如何让 Comet 工作，但在 websockets 中不太了解，虽然我已阅读并理解基础知识以了解其要点。

Also: please let me know if what I'm asking is way off

另外：请让我知道我的要求是否离题

采纳答案by Paul

Just going to agree with the comments and provide a few links. SignalR is the way to go.

只是同意评论并提供一些链接。SignalR 是要走的路。

The site: http://signalr.net/and http://www.asp.net/signalr

网站：http: //signalr.net/和http://www.asp.net/signalr

The code: https://github.com/SignalR/SignalR

代码：https: //github.com/SignalR/SignalR

Nuget: Install-Package Microsoft.AspNet.SignalR -pre

纽吉特： Install-Package Microsoft.AspNet.SignalR -pre

Good starting points:

好的起点：

• Free E-Book http://www.eduardopires.net.br/Repositorio/SignalR_eBook.pdf

• http://weblogs.asp.net/davidfowler/archive/2012/11/11/microsoft-asp-net-signalr.aspx

• http://www.dotnetcurry.com/ShowArticle.aspx?ID=780

• http://www.hanselman.com/blog/AsynchronousScalableWebApplicationsWithRealtimePersistentLongrunningConnectionsWithSignalR.aspx

• 免费电子书http://www.eduardopires.net.br/Repositorio/SignalR_eBook.pdf

• http://weblogs.asp.net/davidfowler/archive/2012/11/11/microsoft-asp-net-signalr.aspx

• http://www.dotnetcurry.com/ShowArticle.aspx?ID=780

• http://www.hanselman.com/blog/AsynchronousScalableWebApplicationsWithRealtimePersistentLongrunningConnectionsWithSignalR.aspx

Video from one of the creators: http://vimeo.com/43659069<--[Loads of information!]

来自其中一位创作者的视频：http: //vimeo.com/43659069 <--[大量信息！]

回答by leggetter

I've researched a bit and I found out the Comet part is pretty straightforward and I'd much rather do it myself. Just AsyncControllers and a pretty plain bit of js is all that's required to handle those long-lived ajax requests.

我进行了一些研究，发现 Comet 部分非常简单，我宁愿自己做。只需要 AsyncControllers 和一些非常简单的 js 就可以处理那些长期存在的 ajax 请求。

Sorry, it's not that easy. Different browsers behave in different ways and perform better using different techniques - XMLHttpRequest, XDomainRequest, ActiveX objects, Multpart replace, Long-Polling, Streaming. Because of this, and the fact there's no defined spec for these solutions, Comet is just a hack. Server Sent Events (EventSource API) and WebSockets have been designed from the ground up to offer the most efficient and standardised way of pushing data from server to the client, and much more importantly WebSockets have been designed for realtime bi-directional communication between a client and a server.

对不起，没那么容易。不同的浏览器以不同的方式运行并使用不同的技术表现得更好 - XMLHttpRequest、XDomainRequest、ActiveX 对象、Multpart 替换、长轮询、流。正因为如此，而且事实上这些解决方案没有定义的规范，Comet 只是一个 hack。服务器发送事件 (EventSource API) 和 WebSockets 是从头开始设计的，以提供将数据从服务器推送到客户端的最有效和标准化的方式，更重要的是，WebSockets 是为客户端之间的实时双向通信而设计的和一个服务器。

Now, in the case of WebSocket, things start to get dirty. I've looked at a few libraries, but they mostly seem to set up a web server (therefore needing another host, or port) of their own, and listen to ws protocol requests there. This is the case for instance for SuperWebSocket, which seemed nice at first, but had this "I'm a web server" issue (which is perfectly fine of course, but I'd rather avoid).

现在，在 WebSocket 的情况下，事情开始变得肮脏。我查看了一些库，但它们似乎大多设置了自己的 Web 服务器（因此需要另一个主机或端口），并在那里侦听 ws 协议请求。例如 SuperWebSocket 就是这种情况，它起初看起来不错，但遇到了“我是 Web 服务器”的问题（这当然很好，但我宁愿避免）。

Windows Server 8 will natively support WebSockets. Until then you'll need to use a separate 'web server' such as XSocketsor SuperWebSockets (which you've already referenced). There's also Alchemy WebSocketsand Fleck.

Windows Server 8 将原生支持 WebSockets。在此之前，您将需要使用单独的“网络服务器”，例如XSockets或 SuperWebSockets（您已经参考过）。还有Alchemy WebSockets和Fleck。

But because Microsoft are driving SignalRforward it is most likely to get full traction and even become part of the standard ASP.NET MVC stack (it may already be planned, I'm a little behind the times with MS stuff). SignalR has WebSocket support (or has a module) and will handle fallbacks to transport mechanisms which support the user's browser.

但是因为微软正在推动SignalR向前发展，它最有可能获得全面牵引力，甚至成为标准 ASP.NET MVC 堆栈的一部分（它可能已经计划好了，我在 MS 方面有点落后于时代）。SignalR 具有 WebSocket 支持（或具有模块），并将处理回退到支持用户浏览器的传输机制。

For more information on self hosted solutions (there are a few more .NET/IIS options) check out these self hosted realtime services.

有关自托管解决方案的更多信息（还有更多 .NET/IIS 选项），请查看这些自托管实时服务。

I'm very much interested in seeing how IIS scales when dealing with thousands of persistent connections - has it been re-written for Windows Server 8? How soon until you need to introduce a load balancer and horizontally scale? If that's not something you are interested in worrying about then I'd look at a hosted realtime service.

我非常想知道 IIS 在处理数千个持久连接时如何扩展 - 它是否已为 Windows Server 8 重新编写？多久后您需要引入负载均衡器并进行水平扩展？如果这不是您有兴趣担心的事情，那么我会考虑托管实时服务。

回答by Stephen Blum

As a point of reference for this thread on WebSockets - I want you to note that at first glance, WebSockets looks like the obvious choice. The API is designed to provide a bi-directional communication channel between browser and server over a single TCP socket. It's been standardized by the IETF, and the latest Chrome, Firefox, IE, and Opera browsers support WebSockets. It's designed to minimize bandwidth overhead by reducing HTTP message overhead. So, what's not to like?

作为 WebSockets 上此线程的参考点 - 我想让您注意，乍一看，WebSockets 似乎是显而易见的选择。API 旨在通过单个 TCP 套接字在浏览器和服务器之间提供双向通信通道。它已被 IETF 标准化，最新的 Chrome、Firefox、IE 和 Opera 浏览器都支持 WebSockets。它旨在通过减少 HTTP 消息开销来最小化带宽开销。那么，不喜欢什么？

Like any perceived silver bullet, things are not always what they seem. Lots of problems exist:

就像任何感知到的灵丹妙药一样，事情并不总是看起来那样。存在很多问题：

Browser Support:As of June 2012, only 47.64% of browsers currently in use actually support WebSockets http://caniuse.com/websockets- That means, no matter how good WebSockets appears, you still need a second "fallback" solution to support the majority of Internet users. And since most "fallback" solutions involve Flash, you're still out of luck on iOS and other mobile devices.

浏览器支持：截至 2012 年 6 月，目前使用的浏览器中只有 47.64% 实际支持 WebSockets http://caniuse.com/websockets- 这意味着，无论 WebSockets 出现多好，您仍然需要第二个“后备”解决方案来支持广大网民。而且由于大多数“后备”解决方案都涉及 Flash，因此您在 iOS 和其他移动设备上仍然不走运。

Read more about WebSockets in reality from this blog post: Are HTML5 WebSockets Gateway and Server the Panacea for Real-Time Data Push

从这篇博客文章中阅读更多关于现实中的 WebSockets：HTML5 WebSockets 网关和服务器是实时数据推送的灵丹妙药

Browser Support Update:As of May 2019, 96.77%of browsers currently in use actually support WebSockets http://caniuse.com/websockets

浏览器支持更新：截至 2019 年 5 月，目前使用的浏览器中有96.77%实际支持 WebSockets http://caniuse.com/websockets