How TCP works: two streams and the acknowledgment rule
Three modes of a channel. Simplex: information flows in one direction only, like a radio. Half-duplex: both directions, but only one at a time, like a walkie-talkie. Full-duplex: both directions at the same time, like a phone call.
A TCP connection is two independent byte streams sharing one envelope — A→B and B→A. Each stream has its own sequence numbers (how much I have sent you has nothing to do with how much you have sent me) and its own flow-control window (a full receive buffer slows only that one direction). A packet often does double duty: data one way, acknowledgment for the other (piggybacking). Because the streams are independent, they also open and close independently — everything else follows from that.
Why the handshake is exactly three messages. Each message can confirm only one direction's sequence number. Alice sends hers (1). Bob replies with his own sequence number and, piggybacked on the same packet, the acknowledgment of Alice's (2). Now Alice knows both directions work — but Bob still does not know his packet arrived. Alice's acknowledgment of Bob's number (3) completes it. Two would leave one direction unconfirmed; a fourth would confirm nothing new.
Why the teardown is four — two times two. Closing one direction takes two messages: a FIN ("my stream is finished") and its ACK. The other direction closes the same way, on its own schedule — the peer may still have data to send after receiving a FIN, and must be allowed to finish (this intermediate state is the half-close; signalling end-of-input while still reading a response is its everyday use). The count can collapse to three when the second FIN happens to piggyback the first ACK. Afterwards the FIN sender lingers in TIME_WAIT for 2 MSL: its last ACK may have been lost, the peer will retransmit its FIN and someone must be there to answer; and the port must not be reused until the connection's late packets have died in the network.
Why anything needs an ACK at all. The network underneath returns no receipt: a packet can be lost, duplicated, delayed or reordered, and the sender hears nothing. The acknowledgment is the only feedback channel the receiver has. So every byte lives in one of two states for the sender — confirmed, or not yet. An unconfirmed byte is indistinguishable from an unsent one (packet lost? ACK lost? just slow? — the sender cannot tell), so the sender keeps it, and retransmits it, until the ACK arrives. Unacknowledged means not delivered: responsibility stays with the sender until the ACK takes it over. The ACK is also the protocol's clock: the sliding window advances on ACKs, round-trip time is measured from them, congestion control reads their rhythm. When ACKs stop, everything stops.
The general principle. Acknowledgment is the universal mechanism for transferring responsibility across an unreliable channel — queue consumers ack before the broker deletes, an HTTP response is an acknowledgment of its request, a signed delivery slip is the same shape on paper. It is not free (a round trip, plus state held at the sender), so it is deliberately omitted where loss is cheap: live video frames (a retransmitted frame is already stale), heartbeats (the next one supersedes, and absence is itself the signal), routine metrics. Pay for confirmation only when not knowing costs more than the round trip.