Both UDP and TCP protocols in the transport layer can directly serve as communication protocols for application data. Table 8.3 lists the differences between UDP and TCP.
Table 8.3. Differences between TCP and UDP
|Reliability||Reliable transmission; supports retransmission, flow control and congestion control||Unreliable transmission; does not support retransmission, flow control or congestion control|
|Connection||Connection-oriented, with three handshakes for connection establishment and four handshakes for disconnection; long connection||No connection; direct data transmission; short connection|
|Connection object||One-to-one connection||One-to-one unicast, one-to-all broadcast, and one-to-many multicast|
|Header overhead||≥ 20 B||8 B|
|Transmission rate||Depends on network environment; retransmission occurs in case of packet loss, lowering transmission rate.||Fast, independent of network environment, and only responsible for transmitting data to the network|
|Application scenario||Suitable for reliable transmission, e.g., file transfer.||Suitable for real-time transmission, e.g., VoIP telephony, video telephony, streaming media, etc.|
For data communication of local control, TCP can be selected from the perspective of the transport layer as it can ensure the data is accurate. When using UDP, the smartphone app will send the command to turn on the light. The command may be discarded due to network environment issues, and ESP32-C3 may not receive the command. While for TCP, even if the data packet is discarded, the underlying layer of the smartphone app will resend the command.
However, a drawback to sending data using a pure transport layer protocol is that you need to develop business logic of upper-layer applications. Therefore, this section also introduces the application protocols HTTP and CoAP based on TCP and UDP.
Both HTTP and CoAP are network transmission protocols based on the REST model, which are used to send requests and respond to requests. The only difference is that one is based on TCP and the other is based on UDP, and each inherits the relevant characteristics of the transport layer protocol. Table 8.4 lists the differences between HTTP and CoAP.
Table 8.4. Differences between HTTP and CoAP
|Header overhead||May contain a large amount of message header data with high overhead||Packet headers are binary compressed for low overhead|
|Power consumption||Long connection, high power consumption||Short connection, low power consumption|
|Resource discovery||Not supported||Supported|
|Request method||Generally triggered by the client; no active trigger by the server.||Both the client and the server can actively trigger requests.|
|Application scenario||Suitable for devices with good performance and large memory||Suitable for devices with poor performance and small memory|
Compared to HTTP, CoAP is more suitable for IoT devices with limited resources. For the device has more resources and better performance, HTTP has more functions than CoAP.
After comparing the communication protocols within the TCP/IP protocol family, we will compare these protocols with the Bluetooth protocol. The most intuitive difference between them is that Bluetooth is a point-to-point protocol, while the TCP/IP is an end-to-end protocol that may go through routers. Therefore, in terms of response speed, although Bluetooth and Wi-Fi are both wireless transmission technologies on the 2.4 GHz channel, Bluetooth is faster than Wi-Fi in data communication between smartphones and ESP32-C3. The packet size of Bluetooth is smaller than that of application data using TCP/IP protocol stack, and the power consumption of Bluetooth is naturally lower than that of Wi-Fi. The Bluetooth protocol supports resource discovery and does not require local discovery because Bluetooth is a point-to-point connection, which is very suitable for local control. However, since most IoT products currently need to connect to the cloud, Wi-Fi functionality is essential. Many IoT products can use only Wi-Fi or only Bluetooth for network configuration. If the IoT product does not need to connect to the cloud, Bluetooth can be used for local control only. If the IoT product needs to connect to the cloud, it needs to use Wi-Fi for cloud connection and local control.