What is TCP/IP? (The protocol suite the internet runs on)

What TCP/IP actually is

TCP/IP is the family of protocols that the internet runs on. It takes its name from its two most important members — the Transmission Control Protocol (TCP) and the Internet Protocol (IP) — but those names are shorthand. The full suite includes dozens of protocols working together: UDP, ICMP, ARP, DHCP, DNS, and application protocols like HTTP, SMTP, and SSH. When people say “the TCP/IP stack,” they mean this whole layered collection, not just the two protocols in the name.

What makes it all hang together is that the protocols are organized into layers. Each layer has one job, talks only to the layers directly above and below it, and treats everything else as a black box. That separation is what let the internet grow without a redesign: swap out the Wi-Fi at the bottom or invent a new app at the top, and the layers in between neither know nor care.

The four-layer TCP/IP model

The practical description of the stack has four layers. From the bottom (closest to the physical wire) to the top (closest to your application):

• Link layer. Moves data across a single hop — Ethernet, Wi-Fi, or a fiber link between two routers. It deals in frames and hardware (MAC) addresses, getting bits to the next device on the same local network.
• Internet layer. Home of IP. It gives every host a global address and routes packets across many links and networks, hop by hop, until they reach the destination. This is the layer that makes it a network of networks.
• Transport layer. Home of TCP and UDP. It connects programs rather than just machines, using port numbers to keep your browser tab, email client, and video call separate. TCP adds reliability here; UDP keeps it lean.
• Application layer. The protocols your software actually speaks — HTTP for the web, DNS for name lookups, SMTP and IMAP for mail, SSH for remote login. It defines the meaning of the data; the layers beneath it only worry about delivery.

How it compares to the OSI model

You will often hear networking described with seven layers instead of four. That is the OSI model — a reference framework built for teaching and standard vocabulary. The two describe the same journey at different resolutions. OSI splits the TCP/IP Application layer into three (Application, Presentation, Session) and splits the TCP/IP Link layer into two (Data Link, Physical). The Transport and Network layers line up almost one-to-one with TCP/IP's Transport and Internet layers.

In practice, the internet is built on TCP/IP, while OSI is the shared language people reach for when they say things like “that's a layer 7 problem” or “the load balancer works at layer 4.” If you want the full seven-layer breakdown and how the numbering maps across, see What is the OSI model?.

IP's job: addressing and routing

The Internet Protocol has two responsibilities: give every host an address, and move packets toward that address. An IP address is the label that tells the network where a device is — for the full explanation of what an address is and what a website can learn from yours, see What is an IP address?. IP delivery itself is deliberately simple, described by two words worth understanding:

• Best-effort. IP promises only to try to deliver each packet. Packets can be lost, duplicated, delayed, or arrive out of order, and IP neither detects nor fixes any of that — it just forwards each one toward the next hop and moves on.
• Connectionless. Each packet is routed independently, carrying its own source and destination address. There is no “call” set up in advance and no memory of previous packets — two packets in the same conversation can even take different paths.

By itself that is unreliable, but the simplicity is a feature: because IP asks so little of the network in the middle, routers can be fast and stateless, and the hard work of making delivery trustworthy is pushed to the endpoints. You can watch IP's hop-by-hop routing with a traceroute, which shows each router a packet passes through on its way to a destination.

TCP's job: a reliable, ordered stream — and UDP's alternative

TCP sits on top of IP and turns that best-effort delivery into something you can trust. When your application hands TCP a stream of bytes, TCP:

• Establishes a connection first, using the three-way handshake (SYN, SYN-ACK, ACK), so both sides agree they are talking.
• Numbers every byte so the receiver can reorder data even if the underlying packets arrive scrambled.
• Acknowledges what arrived and retransmits what didn't, so nothing is silently dropped.
• Controls its sending rate with flow and congestion control, so it overwhelms neither the receiver nor the network in between.

The result is a reliable, ordered, bidirectional stream of bytes — exactly what a web page, file download, or email transfer needs.

Not everything wants that overhead. The User Datagram Protocol (UDP) is the transport layer's other main option: connectionless, it does almost nothing beyond adding port numbers and a checksum on top of IP — no handshake, no acknowledgements, no retransmission, no ordering. That makes it lightweight and fast, which is why it is used for DNS lookups, live video and voice, and online games, where a slightly late packet is worse than a lost one. For a side-by-side breakdown, see TCP vs UDP.

Encapsulation: how your data gets wrapped for the journey

Layers cooperate through a mechanism called encapsulation. As your data travels down the stack, each layer wraps what it received from the layer above in its own envelope by adding a header. Walk it through concretely, using a web request:

1. Application layer. Your browser builds an HTTP request — “GET /index.html” plus some headers — and hands those bytes down to TCP.
2. Transport layer. TCP prepends a header (source and destination ports, sequence and acknowledgement numbers, flags); the result is a TCP segment.
3. Internet layer. IP takes the whole segment as its payload and prepends a header (source and destination IP addresses, time-to-live, and so on); the result is an IP packet.
4. Link layer. The link layer wraps the whole packet in a frame header and trailer (MAC addresses and an error-check field); the result is a frame that goes out onto the wire or the air.

So the same slice of your HTTP request ends up nested like a set of envelopes: HTTP data inside a TCP segment inside an IP packet inside a link-layer frame. Each header is added by the layer that needs it and read only by its counterpart on the other side. At the destination the process runs in reverse — decapsulation — each layer stripping and acting on its own header before passing the payload up, until your HTTP request emerges intact at the server. Along the way, routers rewrite the link-layer frame header at every hop (the next-hop MAC address changes) while the IP addresses inside stay the same end to end — exactly the division of labor the layering is designed to give you.

“TCP/IP” usually means the whole suite

When someone says a device “speaks TCP/IP,” they almost never mean literally just TCP and IP. They mean the entire internet protocol suite — including UDP, ICMP for control and error messages (what traceroute and ping rely on), ARP and DHCP for local addressing, and application protocols like DNS. The two headline names stuck because they are the load-bearing middle of the stack.

How a real request flows through the stack

Put it together and follow what happens when you type an address into your browser and hit enter:

1. Name to address. Your browser needs an IP address, not a name, so it first does a DNS lookup — typically a small UDP exchange — to turn the domain into one. (How DNS works covers this step.)
2. Connection setup. TCP opens a connection to that IP address on the web server's port (443 for HTTPS) with the three-way handshake.
3. Request goes down the stack. Your HTTP request is encapsulated into a TCP segment, then an IP packet, then link-layer frames, and sent out. IP forwards the packets hop by hop across many routers — best-effort, connectionless — while TCP quietly acknowledges what arrives and resends anything that goes missing.
4. Reassembly and reply. The server's stack decapsulates each frame back up through IP and TCP, reassembles the ordered byte stream, and hands the request to its web software. The response travels back the same way, and your browser reassembles and renders it.

All of that — the name lookup, the handshake, the wrapping and unwrapping, the routing — happens in the time it takes a page to appear.

Frequently asked questions

Is TCP/IP one protocol or many?

Many. TCP/IP is named after two protocols — TCP and IP — but the term is used colloquially for the whole suite, including UDP, ICMP, ARP, DNS, DHCP, and application protocols like HTTP. “The TCP/IP stack” means the entire layered set, not just the two headline protocols.

What is the difference between TCP/IP and OSI?

The TCP/IP model is the practical four-layer description of the real internet; the OSI model is a seven-layer reference framework used mainly for teaching and shared vocabulary. They describe the same journey at different resolutions — see What is the OSI model? for the full mapping.

How do IP and TCP work together?

IP handles addressing and routing, forwarding packets best-effort and connectionless with no guarantees. TCP runs on top and adds reliability — numbering bytes, acknowledging what arrived, retransmitting what was lost, and reassembling an ordered stream. IP gets packets roughly there; TCP makes the delivery trustworthy.

Related reading

• What is an IP address? — the addressing that the Internet layer is built around.
• TCP vs UDP — the two transport-layer choices and when each one wins.
• What is the OSI model? — the seven-layer reference framework and how it maps onto TCP/IP.
• How DNS works — the application-layer lookup that turns names into the IP addresses TCP/IP routes to.
• Traceroute explained — watch IP's hop-by-hop routing happen in real time.
• Networking glossary — quick definitions for the terms in this article and more.