As mentioned earlier, TCP is the transport layer protocol upon which HTTP travels to the application layer. Some of the beneficial attributes of TCP connections are that they are reliable, serial, and checked for errors while sending information. These benefits, however, can sometimes lead to undesirable latency:

The Internet Protocol Suite includes many other protocols alongside TCP. One of these protocols is User Datagram Protocol (UDP). UDP is also a core member of the transport layer of TCP/IP. The primary difference between UDP and TCP is that UDP is connectionless. This means that individual units of data are transmitted with self-identifying information and the receiving end of that information has no prior knowledge of when or how it will be received. UDP does nothing to ensure that a recipient endpoint is actually available to receive that information, and thus this risk must be taken into consideration when using UDP.

Since UDP uses no connection, it is inherently not reliable, and that is what sets it apart from a connection-based protocol such as TCP. TCP allows for error checking and correction during a transmission because both parties are aware of each other due to their connection.

Messages sent over UDP and other connectionless protocols are called datagrams. UDP and datagrams should only be used when error checking and correction is not needed or is performed within the application layer itself. Checking errors at the application level is often the model that is used with UDP since error checking and correction is almost always a necessity with any application. Some examples of application types that use UDP are:

The most obvious disadvantages with UDP and a connectionless protocol are that there is no guarantee of message delivery, no error checking, and, consequently, no error correction. This can be a major disadvantage in an application where a user is interacting with the system on their own and most events are user generated. In a system where hundreds or thousands of users may be interacting with each other, however, a connectionless protocol allows the application to be free of latency due to error correction. A massively multiplayer online game is a good example of a system in which thousands or even millions of messages may need to be transported across a network consistently, but this cannot be done reliably while also maintaining connections with error checking and correction.

REST is often compared to Simple Object Access Protocol (SOAP), although SOAP is actually a protocol and not an architectural style like REST. The reason for the comparison is because both are used for web services, and in this context, REST is synonymous with HTTP, which is a protocol. Even though SOAP is a protocol, it also interacts with HTTP to transmit messages for implementing web services. It can also be used over SMTP.

The message format for SOAP is XML. An XML message sent with SOAP is referred to as an envelope. The structure of a SOAP envelope follows a particular pattern involving elements including a mandatory body element and an optional header element. The body may also include nested fault constructs which carry information regarding exceptions. An example of a SOAP message is shown as follows:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
<env:Header> 
    <n:shipping > 
      This is a shipping message 
    </n:shipping> 
  </env:Header> 
  <env:Body> 
    <env:Fault> 
      <env:Code> 
        <env:Value> 
          env:VersionMismatch 
        </env:Value> 
      </env:Code> 
      <env:Reason> 
        <env:Text xml:lang="en"> 
          versions do not match 
        </env:Text> 
      </env:Reason> 
    </env:Fault> 
  </env:Body> 
</env:Envelope> 

REST can also use XML for data exchange, but more commonly uses JSON in modern-day web applications.

WebSockets is a protocol that allows interactive communication between a web browser and a server. The term interactive in this context means that the server can push messages to the web browser without the browser needing to periodically poll the server for new data, as might typically be done in a web application using HTTP, AJAX, and REST.

You may have heard of push technology before. This paradigm is evident in many smartphone applications that push update notifications to a phone as soon as new data is available. This is also referred to as real-time data. HTTP is limited in that it does not support open connections that can receive real-time data. Instead, HTTP requires that a request be made and a connection or socket is opened, a response is received, information is downloaded, and the connection is then closed. Once new information becomes available, this will not be evident to the application needing that information without making periodic requests to the server, which is referred to as polling.

In 2011, WebSockets became officially standardized and supported by modern web browsers. This protocol allows data to be transferred to and from a server by using an open socket connection, allowing the client to request data at will but also allowing the server to push data to the client in real time:

Web applications using REST are limited by the open/close connection constraint with HTTP. This makes sense for many web applications that do not need a server response without a user interaction, or that can implement periodic server polling without too much overhead required. Web applications that want to provide real-time data to the user without an action, however, may be better served by using WebSockets.

MQTT originally stood for MQ Telemetry Transport. It is a messaging protocol designed to be used on top of TCP/IP, or the Internet Protocol Suite. MQTT employs a publish-subscribe, or PubSub, messaging pattern in which events or messages are published by publishers and available to any number of subscribers. In following, subscribers receive messages from any number of publishers. In this paradigm, publishers are entirely agnostic of subscribers.

In contrast to SOAP and WebSockets, MQTT is not designed to be used for web services over HTTP, but instead is primarily use for machine-to-machine (M2M) communication. MQTT is often used for satellite communications, home or smart home automation, and for mobile applications. MQTT is considered to be lightweight and have a small code footprint, making it ideal for mobile applications which may be using slower, wireless mobile network connections.

The "MQ" in MQTT was originally derived from IBM's Message Queuing (MQ) protocol. Message queuing is not actually a requirement for MQTT, however, which is why it is no longer a true acronym and is simply referred to as MQTT.

MQTT is an Organization for the Advancement of Structured Information Standards (OASIS) standard. OASIS is an organization that defines standards for the IoT and other areas of technology.

Any software that implements MQTT is referred to as an MQTT broker, which is a type of message broker architectural pattern that translates messages sent from an application to the proprietary format of the receiver, or the message broker itself:

The purpose of the message broker is to take the messages received by an application and perform some type of action on them. For example, some actions might be:

There are many popular message broker applications and services that can be used for message exchange in single page applications. Some of these are Mosquitto, CloudMQTT, IBM MessageSight, and ActiveMQ.

Advanced Message Queuing Protocol (AMQP) is similar to MQTT. It is an open standard application layer protocol for use with message brokers.

One of the most popular open source message brokers for modern-day web applications is RabbitMQ, which employs AMQP. In an AMQP architecture using something like RabbitMQ, messages are produced by an application and then queued or stored in the RabbitMQ server. A queue is also, in a sense, a buffer because it can store any amount of information for any amount of time until it is needed:

Although it uses AMQP, RabbitMQ also includes an adapter for MQTT. It additionally supports HTTP and Streaming Text Oriented Messaging Protocol (STOMP). The fact that RabbitMQ is open source and that it also includes adapters for other protocols, most notably HTTP, contributes greatly to its popularity today.

Constrained Application Protocol (CoAP) is a web transfer protocol designed for M2M communication. The machines primarily targeted for CoAP services are IoT devices.

CoAP is actually quite similar to HTTP and employs the REST architectural style as part of its specification. The difference with CoAP is that it strictly adheres to REST principles, while HTTP merely supports REST but does not require it.

Since CoAP uses the REST architectural style, it can actually be connected to over HTTP because, like with any RESTful architecture, the client is agnostic of the RESTful server it is accessing. In this scenario, a cross-protocol proxy is used to make the CoAP services available to a HTTP client:

Distributed Data Protocol (DDP) is not commonly used but gaining ground through the popular Meteor JavaScript framework. DDP is a simple protocol used for explicitly retrieving representations from a server, and also receiving updates regarding modifications on those representations in real time.

DDP allows Meteor applications to use WebSockets for services, providing a framework around those services to be connectionless. JSON data is used, but instead of being explicitly requested like it is with a RESTful architecture, the JSON data messages can be pushed in real time to an application.

DDP was originally developed for Meteor by its founders; however, it is not specific to Meteor and can be used in other frameworks. Meteor's implementation of DDP is written entirely in JavaScript and is open source.