IoT and network protocols
Each year, we move further and further into the age of the Internet of Things. IoT devices are finding new uses in many different fields and industries, with the development of automating many aspects of life and business, where we have come up with an array of smart technologies such as factories, agriculture, grid-monitoring, oil & gas, and even the home has not escaped becoming a smart home. These are a few of the hundreds of new use-cases for IoT technology. As a result, IoT development is growing ever more sophisticated to keep up with this skyrocketing demand. With so much focus on IoT, it’s important to not only look at the devices themselves, but also the communication protocols that are used in the delivery of the data that IoT devices rely on.
If you’re a little rusty on what communication protocols are, here’s the basics: Communication protocols are sets of mutually agreed upon rules that govern how data is transferred throughout the world wide web. They’re the rules that ensure that when one computer sends information, the receiving device is able to understand the data sent to it. Even if you’re not an expert in the protocol field, some protocol names will be immediately familiar to you. The IP in IP address stands for Internet Protocol, and it’s the principle protocol in the whole internet protocol suite. HTTP is also one of the big ones, an initialism which you’ve no doubt seen as the frequent beginning to your URLs. HTTP is a protocol operating at the application layer of the internet, the layer most relevant to human users, which is why we interact so frequently with HTTP. But, while HTTP is a great communication protocol, it’s not the only protocol at the application layer, and, when it comes to IoT uses, it may not be the best.
MQTT (Message Queuing Telemetry Transport) is a lesser known protocol that has gained popularity in the IoT world. Developed in 1999, its original purpose was to monitor remote gas pipelines and oil rigs. Since these sites were often offshore and far away from primary servers, MQTT was built to operate in extremely low-bandwidth environments, enabling the forwarding of information to targets that higher bandwidth protocols would simply view as inaccessible dead zones. In 2011, Facebook made the realization that MQTT could be applied to more than just oil rigs, choosing it as the protocol powering their new Facebook Messenger. In 2013, as IoT’s popularity boomed, people began to realize that MQTT’s low bandwidth focus had even broader applications. Its design made it a perfect fit for IoT.
MQTT and HTTP
To understand what makes MQTT special, it’s important to understand the design principles behind HTTP, and the key differences between the two protocols.
Request/Response vs. Publish-Subscribe
The HTTP protocol follows a request/response model for its connections, the simplest form of connection that a network protocol can have. Request/response requests are client-driven. That means that HTTP connections are initiated by the client to a server, and requests take the form of a message from client to server, that the server then sends a response to. This is a very straightforward operation, which is one of the reasons HTTP is such a popular protocol. MQTT’s approach is a tad less direct. MQTT’s publish-subscribe model (known in the industry as pub/sub) is not client-driven in the same way as HTTP. Yes, the client still initiates the connection, but once the connection is made, both client and server are free to initiate different conversations by sending new requests. However, these requests don’t move as cleanly back and forth between sender and recipient. Instead, the device issuing information publishes its data to a specific subsection of its MQTT server, called a variable. Other devices can subscribe to that variable, and in doing so will be updated each time the variable’s value changes from a new data upload.
Scaling
Now even though the MQTT approach is less straightforward, and therefore less efficient for simple 1-to-1 communication, it does have the advantage of simplifying the sharing of data between a large series of simpler devices, such as those found in IoT. Basically, an HTTP request is like a text message, while an MQTT request is more like posting on social media. An HTTP request will always be one device sending a single request to another, so in order to make a large network of HTTP connected devices work, you end up with thousands of individual requests flying around, substituting for a smoother group message set up. With MQTT’s social media style configuration, it doesn’t matter if there’s one device subscribed to a variable or one hundred. The framework is independent of the number of receivers. The transmitter posts, and every subscriber in the network is updated. This separation of publisher from number of subscribers is referred to as decoupling and independent scaling, and its one of the most potent selling points for an MQTT based system.
Momentary vs. Long-Term Connections
Because of these differences in requests, the length of connection for these two protocols is very different as well. HTTP requests are very brief. The client sends the request, the server responds, and then the connection is immediately broken. If the same client wants to send a new request, a whole new connection must be made. On the other hand, because of how publish/subscribe works, MQTT connections continue to operate for as long as the device is subscribed to the server. Any information sent between device and server is transmitted over this one connection. In some ways, this is just another way that HTTP demonstrates its efficiency. Many systems can only handle so many connections at once, and HTTP’s rapid removal of unused connections can spare the system a lot of strain. But this efficiency comes at the cost of security. A connection is most vulnerable to outside interference in the moment when it is being established, and in this way, MQTT’s long term connections prevent fewer points of entry to attackers than HTTP’s constant cycling. HTTP is still very secure, but MQTT just takes that a step further. Also, while HTTP’s momentary connections make it faster at establishing connections, MQTT’s long term connections give it significantly faster throughput in the key area of request time. By taking the time to establish a really solid, stable connection MQTT is able to ensure that any data carried through that connection is sent much faster than an HTTP based network, whose millions of connections means it can’t afford to invest time into perfecting any one connection. The area where MQTT shines in this aspect is large stable networks, with many long term devices, but few devices added to or dropped from the network over shorter time periods. When the specific number of devices linked to the network generally remains constant day to day, MQTT’s slower connection establishing pretty much pays for itself, by building really strong, light-footprint connections that end up saving a lot of time on the request and response end.
So why the MQTT hype?
When you break down the differences between MQTT and HTTP, it’s hard to claim that either protocol is definitively “better” than the other. MQTT generally wins in scalability and lower latency, while HTTP’s strengths include high fault tolerance and greater compatibility with the many other HTTP-running systems that fill the web. But it’s fair to say that MQTT is certainly the more specialized protocol, and the more you dive into MQTT, the more you’ll notice how well that specialization fits the needs of modern IoT. MQTT’s publish/subscribe model makes it much easier to make connections between the many small devices that make up IoT, and its long term connections set up makes connections easier to maintain in the low bandwidth settings where IoT is so often found. It’s pretty impressive that a protocol designed well before IoT was in vogue works so well with an IoT environment, but MQTT really does fit like a glove.
MQTT at the edge
Here at Azion, we’re focused on supporting IoT infrastructure through our edge network technologies. Our product suite is fully compatible with both MQTT and HTTP protocols, offering complex flexibility in building your environment to your specific needs. Azion Edge Services make deploying application configurations scalable and user-friendly, eliminating much of the administrative pain of converting over to a fresh protocol language. Once your chosen protocol is configured in your network, our Data Stream monitors your IoT device connections in real time, ensuring device health and network transparency. And of course, your whole IoT system can be housed on our distributed edge network, enhancing your security and boosting connection speeds by bringing the servers that IoT is subordinate to in closer proximity to them, by moving to the network edge.
As to whether, MQTT or HTTP is the better protocol for your network, the truth is, both are strong, tried and true protocols, that, if set up with the right tools, will offer solid, dependable request connections. If your system is pretty standard and you don’t want to overcomplicate things, HTTP is easy, direct, and works great. If IoT plays a larger role for your business, and the thought of a protocol that focuses more directly on your IoT-specific needs is appealing, than MQTT is probably worth a closer look. And of course, if you can’t decide, you can always just use both. Call it a hybrid approach.
