Azure Service Bus HTTP与WebSocket对比及客户端重试机制相关问询

1. Azure Service Bus 是否使用 WebSocket 而非 HTTP 进行通信？ #

Azure Service Bus 支持多种传输协议，不会仅使用 WebSocket 替代 HTTP：

• 官方默认客户端 SDK 优先使用 AMQP 1.0 协议 收发消息，该协议支持两种传输模式：原生 TCP 端口传输，以及基于 WebSocket 的传输（走 443 端口，适配仅开放 HTTPS 端口的防火墙限制场景）
• 平台同时提供完整的 HTTP REST 接口，供不支持 AMQP 协议的场景直接调用完成消息操作。

2. 客户端临时下线时是否具备对应的重试/消息保留机制？ #

对应机制分为服务端和客户端两层：

• 服务端层面：发往 Topic 的消息会持久化存储到每个匹配规则的订阅队列中，只要消息的 过期时间（TTL） 长于客户端下线时长，消息会一直保存在订阅队列中等待消费，不会因客户端临时下线丢失。注意如果使用临时会话订阅，订阅会在客户端断开后自动删除，对应未消费消息也不会保留。
• 客户端层面：官方 SDK 内置默认重试策略，会对网络波动、服务端临时限流等异常场景自动重试，你也可以根据业务需求自定义重试次数、重试间隔、退避策略等参数。持久化订阅的客户端重新上线后，会自动拉取离线期间堆积的消息继续消费，无需额外适配。

内容的提问来源于stack exchange，提问作者VA1267