1.什么是SignalR:
ASP.NET SignalR是为简化开发开发人员将实时web内容添加到应用程序过程而提供的类库。实时web功能指的是让服务器代码可以随时主动推送内容给客户端，而不是让服务器等待客户端的请求（才返回内容）。
所有"实时"种类的web功能都可以使用SignalR来添加到你的ASP.NET应用程序中。最常用的例子有聊天室，但我们能做的比这要多得多。考虑以下情况：用户需要不停的刷新网页来看最新的数据；或者在页面上通过实现长轮询来检索新数据（并显示），那你就可以考虑使用SignalR来实现了。比如：仪表板及监视型应用程序；协作型应用程序（如多人同时对文档进行编辑）；作业进度更新及实时呈现表单等。
SignalR也适合新型的，需要从服务器上进行高频率更新的web应用程序，例如实时游戏。这里有一个好例子：ShoorR。
SignalR提供了一个简单的API用户创建服务器到客户端的远程过程调用(RPC)，可以方便地从服务器端的.Net代码中对客户端浏览器及其他客户端平台中的的JS函数进行调用。SignalR还包括了用于管理连接（例如：连接和断开事件）及连接分组。
SignalR可以自动对连接进行管理。并让你发送广播消息到所有已连接的客户端上，就像一个聊天室一样。当然除了群发外，你也可以发送到消息到特定的客户端。客户端和服务器的连接是持久的，不像传统的每次通信都需要重新建立连接的HTTP协议。
SignalR支持“服务器推送”功能，即服务器代码可以通过使用远程过程调用(RPC)来调用浏览器中的客户端代码，而不是当前在web上常用的请求-相应处理模型。
SignalR的应用可以使用服务总线，SQL SERVER或者Redis来扩展到数以千计的客户端上。
SignalR是开源的，可以通过GitHub访问。
2.SignalR 和 WebSocket
ignalR使用WebSocket传输方式——在可能的情况下。并且会自动切换到旧的传输方式（如HTTP长连接）。你当然可以直接使用WebSocket来编写你的应用程序，但使用SignalR意味着你将有更多的额外功能而无需重新发明*。最重要的是，你可以将注意力关注在业务实现上，而无需考虑为旧的客户端单独创建兼容代码。SignalR还能够使你不必担心WebSocket更新，因为SignalR将会持续更新以支持变化的底层传输方式，跨不同版本的WebSocket来为应用程序提供一个一致的访问接口。
当然，你可以创建只使用WebSocket传输的解决方案，SignalR提供了你可能需要自行编写代码的所有功能，比如回退到其他传输方式及针对更新的WebSocket实现来修改你的应用程序。
3.运输和回退
SignalR是对客户端及服务器之间实时功能实现所需要的传输技术的抽象。SignalR首先以HTTP方式开始连接，并检查WebSocket是否可用——如果确定，则升级到WebSocket的连接。WebSocket是SignalR最理想的传输方式，因为它可以最有效地利用服务器的内存，拥有最低的延迟及全面的底层功能（比如客户端和服务器间的全双工通讯），但它也有最严格的要求：服务器必须使用Windows Server 2012或Windows 8操作系统，同时.Net框架版本4.5及以上。如果不符合这些要求，SignalR将尝试采用其他传输方式以进行连接。
4.HTML5运输
使用何种传输方式取决于客户端浏览器是否支持HTML5，否则将使用旧的传输方式。
WebSocket（如果服务器和浏览器都支持WebSocket）。WebSocket是唯一一种在客户端和服务器端建立真实持久的双向连接的传输方式。当然WebSocket也有最严格的要求：仅在最新版的IE，Chrome和FF中支持，其他浏览器如Opera何Safari中都只有部分实现。
服务器发送事件，也称为EventSource（如果浏览器支持服务器发送事件，基本上除了IE以外的浏览器都支持该功能）。
5.Comet传输
下列传输类型都是基于Comet Web应用程序模型的，浏览器或客户端将保持一个HTTP的长连接请求，服务器可以在客户端没有明确请求的情况下将数据推送到客户端。
Forever Frame（仅限于IE）Forever Frame将创建一个隐藏的IFrame，向服务器发送一个不会完成的请求。然后服务器不断地发送脚本到客户端并由客户端立即执行，即建立一个从服务器到客户端的单向的实时连接。而从客户端到服务器的连接则使用不同于该连接的其他连接。比如一个标准的HTML请求，为每次数据的发送都会创建一个新连接。
Ajax长轮询不会创建一个持久性连接，而是通过不断地发出对服务器的请求来进行轮询。在每次连接时等待服务器发出响应并关闭这次连接，然后立即发出新的请求。当然这种方式会在连接复位并重新连接时造成一些延迟。
有关各种配置所支持的传输方式，请参见支持的平台。（IE需要8以上，其他浏览器则是当前版本-1）
传输方式选择过程
以下列表显示SignalR如何决定使用何种类型进行传输。
IE8及更早的版本，使用长轮询。
如果配置了JSONP（即连接时jsonp参数设置为true），使用长轮询。
如果正在使用跨域的连接（即SignalR端点和页面不在同一个域中），则满足以下条件的，使用WebSocket：
客户端支持跨域资源共享（CORS），具体的详细信息请参阅CORS at
客户端支持WebSocket
服务器支持WebSocket
如果以上条件中有任何一条不满足，则使用长轮询。跨域连接的详细信息，请参阅如何建立跨域连接。
如果没有配置使用JSONP和连接不跨域，使用WebSocket，当然前提是客户端和服务器都支持WebSocket。
如果客户端或服务器不支持WebSocket，使用服务器发送事件。
如果服务器发送事件不可用，使用Forever Frame。
如果Forever Frame不可用，使用长轮询。
监控传输
你可以通过启用Hub日志记录，并在浏览器的控制台中查看应用程序使用何种传输方式。
要启用日志记录，添加以下命令到客户端应用程序：
nnection.hub.logging = true;
6.检测运输：
你可以通过启用Hub日志记录，并在浏览器的控制台中查看应用程序使用何种传输方式。要启用日志记录，添加以下命令到客户端应用程序：
nnection.hub.logging = true;
$.connection.hub.logging = true;
在IE中，按F12打开开发人员工具，单击控制台选项卡。
在Chrome中，按Ctrl+Shift+J打开控制台
通过观察控制台中的日志记录，你就能看到SignalR正在使用的传输方式。
7.指定运输：
协商传输方式需要使用一定的时间及服务器/客户单的资源。如果客户端环境已知，那么可以在启动连接时指定传输方式来提高性能。下面的代码演示如果已知的客户端不支持任何其他协议时，直接在连接启动时就使用Ajax的长轮询：
connection.start({ transport: 'longPolling' });
如果你想要一个客户端按照特定的顺序进行传输方式的协商，你可以指定尝试协商的顺序。下面的代码演示如何首先尝试使用WebSocket并在失败后直接使用长轮询。
connection.start({ transport: ['webSockets','longPolling'] });
用户指定传输的字符串常量定义如下：
webSockets
forverFrame
serverSentEvents
longPolling
8.连接和Hubs
SignalR API中包含两中客户端-服务器进行通信的模型：永久连接和集线器(Hubs)。
连接表示一个发送单个、分组或广播消息的简单终结点。持久性连接API(在.NET 代码中由 PersistentConnection 类表示)可以让开发人员直接访问SignalR的底层通信协议。使用过基于连接API如WCF的开发人员将更熟悉连接通信模型。
集线器是基于API但级别更高一级的通信管道，它允许客户端和服务器上互相直接调用方法。SignalR能够奇妙的处理跨机器的调度，让客户端轻松的调用服务器上的方法，如同调用本地方法一样，反之亦然。使用过基于远程调用的AIP如.Net Remoting的开发人员将更熟悉集线器模型。使用集线器，你还可以将强类型的参数传递给方法并且对模型绑定。
体系结构关系图：下面的关系图显示集线器、 持续连接和用于传输的基础技术之间的关系.
9.集线器是如何进行工作的：
当服务器代码调用客户端时，服务器将发送一个包含调用方法及参数（当对象作为方法参数时，将被序列化为JSON来发送）的数据包主动推送给客户端。然后客户端检查接收到的方法名称，并在客户端定义方法中进行匹配查找，如果匹配成功，则执行方法并使用反序列化的对象作为方法参数。
你可以使用Fiddler之类的工具来监视方法的调用执行。下图显示了在Fiddler的日志中抓取到的一个从SignalR服务器发送到Web浏览器客户端的方法。从集线器发起调用的方法为MoveShapeHub，被调用的方法为updateShape。
在这个例子中，集线器的名称使用参数"H"标识，方法名称使用参数"M"标识，发送给方法的参数对象使用参数"A"标识。生成该消息的应用程序是在高频实时通讯教程中实现的。
选择通信模型：
大多数应用程序使用集线器的API，该连接的API可以在以下情况下使用：
需要指定发送消息的格式。
开发人员更喜欢使用消息传递和调度模型，而不是一个远程调用模型
现有的应用程序中正在使用消息传递模型，计划移植到SignalR上。