TCP vs UDP: Handshake, Flow and Congestion Control

The network layer gets a packet to the right machine; the transport layer gets the data to the right program on that machine. The internet offers two main transport protocols with opposite philosophies. TCP turns IP's unreliable packets into a reliable, ordered stream of bytes and pays for it with setup time and overhead. UDP adds almost nothing to IP and leaves reliability, if it is needed at all, to the application. Interviewers ask about both, and about the handshake and windows in detail.

What the transport layer does

• Process-to-process delivery using 16-bit port numbers (0 to 65,535).
• Multiplexing and demultiplexing: many applications on one host share the network, and each arriving segment is handed to the right socket.
• In TCP only: connection setup and teardown, reliability, ordering, flow control and congestion control.

A socket is one endpoint: an IP address plus a port. A TCP connection is identified by four values (source IP, source port, destination IP, destination port), so one web server on port 443 can hold thousands of connections at once: each comes from a different client address or port.

The UDP datagram

UDP's header is a fixed 8 bytes; TCP's is 20 bytes before options. Side by side:

That is all. No connection, no sequence numbers, no acknowledgements. Each sendto call produces one datagram, and the receiver gets it whole or not at all, so UDP preserves message boundaries. A lost or reordered datagram is the application's problem.

The TCP segment

The flags that matter most: SYN opens a connection, ACK says the acknowledgement number is valid, FIN says "I have no more data", RST aborts a connection at once, and PSH asks the receiver to pass data to the application without waiting. TCP numbers bytes, not segments, and SYN and FIN each consume one sequence number.

Opening a connection: the three-way handshake

Suppose the client picks an initial sequence number (ISN) of 100 and the server picks 300. Real ISNs are unpredictable 32-bit values, chosen so old or forged segments are unlikely to fit.

1. The client sends a SYN carrying its initial sequence number, 100, and enters SYN_SENT. The server, listening, receives it and enters SYN_RECEIVED.
2. The server answers SYN-ACK: its own ISN, 300, and ack 101, because the SYN used up number 100 and 101 is the next byte it expects. On receipt the client is ESTABLISHED.
3. The client acknowledges the server's ISN with ack 301; its seq is 101, and data may ride in this very segment. The server is now ESTABLISHED too: each side has announced its ISN and heard it acknowledged.

In short: SYN (seq = 100), SYN-ACK (seq = 300, ack = 101), ACK (seq = 101, ack = 301).

Three messages are the minimum because each side must announce its own ISN and hear it acknowledged. With only two, the server could never be sure the client received its ISN, and an old duplicate SYN arriving late could open a connection nobody asked for.

Closing a connection: the four-way termination

TCP is full-duplex, so each direction is closed separately with its own FIN. Between the two FINs one direction is closed while the other may still carry data: a half-close. Suppose the client's next sequence number is 500, the server's is 800, and the server has no more data to send.

1. The client has no more data and sends FIN, seq 500: FIN_WAIT_1. The server's TCP receives it and moves to CLOSE_WAIT, waiting for its application to finish.
2. The server acknowledges at once, ack 501, since the FIN used number 500. The client is in FIN_WAIT_2: its direction is closed, but the server may still send data, a half-close.
3. When its application closes, the server sends its own FIN, seq 800, and enters LAST_ACK. The client, receiving it, enters TIME_WAIT.
4. The client's final ACK, ack 801, reaches the server, which closes. Steps 2 and 3 often travel as one segment, giving three in all.
5. The client waits two maximum segment lifetimes before closing, in case its last ACK was lost and the FIN comes again, and so stray segments of this connection die out first.

The side that closes first waits in TIME_WAIT for twice the maximum segment lifetime (2 × MSL; Linux uses a fixed 60 seconds): if its last ACK is lost, the server will resend its FIN and the client must still be there to answer, and delayed segments of this connection must die out before the same four values are reused.

Reliability: sequence numbers, ACKs and retransmission

TCP's acknowledgements are cumulative: "ack = 1,101" means "I have every byte before 1,101". Take the connection above, where the client's data starts at byte 101, and send five segments of 1,000 bytes. Segment 2 is lost.

1. The sender's data starts at byte 101, in segments of 1,000 bytes. The first arrives and the receiver acknowledges 1,101: it holds every byte before that.
2. The second segment, bytes 1,101 to 2,100, is lost on the way. Nothing tells the sender yet, and it keeps sending while its window allows.
3. Segment 3 arrives with a gap before it. The receiver buffers it but can only repeat ACK 1,101, since acknowledgements are cumulative: a duplicate ACK.
4. Segments 4 and 5 arrive and are buffered too, and each brings another ACK 1,101. Three duplicates say one segment is missing while later ones get through.
5. The sender resends seq 1,101 at once instead of waiting for its timer. It fills the gap, and the receiver acknowledges 5,101 in one go because the rest was already buffered.

The sender learns of the loss in one of two ways:

• Timeout. Each unacknowledged segment has a retransmission timer (RTO), computed from a smoothed RTT estimate plus a margin for its variation. When it expires, the segment is resent and the RTO doubles.
• Fast retransmit. Three duplicate ACKs strongly suggest one segment was lost while later ones arrived, so the sender resends it at once without waiting for the timer, as above.

Once the gap is filled the receiver acknowledges 5,101 in one go, because bytes 2,101 to 5,100 were already buffered. With the SACK option, the receiver can also say exactly which blocks it holds, so only missing data is resent.

Flow control: the sliding window

The receiver has a finite buffer. In every segment it advertises rwnd, the free space left, and the sender keeps the bytes sent-but-unacknowledged at or below it. When rwnd is 0 the sender stops and probes with small segments on the persist timer. Number the bytes from 1 for simplicity and take a 4,000-byte buffer with a 1,000-byte maximum segment size (MSS):

1. The buffer is empty, so the receiver advertises 4,000 bytes. The sender sends four segments and must then stop, whatever its own speed.
2. All four arrived, but the application has read only 1,000 bytes, so 3,000 sit in the buffer and the window is 1,000. The window slides on to segment 5.
3. Segment 5 fills the buffer and the application has stopped reading: the window is 0. The sender stops, probing now and then with a tiny segment so it hears when space opens.
4. The application reads 2,000 bytes, the receiver advertises a window of 2,000, and the sender may send two more segments.

The window "slides" forward as acknowledgements arrive. The 16-bit field caps rwnd at 65,535 bytes, so fast long links use the window scale option to multiply it.

Congestion control

Flow control protects the receiver; congestion control protects the network. The sender keeps a congestion window (cwnd) and may have at most min(rwnd, cwnd) bytes in flight. The classic algorithm (TCP Reno, the textbook model) has these parts:

• Slow start. cwnd starts small (1 MSS in the textbook; modern stacks such as Linux start at 10 MSS) and grows by 1 MSS for every ACK, so it doubles every RTT, until it reaches the slow-start threshold ssthresh.
• Congestion avoidance. Above ssthresh, cwnd grows by about 1 MSS per RTT (additive increase).
• On a timeout: ssthresh = cwnd / 2, cwnd = 1 MSS, and slow start begins again (both Tahoe and Reno).
• On three duplicate ACKs: fast retransmit the lost segment; Reno then sets ssthresh = cwnd / 2 and continues from cwnd = ssthresh (fast recovery), skipping slow start. Tahoe drops cwnd to 1 MSS instead.

Worked example

Initial ssthresh = 16 MSS, cwnd starts at 1 MSS, and a timeout happens in round 9.

The timeout at cwnd = 20 sets ssthresh = 10 and cwnd = 1, and the second slow start stops at the new threshold: 10 in round 14, not 16. Three duplicate ACKs instead would have let Reno continue from cwnd = 10 in round 10.

1. Slow start doubles cwnd every round, 1, 2, 4, 8, until it reaches ssthresh = 16 in round 5. From there congestion avoidance adds one MSS a round: 17, 18, 19, 20.
2. A timeout in round 9, at cwnd = 20, halves the threshold to 10 and drops cwnd to 1. Slow start runs again but stops at the new threshold: 10, not 16, in round 14, then grows by one a round.
3. Had three duplicate ACKs signalled the loss instead, Reno would halve the threshold the same way but continue from cwnd = 10 (fast recovery), skipping slow start: the sawtooth of AIMD.

This sawtooth is called AIMD (additive increase, multiplicative decrease). Linux's default algorithm today is CUBIC, which grows cwnd as a cubic function of time since the last loss, but interview questions use the Reno model above.

TCP vs UDP

Real-time media prefers UDP because a late packet is useless: replaying a lost 20 ms of audio after a retransmission would only add delay.

Common mistakes

• Saying the acknowledgement number is the sequence number received: it is the next byte expected.
• Forgetting that SYN and FIN each consume one sequence number (ISN 100 is acknowledged with 101).
• Claiming UDP has no checksum: it has one, optional only in IPv4.
• Confusing flow control (receiver's buffer, rwnd) with congestion control (the network, cwnd).
• Saying TCP preserves message boundaries: two writes of 100 bytes may arrive as one read of 200.
• Letting slow start overshoot ssthresh after a timeout: cwnd stops at the threshold, then grows linearly.

Interview questions

Why is the TCP handshake three-way and not two-way? Both sides must announce an initial sequence number and receive an acknowledgement for it. Two messages acknowledge only the client's number, leaving the server unsure the client received its own; the third message closes that gap and protects against old duplicate SYNs opening stale connections.

What happens if the final ACK of the handshake is lost? The server stays in SYN_RECEIVED and retransmits its SYN-ACK after a timeout; the client answers with another ACK. If the client has already started sending data, the server accepts it, since every data segment also carries the acknowledgement it was waiting for.

What is TIME_WAIT, and why does it last 2 × MSL? It is the state the side that closes first enters after sending the final ACK. Waiting two maximum segment lifetimes lets it re-acknowledge a retransmitted FIN if its last ACK was lost, and lets stray segments of the old connection expire before the same address and port pair is reused.

What is a SYN flood, and how do SYN cookies help? An attacker sends many SYNs, often from spoofed addresses, and never completes the handshake, filling the server's queue of half-open connections. With SYN cookies, the server keeps no state for a SYN; it encodes the connection details in its own ISN and rebuilds them only when a valid final ACK returns.

What triggers fast retransmit? Three duplicate ACKs for the same number. They mean later segments are arriving while one is missing, so the sender resends that segment immediately rather than waiting for the retransmission timer.

Why does DNS use UDP? A query and its answer usually fit in one small datagram each, so a TCP handshake would double the time for little benefit. The resolver simply retries on loss. DNS switches to TCP when an answer is too large or for zone transfers.

Can two clients connect to the same server port at the same time? Yes. A TCP connection is identified by source IP, source port, destination IP and destination port. Clients differ in address or source port, so thousands of connections can share the server's port 443.

How is the amount of data a TCP sender may have in flight decided? It is the minimum of the receiver's advertised window (rwnd, flow control) and the sender's congestion window (cwnd, congestion control). Whichever is smaller limits the sender.

Next, read DNS, and test the handshakes and windows with the Computer Networks (Intermediate) skill test.