HTTP vs MQTT trade-offs in IOT Protocols - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Primary difference in communication style between HTTP and MQTT

Which statement best describes the main communication style difference between HTTP and MQTT?

A HTTP uses a request-response model, while MQTT uses a publish-subscribe model.

B HTTP uses a publish-subscribe model, while MQTT uses a request-response model.

C Both HTTP and MQTT use a request-response model.

D Both HTTP and MQTT use a publish-subscribe model.

💡 Hint

Think about how clients interact with servers in each protocol.

HTTP works by clients sending requests and servers responding. MQTT uses topics where clients publish messages and others subscribe to those topics.

🧠 Conceptual

intermediate

Energy efficiency trade-off between HTTP and MQTT

Why is MQTT generally more energy efficient than HTTP for IoT devices?

A MQTT uses larger packets which reduce the number of transmissions.

B HTTP keeps connections open longer than MQTT, saving energy.

C MQTT keeps connections open and sends small packets, reducing overhead.

D HTTP uses smaller packets than MQTT, making it more energy efficient.

💡 Hint

Consider connection persistence and packet size.

MQTT maintains a persistent connection and sends minimal data, which saves battery life on devices. HTTP opens and closes connections frequently, causing more energy use.

✅ Best Practice

advanced

Choosing protocol for real-time sensor data streaming

For a system that requires real-time sensor data streaming with minimal latency and reliable delivery, which protocol is best suited?

A MQTT, because it supports persistent connections and QoS levels.

B MQTT, because it uses UDP for faster transmission.

C HTTP, because it uses TCP which guarantees delivery.

D HTTP, because it is stateless and simple.

💡 Hint

Think about latency and message delivery guarantees.

MQTT supports persistent connections and Quality of Service (QoS) levels, making it ideal for real-time and reliable data streaming. HTTP is stateless and less suited for continuous streams.

❓ Troubleshoot

advanced

Troubleshooting MQTT connection issues

An IoT device using MQTT cannot maintain a connection to the broker. Which is the most likely cause?

A The device is using MQTT over TLS on port 80.

B The device is using HTTP instead of MQTT.

C The device is publishing messages without subscribing.

D The device is behind a firewall blocking MQTT port 1883.

💡 Hint

Consider network restrictions and default ports.

MQTT typically uses port 1883. Firewalls blocking this port prevent connection. Using HTTP or publishing without subscribing does not cause connection failure. MQTT over TLS usually uses port 8883, not 80.

🔀 Workflow

expert

Optimizing IoT device communication for low bandwidth

You need to optimize communication for IoT devices with very low bandwidth and intermittent connectivity. Which workflow best achieves this using MQTT?

A 2,1,3,4

B 1,2,3,4

C 1,3,2,4

D 1,3,4,2

💡 Hint

Consider the order of subscribing before publishing and power saving.

Devices should first establish connection, then subscribe to receive commands before publishing data. Disconnecting last saves power. Publishing before subscribing may miss commands.

Practice

1. Which protocol is best suited for devices that need to send data only when requested and have simple communication?

easy

A. FTP

B. MQTT

C. HTTP

D. CoAP

Solution

1. Step 1: Understand HTTP communication style

   HTTP works on a request-response model where the client asks and the server replies, making it simple and direct.

2. Step 2: Compare with MQTT style

   MQTT uses publish-subscribe, which is more complex and suited for many devices and continuous data flow.

3. Final Answer:

   HTTP -> Option C

4. Quick Check:

   Request-response = HTTP [OK]

Hint: Request-response means HTTP, publish-subscribe means MQTT [OK]

Common Mistakes:

• Confusing MQTT as request-response
• Thinking HTTP supports many-to-many easily
• Mixing up protocol purposes

2. Which of the following is the correct way to describe MQTT's communication pattern?

easy

A. Publish-subscribe

B. Request-response

C. Peer-to-peer

D. Broadcast

Solution

1. Step 1: Identify MQTT communication model

   MQTT uses a publish-subscribe model where devices publish messages to topics and others subscribe to those topics.

2. Step 2: Eliminate other options

   Request-response is HTTP, peer-to-peer and broadcast are different models not used by MQTT.

3. Final Answer:

   Publish-subscribe -> Option A

4. Quick Check:

   MQTT = Publish-subscribe [OK]

Hint: MQTT always uses publish-subscribe pattern [OK]

Common Mistakes:

• Choosing request-response for MQTT
• Confusing peer-to-peer with publish-subscribe
• Assuming MQTT uses broadcast

3. Consider a network with many IoT sensors sending small updates frequently. Which protocol will likely reduce network bandwidth usage?

medium

A. HTTP because it uses simple requests

B. MQTT because it uses large message headers

C. HTTP because it supports caching

D. MQTT because it uses lightweight messages and persistent connections

Solution

1. Step 1: Analyze network usage for many devices

   MQTT uses small message headers and keeps connections open, reducing overhead for frequent messages.

2. Step 2: Compare with HTTP overhead

   HTTP opens a new connection per request with larger headers, increasing bandwidth use.

3. Final Answer:

   MQTT because it uses lightweight messages and persistent connections -> Option D

4. Quick Check:

   Low bandwidth = MQTT lightweight messages [OK]

Hint: Persistent connections save bandwidth in MQTT [OK]

Common Mistakes:

• Assuming HTTP is lighter due to caching
• Thinking MQTT has large headers
• Ignoring connection overhead

4. You have an IoT device that must send data only when triggered by a server. You try using MQTT but the device keeps sending data continuously. What is the likely mistake?

medium

A. Using MQTT publish-subscribe instead of HTTP request-response

B. Not configuring the device to subscribe to the server's trigger topic

C. Using HTTP instead of MQTT

D. Setting QoS level to 0

Solution

1. Step 1: Understand MQTT trigger mechanism

   MQTT devices receive triggers by subscribing to topics; without subscription, they can't wait for triggers.

2. Step 2: Identify why device sends continuously

   If not subscribed, device may publish data on its own schedule instead of waiting for server commands.

3. Final Answer:

   Not configuring the device to subscribe to the server's trigger topic -> Option B

4. Quick Check:

   MQTT triggers need subscriptions [OK]

Hint: MQTT triggers require subscription to server topic [OK]

Common Mistakes:

• Confusing publish-subscribe with request-response
• Thinking QoS affects trigger behavior
• Switching protocols unnecessarily

5. You want to design a system where thousands of sensors send data to a central server, but the network is unreliable and bandwidth is limited. Which protocol and feature combination is best?

hard

A. MQTT with persistent sessions and QoS 1 or 2

B. HTTP with frequent polling

C. HTTP with caching enabled

D. MQTT with QoS 0 and no session persistence

Solution

1. Step 1: Consider network constraints

   Unreliable network and limited bandwidth require efficient, reliable message delivery without repeated data loss.

2. Step 2: Evaluate protocol features

   MQTT supports persistent sessions to resume after disconnects and QoS 1 or 2 to ensure message delivery.

3. Step 3: Compare options

   HTTP polling wastes bandwidth and lacks delivery guarantees; MQTT QoS 0 and no persistence risk data loss.

4. Final Answer:

   MQTT with persistent sessions and QoS 1 or 2 -> Option A

5. Quick Check:

   Reliable delivery + low bandwidth = MQTT QoS 1/2 + persistence [OK]

Hint: Use MQTT QoS 1/2 with persistence for unreliable networks [OK]

Common Mistakes:

• Choosing HTTP for unreliable networks
• Using MQTT QoS 0 when reliability needed
• Ignoring session persistence