那么…… ASP.NET MVC和WebSockets？
我在MVC 3中有一个应用程序，我正在寻找添加WebSockets（后备到Comet）。
我研究了一下，我发现Comet部分很简单，我宁愿自己做。 只需AsyncControllers和一些非常简单的js就可以处理那些长期存在的ajax请求。
现在，就WebSocket而言，事情开始变得肮脏。 我看了几个库，但他们似乎主要建立了一个自己的Web服务器（因此需要另一个主机或端口），并在那里监听ws协议请求。 例如SuperWebSocket就是这种情况，一开始看起来很不错，但是这个“我是一个Web服务器”问题（当然这很好，但我宁愿避免）。
然后我看了“PingIt”或类似的东西，我现在找不到链接..，我确实在另一台计算机上有源。 这一个在mvc中的端点上运行，但我不太喜欢它处理事物的方式，比如它需要一个IDisposable对象并通过reflection器创建一个javascript片段，在客户端呈现，这是非常污染的他们的图书馆名称，我真的没有兴趣，加上它感觉很多东西被抛到了我想要的东西，这与我对如何呈现页面的观点有所不同（特别是现在我正在研究MVC，这意味着我可以编写干净，不引人注目的html页面）。
基本上我想要的是我的端点是这样的：
domain.com/rt/comet
domain.com/rt/socket
而不是
domain.com/rt/comet
domain.com:81/
那么：是否有可能在asp.net MVC应用程序的控制器中的端点上接收websocket连接（并进行握手和需要完成的任何操作），而不是在某处设置tcplistener？
这也可以帮助我保持我的彗星代码更接近我的websocket代码
我应该说我对整个彗星/ websockets事情都很认真，所以我真的不太了解（或任何）协议，我确实知道如何使彗星工作，但在websockets中却没有那么多，尽管我已经阅读并理解了基础知识以获得它的要点。
另外：请告诉我，如果我要问的是什么
只是同意评论并提供一些链接。 SignalR是要走的路。
该网站： http ： //signalr.net/和http://www.asp.net/signalr
代码： https ： //github.com/SignalR/SignalR
Nuget： Install-Package Microsoft.AspNet.SignalR -pre
好起点：
-
免费电子书http://www.eduardopires.net.br/Repositorio/SignalR_eBook.pdf
-
http://weblogs.asp.net/davidfowler/archive/2012/11/11/microsoft-asp-net-signalr.aspx
来自其中一位创作者的video： http ： //vimeo.com/43659069 < - [大量信息！]
作为WebSockets上此线程的参考点 – 我希望您注意，乍一看，WebSockets看起来是显而易见的选择。 API旨在通过单个TCP套接字在浏览器和服务器之间提供双向通信通道。 它由IETF标准化，最新的Chrome，Firefox，IE和Opera浏览器支持WebSockets。 它旨在通过减少HTTP消息开销来最小化带宽开销。 那么，有什么不喜欢的？
就像任何被认为的银弹一样，事情并不总是它们看起来的样子。 存在很多问题：
浏览器支持：截至2012年6月，目前只有47.64％的浏览器实际上支持WebSockets http://caniuse.com/websockets – 这意味着，无论WebSockets出现多好，您仍需要第二个“后备”解决方案来支持大多数互联网用户。 由于大多数“后备”解决方案都涉及Flash，因此您在iOS和其他移动设备上仍然运气不佳。
从这篇博文中了解更多关于WebSockets的信息： HTML5 WebSockets网关和服务器是用于实时数据推送的万能药吗？
浏览器支持更新：截至2017年7月，目前使用的93.85％的浏览器实际上支持WebSockets http://caniuse.com/websockets
我研究了一下，我发现Comet部分很简单，我宁愿自己做。 只需AsyncControllers和一些非常简单的js就可以处理那些长期存在的ajax请求。
对不起，这并不容易。 不同的浏览器以不同的方式运行，并使用不同的技术 – XMLHttpRequest，XDomainRequest，ActiveX对象，多部分替换，长轮询，流式处理。 因此，以及这些解决方案没有明确规定的事实， Comet只是一个黑客 。 服务器发送事件（EventSource API）和WebSockets从一开始就设计为提供从服务器到客户端的数据推送的最有效和标准化的方式，更重要的是WebSockets被设计用于客户端之间的实时双向通信和服务器。
现在，就WebSocket而言，事情开始变得肮脏。 我看了几个库，但他们似乎主要建立了一个自己的Web服务器（因此需要另一个主机或端口），并在那里监听ws协议请求。 例如SuperWebSocket就是这种情况，一开始看起来很不错，但是这个“我是一个Web服务器”问题（当然这很好，但我宁愿避免）。
Windows Server 8本身支持WebSockets。 在此之前，您需要使用单独的“Web服务器”，例如XSockets或SuperWebSockets（您已经引用过）。 还有Alchemy WebSockets和Fleck 。
但是因为微软正在推动SignalR向前推进，所以它最有可能获得全面的牵引力，甚至成为标准ASP.NET MVC堆栈的一部分（它可能已经有计划，我有点落后于MS的东西）。 SignalR具有WebSocket支持（或具有模块），并将处理支持用户浏览器的传输机制的后备。
有关自托管解决方案的更多信息（还有一些.NET / IIS选项），请查看这些自托管实时服务 。
我非常有兴趣了解IIS在处理数以千计的持久连接时如何扩展 – 是否已经为Windows Server 8重写了？ 您需要多长时间才能引入负载平衡器并水平扩展？ 如果那不是您有兴趣担心的事情，那么我会看一下托管的实时服务 。