WebAPI进阶知识学习（2） - 文章 - 伯乐在线
& WebAPI进阶知识学习（2）
这部分内容的学习，已经放了大半年时间了，果断补充上，尽早将过去遗留的老技术坑都补上。首先将介绍服务幂等性的概念和相关解决方案，这部分也将是本文的理解难点，由于WebAPI是一种Restful风格服务的实现方式，其遵循HTTP标准方法，因此理解好这部分概念，对于提供良好的业务服务显得非常重要。之后则将介绍SignalR这一长连接通讯的集成解决方案的概念和实践，这部分在交互式的Web场景中非常有效。最后将补充Owin、IOC、EnterpriseLibrary等相关知识，这些也都是.NET程序员比较容易忽视的知识点，这些知识在快速搭建Solution上有很大的帮助。
最早接触这个概念还是在一次面试的过程中，当时记得自己只能是通过卖萌将这一概念一笔带过，由于当时的项目实践相对较少，且被微软便捷的服务搭建所欺骗，以为搭建一个webService只用在IDE中添加有一个.asmx就万事大吉了，其他项目通过一个服务引用就算是SOA实现了（WCF额外需要配置一下终结点），其实对于整个服务的概念完全是个门外汉。
那么在实际中，搭建一个服务需要注意那些问题呢？接下来通过一个简单的表格来描述。
通讯协议的选取
例如常见的TCP、HTTP、SOAP等，实际上任何协议都可以作为服务的载体，只要适合相应的场景即可
服务的地址，服务的消费者可以通过这个地址请求服务
只有通过认证的请求才能获得服务，不同的服务方法需要不同权限控制
对于同一个服务方法来说，相同的请求参数无论请求几次，都将获得相同的结果（简化版的解释，不太完备）
与服务相关的概念非常多，比如：在架构层次流行的微服务，用于解耦应用；服务的监控、限流；分布式服务的治理、扩容等。
接下来将详细介绍服务幂等性的概念，相关解决方案和基于HTTP协议的服务幂等性等知识。
基础概念：从抽象代数的角度，幂等Idempotence就是f(f(x)) = f(x)。也就是说对同一个服务的1次或多次调用，返回的结果相同，且对服务系统的影响相同，接下来通过一个非常简单的图来描述该概念在服务请求场景下的意义。
在上图中，第一次扣款请求成功，但返回丢失，这是Client重发扣款请求，之后成功。在这样的场景下，如果不控制服务的幂等性，就会出现重复扣款的情况出现。
解决方案：上例标准的解决方案是，客户端的这个操作需要两个请求，首先需要向服务端申请一个ticket进行扣款操作，之后将该ticket作为参数的一部分发送给Server请求扣款。服务端首先检验该ticket是否已经被使用，若被使用，直接返回成功；若未被使用，则进行相应扣款操作。逻辑上很简单，不过在实践时有几点需要注意：
幂等的时效性
在实际项目中，幂等是具有时效性的，不同的业务需求会有不同的时效性要求。一般来说，对于重要业务操作，通过是与Money有关的操作，要求持久的服务幂等性，这是就需要选用数据库来实现幂等控制，将ticket（流水号，GUID等）保存起来，其特点是安全、低效；对于一般的数据，可以选用缓存来控制，其特点是高效、不稳定。
数据库实现幂等
比如SQL SERVER, 在Read Committed隔离级别下，，建立一张专门的幂等表，通过重复insert的异常来实现幂等，比较规范；也可以通过NoLock读的方式，更搞笑，但存在隐患，推荐前者。Tip:通过SqlException, Number = 2601
缓存实现幂等
比如Redis，通过与key相关的操作，Exists Key
CRUD操作的幂等级别
SELECT最高，为只读级别；UPDATE、DELETE次之，为幂等级别；INSERT为不能幂等级别。也就是说，SELECT操作不管是一次操作还是多次操作，均不改变目标的状态；UPDATE、DELETE只在第一次调用时会改变状态，之后不会；而INSERT则每次均改变状态。
之前一直有个疑惑，就是关于UPDATE操作，比如a++的情况下，这个操作不是幂等的，但实际上，这不是一个原子操作，其涉及一次查询和一次修改，在很多语言中，都支持称为CAS(CompareAndSet)的原子操作。
Ticket的生成
根据不同的场景，可以是客户端生成，也可以是服务端生成，当然，最好的方案是设置好指定规则，然后由客户端生成ticket，比如GUID组合客户端的标识的方式，因为这样可以减少服务端的压力，无论是CPU还是网络。
基于HTTP协议的服务幂等性：在之前的表格中，已介绍过CRUD操作所对应的幂等级别，那么对应到HTTP的操作呢？很简单，GET表示查询操作，PUT和DELETE表示更新和删除操作，POST表示插入操作，因此POST操作需要添加幂等控制的。当然了，在WebAPI的实际设计中，接口的URL格式和http报文中Body的参数值会需要进一步的思考。
此外，大家也可以查阅博主Todd Wei的博文http的幂等性
SignalR这个名字，咋一看还挺高大上的，实际上和WCF、AJAX类似，并不是什么新技术，而是对已有技术的一种整合，集成了客户端和服务端的库。不知道大家还记不记的，大学时学习的Windows网络编程，当时通过WinSocket搭建了一个聊天室，其实这里的SignalR也一样，最常见的应用仍然是聊天室场景，不过变成浏览器和服务器之间，而不是过去的Client与服务器之间。那么它与H5的WebSocket有什么区别么？准确来说，SignalR整合了WebSocket，在浏览器支持H5的情况下就使用WebSocket，若不支持，就通过长轮训的方式，算是一种兼容性的整体解决方案。
简单来说，记住一点就好，SignalR支持双向通信的长连接，其是对http请求-响应模式的有力补充。其提供一个简单的API用于创建服务端到客户端的远程过程调用(RPC),以便从服务器端.NET代码中调用客户端浏览器中的js代码。
SignalR的API包含两种客户端和服务器之间进行通信的模型：永久连接和Hubs。。接下来通过来通过一段代码，走进SignalR的世界。
ViewBag.Title = "Chat";
&h2&Chat&/h2&
&div class="container"&
&input type="text" id="message" /&
&input type="button" id="sendmessage" value="Send" /&
&input type="hidden" id="displayname" /&
&ul id="discussion"&&/ul&
&a href="/members/SECTION"&@section&/a& scripts{
&script src="~/Scripts/jquery.signalR-2.2.0.min.js"&&/script&
&script src="~/signalr/hubs"&&/script&
$(function () {
//reference the auto-generated proxy for the hub
var chat = $.connection.chatH
chat.client.addNewMessageToPage = function (name, message) {
//add the message to the page
$('#discussion').append('&li&&strong&' + htmlEncode(name) + '&/strong&: ' + htmlEncode(message) + '&/li&');
//get the user name and store it to prepend to messages.
$('#displayname').val(prompt('Enter your name:', ''));
//set initial focus to message input box
$('#message').focus();
//start the connection
$.connection.hub.start().done(function () {
$('#sendmessage').click(function () {
chat.server.send($('#displayname').val(), $('#message').val());
$('#message').val('').focus();
//this optional function html-encodes messages for display in the page
function htmlEncode(value) {
var encodedValue = $('&div/&').text(value).html();
return encodedV
Startup文件
[assembly: OwinStartup(typeof(Sory.Framework.SignalRDemo.Startup))]
namespace Sory.Framework.SignalRDemo
public class Startup
public void Configuration(IAppBuilder app)
//Any connection or hub wire up and configuration should go here
app.MapSignalR();
public class ChatHub : Hub
public void Send(string name, string message)
Clients.All.addNewMessageToPage(name, message);
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566
前端页面@{ViewBag.Title = "Chat";}&&h2&Chat&/h2&&div class="container"&&input type="text" id="message" /&&input type="button" id="sendmessage" value="Send" /&&input type="hidden" id="displayname" /&&ul id="discussion"&&/ul&&/div&&a href="/members/SECTION"&@section&/a& scripts{&script src="~/Scripts/jquery.signalR-2.2.0.min.js"&&/script&&script src="~/signalr/hubs"&&/script&&script&$(function () {//reference the auto-generated proxy for the hubvar chat = $.connection.chatHub;chat.client.addNewMessageToPage = function (name, message) {//add the message to the page$('#discussion').append('&li&&strong&' + htmlEncode(name) + '&/strong&: ' + htmlEncode(message) + '&/li&');};//get the user name and store it to prepend to messages.$('#displayname').val(prompt('Enter your name:', ''));//set initial focus to message input box$('#message').focus();//start the connection$.connection.hub.start().done(function () {$('#sendmessage').click(function () {chat.server.send($('#displayname').val(), $('#message').val());$('#message').val('').focus();});});});&//this optional function html-encodes messages for display in the pagefunction htmlEncode(value) {var encodedValue = $('&div/&').text(value).html();return encodedValue;}&/script&}&Startup文件[assembly: OwinStartup(typeof(Sory.Framework.SignalRDemo.Startup))]namespace Sory.Framework.SignalRDemo{public class Startup{public void Configuration(IAppBuilder app){//Any connection or hub wire up and configuration should go hereapp.MapSignalR();}}}&Hub文件public class ChatHub : Hub{public void Send(string name, string message){Clients.All.addNewMessageToPage(name, message);}}
相关学习可以参见张善友大神的4年前的博文SingalR QuickStart,
另外还有博主的博文/vance/p/SignalR.html，相对版本更新一些，此外其翻译的Signal入门非常的赞，必须顶
简单来说，类似J2EE中javaWeb的相关标准（servlet），之后各种不同的容器厂商均可以针对该接口提供自己的实现，比如Tomcat、Weblogic等。随着微软慢慢走向开发，也提出了相应的接口标准，这个标准就是Owin，我们常见的IIS其实就是该标准的一个官方实现。记得身边的一位大牛说过，JAVA就是先自己开发，其他的厂商也模仿着开发，之后为了统一就建立标准，之后的版本大家都按照这个标准来，类似于实践推导出理论，理论再来指导实践的过程。
在Owin中，将不再使用ASP.NET管道处理请求，而是使用Owin管道来处理请求，其通过一个Dictionary来传递上下文信息，其信息如下表所示。
Owin.RequestBody
Http请求体
Owin.RequestHeaders
IDictionary
Http请求头
Owin.RequestMethod
请求方法, get, post等
Owin.RequestPathBase
Owin.RequestPath
URL路径，根后面的部分
Owin.RequestProtocol
协议名称和版本, http/1.1
Owin.RequestQueryString
查询字符串
Owin.RequestSchema
http或者https
Owin接口微软的官方实现叫做Katana（武士刀）的组件包括：Application, Middleware, Server和Host。在vs2013中的MVC5模板中，添加如下DLL，和在nuget中package添加如下配置。
"Owin" version="1.0" targetFramework="net451"/&
"Microsoft.Owin" version="2.0.0" targetFramework="net451"/&
"Microsoft.Owin.Host.SystemWeb" version="1.0" targetFramework="net451"/&
"Microsoft.Owin.Security" version="1.0" targetFramework="net451"/&
"Microsoft.Owin.Security.Cookies" version="1.0" targetFramework="net451"/&
"Owin" version="1.0" targetFramework="net451"/& "Microsoft.Owin" version="2.0.0" targetFramework="net451"/& "Microsoft.Owin.Host.SystemWeb" version="1.0" targetFramework="net451"/& "Microsoft.Owin.Security" version="1.0" targetFramework="net451"/& "Microsoft.Owin.Security.Cookies" version="1.0" targetFramework="net451"/&
需要提及的是，其通过一个称为claims-based认证方式进行用户的认证，与原有Form认证方式有一定区别，简单来讲，类似于windows的token认证（单登SSO）。
详细信息，可以参考Jesse博主的博文/jesse2013/p/aspnet-identity-claims-based-authentication-and-owin.html#what-is-owin
IOC框架用于解耦系统不同层次间的依赖关系，便于系统的扩展。当然其也会在一定程度上增加系统的复杂性，影响系统的效率，那么选择一个高效可靠IOC显得非常重要。IOC控制反转的相关组件非常的多，包括微软的Unity，第三方的Autofac,CastleWindsor, Spring.NET, StructureMap, Ninject等，其中Unity表现的中规中矩，在大量迭代情况下（&1000000），Autofac和StructureMap效率最高。就我个人而言，由于公司的组件库支持Unity,那么就不用选了，哈哈。
详情请见Leepy大神的博文：/liping/archive//2108734.html
微软的企业库包含的模块非常多，比如缓存、数据存取、日志、IOC、AOP、异常处理等，由于现代企业往往都提供统一的日志管理系统和DAL系统，因此微软企业库仍然有价值的部分为AOP和IOC等部分，其实都是面向切面的应用（我们常用的WCF、MVC、WebAPI项目由于拦截器的存在，已经实现了AOP），当然在一部分做的最好的应该是Spring。
接下来通过一个示例，来对AOP的应用，有一个基本的了解（通过Unity的Interception扩展）。
&configuration&
&configSections&
&section name="unityInterception" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/&
&/configSections&
&unityInterception&
&sectionExtension type="Microsoft.Practices.Unity.InterceptionExtension.Configuration.InterceptionConfigurationExtension
, Microsoft.Practices.Unity.InterceptionExtension.Configuration"&
&sectionExtension type="Microsoft.Practices.Unity.InterceptionExtension.Configuration.InterceptionConfigurationExtension
, Microsoft.Practices.Unity.Interception.Configuration" /&
&container&
&extension type="Interception"/&
&register type="LipinInvoice.BL.AOPDemo, LipinInvoice.BL"&
&interceptor type="TransparentProxyInterceptor" /&
&policyInjection /&
&/register&
&/container&
&/sectionExtension&
&/unityInterception&
&/configuration&
public class ExceptionHandler : ICallHandler
public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
IMethodReturn methodReturn = getNext()(input, getNext);
public int Order { }
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Interface | AttributeTargets.Class)]
public class ExceptionHandlerAttribute : HandlerAttribute
public override ICallHandler CreateHandler(IUnityContainer container)
return new ExceptionHandler() { Order = this.Order };
12345678910111213141516171819202122232425262728293031323334353637383940
配置：&configuration&&configSections&&section name="unityInterception" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/&&/configSections&&unityInterception&&sectionExtension type="Microsoft.Practices.Unity.InterceptionExtension.Configuration.InterceptionConfigurationExtension, Microsoft.Practices.Unity.InterceptionExtension.Configuration"&&sectionExtension type="Microsoft.Practices.Unity.InterceptionExtension.Configuration.InterceptionConfigurationExtension, Microsoft.Practices.Unity.Interception.Configuration" /&&container&&extension type="Interception"/&&register type="LipinInvoice.BL.AOPDemo, LipinInvoice.BL"&&interceptor type="TransparentProxyInterceptor" /&&policyInjection /&&/register&&/container&&/sectionExtension&&/unityInterception&&/configuration&&拦截类public class ExceptionHandler : ICallHandler{public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext){IMethodReturn methodReturn = getNext()(input, getNext);return null;}public int Order { get; set; }}&[AttributeUsage(AttributeTargets.Method | AttributeTargets.Interface | AttributeTargets.Class)]public class ExceptionHandlerAttribute : HandlerAttribute{public override ICallHandler CreateHandler(IUnityContainer container){return new ExceptionHandler() { Order = this.Order };}}
EL6.0官方文档：/files/wanliwang01/EL5.0.pdf
EL5.0的详细配置，可以参考博主黄聪的系列教程：
还可以参考仓储大叔的博文：/lori/p/4088889.html
WebAPI学习系列目录如下，欢迎您的阅读！
参考资料：
蒋金楠. ASP.NET Web API 2框架揭秘[M]. 北京:电子工业出版社, 2014.
（美）加洛韦. ASP.NET MVC 5高级编程(第5版)[M]. 北京:清华大学出版社, 2015.
可能感兴趣的话题
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量，把优秀的原创文章和译文分享给读者，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2016 伯乐在线标签： WebSocket SignalR
最近因为项目中涉及到了实时数据的传输，特地去了解了一下当前Web应用中常见的实时交互手段，当然一开始也不仅限于Web客户端。从c#自带的Socket类，到Html5中的WebSocket，再到Asp .Net利器SignalR，总算将这块知识点及应用入门了，当然今天的主要内容还是Web端的消息交互技术(Ajax,Comet,WebSocket等)，这些技术难度有中有低，应用场所也有不同，最后我们要根据项目情况来选择恰当的技术。接下来便简单介绍一下
1. Web消息交互技术
1.1 常见技术
应用技术 说明 优缺点
轮询（polling）
这应该是最常见的一种实现数据交互的方式，开发人员控制客户端以一定时间间隔中向服务器发送Ajax查询请求大，但是也因此，当服务器端内容并没有显著变化时，这种连接方式将带来很多无效的请求，造成服务器资源损耗。适合并发量小，实时性要求低的应用模型，更像是定时任务。
优点：实现最为简单，配置简单，出错几率小
缺点：每次都是一次完整的http请求，易延迟，有效请求命中率少，并发较大时，服务器资源损耗大
长轮询（long polling）
长轮询是对轮询的改进，客户端通过请求连接到服务器，并保持一段时间的连接状态，直到消息更新或超时才返回Response并中止连接，可以有效减少无效请求的次数。属于Comet实现
优点：有效减少无效连接，实时性较高
缺点：客户端和服务器端保持连接造成资源浪费，服务器端信息更新频繁时，long polling并不比polling高效，并且当数据量很大时，会造成连续的polls不断产生，性能上反而更糟糕
iframe流方式是在页面中插入一个隐藏的iframe，利用其src属性在服务器和客户端之间创建一条长链接，服务器向iframe传输数据（通常是HTML，内有负责插入信息的javascript），来实时更新页面。属于Comet实现
优点：实时性高，浏览器兼容度好
缺点：客户端和服务器端保持长连接造成资源浪费
WebSocket是HTML5提供的一种在单个 TCP 连接上进行全双工通讯的协议，目前chrome、Firefox、Opera、Safari等主流版本均支持，Internet Explorer从10开始支持。另外因为WebSocket 提供浏览器一个原生的 socket实现，所以直接解決了 Comet 架构很容易出错的问题，而在整個架构的复杂度上也比传统的实现简单得多。
优点：服务器与客户端之间交换的数据包档头很小，节约带宽。全双工通信，服务器可以主动传送数据给客户端。
缺点：旧版浏览器不支持
Tips：浏览器和客户端之间想要进行WebSocket通信的话，从一开始的握手阶段，就要从HTTP协议升级为WebSocket协议，这是服务器根据WebSocket发送的请求包决定的。关于WebSocket的具体介绍（规范和语法和状态转换）可以参考.
1.2 WebSocket介绍
WebSocket本质上是一个基于TCP的持久化协议，相对于HTTP这种非持久的协议来说，它能够更好的节省服务器资源和带宽，并且真正实现实时通信。以下是它与传统技术的性能对比图（Websocket.org提供）
我们可以看到相比于传统技术，在流量和负载逐渐增大时，WebSocket的性能表现是远远超过它们的。
上文提到WebSocket在实际运用时是在握手阶段从http请求升级上来的，让我们来看一个Websocket请求的例子——这里借用下维基百科的内容
1.客户端到服务器端
GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Origin: null
Sec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ==
Sec-WebSocket-Version: 13
2.服务器端到客户端
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s=
Sec-WebSocket-Origin: null
Sec-WebSocket-Location: ws:///
注意“1.”中的UpGrade:websocket和Connection: Upgrade这两个核心属性表示本次是一个特殊的http请求，目的就是要将浏览器端和服务器端的通讯协议从HTTP协议—升级—&WebSocket协议，其他属性都是客户端向服务器端提供的握手信息。
Sec-WebSocket-Version: 13代表这是13版修订协议，Sec-WebSocket-Key是随机生成的，服务器端会把Sec-WebSocket-Key加上一个魔幻字符串“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”。使用SHA-1加密，之后进行BASE-64编码，将结果做为Sec-WebSocket-Accept头的值，返回给客户端，表明服务器端同意创建Websocket请求。
1.3 WebSocket示例
以下用控制台和WebSocket简单实现下服务器和客户端的全双工通信，其中后台使用了技术
后台示例代码：
using SuperSocket.SocketB
using SuperWebS
using static System.C
namespace SuperWebSocketDemo
class Program
private static void Main(string[] args)
var server = new WebSocketServer();
server.NewSessionConnected += ServerNewSessionC
server.NewMessageReceived += ServerNewMessageR
server.SessionClosed += ServerSessionC
server.Setup(&127.0.0.1&, 4141);
server.Start();
catch (Exception ex)
WriteLine(ex.Message);
ReadKey();
private static void ServerSessionClosed(WebSocketSession session, CloseReason value)
WriteLine(session.Origin);
public static void ServerNewMessageRecevied(WebSocketSession session, string value)
WriteLine(value);
session.Send(&已收到：&+value);
/// &param name=&session&&&/param&
public static void ServerNewSessionConnected(WebSocketSession session)
WriteLine(session.Origin);
前台示例代码，通过websocket的api我们可以很容易实现主要逻辑
&!DOCTYPE html&
&html lang=&en& xmlns=&http://www.w3.org/1999/xhtml&&
&meta charset=&utf-8&/&
&title&&/title&
&input type=&button& id=&send& onclick=&send()& value=&发送&&
&input type=&text& id=&message&&
&script type=&text/javascript&&
//WebSocket的四个主要方法open onclose onerror send
wsClient=new WebSocket( 'ws://localhost:4141');
wsClient.open=function(e){
console.log(&Connected!&);
wsClient.onclose=function(e){
console.log(&Disconnected!&);
wsClient.onmessage=function(e){
console.log(&接收消息:&+e.data);
wsClient.onerror=function(e){
console.log(e.data);
function send(){
oText=document.getElementById(&message&);
wsClient.send(oText.value);
最终结果如下图：
关于Web实时技术和WebSocket的介绍便到这里了，我们甚至可以用c#自己实现一个WebSocket的服务器，详情请看《》以及用c#实现的一个简单的WebSocket服务器《C# socket编程实践》，当然还是推荐。当然这篇只是简单的介绍而已，我自己的WebSocket实现（结合规范实现）也会在之后的博客中贴出。
假如还写得动……
至此，数种常见的Web实时交互技术已经总览一遍了，对于Asp Web开发者来说，.Net平台为我们提供了一种简洁高效智能的实时信息交互技术——SignalR，它集成了上述数种技术，并能根据配置自动或者手动选择最佳应用。
2.1 SignalR是什么
SignalR是一个.Net开源库，用于构建需要实时进行用户交互和数据更新的Web应用，如在线聊天，游戏，天气或者股票信息更新等实时应用程序。SignalR简化了构建实时应用的过程，它包括了一个Asp .Net服务器端库和一个Js端库，集成了数种常见的消息传输方式，如long polling，WebSocket，并提供相应的Api供开发人员选择如何调用，帮助其可以简单快速地实现客户端与服务器端相互间的实时通信。
当环境条件合适时，SignalR将WebSocket作为底层传输方式的优先实现，当然，它也能很高效地回退到其他技术。同时，SignalR提供了非常良好的Api以供远程调用(RPC) 浏览器中的js代码。
接下来，看看SignalR的传输方式和通信模型，这是SignalR的核心所在。
SignalR基本适用于任何可以用上述技术实现的场合，但是对寄宿平台版本有要求。如.Net Framework 平台，SignalR库需要4.5及以上版本的支持，而Mono上也实现了SignalR。如果是最新的.Net Core 1.0，建议大家直接使用SelfHost方式寄宿。
2.2 默认传输方式
传输方式 选择条件
long polling
1.IE8或更早版本
2.连接启动时JSONP参数设置为TRUE
3.Forever Frame不可用
1.正在使用跨域连接，并且符合以下条件（以下不满足任一条则使用长轮询）
（1）.客户端支持CORS
（2）.客户端支持WebSocket
（3）.服务器端支持WebSocket
2.不配置使用JSONP，连接不跨域并且客户端和服务器端都支持WebSocket
（1）.客户端支持CORS
（2）.客户端支持WebSocket
（3）.服务器端支持WebSocket
ServerSendEvent
客户端或服务器端不支持Websocket
Forever Frame
EventSource不可用（基本上除了IE外都支持）
2.3 指定传输方式
如果开发人员想要让客户端按照特定的方式和顺序进行数据传输，可以通过使用$.connection.start({transport:['webSockets','foeverFrame',……]})，当客户端和服务器端并不支持指定方式时，程序将按照默认规则匹配传输方式。
用于指定传输方式的字符串常量定义如下：
webSockets
foeverFrame
serverSentEvents
longPolling
2.4 自动管理传输方式
不指定传输方式时，SignalR会以Http方式发起请求，比对客户端和服务器端后，假如WebSocket可用，则自动升级到WebSocket模式，WebSocket是最理想的传输方式，除了能高效使用服务器内存，低延迟，还能实现客户端和服务器端的全双工通信。开发人员可以通过SignalR中js库的$.connection.chatHub.logging =来启用hub事件的日志记录
2.5 通信模型
SignalR包括两种客户端和服务器端之间进行通信的模型，Persistent Connections和Hubs。
通信模型 说明
Persistent Connections
Persistent Connections表示一个发送单个，编组，广播信息的简单终结点。开发人员通过使用持久性连接Api，直接访问SignalR公开的底层通信协议。
Hubs是基于连接Api的更高级别的通信管道，它允许客户端和服务器上彼此直接调用方法，SignalR能够很神奇地处理跨机器的调度，使得客户端和服务器端能够轻松调用在对方端上的方法。使用Hub还允许开发人员将强类型的参数传递给方法并且绑定模型
2.6 SignalR示例（永久连接和Hubs(略)）
Hubs的示例网上已经很多了（文章末尾附上链接），这边先来快速开始一个SignalR使用永久连接的Demo.
关于永久连接和Hubs的区别，有些很棒的解释.
（1）安装Nuget包
创建一个默认的Asp .Net Mvc项目
使用Install-Package Microsoft.AspNet.SignalR安装SignalR包
（2）增加SignalR服务
新增Connections文件夹，添加SignalR永久连接类ChatConnections
using System.Threading.T
using Microsoft.AspNet.SignalR;
namespace SignalRUsingPersistentConnectionsDemo.Connections
public class ChatConnection : PersistentConnection
protected override Task OnConnected(IRequest request, string connectionId)
return Connection.Send(connectionId, &Welcome!&);
protected override Task OnReceived(IRequest request, string connectionId, string data)
return Connection.Broadcast(data);
（3）增加Startup启动类
using Microsoft.O
using SignalRUsingPersistentConnectionsD
using SignalRUsingPersistentConnectionsDemo.C
[assembly: OwinStartup(typeof (Startup))]
namespace SignalRUsingPersistentConnectionsDemo
public class Startup
public void Configuration(IAppBuilder app)
// 有关如何配置应用程序的详细信息，请访问 /fwlink/?LinkID=316888
// 配置上文实现的ChatConnections
app.MapSignalR&ChatConnection&(&/Connections/ChatConnection&);
（4）前端js配置
前端js实现消息广播，并实时记录
&script src=&~/Scripts/jquery-1.10.2.min.js&&&/script&
&script src=&~/Scripts/jquery.signalR-2.2.0.min.js&&&/script&
&script type=&text/javascript&&
$(function () {
var connection = $.connection(&/Connections/ChatConnection&);
$('#displayname').val(prompt('Enter your name:', ''));
$(&msg&).focus();
connection.received(function (data) {
$('#messages').append('&li&' + data + '&/li&');
connection.start().done(function() {
$(&#broadcast&).click(function () {
connection.send($('#displayname').val()+'：'+$('#msg').val());
&input type=&text& id=&msg& /&
&input type=&button& id=&broadcast& value=&broadcast&/&
&input type=&hidden& id=&displayname& /&
&ul id=&messages&&&/ul&
（5）实际效果
（6）.Net Client实现
除了Web实时应用之外，你也可以用其他应用程序实现实时交互，如控制台。只需要Install-Package Microsoft.AspNet.SignalR.Client命令，示例编码如下
using Microsoft.AspNet.SignalR.C
using static System.C
namespace DotnetClientWithSignalRDemo
internal class Program
private static void Main(string[] args)
var connection = new Connection(&http://localhost:1508/Connections/ChatConnection&);
connection.Received += WriteL
connection.Start().Wait();
while ((line = ReadLine()) != null)
connection.Send(line).Wait();
效果如图,同样实现了双向通信
至此，常见的Web实时交互技术和SignalR简单介绍就告一段落了，具体的进阶使用我可能会在后续博文贴出，如Hubs通信模型解析，分组连接信息传输等，不过建议大家直接去阅读SignalR官方文档，查阅相关的Api就可以了，我相信普通技术的运用相对于理解还是要方便的。
这里额外推荐一篇SignalR的深入解读,这个博主也深入介绍了SignalR的自动选择和传输机制，也是一篇很棒的文章。
4. 参考资料
C# socket编程实践}