Network protocol dependencies

2026-06-05

Almost every protocol you name is a passenger riding inside another one. “HTTPS runs over TLS over TCP over IP” isn’t a slogan — it’s a literal nesting of headers, each layer wrapping the one above before handing it down. Learn the stacking rules and a hundred acronyms collapse into four tiers.

Encapsulation is just “runs on top of”

When protocol A runs on protocol B, B treats A’s entire message — header and all — as opaque payload, wraps it in B’s own header, and passes it down. The receiver unwraps in reverse. So a single HTTPS request on the wire is a set of nested envelopes:

[ IP header [ TCP header [ TLS record [ HTTP request ] ] ] ]

Each layer only talks to the layers directly above and below it. TCP has no idea it’s carrying TLS; IP has no idea it’s carrying TCP. That ignorance is the whole point — it’s what lets you put a brand-new application protocol on top of TCP without changing a single router. This is the TCP/IP model as it actually runs: application on top, then (optionally) a security layer, then a transport, then the network layer that every packet bottoms out in.

The map

Here is the dependency graph — read it top to bottom, every arrow meaning “runs on top of.” Everything terminates at IPv4/IPv6, because on the public internet there is nothing below IP that an application ever addresses directly.

The classic secure stack, and its cleartext twins

Most “secure” application protocols are not separate protocols at all — they are the cleartext protocol wrapped in TLS. HTTPS is HTTP inside a TLS record; SMTPS, IMAPS, POP3S, and LDAPS are the same trick for mail and directory traffic. The pattern is identical every time:

The cleartext siblings skip the middle box and go straight onto TCP. TLS itself is a tenant of TCP — it needs the reliable, ordered byte stream TCP provides, then layers encryption and authentication on top. That’s why a TLS handshake can only begin after the TCP three-way handshake completes.

Why HTTP/3 is the odd one out

For decades the rule was simple: web traffic is HTTP over TCP, encrypted with TLS. HTTP/3 breaks the pattern. It does not run on TCP at all — it runs on QUIC, and QUIC runs on UDP.

The subtle part: QUIC is not “just UDP.” QUIC folds the transport features TCP used to provide (reliability, ordering, congestion control, multiplexed streams) and TLS 1.3 into a single protocol that lives in user space on top of UDP. So there is no separate TLS box in the HTTP/3 path — encryption is baked into QUIC itself. Drawing HTTP/3 as “HTTP/3 → TLS → UDP” is wrong; the correct chain is:

HTTP/3  →  QUIC (TLS 1.3 built in)  →  UDP  →  IP

This is why HTTP/3 connections establish faster (the crypto and transport handshakes are combined) and survive a network change without a full reconnect — state QUIC keeps that TCP+TLS could not.

Protocols that speak two transports

A few application protocols are not loyal to one transport. DNS is the textbook case: it runs over UDP for the small, fast, fire-and-forget queries that make up the bulk of lookups, and falls back to TCP when a response is too large for a single datagram or when zone transfers need a reliable stream. SIP, the call-setup protocol behind VoIP, is the same — deployable over either UDP or TCP (and TLS for SIPS) depending on what the network and the message size demand. On the map these are the nodes with arrows fanning out to both TCP and UDP.

The protocols that skip TCP and UDP entirely

It’s tempting to assume everything sits on TCP or UDP, but a whole class of protocols rides directly on IP — IP carries them by protocol number, with no transport layer in between:

• SCTP and DCCP are themselves transport protocols, peers of TCP/UDP, so naturally they sit straight on IP.
• OSPF, the interior routing protocol, is its own IP protocol (number 89) — no TCP, no UDP. Its routing cousins differ: BGP runs over TCP (port 179) and RIP runs over UDP (port 520).
• IPsec (its ESP and AH headers) protects traffic at the IP layer itself, so it lives directly on IP.
• GRE is a generic tunnelling protocol that wraps one packet inside another straight over IP.
• ICMP and IGMP are the control and group-management protocols of IPv4; ICMPv6 and MLD play those roles for IPv6. A ping is an ICMP Echo carried directly in an IP packet — there is no port number because there is no transport layer.

These are the dashed boxes on the map: same row spirit as the transports, but they bypass TCP/UDP and attach straight to IPv4/IPv6.

Everything bottoms out at IP

Whatever the path — through TLS, through QUIC, through a bare transport, or straight onto the network layer — every arrow eventually lands on IPv4 or IPv6. The transports (TCP, UDP, SCTP, DCCP) and the direct-on-IP protocols all ride on both versions; the application above almost never cares which one is underneath, because IP’s addressing and routing job is the same in either generation. That uniform foundation is exactly what lets the tower above it grow new floors — a new application protocol, a new security layer, even a new transport like QUIC — without the internet’s routers needing to learn a thing.

TL;DR: “Runs on top of” is literal encapsulation — each layer wraps the one above as opaque payload. Secure app protocols (HTTPS, SMTPS, IMAPS, POP3S, LDAPS) go app → TLS → TCP → IP; their cleartext twins skip TLS. HTTP/3 is special: it rides QUIC over UDP, with TLS 1.3 baked into QUIC rather than a separate layer. DNS and SIP speak both TCP and UDP. SCTP, DCCP, OSPF, IPsec, GRE, and ICMP/IGMP (plus ICMPv6/MLD) skip the transport layer and sit straight on IP. Trace any protocol down far enough and it always bottoms out at IPv4/IPv6.

← network