Introduction — What TCP promises
Start from the premise that in an IP-only world data gets lost, reordered, and duplicated, then grasp TCP's three promises, the division of labor with UDP, and the roles of port numbers and sockets.
Stuck at "the connection timed out"
You found the connection-timeout line in the log. A retry fixed it. But the "why" remains unknown — this is where TCP troubleshooting stops for most people. Even with a packet capture open, the columns of seq, ack, and win numbers say nothing to you.
The shortcut to reading them is not memorizing TCP features but first grasping what foundation TCP stands on and what it is trying to promise. The starting point is the nature of IP, which sits below TCP. IP carries packets (small parcels of data) to the destination host, but its delivery is "best effort" — it does its best, yet guarantees no outcome. Concretely, this is what happens on the path.
On this foundation, the job of "delivering a file without losing a single byte, in order" is taken over from the application by TCP (Transmission Control Protocol).
IP goes only as far as "it will probably arrive." On top of it, TCP keeps three promises while UDP deliberately passes things through almost untouched. Neither is superior — their roles differ.
TCP's three promises — the backbone of this course
TCP seems to have many mechanisms, but every one of them is a tool for keeping one of the following three promises. In every chapter of this course, we come back to which promise the mechanism at hand serves.
| Promise | Meaning | Tools that realize it | Chapters |
|---|---|---|---|
| Reliable delivery — noticing when it fails | Detect gaps and retransmit | Sequence numbers + ACK + retransmission timer | Chapters 2–3 |
| In order | Fix reordering and duplication before handing data over | Sequence numbers + receive buffer | Chapters 3 and 6 |
| Paced to the peer and the network | Never send faster than receiver and path allow | Window (flow control) + cwnd (congestion control) | Chapters 4–5 |
UDP (User Datagram Protocol), on the other hand, deliberately makes none of these promises. It is a thin layer that adds only port numbers and a minimal checksum to IP's best effort. That is not laziness — it is the option for uses where retransmission and in-order waiting get in the way (video calls, online games, DNS queries, and so on), because TCP's three promises always come with delay as their cost.
Practice 1-1 — IP's properties and the TCP/UDP division of labor
Being able to state precisely what IP does not do for you is the starting point for understanding TCP.
Q1. If you send data over IP alone (no TCP), which combination of things can ordinarily happen along the path?
IP delivery is 'best effort.' Packets are silently dropped when router queues overflow, overtaken when they take different routes, and duplicated as a side effect of retransmission machinery. And IP itself neither detects nor reports any of it. TCP's design begins by accepting this foundation that guarantees nothing. Preserved ordering, guaranteed delivery, and reported anomalies are all properties IP does not have.
Q2. In which situation is choosing UDP over TCP appropriate?
UDP is a thin layer that hands IP's best effort to the application almost as-is. In a video call, a retransmitted copy of audio from 0.1 seconds ago arrives too late to be useful, so 'give up on gaps and move on' gives a better experience — that is UDP territory. File transfer and email cannot tolerate a single missing byte, so they belong to TCP. Note that tamper protection is the job of TLS and friends, not of TCP or UDP.
Q3. Which of these does TCP not promise?
TCP promises 'reliable delivery (noticing when it fails), in order, paced to the peer and the network' — but there is no time guarantee anywhere. If anything, retransmissions and waiting push delay upward. 'TCP, yet slow' is not a broken promise; it is TCP keeping its promises at the cost of speed — and that viewpoint underpins this whole course.
Port numbers and sockets — pinpointing the mouth of the conversation
An IP address identifies "which host," but on the host that receives the data, a web server, a database, and SSH are all running at once. The additional number that identifies which program on that host the data is for is the port number (0–65535; HTTPS is 443, SSH is 22, and so on).
The communication endpoint identified by the pair IP address : port number is called a socket. From a program's point of view, a socket is "a pipe of bytes connected to the peer": you pour data in with send() and take it out with recv() (a surprising property of this pipe is the star of Chapter 6).
The important point here is that a single TCP connection is not identified by the destination alone. A connection is identified by the
(source IP, source port, destination IP, destination port)
4-tuple. That is why tens of thousands of clients can connect to port 443 of a single server at the same time — the destination side is identical, but if the source IP or source port differs (the client side gets a free number assigned automatically), it is a different connection.
This course's motto: when you look at a capture or an incident log, ask — which promise is being broken right now: delivery, ordering, or pacing?
Practice 1-2 — Port numbers and sockets
Let's confirm the role of the 'other number' that an IP address alone cannot cover.
Q4. Which is the correct reason a port number is needed in addition to an IP address?
An IP address only identifies 'which host.' On a single host, a web server, SSH, a database, and more are all waiting for traffic at the same time, so a separate number is needed to identify 'which door on that host.' That is the port number (e.g., HTTPS is 443). Routers forward by looking only at IP addresses, and encryption is the job of TLS and friends.
Q5. Many clients can connect to port 443 of one server simultaneously. Why can the server keep the individual connections apart without mixing them up?
A connection's identifier is not the single destination point but the 4-tuple (source IP, source port, destination IP, destination port). Even if every destination is 443, a different source IP or source port makes it a different connection. One end of this 4-tuple — your own IP:port endpoint — is a socket. The 4-tuple stars again in Chapter 2's TIME_WAIT and in the Chapter 7 cases.
Key takeaways from this chapter
- IP is best effort — it loses, reorders, and duplicates. And it tells no one
- TCP's promises are three — reliable delivery (noticing when it fails), in order, paced to the peer and the network. There is no time guarantee
- UDP trades the promises for low latency. Choose by use case
- A connection is identified by the 4-tuple (source IP, source port, destination IP, destination port)
In the next chapter, we follow — packet by packet — the ritual in which both ends of this 4-tuple agree "I am about to start counting from this number": the three-way handshake.