Azure SignalR 服务的计费模型基于连接数和来自服务的出站消息数。 本文介绍消息和连接数目的定义方式，以及它们如何影响计费。
Azure SignalR 服务支持的格式与 ASP.NET Core SignalR 相同：
JSON
和
MessagePack
。
以下限制适用于Azure SignalR 服务消息：
客户端消息：
-
对于长时间轮询或服务器端事件，客户端无法发送大于 1 MB 的消息。
-
服务的 WebSocket 没有大小限制。
-
应用服务器可以为客户端消息大小设置限制。 默认值为 32 KB。 有关详细信息，请参阅
ASP.NET Core SignalR 中的安全注意事项
。
-
对于无服务器，消息大小受上游实现的限制，但建议低于 1 MB。
-
服务器消息：
-
服务器消息大小没有限制，但建议低于 16 MB。
-
应用服务器可以为客户端消息大小设置限制。 默认值为 32 KB。 有关详细信息，请参阅
ASP.NET Core SignalR 中的安全注意事项
。
-
无服务器：
-
Rest API：消息正文为 1 MB，标头为 16 KB。
-
WebSocket、
管理 SDK 持久模式
没有限制，但建议低于 16 MB。
对于 WebSocket 客户端，大型消息将拆分为较小的消息，每个消息不超过 2 KB，并单独传输。 消息拆分与组合由 SDK 进行处理， 无需开发人员的干预。
大消息确实会对消息传送性能造成负面影响。 请尽量使用小消息，并通过测试来为每种使用方案确定最佳消息大小。
消息如何影响计费
发送到服务的消息是入站消息，从服务发送的消息是出站消息。 仅将来自Azure SignalR 服务的出站消息计入计费。 将忽略客户端与服务器之间的 Ping 消息。
大于 2 KB 的消息算作多个大小为 2 KB 的消息。 每当每个中心出现 100 个消息时，Azure 门户中的消息计数图表就会更新。
例如，假设你有 1 个应用程序服务器和 3 个客户端：
-
当应用程序服务器向所有连接的客户端广播 1 KB 的消息时，从应用程序服务器到服务的消息被视为免费入站消息。 从服务发送到每个客户端的三条消息是出站消息，需要付费。
-
当
客户端 A
向
客户端 B
发送 1 KB 入站消息时，无需通过应用服务器，则消息为免费入站消息。 从服务路由到
客户端 B
的消息按出站消息计费。
-
如果你有三个客户端和一个应用程序服务器，当一个客户端向所有客户端发送服务器广播的 4 KB 消息时，计费的消息计数为 8：
-
从服务到应用程序服务器的一条消息。
-
从服务发送到客户端的三条消息。 每条消息算作 2 条 2-KB 大小的消息。
如何统计连接数
Azure SignalR 服务创建应用程序服务器和客户端连接。 默认情况下，每个应用程序服务器启动时每个中心有五个初始连接，每个客户端有一个客户端连接。
例如，假设你有 2 个应用程序服务器，并在代码中定义了 5 个中心。 服务器连接计数为 50： (2 个应用服务器 * 5 个中心 * 每个中心) 5 个连接。
Azure 门户中显示的连接计数包括服务器、客户端、诊断和实时跟踪连接。 连接类型在以下列表中定义：
-
服务器连接
：连接 Azure SignalR 服务和应用服务器。
-
客户端连接
：连接 Azure SignalR 服务和客户端应用。
-
诊断连接
：一种特殊类型的客户端连接，可以生成更详细的日志，这可能会影响性能。 此类客户端旨在进行故障排除。
-
实时跟踪连接
：连接到实时跟踪终结点，并接收 Azure SignalR 服务的实时跟踪。
实时跟踪连接不计为客户端连接或服务器连接。
ASP.NET SignalR 在计算服务器连接数方面有所不同。 除了定义的中心以外，它还包括一个默认的中心。 默认情况下，每个应用程序服务器需要 5 个额外的初始服务器连接。 默认中心的初始连接计数与其他中心保持一致。
服务和应用程序服务器会持续同步连接状态，并调整服务器连接，以获得更好的性能和服务稳定性。 因此，你可能会在正在运行的服务中看到服务器连接数的变化。
-
Azure Monitor 中的聚合类型
-
ASP.NET Core SignalR 配置
-
MessagePack
