TCP/IP is the foundation under almost all communication on the internet. When you open a website, send an email or make a call over the internet, TCP/IP is what makes sure data is split into packets, finds its way through a sea of networks, and is put back together correctly at the recipient.
The name covers a whole family of protocols, but three of them carry most of the load: IP, which finds the way, TCP, which makes sure everything arrives, and UDP, which gives up the guarantees for speed. This guide covers all three. If you’re completely new to the subject, start with our introduction to network protocols.
The layers of the TCP/IP model
TCP/IP is built in layers, where each layer solves one task and trusts the layer below to handle its own. A program sending a message doesn’t need to know whether it travels over fiber, Wi-Fi or a mobile network, and the router forwarding the packet doesn’t need to know whether it contains a website or an email.
| Layer | Job | Examples |
|---|---|---|
| Application | What the programs talk about | HTTP, DNS, SMTP, SSH |
| Transport | Delivery between two programs | TCP, UDP, QUIC |
| Internet | Addressing and routing through the networks | IPv4, IPv6 |
| Link | The actual transfer on the local network | Ethernet, Wi-Fi |
You’ll also come across the OSI model with seven layers. It’s a more theoretical division, but OSI layers 3 and 4 correspond to the internet and transport layers here, which is why people talk about IP as “layer 3” and TCP as “layer 4”.
IP: finding the way
IP (Internet Protocol) has one job: getting a packet from one computer to another, however many networks lie between them. Everything sent over the internet is split into packets, and each packet gets an IP header containing, among other things, the sender’s and recipient’s addresses. In the end, it’s all just bytes, that is, bits with the value 0 or 1, which we explain in the guide to binary numbers.
The address is the key. An IP address identifies a network connection and is built so that the first part points to a network and the rest to a particular device in it. How addresses are built, and how networks are split up with subnet masks, is covered in the guide to IP addresses.
No single machine knows the whole route to the recipient. Instead, the packet is sent from router to router. Each router looks at the destination address, looks up in its routing table which neighbor is closest to the destination, and passes the packet on to it. A packet from Copenhagen to a server in Frankfurt typically passes through anywhere from a handful to a couple of dozen routers, and two packets in the same conversation can easily take different routes. So a packet can’t circulate forever if routing goes in a loop, it has a lifetime (TTL in IPv4, hop limit in IPv6), which is counted down at every router and gets the packet discarded when it reaches zero.
The most important thing to understand about IP is what the protocol doesn’t promise. IP is “best effort”: packets can be lost when a router is overloaded, they can arrive in a different order than they were sent, and in rare cases they can arrive twice. IP doesn’t detect it and doesn’t fix it. That’s a deliberate choice that keeps routers simple and fast, and leaves reliability to the layer above, usually TCP.
Packets also have a maximum size that depends on the network (MTU), typically around 1,500 bytes on ordinary Ethernet. If a packet is too big for a network along the way, it either has to be split up or sent again at a smaller size, and that’s one of the classic sources of tricky network errors.
Today two versions run side by side. IPv4 has 32-bit addresses and so around four billion possible addresses, which stopped being enough long ago. IPv6 has 128-bit addresses and a simpler packet header, and an ever larger share of traffic uses it. For most websites, it simply means the server should be reachable on both.
TCP: reliable delivery
TCP (Transmission Control Protocol) builds a reliable layer on top of unreliable IP. To the program using it, a TCP connection looks like a pipe: bytes put in at one end come out at the other, in the same order and without gaps. Under the surface, TCP works hard to maintain that illusion.
It starts with the two parties establishing a connection with the so-called three-way handshake:
- The client sends a SYN packet with its starting sequence number.
- The server replies with SYN-ACK: it acknowledges the client’s number and sends its own.
- The client replies with ACK, and the connection is open.
The handshake costs one round trip before any data can be sent, and with TLS encryption on top, it costs more. That’s one of the reasons newer protocols like QUIC try to merge the two steps.
The reliability itself rests on sequence numbers and acknowledgments. Every byte sent has a number, and the recipient continuously reports how far it has received everything in order. If no acknowledgment arrives within a certain time, or the sender sees the recipient repeatedly asking for the same byte, the missing data is sent again. Packets that arrive out of order are held back and sorted before being passed on to the program. A checksum in every packet catches data that has been corrupted along the way.
TCP also has to avoid sending faster than the recipient and the network can handle. Flow control takes care of the recipient: it advertises a window saying how many bytes it has room for, and the sender stays within it. Congestion control takes care of the network, which the sender can’t see into. A new connection starts cautiously and speeds up quickly as long as everything goes well (slow start). If packets are lost, it’s taken as a sign that a router along the way is overloaded, and the pace is reduced. That’s the mechanism that lets millions of connections share the same wires without choking each other, and it’s also why a fresh connection doesn’t use all the bandwidth right away.
The price of reliability is waiting. Because TCP delivers everything in order, all subsequent data has to wait if one packet is lost, until it has been sent again. For a file transfer that doesn’t matter, but for a video call, a frame that arrives too late is worthless. That’s where UDP comes in.
When one of the parties is done, the connection is closed cleanly with FIN packets in both directions, so no data is lost at the last moment. Many programs keep the connection open and reuse it, though, because opening a new one is expensive.
UDP: fast and without guarantees
UDP (User Datagram Protocol) is TCP’s minimalist sibling. There’s no handshake, no acknowledgments, no retransmission and no sorting: a UDP packet is sent off, and the sender’s job is done. If it doesn’t arrive, UDP doesn’t notice.
That sounds like a bad deal, but it’s exactly what many programs need. A DNS lookup is one question and one answer, and it’s faster to simply ask again than to open a connection first. Video calls, live streaming and online games would rather skip a lost moment than wait for it. And because UDP doesn’t decide anything, programs can build the reliability they need on top themselves. That’s exactly what QUIC does: it provides TCP’s guarantees, but without one lost packet stopping all the others, and it’s the foundation of HTTP/3.
Ports
The IP address gets the packet to the right machine, but many programs run on that machine. The port number in the TCP and UDP header decides which program the packet is for. Servers listen on fixed ports, such as web servers on port 443 for HTTPS and 80 for HTTP, SSH and SFTP on 22 and DNS on 53, while the client gets a random port for each connection. The combination of the two addresses and the two ports uniquely identifies a connection, and ports are also what a firewall typically opens and closes.
A page view from start to finish
Let’s pull the threads together and follow what happens when you type an address into the browser and press enter.
First the name has to be translated into an IP address. The browser asks via DNS, usually in a single UDP packet to port 53, and gets an address back. Then it opens a TCP connection to port 443 at that address with the three-way handshake, and on top of it negotiates an encrypted TLS connection. Underneath it all, IP wraps every single piece with sender and recipient and sends it from router to router, without any of them knowing it’s a website.
Only now can the browser send its actual request, an HTTP message asking for the page. The server’s response is split into many TCP segments, each with its own IP header and possibly taking different routes. If one of them is lost, TCP sends it again, and the browser gets everything in the right order without knowing anything went wrong. The page refers to images, stylesheets and scripts, and for each of them part of the process is repeated, often over the same connection. How HTTP manages that part, and how HTTP/3 moves it all onto QUIC and UDP, you can read in our guide to HTTP.
Frequently asked questions
Is TCP/IP the same as the internet?
Almost. The internet is the network of networks, and TCP/IP is the shared set of rules that lets them talk to each other. The same protocols are also used in closed networks, for example in an office.
When do you use UDP instead of TCP?
When low latency matters more than everything arriving, as in calls and games, or when the program handles reliability itself, like DNS and QUIC.