10x Smaller Headers, Only ~8% Less Bandwidth
10x Smaller Headers, Only ~8% Less Bandwidth
Ada re-derives this chapter’s own numbers step by step, at full precision
ADA · CALCULATION AUDIT
10x Smaller Headers, Only ~8% Less Bandwidth
Misconception 4 pits two numbers against each other: AMQP’s header runs up to 10x larger than MQTT’s, yet over 10,000 messages of 200-byte payload MQTT sends only about 8% less data — 2.02 MB against 2.18 MB. Both figures are correct, and reading one as the other is how a team reaches for MQTT on the wrong axis. This audit rebuilds the comparison from the payload up and asks how a header 9x smaller can move the total transfer by barely 7%.
Companion to the chapter AMQP Implementation Pitfalls — every number here comes from that chapter.
Select Calculate for 10000 messages carrying 200-byte payloads with the displayed MQTT and AMQP headers.
Check compares 2.02 MB with 2.18 MB: a roughly 10x header ratio changes total traffic by only about 8%.
Payload bytes dominate this fixture, so the smaller MQTT header barely changes steady bandwidth even though setup, memory, and battery costs can still differ.
See the relationship before changing it
The figure reads from left to right. The blue input is payload size. The middle card names the page’s rule. The green output is traffic saved. The arrow matters: change the input, apply the rule once, then read the result with its unit.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 200 bytes.
- 2
Name the relationship. saving = 16 / (payload + 18) x 100
- 3
Substitute with units. 16 / (200 + 18) x 100 = 7.34%
- 4
Read the result. Keep the unit beside the value, then use the result only inside the technical boundary below.
Predict, then change payload size
Try Predict how traffic saved responds when payload size moves. Calculate payload size; compare traffic saved with that prediction.
Observe Return to 200 bytes. Recheck traffic saved with payload size at its chapter value.
Explain Small payloads make fixed headers matter more. Large payloads hide the header gap.
Check yourself
What should you do before trusting a moved-slider result?
What does this small model leave out?
Technical boundaries
For the header comparison, excluded from this fixed arithmetic are TCP and TLS framing, acknowledgements, retransmissions, broker batching, or payload compression.
Ada: Misconception 4 sets two numbers against each other. The overhead row says AMQP’s header runs up to 10x larger than MQTT’s — 2 bytes versus 8-20 — yet the bandwidth row says MQTT sends only about 8% less data. Both are correct, and reconciling them is the whole lesson. Let me rebuild the comparison from the payload up.
The scenario is 10,000 messages of 200-byte payload. MQTT adds a 2-byte header: 10000 x (200 + 2) = 2,020,000 bytes, about 2.02 MB — matching the table. Take AMQP at the 18-byte overhead its 2.18 MB total implies: 10000 x (200 + 18) = 2,180,000 bytes, 2.18 MB. The header ratio is 18 / 2 = 9x, right beside the quoted 10x.
Now the bandwidth gap. MQTT saves 2,180,000 - 2,020,000 = 160,000 bytes, which against AMQP’s total is 160,000 / 2,180,000 = 0.0734 — about 7%, which the table rounds to 8%. A 9x smaller header shrank the transfer by only ~7%, because the payload is 200 / 218 = 0.917 of every AMQP message: trimming the ~8% that is header can never move the total by more than ~8%.
Design meaning: header overhead only dominates when the payload is tiny, so MQTT’s real advantage lives in the table’s battery, setup-RTT, and memory rows — not in steady bandwidth — and reaching for MQTT “to save bandwidth” on 200-byte telemetry optimises the one axis where the two protocols are all but tied.
Every number above is taken from the chapter’s own material and re-derived step by step.