2026
TCP/IP: How the Internet Actually Works
TCP and IP are two separate protocols with two separate jobs. Here is what each one does, how they fit together and why the distinction matters when something goes wrong.
TCP/IP gets treated as a single word in most conversations. People hear it early and file it away as the label for how the internet works. That understanding holds up fine right up until you need to debug something. A connection that times out, a reset that comes back instantly, a service that is unreachable for no obvious reason. Without knowing which layer is responsible, you are guessing.
The name is shorthand for two distinct protocols. IP handles routing. It moves packets from one address to another across a network of networks. TCP sits above it and makes delivery reliable. Neither protocol does the other's job. They were designed to work together, which is why they are almost always named together, but understanding what each one actually does explains a lot about how modern networking behaves when things go sideways.
IP: the unreliable foundation
The Internet Protocol is a layer 3 protocol. Its job is to deliver packets from one IP address to another. It is explicitly best-effort. No delivery guarantee, no ordering guarantee, no promise that a packet will not show up twice. That is not a flaw. It is the design.
Keeping IP simple keeps routers simple. A router running IP does not need to track state for every flow passing through it. It reads the destination address on a packet, checks its routing table and forwards the packet one hop closer to the destination. That is the whole job. The complexity of reliable delivery gets pushed out to the endpoints, which is exactly where TCP takes over.
Addressing
Every device on an IP network has an IP address. Source and destination addresses both travel in the packet header. Routers use the destination address to decide where to send the packet. The source address tells the receiver where to send its reply.
Routing
Routers forward packets hop by hop toward the destination. No single router needs to know the full path. Each one only needs to know the next hop for a given destination prefix.
Fragmentation
Different network links have different limits on how large a packet can be. IP can break a packet into smaller fragments when it hits a link that cannot carry it whole. The destination reassembles the fragments before passing the data up the stack.
TTL enforcement
Each IP packet carries a time-to-live field. Every router that forwards the packet decrements it by one. When it hits zero the packet is discarded and an ICMP Time Exceeded message goes back to the sender.
IPv4 addresses are the familiar four-number format: 192.168.1.1. Each number sits between 0 and 255. The 32-bit address space gives roughly 4.3 billion unique addresses, which the internet outgrew. IPv6 uses 128-bit addresses written in hexadecimal notation, expanding the space to a number large enough that exhaustion is not a practical concern. Most infrastructure today runs both versions side by side.
TCP: reliability on top of IP
TCP sits at layer 4. It adds everything IP deliberately left out: ordered delivery, duplicate detection and retransmission of lost segments. It does this through sequencing, acknowledgements, flow control and congestion control.
TCP is connection-oriented. Before any data flows, both sides go through a setup procedure. After the exchange is done, both sides go through a teardown. The protocol maintains state throughout the life of the connection on both machines. That statefulness is the foundation every reliability guarantee rests on.
Sequencing
Every byte in a TCP stream has a sequence number. If segments arrive out of order, the receiver holds them and waits for the gap to fill before passing data to the application. The application always sees a clean ordered stream regardless of what happened on the network in transit.
Acknowledgements
The receiver sends acknowledgements telling the sender which bytes arrived successfully. The sender keeps copies of everything it has transmitted until the acknowledgement comes back. If nothing arrives within the retransmission timeout, the sender tries again. Nothing gets discarded until delivery is confirmed.
Flow control
The receiver advertises how much buffer space it has available. The sender is not permitted to exceed that limit. This keeps a fast sender from overwhelming a slow receiver with more data than it can process before handing it to the application.
Congestion control
TCP pays attention to the network itself. Packet drops are usually a sign that a router somewhere along the path is overloaded. TCP backs off its sending rate in response. This is how TCP avoids making an already congested network worse under its own load.
The three-way handshake
A TCP connection does not start with data. It starts with a three-segment exchange. Both sides need to agree on starting sequence numbers before any application data moves, so that each knows exactly what the other has sent from the very beginning.
Client → Server
The client sends a segment with the SYN flag set. It picks a random starting sequence number and announces it in the header. This is the opening move. The client is saying it wants to connect and declaring where its numbering begins.
Server → Client
The server acknowledges the client's sequence number by incrementing it by one. It picks its own starting sequence number and sends back a segment with both SYN and ACK flags set. It is saying: I received your request, I acknowledge it, here is where my numbering begins.
Client → Server
The client acknowledges the server's sequence number. Both sides now agree on starting sequence numbers in both directions. The connection is established and data can begin to flow.
That three-segment exchange has a real cost. Every new TCP connection pays at least one full round trip before the first byte of application data can move. For a short DNS query that overhead would dominate the whole exchange, which is part of why DNS prefers UDP by default. For a connection that will carry megabytes of data the cost becomes negligible within the first few seconds.
Ports: addressing within a host
An IP address identifies a machine. A port number identifies a process on that machine. The combination of an IP address and a port is called a socket. When your browser connects to a web server over HTTPS, the full destination is not just the server IP address. It is the server IP address on port 443.
Ports below 1024 are well-known ports. Most operating systems require elevated privileges to bind to them. Port 22 is SSH. Port 25 is SMTP. Port 53 is DNS. Port 443 is HTTPS. On the client side, your browser picks an ephemeral port somewhere above 49152. That port gets released when the connection closes.
22SSHSecure remote shell access53DNSDomain name resolution, UDP first with TCP fallback80HTTPUnencrypted web traffic443HTTPSEncrypted web traffic over TLS5432PostgreSQLDefault port for Postgres database connectionsTCP versus UDP
TCP is not the only transport layer protocol. UDP, the User Datagram Protocol, also runs on top of IP. UDP skips the handshake, skips the sequence tracking and sends packets without checking whether they arrived. There is no connection state to maintain because there is no connection.
That sounds like a problem until you think about where it actually helps. A video call has no use for a retransmitted frame arriving 500 milliseconds after it was needed. By the time it gets there, the stream has moved on. A stale frame degrades the experience rather than improving it. For real-time traffic where latency matters more than completeness, UDP is the right tool for the job.
The TCP/IP model
The OSI model organises networking into seven layers. The TCP/IP model does it in four. Both describe the same fundamental principle: network communication is divided into layers of responsibility, with each layer handling a specific part of the problem. The OSI model is a useful framework for discussion. The TCP/IP model is what the actual internet implements.
Application
≈ OSI Layers 5, 6, 7
HTTP, DNS, SSH, SMTP. The protocols your software speaks directly.
Transport
≈ OSI Layer 4
TCP and UDP. Ports, delivery guarantees, segmentation.
Internet
≈ OSI Layer 3
IP. Addressing, routing, best-effort packet delivery.
Network Access
≈ OSI Layers 1, 2
Ethernet, Wi-Fi. Getting packets onto and off the physical medium.
What actually happens when you load a webpage
Walking through a real request is the fastest way to see TCP and IP working together. Here is what happens at the protocol level when you type a URL into your browser and press enter.
DNS resolves the domain to an IP address.
This uses UDP. A short question gets a short answer. If the response is too large for a single datagram, DNS falls back to TCP for that query.
Your OS creates a TCP socket targeting port 443 on the server.
Port 443 is HTTPS. The OS assigns an ephemeral source port on your end, typically somewhere in the range above 49152.
The three-way handshake runs.
SYN, SYN-ACK, ACK. Both sides agree on starting sequence numbers. No application data moves until this is complete.
TLS negotiates over the TCP connection.
The browser and server agree on a cipher suite and exchange keys. TCP carries the TLS messages as a reliable ordered byte stream.
The browser sends an HTTP GET request.
TCP segments the request if needed. IP wraps each segment in a packet with source and destination addresses.
Routers forward packets toward the destination using the IP address.
Each router reads only the IP header. It has no knowledge of TCP. It has no knowledge of HTTP. It forwards and moves on.
The server sends back the HTML.
Potentially hundreds of TCP segments. TCP on your machine resequences them. Your browser receives a clean ordered stream.
The TCP connection closes.
FIN and ACK segments run in both directions. Connection state is cleaned up on both sides.
Why this matters in practice
Most of the time TCP and IP are invisible. The operating system manages sockets. Libraries handle the protocols. Things work and there is no reason to think about the layers underneath. That changes the moment something fails.
A connection that never receives a response means the SYN segment is being dropped somewhere. A firewall rule, a routing problem, nothing listening on the target port. A connection that resets immediately means the server received the SYN and actively refused it. These are distinct failures. They point in different directions and call for different fixes. Knowing which layer is responsible is what separates a diagnosis from a guess.
Latency compounds at the TCP layer in ways that stay hidden if you only look at application metrics. A 100 ms round trip adds 100 ms to the handshake, 100 ms to the TLS negotiation and 100 ms to the first application request. That is 300 ms of overhead before any useful response data arrives. Physical distance, hop count and routing decisions all feed into this. IP-level choices have TCP-level consequences.
Both protocols have been at the core of the internet since the early 1980s. They have outlasted almost everything else from the original design. Getting a solid understanding of what each one actually does is one of those fundamentals that keeps paying off regardless of what you are building or what you are trying to fix.