I am trying to understand HTTP protocol for internet of things. As I understand there may be one server and many clients in the communication. Client send the http request to the server and server return the response to the client.

Suppose we created server and storeing record of humidity and temperature in server so that any client can access it from anywhere.

I have read in many places that TCP/IP, HTTP, MQTT protocols are used in this kind of communication.

Which protocol's will be used in this whole process? Is only TCP/IP used or are multiple protocols used for this?

 

There are transport protocols that send/receive messages and application layer protocols that generate and interpret messages to/from transport protocols.

https://en.wikipedia.org/wiki/Internet_protocol_suite

Here is a simple 'IOT' system for a solar energy monitor.
A HTTP server runs on a PIC32 using a serial data link to a PIC18 that controls the hardware.

Javascript from the PIC32 HTTP server runs the cube graphics on the local browser.
https://github.com/nsaspook/mbmc/blob/new_solar/TCPIP Demo App/WebPages2/solar_cube.pdf
https://github.com/nsaspook/mbmc/blob/new_solar/TCPIP Demo App/WebPages2/dynvars_a.htm

 

A good reason to use http is that any device having a browser can communicate with it. Ither methods would require some special software on the client.

Bob

 

Here is a simple 'IOT' system for a solar energy monitor.
A HTTP server runs on a PIC32 using a serial data link to a PIC18 that controls the hardware.

The two protocol HTTP and MQTT both are ideal for the IoT application so can you tell me when you will use MQTT in your application?

 

The two protocol HTTP and MQTT both are ideal for the IoT application so can you tell me when you will use MQTT in your application?

In my application MQTT could be used to transfer data from the PIC18 to the PIC32 via the RS232 serial link. I didn't use MQTT over serial because I wrote my own binary data transfer protocol for the link data.

 

HTTP and MQTT have different purposes. Although each can be pressed into service in overlapping cases, each is far stronger in the role it was intended for, and incapable in other cases.

HTTP was designed to transfer text and images from a server to a web browser. Later, because of its ubiquity it was adopted as a transport of APIs. Like TCP/IP, it is generally available on all platforms, this makes using it easy. It is very well suited to user interfaces like control panels and dashboards where the terminal can be a browser.

It can be used with POST to send data from a sensor to an application that populates a database. But, HTTP is not designed to be efficient. Sensors may be battery powered relying on deep sleep modes to save battery power and waking on an interrupt or timer to transit a message. The battery life is directly proportional to that message length because the transmitter must be on the air to send it.

Some sensors may not be using WiFi or even TCP/IP to send data. LoRa, and other radio low power methods would be overwhelmed by the TCP/IP overhead because of their smaller packet sizes requiring several transmissions to send the necessary housekeeping data for an HTTP/1.1 request.

If you intend to have two way communications with nodes, HTTP requires implementing an httpd on the sensor node to accept messages. This might be feasible for nodes that are built on larger MCU platforms with sufficient memory and are powered in such a way as to make battery life not a concern. But on very small MCUs, often found in sensor networks, the overhead of an httpd may not be acceptable and with nodes that sleep, the httpd cannot be available during those times,

You could implement a store-and-forward system that would allow the node to pull messages when it woke up, but now you are reinventing the MQTT wheel for no good reason. So, does HTTP have a place in IoT networks? Absolutely, but it doesn't replace MQTT. In general, HTTP makes sense if:

1. The node needs offer a UI for management and can't use a remote dashboard for that purpose; and/or
2. The node must transfer large amounts of data, such as video or images and/or;
3. The node is not really part of an IoT network rather it is the only, or one of a few, small computers in a system where everything else is using HTTP;

and

1. The node is using a high bandwidth channel (e.g.: WiFi, Ethernet, &c) suited to HTTP; and/or
2. The node is not battery powered and doesn't use deep sleep to conserve power so it always on.
3. The node has sufficient resources to implement the httpd without interfering with space for other needed code.

MQTT was purpose built for sensor networks. It uses very small packets with low overhead. This efficiency can make a material difference in battery life. It also runs very well over low bandwidth channels and preserves battery. The shorter messages also makes it more reliable in cases where the channel suffers fading or the device is simply very low powered and has a poor SNR.

The publish-subscribe model of MQTT is also an important advantage in sensor networks and other IoT applications. When devices use deep sleep, or cannot be on the air full time for other reasons, pushing messages to those devices would require not only the overhead of the messages and httpd but the spending of power budget without advantage. Even if the node sometimes needed to use HTTP POST to send some data, using MQTT for the return channel extends battery life and reliability.

Where an HTTP POST request looks something like:

POST /api/sensor_data HTTP/1.1
Host: dbasehost.tld
Content-Type: application/json
Cache-Control: no-cache

{
"temperature": 29,
"humidity": 48
}

the MQTT equivalent would look like:

[2 byte header]0000100MQTT0000010000000000000000000000000temperature:29,humidity:48

In the publish-subscribe mode the node can subscribe to a topic on the MQTT server to which messages it should consume will be published. It can subscribed to more than one topic, so unicast, multicast, and broadcast transmissions are possible.

Once subscribed the MQTT server will preserve messages in the selected topics until the node wakes up and asks for them. This way it is possible to send control messages to nodes that spend the majority of time sleeping.

MQTT is also very widely supported for IoT and sensor network applications. Services like TTN which provide free LoRaWAN access use MQTT, and commercially built nodes will almost universally support it. This means compatibility with things now and in the future. It also doesn't preclude using HTTP or any other protocol when it is called for.

You can also use MQTT a gateway can translate the data into HTTP API calls if that is needed. The gateway would either be the same as the MQTT server, or simply subscribe to one or more topics on the MQTT server and translate the messages destined for the HTTP API on behalf of the node.

So, in general use MQTT if:

1. Your nodes are battery powered and need to sleep most of the time; and/or
2. Your nodes are on low bandwidth links possibly also with poor SNR, and/or
3. Your nodes have limited storage and/or processor power

and

1. You don't need to provide a friendly UI directly on the node itself; and/or
2. You don't need to transfer large amounts of data; and/or
3. You don't just have a couple of nodes that are powered from mains or very large capacity batteries and an otherwise exclusively HTTP network

MQTT is an easy, lightweight purpose built solution for sensor networks. In the absence of some contraindications it should be the default for IoT networks because of the advantages of efficiency and interoperability.

[EDIT: un-jumbled word order]