The Transport Layer: UDP and TCP

An application sends through a socket, the interface between its process and the transport layer. The transport layer makes processes on different hosts appear to communicate directly. This is logical communication: the data still crosses links and routers, but the application works through its local socket.

Follow the data through the layers

At the sender, the transport protocol takes application data, divides it into chunks when needed and adds a transport header. The resulting segment goes to IP. IP adds its own header, producing an IP datagram for the network to carry. At the destination, IP hands the segment to the transport protocol, which interprets the transport header and delivers the data to a socket.

The protocol logic runs in the end hosts. Ordinary routers forward IP datagrams; they do not perform TCP acknowledgment and retransmission on behalf of the applications. Think of an IP address as a building's address and the receiving socket as the intended recipient inside. Getting a letter to the building and getting it to the right person are separate jobs.

IP offers best-effort host-to-host delivery. Datagrams can be lost, duplicated, reordered or corrupted. Transport extends delivery to processes, and it may add mechanisms that repair these failures.

Compare the services

UDP, the User Datagram Protocol, adds ports and an error check to IP's delivery. A segment can arrive without any earlier setup exchange. UDP does not recover a lost segment or hold a later segment until an earlier one arrives.

TCP, the Transmission Control Protocol, sets up connection state before normal data transfer. It numbers bytes, checks for errors, obtains acknowledgments and retransmits missing data. The receiving application gets a reliable, in-order byte stream. Flow control protects its buffer; congestion control responds to network load.

Reliability does not make the network underneath reliable. If an IP datagram disappears, TCP sends another copy of the missing data. If later bytes arrive first, the receiver can hold them until the gap is filled. The application sees repaired delivery, but it may wait longer. Neither TCP nor UDP can promise a delivery deadline or reserve network capacity merely by running over best-effort IP.

Choose the service at the socket

A stream socket normally selects TCP; a datagram socket selects UDP. HTTP/1.1 and HTTP/2, SMTP email transfer and SSH remote login use TCP. Ordinary DNS queries commonly use UDP. HTTP/3 uses QUIC over UDP: QUIC supplies reliable streams and security above UDP's minimal service.

A TCP connection alone does not keep a password secret. TLS adds encryption and authentication above TCP; QUIC integrates TLS into its design. Reliability answers whether bytes reach the application correctly and in order. Confidentiality answers whether an observer can read them.

A host often has many sockets open. Multiplexing gathers outgoing data from those sockets and adds transport headers. Demultiplexing selects the receiving socket for each arriving segment.

Read the addressing information

Both TCP and UDP carry a 16-bit source port and a 16-bit destination port. Values run from 0 to 65,535. The destination port identifies the receiving service; the source port helps the peer address its reply. IANA groups ports as system ports 0–1023, user ports 1024–49151 and dynamic ports 49152–65535.

Servers listen on agreed ports: SSH uses 22, SMTP 25, DNS 53, HTTP 80 and HTTPS commonly 443. Clients usually get a temporary, ephemeral port from the operating system. Its configured range need not equal IANA's dynamic range: a common Linux default is 32768–60999, while Windows commonly uses 49152–65535.

For an arriving IP datagram, the host first identifies the transport protocol. IPv4 protocol value 6 means TCP and 17 means UDP; IPv6 identifies the upper-layer protocol through its Next Header chain. TCP port 53 and UDP port 53 belong to different transport namespaces. The receiver then uses addresses and ports to select a socket and queues the data for the application.

UDP: many clients, one receiving socket

In the basic unconnected UDP server model, the receiving socket is selected by destination IP address and destination port. Different clients can all send to that same socket.

A server at 203.0.113.53 listens on UDP port 53. Requests from 198.51.100.7:51000 and 192.0.2.44:62011 reach this one server socket. The first reply travels from 203.0.113.53:53 to 198.51.100.7:51000. The application obtains each request's source address and port so that it can reply to the right client. A connected UDP socket can also restrict the peer it receives from; no UDP handshake is added.

TCP: distinguish connections by four values

A TCP server has a listening socket and separate connection sockets. A connection is identified by the four-tuple of source IP, source port, destination IP and destination port.

For a server at 203.0.113.10:80, these are different connections:

• 198.51.100.7:50312 → 203.0.113.10:80
• 198.51.100.7:50313 → 203.0.113.10:80
• 192.0.2.44:50312 → 203.0.113.10:80

The first two differ in source port. The first and third share a source port but differ in source address. All three use server port 80. A separate server port per client is unnecessary because the full four-tuple distinguishes their connection sockets. One process can handle many such sockets.

When no socket matches

A SYN sent to a closed TCP port normally receives a reset, with the RST flag set. A UDP segment sent to a port with no receiver normally triggers an ICMP “port unreachable” message. Firewalls, filtering and response limits can affect what returns. In a port probe, SYN-ACK is evidence of a listening TCP service; RST indicates refusal. Silence alone cannot distinguish filtering from loss or a host that is unavailable.

UDP sends each message independently, with no handshake or shared connection sequence state. Its fixed 8-byte header contains four fields, each 16 bits wide: source port, destination port, length and checksum.

Count the correct bytes

The length covers the UDP header plus its data. It is at least 8 bytes. A message with 40 data bytes has UDP length 48. With a 20-byte IPv4 header and no IP options, the complete IP datagram is 68 bytes. The IP header is outside the UDP length.

The checksum detects some bit errors across the UDP header and data. It also covers a pseudo-header built from IP addressing information, the protocol number and UDP length. Those values help detect a segment delivered under the wrong addressing information. The pseudo-header is calculation input; it is not an extra transmitted part of the UDP header.

Add with end-around carry

Treat the calculation input as 16-bit words. Set the checksum field to zero while computing. Add the words, wrapping any carry beyond bit 16 back into the low end. This is one's complement addition. Finally flip all 16 bits of the folded sum to obtain the checksum. If the byte count is odd, append a zero byte for the calculation only.

For three illustrative words, use hexadecimal to make the carry visible:

1. Add A35C and 69C3 to get 10D1F. The leading 1 is a carry outside 16 bits.
2. Fold it back: 0D1F + 1 = 0D20.
3. Add 1234: 0D20 + 1234 = 1F54.
4. Complement every bit: FFFF − 1F54 = E0AB.

The checksum is E0AB. Simply dropping the leading carry would give the wrong sum. In binary, the final sum is 0001 1111 0101 0100 and its complement is 1110 0000 1010 1011.

Check at the receiver

The receiver repeats the folded addition over the pseudo-header and received segment, now including the checksum field. An unchanged segment gives all ones, FFFF. Here, 1F54 + E0AB = FFFF. A result containing a zero bit detects an error. UDP silently discards a segment whose supplied, nonzero checksum fails; it does not send a replacement or repair the data.

All ones means that the check passed, not that every possible error was excluded. Compensating changes in different words can leave the sum unchanged. The checksum detects errors; it neither locates the bad bits nor corrects them.

Why the end hosts check again

A link check protects a particular link. Some links may lack that check, and corruption can also happen inside equipment between links. An end-to-end check tests what reached the destination host. This illustrates the end-to-end principle: a property needed across the full path must be checked at its endpoints.

Over IPv4, a zero UDP checksum field signals that the sender omitted the checksum. A computed checksum of zero is transmitted as all ones to preserve this distinction. IPv6 normally requires a UDP checksum, with narrowly specified tunnel exceptions. TCP also uses an Internet checksum with a pseudo-header, and requires its checksum.

UDP's small service gives an application control over its messages. There is no transport handshake before the first message, no UDP retransmission queue and no UDP mechanism that holds later data behind a missing earlier message. The application decides what to send and which losses matter.

Match recovery to useful arrival time

Consider voice audio sent in 20 ms chunks: 50 messages per second. A missing chunk is due for playback in 60 ms, but detecting the loss and obtaining another copy takes about 150 ms. That recovered chunk would arrive too late. A voice application can play later chunks on time and conceal the missing sound, for example by smoothing the gap.

The decisive quantity is time remaining before playback, not the 20 ms duration of one chunk. If recovery can finish before the deadline, retransmission may help. TCP must deliver bytes in order, so a missing earlier byte can also delay delivery of later bytes already received. This wait is often called head-of-line blocking within the stream.

A file transfer has a different priority: every byte must arrive correctly, and waiting for recovery is acceptable. TCP already provides that service. Using UDP would move the work of detecting loss, requesting replacement data and restoring order into the application or another protocol.

What the small header buys

UDP's header is 8 bytes; TCP's is at least 20. A UDP server can receive messages from many clients without setting up per-client transport connections. There are still socket buffers and application resources, so “connectionless” does not mean that the host stores nothing.

Common UDP uses include ordinary DNS queries on port 53, NTP time synchronization on 123, SNMP management on 161 and DHCP address assignment on 67 and 68. Calls and games often choose UDP for timely messages. On-demand video commonly uses HTTP over TCP or QUIC, so “video uses UDP” is too broad a rule.

QUIC shows how much a protocol can add above UDP: reliable streams, congestion control and TLS 1.3 security. It was standardized in 2021 and commonly uses UDP port 443; HTTP/3 runs over QUIC. UDP itself has not acquired those services.

Keep messages small enough

UDP preserves message boundaries. A receive operation reads one message, not a byte stream assembled from several sends. The application must supply a large enough read buffer; a smaller buffer can truncate the message.

For IPv4 with a 20-byte IP header, the theoretical maximum payload is 65,535 − 20 − 8 = 65,507 bytes. Sending near that limit may require IP fragmentation. On a path supporting 1,500-byte IPv4 datagrams, 1,500 − 20 − 8 = 1,472 data bytes fit without fragmentation when there are no IP options. Other paths and headers can reduce that value.

Account for the missing controls

UDP has no built-in flow control to protect a slow receiver. If its socket buffer fills, arriving messages can be dropped. It also lacks built-in congestion control. Responsible UDP applications provide suitable rate control so that they do not overwhelm a shared path. Some networks filter UDP, so applications may need a fallback.

Skipping setup and recovery can reduce delay, but UDP does not increase a link's capacity or prevent IP loss. Judge the whole application protocol: the work it adds above UDP can matter more than the header size.

A reliable data transfer protocol gives the receiving application correct data, in order and without duplicates, even when the channel below it damages packets. Build the design by asking what can go wrong at each stage. For these protocols, application data moves one way and control feedback travels back.

Describe behavior with states

A finite-state machine (FSM) records the sender's or receiver's current state. Each transition has a triggering event and the actions to perform. A state such as “waiting for ACK 0” captures what evidence the sender needs before moving on. In FSM notation, Λ marks no event or no action; a dashed incoming arrow marks the initial state.

With a perfectly reliable channel, version 1.0 needs only sending and delivery. The sender packages data, the receiver extracts it, and neither needs feedback. Adding bit errors changes the design.

Detect an error and ask for another copy

Version 2.0 uses three mechanisms:

• A checksum lets the receiver test a packet for corruption.
• An ACK reports successful receipt; a NAK reports damaged data.
• Retransmission sends another copy when needed.

Together these form automatic repeat request (ARQ). The sender sends one packet and waits for feedback before sending the next: stop-and-wait. It keeps a copy of the current packet because it may need to resend it.

But feedback packets cross the same unreliable channel. A damaged ACK leaves the sender unsure: did the receiver accept the data, or is another copy needed? Resending is safe only if the receiver can distinguish a replacement copy from fresh application data. A checksum alone does not identify duplicates; two valid copies have the same valid contents.

Give each outstanding packet an identity

Version 2.1 adds a sequence number. With only one packet outstanding, a one-bit number alternating 0, 1, 0, 1 is sufficient in this stop-and-wait channel model. The receiver remembers which number it expects. It delivers a valid packet with that number once and then changes its expectation. A packet with the previous number is a duplicate: acknowledge it again, but do not deliver its data again.

The sender retains the current number while retransmitting. It advances to the other number only after the matching, readable ACK. Corrupted feedback or a NAK causes a retransmission in this error-only design.

Replace NAKs with repeated ACKs

Version 2.2 removes NAKs. The receiver responds to a damaged or duplicate packet with an ACK for the last packet it accepted. The ACK therefore needs a number.

Suppose packet 0 carries “A” and arrives correctly. The receiver delivers “A” and sends ACK 0. Packet 1 carrying “B” is corrupted, so the receiver repeats ACK 0. The sender is waiting for ACK 1; this duplicate ACK signals that it should resend packet 1. The valid replacement is delivered as “B” and acknowledged with ACK 1.

Discarding duplicate data and acknowledging the duplicate packet are different actions. If the receiver silently ignored a replacement whose earlier ACK was unreadable, the sender could never learn that delivery had succeeded. TCP also avoids NAKs, although its byte numbering and fast-retransmit rules differ from this simple protocol.

Feedback cannot help if it never arrives. When the channel can lose a data packet or an ACK, the sender needs a way to resume without receiving a message. Version 3.0 adds a countdown timer to the alternating-bit protocol.

Handle silence without delivering twice

The sender starts the timer whenever it sends the current packet, including a replacement. A matching, intact ACK stops the timer and permits the next packet. A corrupted ACK or an ACK with the wrong number is ignored. If the timer expires first, the sender resends the same packet and restarts the timer.

For a lost data packet, the receiver has nothing to acknowledge; timeout supplies the replacement. For a lost ACK, the receiver has already delivered the data. When the replacement arrives, the sequence number identifies a duplicate. The receiver discards its data and sends the ACK again.

A premature timeout occurs when the original packet or ACK was only slow. The replacement wastes transmission effort, but duplicate detection preserves correct delivery. A useful timeout must allow the expected round trip and receiver processing. Too short produces needless retransmissions; too long delays recovery from real loss.

Separate transmission time from waiting time

Let packet length be $L$ bits and link rate be $R$ bit/s. The sender needs $L\mathrm{/}R$ seconds to put one packet onto the link. Ignoring ACK transmission and processing time, one stop-and-wait cycle takes $RTT+L\mathrm{/}R$. The fraction of time spent sending is

For 1,500-byte packets on a 1 Gbit/s link, first convert bytes to bits:

Then $L\mathrm{/}R=12\mu \text{s}=0.012\text{ ms}$. With an RTT of 40 ms,

The sender is active about 0.03% of the time. Throughput is about 12,000 bits every 0.040012 s, or 300 kbit/s. A very fast link still carries little useful traffic because the sender spends almost the entire cycle waiting.

Pipeline the packets

Pipelining allows multiple unacknowledged packets in flight. If up to $N$ packets fit in the sending window, the ideal utilization becomes

With the same link, 1,000 packets give utilization about 0.30. To keep it fully busy requires at least $40.012\mathrm{/}0.012\approx \mathrm{3,334.33}$ packet transmission times, so round up to 3,335 packets. Rounding down leaves a small idle interval before the first ACK.

A larger pipeline needs enough sequence numbers to distinguish its packets and enough buffer space to retain unacknowledged data. The receiver may also need buffering, depending on the protocol. Go-back-N and selective repeat solve these design choices differently.

Increasing the link rate alone shortens the already brief transmission time. For a fixed packet size and RTT, it reduces stop-and-wait utilization. More data in flight is what lets the sender use the available capacity.

Go-back-N (GBN) allows up to $N$ sent but unacknowledged packets. The sender's sliding window moves forward when acknowledgments confirm delivery. The receiver stays simple: it accepts only the next packet in order.

Keep the sender's ranges separate

The variable base identifies the oldest unacknowledged packet. nextseqnum identifies the next new packet to send. Before sequence-number wraparound, the ranges are:

• Below base: already acknowledged.
• From base through nextseqnum − 1: sent, awaiting acknowledgment.
• From nextseqnum through base + N − 1: available for new data.
• At or above base + N: blocked until the window advances.

For base = 10, nextseqnum = 13 and $N=5$, packets 10–12 are outstanding. Packets 13 and 14 can be sent. Packet 15 cannot. A window limits outstanding data, not the total number of packets in a transfer.

Cumulative acknowledgments move the base

GBN ACK $n$ confirms all packets through $n$. It moves base to $n+1$. One later cumulative ACK can therefore cover earlier ACKs that were lost. This numbering convention identifies the last accepted packet; TCP's ACK convention identifies the next expected byte.

GBN keeps one timer for the oldest outstanding packet. Sending the first outstanding packet starts it. An advancing ACK restarts it if data is still outstanding; acknowledgment of everything stops it. When the timer expires, the sender retransmits every packet that has been sent but remains unacknowledged. That number may be smaller than the maximum window $N$.

Trace a missing packet

Use a window of four and send packets 0, 1, 2 and 3. Packet 2 is lost. The receiver delivers 0 and 1 and sends ACK 0 and ACK 1. Packet 3 arrives beyond the gap: the receiver discards it and repeats ACK 1.

The first two ACKs open space for packets 4 and 5. They also arrive beyond missing packet 2, so both are discarded and answered with ACK 1. The sender's base remains 2. On timeout it retransmits 2, 3, 4 and 5. They now arrive in order and can all be delivered.

The copies of 3, 4 and 5 were intact the first time. GBN resends them because its receiver chose not to buffer out-of-order packets. That saves receiver state at the cost of extra traffic after a loss.

Leave one sequence number outside the window

A $k$-bit field provides $2^k$ packet numbers, reused cyclically. GBN requires

With three bits, the numbers are 0–7 and the largest sender window is seven. If all eight were allowed, the receiver could accept 0–7 and return to expecting 0. If all ACKs were lost, a retransmitted old 0 would then look new. With only 0–6 sent, the receiver instead expects 7 and can recognize the retransmitted 0 as old. Window arithmetic near wraparound follows the cyclic order, not ordinary numerical size.

Selective repeat (SR) saves correctly received packets even when earlier ones are missing. Each valid packet receives its own ACK. The sender can then replace just a packet whose timer expires.

Track each packet separately

The sender's window begins at send_base, the oldest unacknowledged packet, and contains $N$ allowed sequence numbers. Each outstanding packet has a logical timer. An ACK marks that particular packet as received. An ACK beyond the base does not by itself move the window: the base stays at the first hole. Once that hole is acknowledged, the base skips past any following packets already acknowledged.

The receiver's window starts at rcv_base, the next packet needed for delivery. A valid packet inside the window is acknowledged. Out-of-order data is buffered. When the base packet arrives, the receiver delivers it and every consecutive buffered packet after it, stopping at the next gap.

A packet in the immediately preceding window is an old duplicate. The receiver acknowledges it again without delivering it. This rule is essential when the original ACK was lost: the sender may still be waiting even though the receiver has moved on.

Recover one loss

Use $N=4$ and let packet 2 be lost after the sender sends 0–3. The receiver delivers and acknowledges 0 and 1, then buffers and acknowledges 3. Those first two ACKs let the sender transmit 4 and 5. Both are buffered and individually acknowledged, but send_base stays at 2.

When packet 2's timer expires, only 2 is resent. Its arrival lets the receiver deliver 2, 3, 4 and 5 together and move rcv_base to 6. Once ACK 2 reaches the sender, its base also advances to 6, passing packets 3–5 whose ACKs it already holds.

Why the window is at most half the number space

The receiver may be ahead of the sender because ACKs are delayed or lost. New acceptable numbers must not overlap numbers that might still be retransmitted as old packets.

With two-bit numbers 0–3 and a window of three, suppose the receiver accepts 0, 1 and 2. Its new window is {3, 0, 1}. If all ACKs disappear, a retransmitted old 0 fits this window and looks new. The receiver cannot distinguish it from a genuinely new 0 sent after a lost 3.

For equal-sized sender and receiver windows, the safe bound is

Three-bit numbering therefore allows SR windows up to four, while GBN permits seven.

Distinguish an old copy after wraparound

Window limits handle the current windows, but a real network can also keep an old copy in transit until numbers are reused. A maximum packet lifetime bounds how long such copies can survive. TCP calls this the maximum segment lifetime (MSL). At high rates, TCP can reuse its 32-bit sequence space quickly, so timestamp-based Protection Against Wrapped Sequences (PAWS) helps reject stale data.

A TCP connection is state held in two end hosts: buffers, byte counters and other variables created during setup. It is point-to-point, between two endpoints, and full-duplex, allowing both to send at once. Ordinary routers forward its IP datagrams without maintaining TCP's endpoint state.

Bytes have no message boundaries

TCP preserves the order of bytes, but not application write boundaries. Three writes of 100 bytes can reach the application in a single 300-byte read, or in reads of 50 and 250 bytes. An application that exchanges messages must provide framing, such as a length field or a delimiter. A short read does not establish that a complete message has arrived.

Application writes enter a send buffer. TCP chooses chunks to transmit, retaining unacknowledged data for possible retransmission. Incoming data enters a receive buffer until the receiving application reads it.

Size the data separately from the headers

The maximum segment size (MSS) limits application data in a segment. It excludes both TCP and IP headers. For a path supporting 1,500-byte IP datagrams with 20-byte IPv4 and 20-byte TCP headers,

Options take more space, so a sender must allow for their actual header lengths. Each endpoint announces the MSS it can receive during the handshake; path limits may further restrict what can be sent. Without an MSS option, the default assumptions are 536 data bytes for IPv4 and 1,220 for IPv6.

Read the header fields

The minimum header is five 32-bit words, or 20 bytes. A data offset of 8 means 32 bytes, including 12 bytes beyond the fixed header. The maximum offset is 15: 60 bytes total, allowing up to 40 bytes of options.

Interpret flags and options

SYN synchronizes sequence numbers during opening. FIN closes one sending direction. RST aborts or refuses a connection. ACK makes the acknowledgment field valid. PSH requests prompt delivery toward the application; it does not create a message boundary. URG makes the urgent pointer meaningful, although new applications are advised to avoid that mechanism. ECE and CWR carry explicit congestion-notification signals.

Common options include MSS, window scaling, timestamps and selective acknowledgment (SACK). Scaling extends the receive-window range. Timestamps help measure RTT and reject stale segments. SACK describes received blocks beyond a gap.

Without options, TCP plus IPv4 adds 40 bytes. A full 1,460-byte data segment occupies a 1,500-byte IP datagram, about 97.3% application data. A pure ACK has no data but still occupies those 40 header bytes.

TCP sequence numbers count bytes, not segments. A segment's sequence number names its first data byte. Its acknowledgment number describes the opposite direction: the next byte that this sender expects to receive.

Split a stream into segments

An initial sequence number (ISN) of 3,000 is used by the SYN. The first data byte is therefore 3,001. A 10,000-byte file with an MSS of 1,460 needs six full data segments and one shorter segment:

Each next sequence number adds the preceding segment's data length. The final byte is 13,000, so successful receipt of the whole file produces cumulative ACK 13,001.

Acknowledge a continuous prefix

ACK $n$ confirms all bytes through $n-1$. It does not confirm byte $n$. If the receiver has bytes through 4,460, it expects 4,461. A segment starting at 5,921 leaves a gap. A receiver that buffers that segment still sends ACK 4,461 because its continuous prefix has not grown.

This is why the acknowledgment cannot simply be the largest sequence number observed. Later bytes show that something arrived beyond the gap; they do not fill it. When the missing range arrives, a cumulative ACK can jump over data already buffered.

Track both directions independently

Suppose a client's next byte is 1,000 and a server's next byte is 5,000. The client sends 200 data bytes with sequence 1,000 and acknowledgment 5,000. The server's reply carries 1,200 bytes with sequence 5,000 and acknowledgment 1,200. The client's next pure ACK has sequence 1,200 and acknowledgment 6,200.

The server did not derive its own sequence number from the request's length. Each direction has its own numbering. Carrying an ACK with outgoing data is piggybacking. A pure ACK consumes no sequence space; SYN and FIN each consume one number even without data.

Manage initial values and wraparound

Endpoints choose an ISN when opening a connection. A clock and a keyed pseudo-random function of the connection addresses and ports help separate a new connection from old delayed segments and make valid numbers difficult for an outsider to guess. Starting every connection at zero would weaken both protections.

The fields are 32 bits, so numbering wraps modulo $2^{32}$, about 4.3 billion bytes. At 1 Gbit/s, cycling through that space takes about 34 s; at 10 Gbit/s, about 3.4 s. Timestamp-based PAWS provides an additional stale-segment check on fast paths.

For ordinary arithmetic away from wraparound, the next byte after a data segment is its sequence number plus its data length. When a SYN or FIN is present, include the one extra number that control flag consumes. Apply the calculation separately to each direction.

TCP setup lets both endpoints announce a starting sequence number and learn that the peer received it. Closing later releases each direction separately. These control exchanges use the same sequence space as data.

Trace the three-way handshake

1. The client creates connection state, sends SYN with ISN 7,000 and enters SYN_SENT.
2. The server replies with SYN-ACK, sequence 21,000 and acknowledgment 7,001. It is in SYN_RCVD while waiting for confirmation.
3. The client records the server's number and sends ACK with sequence 7,001 and acknowledgment 21,001. The client enters ESTABLISHED; the server does so when that ACK arrives.

Each SYN consumes one number. The third segment can already carry application data. The ordinary handshake costs one round trip before the client can send that first data. A two-message exchange would not tell the server that the client received its ISN and could leave it accepting a delayed old SYN as a fresh request.

At the socket interface, connect starts an active open. A server listens for requests, and accept returns a new connection socket after setup. The listening socket remains available for other clients.

Close each direction

An endpoint sends FIN when it has no more bytes to send. The peer acknowledges that FIN by advancing its ACK one beyond it. The peer can still send its own remaining bytes: this is a half-close. Its later FIN closes the other direction and needs an ACK too. Closing commonly uses four segments, although a FIN and ACK can be combined.

For a client that closes first, the usual state path is ESTABLISHED → FIN_WAIT_1 after sending FIN → FIN_WAIT_2 once that FIN is acknowledged → TIME_WAIT after receiving and acknowledging the peer's FIN → CLOSED. The peer passes through CLOSE_WAIT while its application finishes, then LAST_ACK after sending its own FIN, and finally CLOSED on receiving the ACK.

Keep the last ACK recoverable

In the usual active-close path, TIME_WAIT lasts twice the maximum segment lifetime. If the final ACK disappears, the other endpoint can resend its FIN and receive another ACK. Waiting also gives old segments time to expire before the connection's four-tuple is reused. The standard's MSL value of two minutes yields four minutes; implementations can use different durations, with 60 seconds a familiar Linux value.

An RST is different from FIN: it aborts the connection or refuses a request. A closed-port SYN normally receives RST. SYN-ACK indicates a listener; silence can result from filtering, loss or an unavailable destination.

Protect incomplete handshakes

A SYN flood sends many opening requests without completing them. A server that reserves resources for every half-open connection can exhaust its available state. SYN cookies delay allocating that per-connection state. The server encodes verifiable connection information into its chosen ISN using a secret and time-dependent input. A valid final ACK returns the cookie through its acknowledgment number, allowing the server to check it and create state. The server still has a listener and shared resources; it avoids storing an individual unfinished connection for every SYN.

TCP needs a retransmission timeout long enough to allow normal round trips, but short enough to recover promptly from loss. RTT varies as queues and paths change, so the timeout follows both a smoothed estimate and the size of recent deviations.

Take an unambiguous sample

SampleRTT measures the interval from sending data to receiving an ACK that covers it. In a basic implementation, TCP times one eligible segment at a time. Karn's algorithm excludes retransmitted data from ordinary RTT sampling: an ACK might refer to the original copy or the replacement. Negotiated timestamps can remove this ambiguity.

The first valid sample $R$ initializes EstimatedRTT to $R$ and DevRTT to $R\mathrm{/}2$. Before a sample exists, the recommended initial timeout is 1 s.

Update variation before the average

For a new sample, use the previous EstimatedRTT to measure the deviation:

Then update the exponentially weighted moving average:

The recommended weights are $\beta =1\mathrm{/}4$ and $\alpha =1\mathrm{/}8$. Older samples retain less influence after each update. Updating the average first would change the deviation used in the first equation.

Work through one update

Start with EstimatedRTT = 100 ms and DevRTT = 10 ms; take a 120 ms sample.

1. Absolute deviation: $\mathrm{\mid }120-100\mathrm{\mid }=20\text{ ms}$.
2. New DevRTT: $0.75(10)+0.25(20)=12.5\text{ ms}$.
3. New EstimatedRTT: $0.875(100)+0.125(120)=102.5\text{ ms}$.
4. Basic timeout: $102.5+4(12.5)=152.5\text{ ms}$.

The basic rule is

The full standard uses EstimatedRTT + max(G, 4 DevRTT), where $G$ is clock granularity. When the four-deviation margin exceeds the clock interval, the basic rule gives the same result.

The standard recommends raising a computed value below 1 s to 1 s. Real implementations may use a smaller floor; a common Linux minimum is 200 ms. The calculated 152.5 ms is therefore a raw estimate, not necessarily the timer a host installs. An optional upper limit must be at least 60 s.

Back off after timeout

When the timer expires, TCP resends the earliest unacknowledged data and doubles the timeout. A current value of 0.75 s becomes 1.5 s, then 3 s after another expiration. Repeated immediate retries would add traffic to a path already failing to deliver feedback.

A newly arriving ACK does not necessarily collapse that backed-off timeout. TCP needs a valid new RTT measurement to recompute the estimate. Without timestamps, retransmission ambiguity prevents using an ACK for the resent data as that new sample. Once eligible new data is sent and acknowledged, a fresh sample can bring the computed timeout down.

TCP combines a checksum, byte sequence numbers, cumulative ACKs and retransmission to deliver a reliable stream. The sender must distinguish an ACK that advances delivery from one that repeats the current boundary.

Follow the sender's events

SendBase is the first unacknowledged byte; NextSeqNum is the next unused byte number. New application data is sent with sequence NextSeqNum, which then advances by the data length. If no retransmission timer is running, sending outstanding data starts it.

The recommended basic timer algorithm uses one retransmission timer for the oldest unacknowledged segment. A timeout retransmits that earliest outstanding segment, doubles the interval and restarts the timer. An ACK greater than SendBase advances the base and restarts the timer if data remains outstanding. If everything is acknowledged, the timer stops. A duplicate ACK does not advance the base.

Lost ACKs can disappear from the problem

A sends 500 bytes starting at 501. B receives them and sends ACK 1,001, which is lost. If nothing else confirms those bytes, A times out and resends them. B recognizes the duplicate, delivers no extra data and sends ACK 1,001 again.

Now suppose A had also sent the next 500 bytes, starting at 1,001. If ACK 1,501 arrives before timeout, it confirms both segments. The loss of ACK 1,001 requires no retransmission. An ACK is cumulative, so the sender does not need a separate surviving ACK for every segment.

For a premature timeout, A resends only the oldest segment. If delayed ACKs subsequently confirm both original segments, A need not resend the second one. A timeout is evidence that feedback did not arrive in time, not proof that every outstanding segment vanished.

Use ACK timing to report gaps

For in-order data with no ACK pending, the receiver may delay an ACK briefly, for less than 0.5 s, to combine acknowledgments. It should acknowledge at least every second full-sized segment. A second in-order arrival while an ACK is pending triggers a cumulative ACK. An out-of-order arrival beyond a gap triggers an immediate duplicate ACK; filling all or part of a gap also triggers an immediate ACK.

Repair a gap before timeout

Suppose A sends five 1,000-byte segments beginning at 1,001, 2,001, 3,001, 4,001 and 5,001. The second is lost. B's ACK after the first is 2,001. The three later arrivals each produce another ACK 2,001.

After three duplicate ACKs, A uses fast retransmit to resend the segment beginning at 2,001 without waiting for timeout. With the later data buffered, filling that gap lets B acknowledge 6,001. The first ACK 2,001 is the original ACK; the next three are duplicates. One or two duplicates can result from ordinary reordering, which explains waiting for more evidence.

TCP combines ideas from both window protocols. Its cumulative ACKs and basic single timer resemble GBN, but its buffering and targeted retransmission resemble SR. Negotiated SACK reports byte blocks held beyond the cumulative boundary so that the sender can identify several holes more precisely. TCP sends no NAK for a failed checksum; the resulting gap is exposed by later ACKs or timeout.

Flow control keeps a TCP sender from overflowing the receiver's buffer. It responds to how quickly the receiving application reads. Congestion control responds to load in the network; the two controls protect different resources.

Calculate available space

Let RcvBuffer be the buffer capacity, LastByteRcvd the last in-order byte stored and LastByteRead the last byte read by the application. In this contiguous-data model, occupied space is LastByteRcvd − LastByteRead. The receive window is

The receiver advertises available space in the window field of its returning segments. The sender keeps its unacknowledged byte count within that allowance:

For RcvBuffer = 40,000 bytes, LastByteRcvd = 30,000 and LastByteRead = 18,000, occupancy is 12,000 and rwnd is 28,000 bytes. ACK 30,001 with this window permits unacknowledged bytes through 58,000. If the sender has already sent through 34,000, it has 4,000 outstanding bytes and may send 24,000 more. The window is an allowance for all outstanding bytes, not an extra allowance on top of them.

Restart after a zero window

When no space remains, the receiver advertises rwnd = 0 and the sender stops normal new-data transmission. When the application reads, the receiver advertises the newly available space in a window update.

That update may be a pure ACK, which is not reliably delivered by itself. If it is lost, the sender could keep waiting although space exists. Zero-window probes, commonly carrying a byte, prompt the receiver to return its current window. Probes are spaced with growing intervals; they are not normal bulk sending through a closed window.

Relate the window to throughput

With a fixed window and RTT, the ideal window-limited throughput satisfies

Use bytes and seconds to get bytes/s. A 65,535-byte window over a 0.1 s RTT allows about 655,350 bytes/s, or 5.2 Mbit/s. A higher link rate cannot remove this window limit.

To fill a path, the window must cover its bandwidth-delay product. At 1 Gbit/s and 0.1 s, the required in-flight data is 100 million bits, or 12.5 MB. This is a necessary window size for that ideal rate, not a guarantee of achieving it.

Scale the field and avoid tiny updates

The 16-bit field alone cannot represent such a large window. A window scale option negotiated in SYNs multiplies later window values by $2^s$, with $s\le 14$. The largest scale gives a little under 1 GiB. A shift of 7 allows at most 8,388,480 bytes; shift 8 allows 16,776,960, enough for the 12.5 MB example. The scale stays fixed for its direction, while the advertised space changes. SYN window fields themselves are not scaled.

Advertising every few newly freed bytes can cause silly window syndrome: many tiny segments with large header overhead. Receiver avoidance waits for a useful amount of free space, commonly one MSS or half the buffer, whichever is smaller. Nagle's algorithm addresses small sender writes by holding them while earlier data remains unacknowledged, or until enough data forms a full segment.