MQTT is an asymmetric protocol, whereas HTTP or HTTPS is a nonsymmetric protocol. Say node A needs to communicate with node B. An asymmetric protocol between A and B would only require one side (A) to use the protocol, however, all information needed for the reassembly of packets must be contained in the fragmentation header sent by A.
Asymmetric systems have one master and one slave. In a symmetric protocol, both A and B would have the protocol installed. A or B can assume the role of master or slave (telnet being a primary example). MQTT has distinct roles which makes sense in sensor/cloud topology.
MQTT defines an optional facility called Last Will and Testament (LWT). The LWT contains the Last Will topic, QoS, and the actual message. If a client disconnects from a broker connection ungracefully the broker is then obligated to broadcast the LWT message to all other subscribed clients to that topic.
Even though MQTT is based on TCP, connections can still be lost, especially in a wireless sensor environment. A device may lose power, lose signal strength, or simply crash in the field, and a session will enter a half-open state. Here, the server will believe the connection is still reliable and expect data.
To remedy this half-open state, MQTT uses a keep-alive system. Using this system, both the MQTT broker and client have assurance that the connection is still valid even if there hasn't been a transmission for some time. The client sends a PINGREQ packet to the broker, which in turn acknowledges the message with a PINGRESP. A timer is preset on the client and broker side. If a message has not been transmitted from either within a predetermined time limit, a keep-alive packet should be sent. Both a PINGREQ or a message will reset the keep-alive timer.
More details on the MQTT can be found here: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf