一、SignalR和WebSocket
SignalR是在WebSocket的基础上进一步的封装，可以实现除了WebSocket原有功能上更多的功能，例如回退到其他transports，修改应用程序以更新WebSocket implementations。SignalR可以自动判断传输方式，在可以用的情况下使用新的WebSocket传输，并在必要时使用旧的传输。使用SignalR无需担心WebSocket的更新，因为SignalR为应用程序提供跨WebSocket版本的一致接口，并且在持续更新基础传输协议的更改。
二、Transports and fallbacks
SignalR是对在服务器和客户端需要实时工作所需的一些传输的抽象。SignalR连接以HTTP方式启动，如果WebSocket可用，则会将其提升为WebSocket连接。WebSocket是SignalR的理想传输方式，因为它使服务器内存的使用效率最高，延迟最低，并且具有最多的底层功能（例如客户端和服务器之间的全双工通信），但它也具有最严格的要求：WebSocket要求服务器使用Windows Server 2012或Windows 8和.NET Framework 4.5。如果这些要求不符合，SignalR将尝试使用其他传输进行连接。
HTML 5传输
这些传输依赖于对HTML 5的支持。如果客户端浏览器不支持HTML 5标准，则将使用较旧的传输。
- WebSocket（如果服务器和浏览器都表示可以支持WebSocket）。WebSocket是在客户机和服务器之间建立一个真正的永久性双向连接的唯一传输方式。但是，WebSocket也有最严格的要求; 它仅在最新版本的Microsoft Internet Explorer，Google Chrome和Mozilla Firefox中得到完全支持，并且只在其他浏览器（如Opera和Safari）中部分实现。
- Server Sent Events，也称为EventSource（如果浏览器支持Server Sent Events，基本上所有浏览器都是Internet Explorer除外）。
Comet Transports
以下传输基于Comet Web应用程序模型，其中浏览器或其他客户端维护长时间的HTTP请求，服务器可以使用该请求将数据推送到客户端，而无需客户端特别请求。
- Forever Frame（仅适用于Internet Explorer）。Forever Frame创建一个隐藏的IFrame，向服务器上的一个未完成的端点发出请求。然后，服务器不断发送脚本到立即执行的客户端，提供从服务器到客户端的单向实时连接。从客户端到服务器的连接使用从服务器到客户端连接的单独连接，并且像标准HTTP请求一样，为每个需要发送的数据创建一个新的连接。
- Ajax长时间轮询。长轮询不会创建一个持久连接，而是用一个保持打开的请求轮询服务器，直到服务器响应，此时连接关闭，并立即请求一个新的连接。连接重置时，这会产生一定的延迟。
有关在哪些配置下支持哪些传输的更多信息，请参阅支持的平台。
Transport的选择过程
以下列表显示了SignalR用来决定使用哪个传输的步骤。
- 如果浏览器是Internet Explorer 8或更低版本，则使用长轮询。
- 如果配置了JSONP（即连接启动时
JSONP设置为参数true），则使用长轮询。 - 如果正在进行跨域连接（即，如果SignalR端点与宿主页面不在同一个域中），那么如果满足以下条件，将使用WebSocket：
- 客户端支持CORS（跨源资源共享）。有关哪些客户端支持CORS的详细信息，请参阅caniuse.com上的CORS。
- 客户端支持WebSocket
- 该服务器支持WebSocket
- 如果这些标准有一个不符合，将使用长轮询。有关跨域连接的更多信息，请参阅如何建立跨域连接。
- 如果JSONP没有配置，并且连接不是跨域的，如果客户端和服务器都支持，将使用WebSocket。
- 如果客户端或服务器不支持WebSocket，则使用“Server Sent Events”（如果可用）。
- 如果Server Sent Events不可用，则尝试Forever Frame。
- 如果Forever Frame失败，则使用长轮询。