所以我一直潜入 SignalR 这是一个非常巧妙的技术，已经成为 ASP.NET 系列的一部分。我已经学了几个教程，解释了如何构建一些整洁的实时应用程序，例如股票代码，聊天，仪表板和移动对象。
这些基本教程真正展示了框架背后的一些力量。我正在阅读一些文件，其中显示：
基本上，您有两种选择来连接客户端和服务器。但在我通过所有这些文档发现时，它指出：
SignalR可以使用连接或集线器;通过使用Connection进行绘制，它将使用Web套接字。编码到原始套接字中的是哪种，但它具有高保真和低延迟。但正如我所说，这可能会对Web Socket的支持，直接编码到套接字有缺点。
这是有道理的，但后来他描述了Hub的工作原理。哪个是直接在原始套接字上编码的。这是有趣的部分，Hub将应用以下传输方法：
显然Hub非常整洁。因为它确定了最佳的运输方法，然后实施该方法来实现目标。
我的问题当Hub无论如何都会自动选择最佳传输方式时，为什么还要直接向套接字编码？包括Web Socket？
澄清会很好。我不太明白为什么不使用Hub？为什么要使用Connection？
答案 0 :(得分：3)
Patrick Fletcher在Introduction to SignalR: Connections and Hubs中解释了为什么您可能希望使用Connections over Hubs。在所有其他情况下，您应该使用集线器，因为它们为您提供了许多其他功能。这是他写的：
连接与中心
SignalR API包含两种用于在客户端和服务器之间进行通信的模型：连接和集线器。
Connection表示发送单一收件人，分组或广播邮件的简单端点。 Connection API（由PersistentConnection类在.NET代码中表示）使开发人员可以直接访问SignalR公开的低级通信网络。使用Connections通信模型对于使用基于连接的API（如Windows Communcation Foundation）的开发人员来说很熟悉。
Hub是基于Connection API构建的更高级别的管道，允许您的客户端和服务器直接相互调用方法。 SignalR处理跨机器边界的调度，就好像通过魔术一样，允许客户端像本地方法一样轻松地调用服务器上的方法，反之亦然。如果您的应用程序使用不同类型的消息，建议您使用Hub类，这样您就不必创建自己的调度;使用Hub，您可以在客户端上调用方法，而不是发送需要接收，解释和操作的显式消息。使用远程调用API（如.NET Remoting）的开发人员将熟悉使用Hubs通信模型。
选择沟通模式
大多数应用程序都应使用Hubs API。 Connections API可用于以下情况：
- 需要控制发送的消息格式。
- 开发人员更喜欢使用消息传递和调度模型而不是远程调用模型。
- 正在移植使用消息传递模型的现有应用程序以使用SignalR。