☰
bussin logobussin
Open App

Industry Standard Messaging

AMQP 1.0 (Advanced Message Queuing Protocol)

AMQP 1.0 (standardized as ISO/IEC 19464) is an open, binary wire protocol designed for high-performance, secure, and transactional message transfer. Azure Service Bus uses AMQP 1.0 as its primary high-fidelity data-plane protocol.

Launch Protocol Client Workspace Review WebSocket Specs

Core Architecture of AMQP 1.0

Unlike HTTP/1.1 or HTTP/2, which operate on a rigid request-response cycle, AMQP 1.0 is a symmetrical, asynchronous protocol. Connections contain sessions, which in turn contain unidirectional links (senders and receivers) that exchange binary frames. Crucial structural details include:

Binary Framing Efficiency

Payloads and headers are serialized into compact binary streams. This eliminates the text-parsing overhead of JSON or SOAP, saving CPU cycles on message brokers and client engines alike.

Link-Attach and Credits

Flow control is strictly credit-based. A receiver issues a set number of "credits" to the sender. The sender can only transmit frames until its credit allocation is consumed, protecting receivers from buffer overflows.

Symmetric State Settlement

Both client and broker track delivery states (e.g., Accepted, Released, Rejected, or Modified) synchronously. This enables strong transactional guarantees like at-least-once or exactly-once message deliveries.

Direct-to-Browser Encapsulation

Historically, AMQP 1.0 connections ran over raw TCP port 5671 or 5672, which is frequently blocked by restrictive enterprise firewalls. Microsoft solved this by standardizing an AMQP tunnel within the secure WebSocket protocol (running on standard HTTPS port 443):

AMQP WebSocket Handshake

Bussin initializes connections over standard ports using the sub-protocol amqp:

GET wss://<namespace>.servicebus.windows.net:443/$servicebus/websocket HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Protocol: amqp

This allows the browser network stack to establish direct, bi-directional AMQP 1.0 paths without any client-side installs or server-side relays, keeping message pathways completely isolated.

CBS (Claims-Based Security) Authentication

Because AMQP does not natively enforce HTTP authorization headers, it leverages the Claims-Based Security (CBS) specification. Bussin uses MSAL.js to retrieve a standard OAuth 2.0 JSON Web Token (JWT) from Microsoft Entra ID. The Rhea protocol stack then establishes a dedicated AMQP link pointing to the broker's $cbs node:

  1. An AMQP sender link attaches to the $cbs address.
  2. Bussin publishes a CBS message containing the active Entra ID JWT payload to the $cbs endpoint.
  3. The broker validates the token and returns an AMQP response frame indicating authentication success.
  4. Subsequent AMQP links attach to active queues or topics, authenticated under the user's delegated identity.

Why AMQP Exceeds REST in Diagnostics

While REST endpoints are convenient, they lack key enterprise messaging capabilities. The REST interface of Azure Service Bus cannot handle active peek-lock state tracking, lock leases, or target sequence number recoveries. AMQP 1.0 remains the only protocol capable of exposing the complete diagnostic control plane required for enterprise SRE workflows.