TCP, UDP, IP, ICMP and ARP: the transport and internet layer protocols

Transport layer: TCP and UDP

TCP: Transmission Control Protocol

TCP is connection-oriented and reliable. Before sending data it sets up a connection with a three-way handshake (SYN, SYN-ACK, ACK). It then:

• splits data into segments and numbers them so the receiver can put them back in order;
• waits for acknowledgements and resends anything lost or damaged;
• controls the flow, so a fast sender doesn't overwhelm a slow receiver.

Use TCP when every byte must arrive correctly: web pages, email, file transfers, SSH.

UDP: User Datagram Protocol

UDP is connectionless: it sends datagrams immediately with no handshake, no acknowledgements and no resending. It checks each datagram with a checksum and simply drops damaged ones. That makes UDP light and fast, ideal when a late packet is worse than a lost one: voice and video calls, online games, live streaming and quick DNS lookups.

Internet layer

IP: Internet Protocol

IP gives every device a logical address and moves packets from the source host to the destination host, choosing a path across networks by reading the addresses in each packet's header. IP itself is "best effort": it doesn't guarantee delivery; that is TCP's job. There are two versions in use, IPv4 and IPv6.

ICMP: Internet Control Message Protocol

ICMP carries error and status messages for IP, and is part of every IP implementation. Its messages travel inside IP packets. Routers use it to report problems such as "destination unreachable" or "time exceeded". It powers two everyday tools:

• ping sends ICMP echo request messages and waits for echo replies to test reachability and delay.
• traceroute (tracert on Windows) maps each router on the path using "time exceeded" messages.

ICMP reports problems but does not fix them: packets can still be lost without any report. Many firewalls block some ICMP, so a failed ping doesn't always mean a device is down.

ARP: Address Resolution Protocol

To deliver a frame on a LAN, a device needs the destination's MAC address (48 bits, layer 2), not just its IP address (layer 3). ARP finds it:

1. The sender broadcasts an ARP request to every device on the LAN: "Who has 192.168.1.20?"
2. Only the device with that IP replies directly with its MAC address.
3. The sender stores the answer in its ARP cache for a while, so it doesn't have to ask every time.

View the cache with arp -a. RARP (Reverse ARP) did the opposite, letting a device learn its IP from its MAC; it is obsolete and has been replaced by DHCP.

Security note: ARP trusts any reply, so attackers can send fake replies (ARP spoofing) to intercept traffic. Managed switches can block this with Dynamic ARP Inspection.

Going deeper

Each protocol on this page has more detail that matters when you troubleshoot:

• TCP uses sequence numbers, windows and congestion control; a small window on a long link limits speed. See TCP in depth.
• IP carries a TTL that stops loops and a Don't Fragment bit that drives path MTU discovery. See the IPv4 header.
• ICMP powers ping and traceroute, and some of its messages must never be blocked. See ICMP, ping and traceroute.
• ARP can be spoofed on the local network; switches defend with Dynamic ARP Inspection. See ARP explained.

Real-world example: TCP and UDP side by side in a call centre

A small call centre runs its phones over the network and its customer database in the cloud. The voice traffic uses UDP: if a packet is late it is useless, so it is simply dropped and the conversation carries on with a tiny gap. The database application uses TCP, because every byte of a customer's address must arrive complete and in order, even if that takes a resend.

One Monday agents complained of choppy calls while the database felt only slightly slow. The network engineer checked the internet link and found it was full because a new PC was downloading large updates. The UDP voice packets were being lost, while TCP quietly resent its lost data. Adding a quality-of-service rule to give voice traffic priority fixed the calls, and scheduling updates out of hours fixed the rest.