What is TCP?
TCP (Transmission Control Protocol) is the connection-oriented transport protocol of the internet protocol suite that delivers data between two applications reliably, completely and in the right order, by numbering every byte, having receipt acknowledged and retransmitting lost segments. TCP runs on top of IP at Layer 4 (the transport layer) of the OSI model and has been an internet standard since 1981. In OT networks, TCP carries the traffic between SCADA, PLCs, HMIs, Historian systems and engineering stations, for instance with Modbus TCP, OPC UA, S7 communication and HTTP.
🕰️ Where does TCP come from?
Vint Cerf and Bob Kahn described the protocol in May 1974 in the paper A Protocol for Packet Network Intercommunication. In 1978 the original design was split into TCP (reliable transport) and IP (addressing and routing), so that applications that do not need reliability, such as voice, could run directly on IP; this later gave rise to UDP. On 1 January 1983 the ARPANET officially switched over to TCP/IP.
| Year | Milestone |
|---|---|
| 1974 | Cerf and Kahn publish the design of the Transmission Control Protocol |
| 1978 | Split into TCP and IP |
| 1981 | RFC 793 defines TCP as a standard |
| 1983 | ARPANET switches over to TCP/IP |
| 2007 | RFC 4987 describes SYN flood attacks and countermeasures |
| 2022 | RFC 9293 replaces RFC 793 as the current specification (STD 7) |
🧠 How does TCP work?
A TCP connection goes through three phases:
- Set-up with the 3-way handshake - the client sends SYN, the server replies with SYN-ACK and the client confirms with ACK. Both sides pick a random starting sequence number (initial sequence number), which makes it harder for attackers to guess sequence numbers.
- Data transfer - data travels in numbered segments. The receiver uses ACKs to confirm up to which byte everything has arrived. If an acknowledgement does not come, the sender retransmits the segment. A checksum over header and data detects damaged segments, which are discarded and sent again. TCP therefore does not correct errors itself; it recovers from them by retransmission.
- Teardown - each side closes its own direction with FIN and ACK, usually in four segments. The side that closes first then stays in the TIME-WAIT state for a while (2 × the maximum segment lifetime, 4 minutes according to the standard) to catch late segments.
TCP also manages two kinds of throughput. Flow control via the receive window prevents a fast sender from overwhelming a slow receiver, such as a small PLC. Congestion control slows the sender down as soon as the network starts losing packets, so that a single connection does not clog the whole network.
🔧 Which technical values matter?
| Characteristic | Typical value | What it means in practice |
|---|---|---|
| Port number | 16 bits (0–65535) | Determines which application receives the traffic, for example 502 for Modbus TCP |
| Header size | 20 bytes, up to 60 bytes with options | Overhead per segment |
| MSS on Ethernet | 1460 bytes (1500 MTU − 20 IP − 20 TCP) | Maximum amount of data per segment |
| Default MSS without option | 536 bytes (IPv4) | Fallback value for old or constrained devices |
| Initial retransmission timer | 1 second (RFC 6298) | First wait before a segment is resent; doubled on each further attempt |
| TIME-WAIT | 2 × MSL, 4 minutes in the standard | Port stays occupied after closing; Linux, for example, uses a fixed 60 seconds |
| Keepalive | Off by default; if on, only after 2 hours of silence | Detects dead connections, but far too slowly for process monitoring |
These values explain many faults seen in the field. A lost segment costs at least the retransmission time, which rises to seconds on repeated loss. With continuous traffic TCP recovers faster through fast retransmit after three duplicate ACKs (RFC 5681), but a single SCADA poll has no follow-up traffic, so the sender waits for the timer. The Nagle algorithm (RFC 896), which bundles small messages, can also add tens to hundreds of milliseconds of delay in combination with delayed ACKs; this is why many industrial stacks enable the TCP_NODELAY option.
🏭 Which industrial protocols use TCP?
Practically every modern OT protocol without hard real-time requirements runs on TCP. Readings from sensors usually reach SCADA and the historian through a PLC or gateway that speaks one of these protocols:
| Protocol | TCP port | Typical use |
|---|---|---|
| Modbus TCP | 502 (secured: 802 with TLS) | Reading and writing registers in PLCs, controllers and meters |
| OPC UA | 4840 (opc.tcp), 4843 for TLS |
Data exchange between PLCs, SCADA, MES and historian |
| S7 Comm | 102 (ISO-on-TCP) | Programming and reading Siemens PLCs |
| IP | 44818 (explicit messaging) | Configuration and diagnostics; cyclic I/O runs over UDP 2222 |
| IEC 60870-5-104 | 2404 | Telecontrol in electricity grids |
| DNP3 | 20000 | Telemetry in water and energy |
| IEC 61850 (MMS) | 102 | Substation automation |
| MQTT | 1883, 8883 with TLS | IIoT telemetry via a broker |
In addition, web servers on components, HTTPS, SSH, engineering software and connections via VPN, Remote Access or a Jump Server almost always run over TCP. For deterministic I/O, TCP is deliberately avoided: ProfiNET RT uses its own Ethertype directly on Ethernet, and EtherNet/IP uses UDP for cyclic data.
🔄 What is the difference between TCP and UDP?
| Aspect | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented, with handshake | Connectionless |
| Reliability | Acknowledgement, retransmission and ordering | Best effort, no retransmission |
| Overhead | Header of 20–60 bytes | Header of 8 bytes |
| Behaviour on loss | Delay caused by retransmission | Data is lost, no delay |
| Use in OT | Configuration, SCADA polling, historian, engineering | Cyclic I/O, time synchronisation, monitoring |
| Examples | Modbus TCP, OPC UA, HTTP | SNMP, PTP (also directly on Ethernet), Syslog (classic), VoIP |
The choice is a trade-off: TCP guarantees that every command arrives, but can cause unpredictable latency when packet loss occurs. Syslog classically runs over UDP, but can also run over TCP with TLS for reliable logging.
🔐 How do you secure TCP traffic in OT?
TCP itself provides no authentication or encryption, so its security has to come from other layers. Anyone who can watch the network can read the traffic, and anyone who can connect to port 502 can write registers over standard Modbus. That became clear in January 2024 with FrostyGoop: the malware sent commands over Modbus TCP to controllers of a heating company in Lviv, after which more than 600 apartment buildings were left without heating for two days. Key measures:
- Encrypt - use TLS, Modbus/TCP Security or the security modes of OPC UA; otherwise a VPN tunnel between sites
- Restrict ports - use a Firewall or industrial firewall and ACLs to allow only the required TCP ports between known systems; protocol filtering can block write commands
- Restrict devices - Port Security on switches determines which devices may use a switch port; this concerns physical ports, not TCP ports
- Segment - separate zones according to IEC 62443 with network segmentation and a DMZ; never make OT ports directly reachable from the internet
- Monitor - track TCP connections with network monitoring, an IDS and a SIEM; new connections to port 102 or 502 are often a warning sign
- Absorb SYN floods - a SYN flood fills the queue with half-open connections; SYN cookies, rate limiting and DDoS protection limit the impact, but small PLC stacks can lock up at low volumes
In industrial networks, segmentation and Logging of TCP traffic are essential for security and troubleshooting. Both fit the duty of care under NIS2 and the Dutch Cybersecurity Act to take appropriate network security measures.
🛠️ How do you troubleshoot TCP problems in an OT network?
- Check the connection - does the handshake complete? An RST straight after SYN usually means the port is closed; no response points to a firewall or routing problem.
- Capture traffic - with Wireshark on a mirror port you can see retransmissions, duplicate ACKs and zero-window messages from an overloaded PLC.
- Watch the number of connections - many PLCs accept only a handful of simultaneous TCP connections. An extra SCADA client or scanner can push out legitimate connections.
- Tune time-outs - set the SCADA driver time-out well above the retransmission time and use application heartbeats or short keepalives, so that a dropped connection is noticed within seconds.
- Be careful with scanning - active port scans with many SYN packets can make older devices lock up; schedule them in a maintenance window.
❓ Frequently asked questions
Which layer of the OSI model does TCP work on?
TCP works on Layer 4, the transport layer of the OSI model, on top of IP at Layer 3. TCP handles reliable transfer between two applications, while IP makes sure packets reach the right device.
Is TCP suitable for real-time control?
TCP is not suitable for hard real-time control, because retransmissions after packet loss cause unpredictable delay. For cyclic I/O, protocols such as PROFINET RT and EtherNet/IP therefore use their own Ethernet frames or UDP. TCP is well suited to SCADA polling, configuration and historian traffic.
Which TCP port does Modbus TCP use?
Modbus TCP uses TCP port 502 by default. The secured variant, Modbus/TCP Security, wraps the traffic in TLS and uses port 802. Port 502 should never be reachable from the internet.
Is TCP traffic encrypted?
TCP traffic is not encrypted by default; TCP only guarantees delivery and ordering. Encryption comes from a layer above, such as TLS in HTTPS, OPC UA or Modbus/TCP Security, or from a VPN tunnel.
What is a SYN flood attack?
A SYN flood attack is a denial-of-service attack in which an attacker sends large numbers of TCP connection requests (SYN) without completing the handshake. The receiver’s queue fills up, so legitimate connections are refused. Small OT devices with limited TCP stacks are particularly vulnerable to this.
Why does a TCP connection to a PLC sometimes drop?
A TCP connection to a PLC often drops because the PLC reaches its maximum number of connections, a firewall closes an idle connection, or a network interruption is only detected late. Short keepalives or application heartbeats and correctly set time-outs in the SCADA driver prevent most of these problems.
📌 In summary
TCP is the reliable transport protocol underneath practically all modern OT communication, from Modbus TCP and OPC UA to engineering and remote access. It guarantees complete and ordered delivery, but neither timeliness nor confidentiality. Combine TCP with TLS or a VPN, restrict ports with firewalls and segmentation, and use protocols that deliberately avoid TCP for hard real-time I/O.