The data model is identical. Same holding registers, same input registers, same coils, same function codes. Anything that can read one can read the other after a change of framing, and a register map written for RTU is valid for TCP without modification.
What differs is the physical and framing layer. Modbus RTU runs over RS-485 or RS-232 — a two-wire multidrop bus, typically 9600 to 115200 baud, with a CRC-16 for integrity and silent-interval framing to delimit messages. Devices are addressed 1 to 247, and there is exactly one master on the bus. Modbus TCP wraps the same protocol data unit in an MBAP header over TCP port 502, drops the CRC because TCP already provides integrity, and allows many concurrent clients.
The operational consequences are what matter in practice. On RTU, throughput is shared: one slow or retrying device delays every other device on the loop, and a poll cycle across forty devices at 9600 baud is measured in seconds. On TCP, a slow device delays only its own connection. RTU brings physical-layer work that TCP does not — termination resistors, biasing, cable length limits, ground potential differences between buildings — and those are the faults that take a day to find.
RTU still wins in one important case: it runs over two wires for a kilometre with no switch, no IP stack and no network team involved. That is why brownfield meter and drive installations are still overwhelmingly RTU, and why a gateway that speaks both is standard equipment.
Yes. The register map is a property of the device, not of the transport. Only the framing changes.
Almost always, and the reason is contention rather than raw bandwidth: on RTU every device shares one serial bus and one master, so poll latency scales with the number of devices.
Correct. RTU carries a CRC-16 because a serial line has no integrity checking of its own. TCP provides that already, so Modbus TCP omits it and uses the MBAP header for transaction matching instead.