154
E. Fraccaroli and D. Quaglia
Table 3.5 Comparison
between HTTP and CoAP
architecture
Feature
HTTP CoAP
Transport protocol
TCP
UDP
Network protocol
IP
6LoWPAN
Multicast support
No
Yes, through UDP
Client/server mode
Yes
Yes
Publish/subscribe mode
No
Yes
Synchronization requirement Yes
No
CPU overhead
Large Small
originally designed as a client/server protocol, but in 2019 IETF published an
Internet Draft describing a publish/subscribe mechanism [86].
Table 3.5 compares HTTP and CoAP. Like HTTP, CoAP is an Application Layer
protocol. A client requests a resource at a Uniform Resource Identifier (URI) and
the server responds. Morever, RESTful principles are followed; verbs GET, POST,
PUT, DELETE are used. Protocol is indicated with coap://. Where CoAP differs
from HTTP is that UDP is used for transport instead of TCP. UDP handshaking is
lighter and easier to implement on microcontrollers. CoAP header is only 4 bytes.
CoAP can also use UDP’s broadcast and multicast features. Since there’s no TCP,
CoAP takes care of message acknowledgments, retries with congestion control,
and duplicates detection. With a very simplified reasoning, we can say that CoAP,
MQTT, and AMQP exhibit an increased message overhead with higher consumption
of computational and communication resources as well as energy.
Figure 3.32 shows an example of CoAP/HTTP interoperation. A REST client,
implemented on a constrained node, calls services provided by a REST server
implemented on a powerful Internet node. REST messages flow seamlessly between
client and server as they both were on traditional Internet. On the constrained
network, HTTP, TLS, and IP are replaced by CoAP, DTLS, and 6LoWPAN,
respectively. A proxy node is also shown. It has in charge the mapping between
CoAP messages into HTTP messages and vice versa.
CoAP supports four different message types:
• confirmable (CON);
• non-confirmable (NON);
• acknowledgment (ACK);
• reset (RST).
A confirmable message is considered as a reliable message. Using this kind of
message, the client can be sure that the message will arrive at the server because
it is repeatedly sent until the receiver answers with an acknowledge message.
The acknowledge message must contain the same ID of the confirmable message.
Figure 3.33 shows an example of a confirmable message exchange.
Whenever the server is unable to manage the incoming request, it can answer to
the client with a reset message (RST) instead of the acknowledge message (RST).
Figure 3.34 shows an example where the server answer with a reset message.
E. Fraccaroli and D. Quaglia
Table 3.5 Comparison
between HTTP and CoAP
architecture
Feature
HTTP CoAP
Transport protocol
TCP
UDP
Network protocol
IP
6LoWPAN
Multicast support
No
Yes, through UDP
Client/server mode
Yes
Yes
Publish/subscribe mode
No
Yes
Synchronization requirement Yes
No
CPU overhead
Large Small
originally designed as a client/server protocol, but in 2019 IETF published an
Internet Draft describing a publish/subscribe mechanism [86].
Table 3.5 compares HTTP and CoAP. Like HTTP, CoAP is an Application Layer
protocol. A client requests a resource at a Uniform Resource Identifier (URI) and
the server responds. Morever, RESTful principles are followed; verbs GET, POST,
PUT, DELETE are used. Protocol is indicated with coap://. Where CoAP differs
from HTTP is that UDP is used for transport instead of TCP. UDP handshaking is
lighter and easier to implement on microcontrollers. CoAP header is only 4 bytes.
CoAP can also use UDP’s broadcast and multicast features. Since there’s no TCP,
CoAP takes care of message acknowledgments, retries with congestion control,
and duplicates detection. With a very simplified reasoning, we can say that CoAP,
MQTT, and AMQP exhibit an increased message overhead with higher consumption
of computational and communication resources as well as energy.
Figure 3.32 shows an example of CoAP/HTTP interoperation. A REST client,
implemented on a constrained node, calls services provided by a REST server
implemented on a powerful Internet node. REST messages flow seamlessly between
client and server as they both were on traditional Internet. On the constrained
network, HTTP, TLS, and IP are replaced by CoAP, DTLS, and 6LoWPAN,
respectively. A proxy node is also shown. It has in charge the mapping between
CoAP messages into HTTP messages and vice versa.
CoAP supports four different message types:
• confirmable (CON);
• non-confirmable (NON);
• acknowledgment (ACK);
• reset (RST).
A confirmable message is considered as a reliable message. Using this kind of
message, the client can be sure that the message will arrive at the server because
it is repeatedly sent until the receiver answers with an acknowledge message.
The acknowledge message must contain the same ID of the confirmable message.
Figure 3.33 shows an example of a confirmable message exchange.
Whenever the server is unable to manage the incoming request, it can answer to
the client with a reset message (RST) instead of the acknowledge message (RST).
Figure 3.34 shows an example where the server answer with a reset message.