MQTT vs TCP for
Telematics

The dominant pattern in the low-cost tracker market is a custom binary protocol over a plain TCP socket. The GT06, Concox, and Teltonika families all work this way: the device opens a TCP connection to a fixed server IP and port, sends a login packet with its IMEI, and then streams compact binary location packets. A typical GT06 location frame is on the order of 20 to 40 bytes and looks like a start marker (0x7878), a length byte, a protocol number, the packed payload (latitude and longitude as scaled integers, speed, course, satellite count, status bits), a rolling serial number, a CRC, and a stop marker (0x0D0A). Every field is exactly as wide as it needs to be, with no text, no keys, and no whitespace.

The appeal is total control and minimal overhead. You decide the framing, so a fix can be packed into 30 bytes instead of the 150-plus a JSON-over-MQTT message might take. Firmware is tiny because there is no protocol library, just a socket and a buffer. On a metered cellular plan and a battery budget, those saved bytes and that saved radio time are real money and real runtime. The cost is that the system owns everything: the framing, the acknowledgement scheme, the keepalive, the reconnection logic, and a custom server-side parser that has to tolerate every malformed and partial frame a flaky modem will produce. The server is the hard part, because TCP is a byte stream, not a message stream, and a single read can return half a frame or three frames glued together. Getting that parser right at scale is part of telematics backend and data ingestion engineering.

MQTT is a publish-subscribe protocol that runs over TCP. The device connects to a broker, publishes location messages to a topic such as fleet/device-id/telemetry, and any number of backend consumers subscribe to those topics without the device knowing or caring. This decoupling is the structural advantage: adding a new consumer (a live map, an analytics pipeline, an alerting service) requires no device change at all. With a raw TCP protocol, every consumer either reads from your custom server or you build the fan-out yourself.

MQTT defines three quality-of-service levels. QoS 0 is fire-and-forget, with no acknowledgement, so a message lost in a network blip is gone; it is the cheapest and fine for high-frequency telemetry where the next fix is along in a second anyway. QoS 1 guarantees at-least-once delivery using a PUBACK, so a message is retried until acknowledged, at the cost of possible duplicates the consumer must de-duplicate. QoS 2 guarantees exactly-once with a four-step handshake, which is rarely worth its overhead for telematics. Keepalive is built in: the client declares a keepalive interval at connect, and if no packet flows within 1.5 times that interval, the broker considers the client dead and fires its Last Will and Testament message, which is a clean way to publish a device-offline event automatically. Reconnection logic still lives in the firmware, but the protocol gives you the session and clean-or-persistent session flags to make it well-defined.

The Last Will mechanism deserves emphasis because it is genuinely useful for fleets. With raw TCP a dead device is detected only when the socket times out and the server notices; with MQTT the broker publishes the offline status the instant keepalive lapses. MQTT is the default transport for new platforms for exactly these reasons, and the broker and cloud integration scope is described under MQTT cloud integration.

Vehicles drive through tunnels, parking structures, and coverage gaps, so the link will drop, and what the firmware does during the drop determines whether you lose data. Store-and-forward is the answer regardless of protocol: when the connection is down, the device writes location fixes to a local buffer (RAM ring buffer or flash, depending on how long an outage must be survived), and when the link returns it flushes the backlog. The subtlety is ordering and acknowledgement. With a raw TCP protocol you design your own ACK so the device knows which buffered fixes the server has durably stored before it deletes them; with MQTT QoS 1 you get that acknowledgement from the PUBACK, which is one more reason MQTT removes custom code.

Reconnection needs care on both transports. A naive client that reconnects immediately on every drop will hammer the broker or server when a regional cell outage brings thousands of devices back at once, a thundering herd that can take down the very server they are trying to reach. Exponential backoff with jitter spreads reconnections out in time. Whether the device runs raw TCP, MQTT, or CoAP, the cellular layer underneath also has to be designed for these conditions, which is the scope of cellular connectivity design.

At fleet scale the backend has to hold a very large number of mostly-idle persistent connections. A modern MQTT broker (EMQX, HiveMQ, VerneMQ, or a managed cloud broker) handles hundreds of thousands to millions of concurrent connections per cluster by keeping per-connection state small and clustering horizontally, sharing subscription routing across nodes. A custom TCP server can match this, but you build the connection management, the horizontal sharding, and the backpressure handling yourself, which is months of work that the broker ecosystem gives you off the shelf. Either way the bottleneck is rarely raw throughput and usually connection count and the cost of waking idle connections, so keepalive intervals and session handling are the real tuning knobs.

The default guidance is straightforward. Choose MQTT for new connected-fleet platforms where you control both ends and value standard tooling, native fan-out, and built-in delivery guarantees; the small byte overhead is almost always worth the engineering it avoids. Choose raw TCP with a custom binary protocol when integrating with existing trackers that already speak GT06 or Concox, or when unit economics are so tight that every byte counts and owning the parser and fan-out is justified. Choose CoAP for sleepy NB-IoT asset trackers and lossy links where holding a TCP socket open is the wrong model. Most real platforms end up supporting more than one, because a fleet is a mix of device generations, and an ingestion layer can be built to normalize all of them into one clean stream.