目录

编者按
Fleck
SignalR
AlchemyWebSocket
XSockets
SuperWebsocket
总结
.NET 的 WebSocket 开发包比较

编者按

本文出现在第三方产品评论部分中。在这一部分的文章只提供给会员，不允许工具供应商用来以任何方式和形式来促销或宣传产品。请会员报告任何垃圾信息或广告。

Web项目常常需要将数据尽可能快地推送给客户，必要时无需等待客户端请求。对于与用户之间进行实时通信的网站，例如在线交流或文档协作工具，或者在长期运行的计算/执行任务的服务器上更新系统状态，等等这些时候，采用双向沟通机制是理想的。

以前,这类问题一般使用下面的解决方案:

但现在我们有了更好的选择：WebSocket。它的标准在2011年发布，在现代浏览器上已实施了一段时间。它更好的原因是使用更安全和更成熟的协议，带来了改进和升级。

略注:

这份比较是几个月前做的，可能不够及时，但如果有人要找好的WebSocket库，我认为这对他仍然是有用的。

本比较只针对以 NuGet 包形式发布的库， SuperWebSocket 虽然使用 NuGet 的 repository，但需要从网页中下载。

也许等我抽出空来，我会使用新的库或已测试的库的新版本进行比较然后更新这篇文章。

Fleck

https://github.com/statianzo/Fleck

我发现这个库真的是简单易用，对于库、文档、例子等都是，只要添加库，复制几行例子里的代码，然后运行——就这么简单。

但是简单是有代价的：其功能并不强大，且可配置的地方太少。

01 private static void Main(string[] args)
02 {
03      var server = new WebSocketServer("ws://localhost:8181");
04      server.Start(socket =>
05      {
06           socket.OnOpen = () => OnOpen(socket);
07           socket.OnClose = () => OnClose(socket);
08           socket.OnMessage = m => OnMessage(socket, m);
09      });
10 }

 

对于简单快速的项目我会用它，如果你不需要用WebSocket发送太复杂的数据结构、命令一样的消息、或在客户端无WebSocket支持时的备选方式，这就是你要的了。

优点:

  • 简单

  • 无依赖项

缺点:

  • 可配置项少

  • 客户端浏览器不支持WebSocket时就没戏了

SignalR

http://www.asp.net/signalr

微软出品是我认为这个库最大的优点了。它已经和现有的ASP.NET框架做了集成，对服务器端和客户端代码都做了很好的抽象类， 这意味着你不需要太深入了解协议的东西。然后它还可以很聪明地在客户端浏览器不支持WebSocket时自动使用别的通信机制。它还可以完成一些叫远程过程调用（RPC）的东西，从服务器到客户端。 

.NET 的 WebSocket 开发包比较(转)_qt_02

它能广播消息到所有客户端，也能单独发给指定用户。对大量并发连接的处理也很优秀。还有——它是开源的！

听起来很棒是不？但是...它需要IIS8或者说Windows Server 2012（Windows8也行，不过相信你不会在win8上面跑大项目的）。对我来说，这就是“微软新一代值得买的操作系统”的超酷特性。如果开发企业项目的话是不错的，但对小项目来说，为了这个开源的库买操作系统——太贵了。

 

当然这些环境是WebSocket必须要求的. 这篇文章就是讲WebSocket通讯的，所以我把这个算成大缺点。

1 public class MyHub1 : Hub
2 {
3     public void Send(string name, string message)
4     {
5         // Call the broadcastMessage method to update clients.
6         Clients.All.broadcastMessage(name, message);
7     }
8 }

 

01 $(function () {
02     var chat = $.connection.myHub1;
03     chat.client.broadcastMessage = function (name, message) {
04         //...
05     };
06     $.connection.hub.start().done(function () {
07         $('#sendmessage').click(function () {
08             chat.server.send('message');
09         });
10     });
11 });

 

优点:

  • 非常好的抽象

  • 与IIS和ASP.NET紧密集成

  • 很多候选方式

  • 开源

  • 微软官方库

  • 可扩展性好

缺点:

  • 需要IIS8…

  • … 也就是Windows Server 2012太贵了

AlchemyWebSocket

http://alchemywebsockets.net/

当我想到websocket库时，这个让人不可思议。没错这是真的。它可以排在Fleck后面，它非常容易使用，容易安装（Nuget包可用），文档中含有很好的例子。

它包含服务端和客户端两部分，同时也具有可伸缩性

01 static void Main(string[] args)
02 {
03     // 创建一个新的server - 接受端口和ip范围,
04     // 设置方法
05  
06     var aServer = new WebSocketServer(81, IPAddress.Any)
07     {
08         OnReceive = OnReceive,
09         OnSend = OnSend,
10         OnConnect = OnConnect,
11         OnConnected = OnConnected,
12         OnDisconnect = OnDisconnect,
13         TimeOut = new TimeSpan(0, 5, 0)
14     };
15  
16     aServer.Start();
17     string consoleReadLine;
18     do
19     {
20         consoleReadLine = Console.ReadLine();
21         sockets.ForEach(s => s.Send(consoleReadLine));
22     } while (consoleReadLine != "exit");
23 }

 

但是它有一些别扭，我不能避开。例如那里没有简单的事件方法"OnReceive"，仅仅只有string，事实上消息在客户端被发送了。你必须你自己完成。是的，你必须调用，而且只能调用 .ToString()来得到真实的消息，但使用库的目的是为了不要强迫自己实现通信协议。

1 private static void OnReceive(UserContext context)
2 {
3     Console.WriteLine("Client " + context.ClientAddress.ToString() + " sended: " + context.DataFrame.ToString());
4 }

WebSocket服务器初始化方法首先接收端口然后是IP设置。我一直认为，地址的表达应该是先IP然后是端口，而且只有当有必要指明端口的时候。还有超时设置：为什么必须有超时呢？我可以理解这有时可能是有用的，但它作为一个特性不应作为主要设置之一。当然，这只是一些细节问题。

对我来说这迫使你一开始就得通过这个库用另一层代码把它抽象出来。

总之你可以试试，和Fleck比较一下性能，然后决定哪个更适合你的简单项目。

优势：

  • 简单

  • 无依赖性

  • 文档完备

缺点：

  • 有点笨拙，比Fleck结构更复杂

  • 没有 fallback

XSockets

http://xsockets.net/

这个库看上去很有前途。我尝试过它，并且还花了很多时间，用它工作超过其它的库（甚至用来执行测试工作等等）。但是很不幸我没有运气，任何我考虑到的错误在这个库中都是错误的，与代码不一致的糟糕文档。难道是因为代码或者文档过期了？它不容易安装和运行，事实上这个库的使用样例我很难组建和运行。Xsocket更多向我们展示了MVC框架的样子。我尝试把它运行在ASP.NET项目里面，MVC和WinService，遗憾的是没有一个能够工作。

我真的很想用这个库，但最后我放弃了以便支持更好的库（阅读其他）。认真地说为什么使用这个库是困难的，甚至一个简单的项目。你可以预测更多的问题当把它使用在项目里，我强烈建议避开这个项目。

1 public static class XSocketsBootstrap
2 {
3     private static IXBaseServerContainer wss;
4     public static void Start()
5     {            
6         wss = XSockets.Plugin.Framework.Composable.GetExport();
7         wss.StartServers();
8     }
9 }

 

01 <p>Advantages:</p>
02 <ul>
03 <li>Seems powerful</li>
04 <li>Should have good JavaScript integration</li>
05 </ul>
06 <p>Disadvantages:</p>
07 <ul>
08 <li>Complicated and hard</li>
09 <li>Complicated to configure and run inside of WebForms, MVC and WinService</li>
10 <li>Differences between code and documentation</li>
11 <li>Outdated documentation and examples</li>
12 </ul>
13 </li>
14 <li>
15 <h2>Microsoft.WebSocket</h2>
16 <p><a href="http://msdn.microsoft.com/en-us/hh969243.aspx">http://msdn.microsoft.com/en-us/hh969243.aspx</a></p>
17 <p>Another library from Microsoft. And it requires IIS 8 too, so I did not have means to test it. Examples are really low level, so it force you to deal with buffers and streams instead of strings. In some cases this can be good, but mostly there is no point. If you have IIS 8 on server why bother with this library if you can use SignalR, which will take care most of the stuff for you.</p>
18 <p>I think this is more of proof-of-concept then usable library.</p>
19 <pre>int count = receiveResult.Count;
20  
21 while (receiveResult.EndOfMessage == false)
22 {
23     if (count >= maxMessageSize)
24     {
25         string closeMessage = string.Format("Maximum message size: {0} bytes.", maxMessageSize);
26         await socket.CloseAsync(WebSocketCloseStatus.MessageTooBig, closeMessage, CancellationToken.None);
27         return;
28     } receiveResult = await socket.ReceiveAsync(new ArraySegment(receiveBuffer, count, maxMessageSize - count), CancellationToken.None);
29     count += receiveResult.Count;
30 } var receivedString = Encoding.UTF8.GetString(receiveBuffer, 0, count);
31 var echoString = "You said " + receivedString;
32 ArraySegment outputBuffer = new ArraySegment(Encoding.UTF8.GetBytes(echoString));
33 await socket.SendAsync(outputBuffer, WebSocketMessageType.Text, true, CancellationToken.None);

SuperWebsocket

http://superwebsocket.codeplex.com/

最后但并不是最不重要的是SuperWebsocket。我对这个有一点怀疑（如果我没记错的话，这仅仅是一个我通过NuGet网站发现的包，但又不是一个可用的包）。它似乎有一点复杂，但实际上它是非常简单的。有文献支持的例子帮助你一步步的从最简单的WebSocket服务器，到有命令请求，JSON，多服务器实例，.config文件配置或者更多的复杂Websocket服务器。

这个库也许没有包含所有其他库有的那些很酷的特性，但是这没关系，因为它是高度可配置的，你可以很容易的让它实现你想要的。它可以作为控制台应用程序或者windows服务运行于ASP.NET中。文献上则建议以系统服务的形式来运行服务器。从我的经验来看，建议不要在一个web应用程序里面运行它因为这种解决方案很慢（非常糟糕的表现，比控制台应用程序大约慢50倍）。从另一方面，独立的服务器应用程序，需要运行.exe结尾的文件，这个文件并不是库的一部分，但是是SuperSocket项目的一部分（SuperWebSocket就是基于这个项目的）。这使得你需要一点技巧在调试会话中开启服务器，或者完全启用调试。当你作为应用程序运行服务器的时候，虽然这不是解决方案的一部分，也需要确保服务器采用来自其他项目的最新版的组件。

作为回报，你得到了关于灵活的WebSocket的众所周知的解决方案。

它仍然是开源的所以你可以根据需要改变它。

从另一方面，你可能把这个服务器缺乏JavaScript客户端看做是它的缺点（但是它有C#客户端）。这个服务器也有第三方的依赖关系。

在使用这个库工作了几个月之后我没发现什么主要的问题。

缺点和优点:

  • 无备用通信

  • 依赖

  • 优雅的特性和高度可配置性

  • 很棒的例子

  • 例子的都有推荐设置的文档

  • 可以作为windows服务和ASP.NET模块和控制台应用程序运行

  • 好的性能表现

总结

对于复杂的解决方案/项目我建议用SuperWebSocket，因为它是一个稳定而且高度可配置的库。对于简单和需要快速开发的项目我会选择Fleck，但是如果有办法使用最新的windows服务器来作为测试和生产机器的话，我会放弃使用这两个而选择SignalR。