Chapter · TCP and UDP
TCP, step by step
The handshake, the byte stream, acknowledgements and resends, the receiver's window, congestion, and how a connection ends.
- 05TCP starts a connection4 minBefore TCP sends data, two endpoints exchange three slips and agree their starting numbers. The handshake sets those numbers up. It does not promise that the path stays healthy.
- 06TCP is a byte stream4 minTCP gives an application an ordered stream of bytes. The segments it cuts that stream into are its own business, and they are not the application's messages.
- 07ACKs, resends and waiting5 minA TCP acknowledgement is not a receipt for a strip. It names the next byte the receiver expects. A loss is found either when the same acknowledgement arrives three times, or when a timer runs out, and what it costs the program is waiting.
- 08Flow control: the receiver's room4 minEvery TCP acknowledgement carries a second number, the window, which is how many more bytes the receiver has room for. It protects the receiver's buffer and says nothing about the network. A window of zero stops the sender until the receiver opens it again.
- 09Congestion: the crowded desks5 minNobody tells a TCP sender how much a path can carry, so it finds out. It starts small, grows until a segment is dropped, then cuts its window and grows again. Real stacks differ in the details. That limit is separate from the receiver's window, and whichever is smaller rules.
- 10Finishing, half-close, reset4 minA TCP connection is two byte streams, one each way, and each is closed on its own. A FIN ends one direction politely, a RST throws the whole connection away, and the side that closed first keeps some state for a while.
Start at 05 and read down — the order is the order things get easier in. Or take the one with your part in it; every article stands on its own, and links back to whatever it needs.