Port 5672: AMQP — The Protocol That Freed Enterprise Messaging

Port 5672 is the default port for the Advanced Message Queuing Protocol (AMQP). When your applications need to send messages reliably, when your microservices need to communicate without waiting, when your systems need to queue work for later, this is the port that carries those promises.

What AMQP Does

AMQP is a wire-level protocol for message-oriented middleware.¹ That means it defines exactly how bytes flow across the network, not just what methods to call. When a producer sends a message and a consumer receives it, AMQP specifies every frame, every field, every handshake.

The protocol operates on a model of exchanges, queues, and bindings:²

• Exchanges receive messages from producers. They're like post offices that sort incoming mail.
• Queues store messages until consumers retrieve them. They're the mailboxes.
• Bindings are the rules that connect exchanges to queues. They define which messages go where.

A message enters an exchange, the exchange evaluates its routing key against the bindings, and the message lands in zero or more queues. Consumers subscribe to queues and pull messages when ready. This decoupling is the core insight: producers don't need to know who will consume their messages, and consumers don't need to know who sent them.

The History: Breaking Free from Vendor Lock-In

In 2003, John O'Hara sat in the JPMorgan Chase offices in London with a problem.³ The bank's messaging infrastructure ran on proprietary middleware, primarily IBM MQ and TIBCO Rendezvous. These systems worked, but they came with crippling constraints.

The economics were brutal. IBM MQ charged around $25,000 per CPU in 2000.⁴ But worse than the cost was the lock-in. MQ couldn't talk to TIBCO. TIBCO couldn't talk to MQ. Each vendor's protocol was a walled garden. If you wanted to integrate with a partner bank, you either convinced them to buy the same vendor, built expensive bridges, or watched your integration projects die in committee.

O'Hara had specific requirements: high durability, extreme volume (500,000 messages per second), and interoperability.⁵ In financial trading, a lost message isn't an inconvenience. It's a regulatory violation. It's millions of dollars. It's someone's career.

He decided to build something new. Not a product, but a specification. An open protocol that anyone could implement, that any vendor could support, that would let applications from different vendors finally speak the same language.

From 2004 to 2006, JPMorgan Chase designed the initial protocol, contracting with iMatix Corporation to build the first implementation.⁶ Pieter Hintjens of iMatix became the main designer of AMQP 0.8 and editor of the de-facto standard AMQP 0.9.1.⁷ The implementation was called OpenAMQ, and by 2006, JPMorgan had migrated their largest trading application to it.

In 2005, the effort expanded. JPMorgan approached Cisco, Red Hat, IONA Technologies, and others to form a working group.⁸ The group eventually grew to 23 companies, including Bank of America, Barclays, Goldman Sachs, Credit Suisse, Deutsche Börse, and Microsoft.

The first public specification, AMQP 0.8, was released in June 2006. Version 0.9.1 followed in November 2008 and became the most widely deployed version, largely thanks to RabbitMQ.

RabbitMQ: The Implementation That Won

In 2007, a joint venture between LShift and CohesiveFT called Rabbit Technologies created RabbitMQ.⁹ They chose to write it in Erlang, a language designed by Ericsson for building telephone switches.

This choice was inspired. Erlang was built for telecom, where calls must not be dropped and systems must not go down. The language has built-in support for concurrency, distribution, and fault tolerance.¹⁰ It handles thousands of simultaneous connections gracefully. The AMQP domain maps almost directly onto Erlang's process model: each connection, channel, and queue becomes an independent lightweight process.

The result was a compact, readable codebase. The AMQP codec, handling all 87 protocol methods, fit in just 1,150 lines of code.¹¹

RabbitMQ was acquired by SpringSource (a division of VMware) in 2010, transferred to Pivotal Software in 2013, and returned to VMware in 2019 when VMware acquired Pivotal.¹² Today it's part of VMware Tanzu, and it remains the most popular AMQP implementation in the world.

AMQP 0.9.1 vs AMQP 1.0: The Protocol That Split

Here's something strange about AMQP: version 1.0 is not an upgrade of version 0.9.1. They are completely different protocols.¹³

When the AMQP working group moved to OASIS for standardization, they created something new. AMQP 1.0 is a more generic, layered protocol. It doesn't define exchanges or queues or bindings. It defines peers exchanging messages, with separate layers for transport, transactions, security, and messaging.¹⁴

AMQP 0.9.1 assumes a broker with specific semantics. AMQP 1.0 is so generic it doesn't even require a central broker. The two protocols are wire-incompatible.¹⁵

This created a rift. RabbitMQ continued with 0.9.1 because that's what their users knew and depended on. Microsoft Azure Service Bus implemented 1.0. Both claim the AMQP name, but they cannot talk to each other without translation.

Despite the confusion, AMQP 1.0 achieved something important: it became an international standard. OASIS approved it in October 2012.¹⁶ ISO and IEC approved it as ISO/IEC 19464 in April 2014.¹⁷ For enterprises that require standards compliance, this matters.

RabbitMQ now supports both protocols, handling version negotiation when a client connects to port 5672.¹⁸

How AMQP Routing Works

The elegance of AMQP 0.9.1 lies in its exchange types:¹⁹

Direct exchanges route messages based on exact matching. A message with routing key "orders.new" goes to queues bound with exactly that key.

Fanout exchanges broadcast to all bound queues. Every subscriber gets every message. No routing key required.

Topic exchanges support wildcards. A binding of "orders.*" matches "orders.new" and "orders.cancelled". A binding of "orders.#" matches those plus "orders.new.priority".

Headers exchanges ignore routing keys entirely, matching on message header attributes instead.

The default exchange is a direct exchange with no name. Every queue automatically binds to it using its queue name as the routing key. This makes simple cases simple: send a message to queue "my-queue" and it arrives.

Security Considerations

AMQP itself defines authentication and can run over TLS (on port 5671), but the protocol has been the target of various attacks:²⁰

Denial of service: Malformed AMQP 1.0 messages could crash RabbitMQ servers before version 3.8.16 (CVE-2021-22116).²¹ The HTTP management API was vulnerable to memory exhaustion from oversized messages.

Deserialization attacks: Spring AMQP allowed arbitrary class deserialization by default until patches in 2023 (CVE-2023-34050).²²

Man-in-the-middle: Spring AMQP versions before 1.7.10 didn't validate hostnames during TLS handshakes (CVE-2018-11087).²³

Best practices:

• Use port 5671 with TLS for all production traffic
• Keep the management port (15672) behind a firewall
• Update RabbitMQ regularly; the vulnerability list is long
• Authenticate all connections; AMQP 1.0 requires SASL

The ZeroMQ Departure

In 2010, iMatix, the company that helped design AMQP and built its first implementation, announced they were leaving the AMQP working group.²⁴ Pieter Hintjens cited "irremediable failures in the AMQP development process."

Instead, iMatix focused on ZeroMQ, a brokerless messaging library that Martin Sustrik (who had led the AMQP working group) began developing as a low-latency alternative.²⁵ ZeroMQ took the opposite approach: no broker, no server, just smart sockets that applications embed directly.

The split highlighted a philosophical divide. AMQP 1.0 pursued flexibility and standardization. ZeroMQ pursued simplicity and performance. RabbitMQ and AMQP 0.9.1 occupied the middle ground: a standardized protocol with practical broker semantics.

Who Uses Port 5672 Today

OpenAMQ once ran the Dow Jones Industrial Average.²⁶ Today, AMQP and RabbitMQ power:

• Microservice architectures at companies like Pinterest, Uber, and WeWork
• Background job systems in Ruby on Rails, Django, and Node.js applications
• Event-driven systems that need reliable, ordered message delivery
• IoT platforms where devices publish data to be processed later
• Financial systems that require auditable, durable message logs

Azure Service Bus, Amazon MQ, and Google Cloud Pub/Sub all support AMQP connections. The protocol that started as one bank's rebellion against vendor lock-in became the standard way applications talk to each other.

Related Ports