TCP-IP Suite

Definition: The TCP/IP suite is the practical 4-layer protocol stack, named for its two foundational protocols, that actually implements the modern internet, as opposed to the OSI model’s 7-layer theoretical reference.

How It Works

Layer	Role	Protocols
Application	End-user protocols and data formatting/session logic (collapses OSI’s 5-7)	HTTP, DNS, SSH, SMTP, TLS
Transport	Host-to-host, process-to-process delivery	TCP, UDP
Internet	Logical addressing and routing between networks	IPv4, IPv6, ICMP, IGMP
Network Access (Link)	Framing and delivery on a single physical link	Ethernet, Wi-Fi (802.11), ARP

Data flows down the stack on send (encapsulation) and up on receive (decapsulation). Each layer wraps the layer above’s output in its own header:

Application data
  -> [TCP header | data]                         = segment
    -> [IP header | TCP header | data]           = packet
      -> [Ethernet header | IP header | ... | Ethernet trailer]  = frame

At each hop through a router, the frame is stripped down to the packet, the packet’s destination IP is examined for the next-hop decision, and a new frame header is added for the next physical link, the IP packet itself (and everything inside it) is untouched by intermediate routers, only the framing changes hop to hop.

Under the Hood

The suite emerged from ARPANET-era DARPA research (RFC 791 for IP, RFC 793 for TCP, both 1981) and was standardized bottom-up from working implementations, in contrast to OSI, which was designed top-down as a committee standard before deployment. That history is why TCP/IP won: it existed and worked before OSI protocols were finished.

The “Network Access” layer is sometimes split further into Link and Physical to more closely mirror OSI’s bottom two layers, this is a documentation convention, not a protocol distinction, both concerns are handled by the same technologies (Ethernet, Wi-Fi) in practice.

The Internet Layer’s job is specifically “best-effort, unreliable, connectionless” packet delivery, IP itself makes no delivery guarantee. Reliability, when needed, is layered on top by TCP; UDP deliberately opts out of it. ICMP, also at this layer, isn’t a data-carrying protocol but a control/diagnostic one: it reports errors (destination unreachable, TTL exceeded) and carries ping/traceroute machinery.

The suite’s layering is looser in practice than OSI’s strict model suggests. TLS operates as a library sitting between transport and application rather than as a distinct layer; HTTP/3 runs its transport logic (QUIC) over UDP instead of using TCP directly, blurring the “transport vs application” line further. This flexibility, protocols composing pragmatically rather than obeying a rigid layer boundary, is part of why TCP/IP proved more adaptable than the rigidly layered OSI stack.

Port numbers, assigned by IANA, are what let the transport layer multiplex many applications over one IP address: well-known ports (0-1023, e.g. 80 HTTP, 443 HTTPS, 22 SSH, 53 DNS) are reserved for standard services, registered ports (1024-49151) for specific applications, and ephemeral ports (49152-65535, OS-assigned) for the client side of outgoing connections.

Port Number Ranges

Range	Name	Examples
0-1023	Well-known ports	80 HTTP, 443 HTTPS, 22 SSH, 53 DNS, 25 SMTP
1024-49151	Registered ports	3306 MySQL, 5432 PostgreSQL, 6379 Redis
49152-65535	Ephemeral/dynamic ports	OS-assigned for the client side of outgoing connections

Well-known ports below 1024 historically required root/administrator privileges to bind on Unix systems, a legacy security convention (a process that can bind port 80 was assumed to be trusted) that still shapes why web servers often run behind a reverse proxy that binds the low port and hands off to an unprivileged worker process.

A concrete byte count for the encapsulation diagram above: a typical HTTPS request over Ethernet adds roughly 14 bytes of Ethernet header, 20 bytes of IPv4 header (more for IPv6, whose header is a fixed 40 bytes), and 20+ bytes of TCP header before a single byte of actual HTTP data is sent, on top of whatever TLS record overhead applies. For a small API request, that overhead can easily exceed the size of the actual payload, part of why protocols like HTTP/2 and HTTP/3 invest heavily in header compression.

History: From ARPANET to Today

ARPANET originally ran the Network Control Program (NCP), not TCP/IP. The switch to TCP/IP happened on a single flag day, January 1, 1983, remembered as “flag day” in internet history, after which NCP was permanently retired.
TCP and IP were originally a single combined protocol; they were split into separate layers (RFC 791 for IP, RFC 793 for TCP) in 1981 specifically so unreliable, connectionless delivery (IP) could be reused underneath other transport protocols like UDP, rather than baking TCP’s reliability logic into the addressing layer itself.
NSFNET adopted TCP/IP as its backbone standard in 1985, cementing it as the de facto protocol suite for what would become the commercial internet through the 1990s.
The suite’s core layering (Application/Transport/Internet/Network Access) has remained stable for over 40 years even as the protocols riding on top of it changed dramatically, from Telnet and FTP in the 1980s to HTTP/3 and QUIC today.

Why It Matters

TCP/IP is not a theoretical model, it’s the literal set of protocols every device on the internet runs to communicate. Understanding its layering is what lets an engineer reason about encapsulation overhead, MTU/fragmentation issues, why NAT operates where it does (rewriting Internet-layer addresses and Transport-layer ports), and why a firewall rule written at one layer (e.g. blocking a port) behaves differently from one written at another (blocking an IP range).

Common Pitfalls

Treating TCP/IP’s 4 layers and OSI’s 7 layers as interchangeable one-to-one, they’re related but not equivalent; TCP/IP’s Application layer alone absorbs three separate OSI layers.
Assuming a lower layer can inspect or act on higher-layer payload content, encapsulation deliberately hides it, a Layer 3 router doesn’t know or care it’s carrying an HTTP request versus a database query, only Layer 4 port numbers and Layer 3 addresses are visible to it without deep packet inspection.
Ignoring MTU: each link has a maximum transmission unit (commonly 1500 bytes for Ethernet), and a packet exceeding it must be fragmented (IPv4) or rejected with a “packet too big” ICMP message requiring the sender to shrink it (IPv6, which doesn’t support in-flight fragmentation by routers).
Forgetting that IP itself is unreliable and connectionless, any ordering or delivery guarantee an application relies on comes from the transport layer above it (TCP) or the application itself, not from IP.
Confusing the “Internet” layer’s name with “the internet” as a whole, it specifically refers to the IP-addressing-and-routing layer, one piece of the full stack.
Assuming every hop between client and server actually forwards a packet unmodified, middleboxes (NAT devices, proxies, firewalls) routinely rewrite or drop packets in ways that violate the “each layer only touches its own header” idealization, which is part of why protocol evolution (like adding new TCP options) has to be done cautiously.
Overlooking that the four layers don’t map to four physical devices, a single home router typically operates across Network Access, Internet, and (via NAT) effectively touches Transport-layer port numbers too, all inside one box.

Comparison

	TCP/IP Suite	OSI Model
Layers	4	7
Status	Actually implemented and deployed	Reference/teaching framework
Origin	Grew from working ARPANET protocols	Designed top-down by ISO committee
Session/Presentation	No separate layers	Explicit, separate layers
Standardization body	IETF (RFCs)	ISO
Extensibility model	Loose, protocols compose pragmatically	Strict, layer boundaries meant to be respected

Debugging Workflow: Isolating Which Layer Failed

When an application can’t reach a remote service, working through the stack bottom-up narrows down the cause fast:

Network Access: is the interface up (ip link / ipconfig)? Any dropped or error frames counted at the interface level?
Internet: ping <ip> confirms basic reachability; traceroute shows where along the path packets stop progressing.
Transport: nc -zv host port or telnet host port tests whether a TCP handshake succeeds independent of the application protocol.
Application: curl -v or an application-specific client shows whether the transport connection works but the application-layer exchange itself fails (wrong response code, malformed data, auth failure).

Each step rules out an entire layer, if ping succeeds but nc -zv fails on the target port, the problem is narrowed to that specific port being closed or filtered, not a broader network outage.

Example

Sending an HTTP GET request encapsulates it: HTTP (Application) rides inside a TCP segment (Transport, port 443 for HTTPS) inside an IP packet (Internet, carrying source/destination IP) inside an Ethernet frame (Network Access, carrying source/destination MAC for the local hop). tcpdump -i eth0 -X shows all four layers’ headers stacked in a single captured frame.

FAQ

Why did TCP/IP win over OSI protocols? Mainly deployment timing and simplicity, TCP/IP was already running on real networks (ARPANET, then NSFNET) while the OSI protocol suite was still being finalized by committee, and TCP/IP’s looser layering proved easier to implement and extend.

Is “the internet” the same thing as “TCP/IP”? Practically yes at the protocol level, the public internet is defined by common use of the IP internet layer for interconnection, though plenty of application-layer diversity (HTTP, SMTP, custom protocols) sits on top of it.

Does every internet application use both TCP and UDP? No, an application typically picks one per use case, though some do use both for different purposes (DNS primarily UDP with TCP fallback for large responses; a game client might use UDP for real-time state and TCP for a lobby/chat channel).

Where does IPsec fit into this model? At the Internet layer, it adds authentication and encryption directly to IP packets, functioning below the transport layer, which is why IPsec VPNs can carry any transport-layer protocol transparently.

Referenced by

Dig deeper

Spot an error in this note?