Transport Layer | Computer Science

flowchart TD
    A[5_Transport Layer] --> B[Key Concepts]
    A --> C[Core Principles]
    A --> D[Practical Applications]
    B --> E[Fundamental definitions]
    C --> F[Design patterns]
    D --> G[Real-world usage]

The transport layer provides end-to-end communication services between applications. UDP is the minimalist option: connectionless, unreliable, but fast, suitable for real-time applications where occasional loss is acceptable. TCP is the reliable option: it establishes connections through handshakes, numbers bytes for ordering, acknowledges receipt, and retransmits lost data. Flow control prevents the sender from overwhelming the receiver, and congestion control prevents the sender from overwhelming the network. The choice between TCP and UDP depends on whether reliability or latency matters more.

Connectionless, unreliable, message-oriented. 8-byte header.

Use cases: DNS, DHCP, VoIP, video streaming, gaming. Suitable when low latency matters more Than reliability, or when the application handles reliability itself.

Connection-oriented, reliable, byte-stream. Provides flow control, congestion control, ordered Delivery. Header: 20 bytes minimum.

The TCP header can include options (within the data offset space):

Selective Acknowledgement (SACK). Standard TCP only acknowledges contiguous data. If segments 3, 4, 5 are lost but 6-10 arrive, the receiver can only ACK up to segment 2. SACK allows the Receiver to inform the sender exactly which blocks have arrived, avoiding unnecessary Retransmissions.

Window scaling. The TCP window field is 16 bits (max 65,535 bytes), insufficient for high-BDP Paths. The window scale option shifts the window left by $S$ bits, allowing windows up to $2^{16+S-1}$ bytes (maximum $S = 14$Yielding a 1 GiB window).

Theorem 5.1. TCP achieves reliable ordered delivery over an unreliable network using cumulative Acknowledgements, sequence numbers, and retransmission timers.

Proof. TCP assigns each byte a sequence number. The receiver sends cumulative ACKs indicating the Next expected byte. If an ACK is not received within the RTO, the sender retransmits. Since the Receiver buffers out-of-order segments and only delivers in-order data to the application, and since Every byte is eventually acknowledged or retransmitted until acknowledged, all data is delivered Exactly once and in order. $\blacksquare$

Three-way handshake:

Client                        Server
  |--- SYN (seq=x) ---------->|    Client: SYN_SENT
  |<-- SYN+ACK (seq=y,       |    Server: SYN_RCVD
  |    ack=x+1) ------------|
  |--- ACK (ack=y+1) -------->|    ESTABLISHED

Four-way termination:

Client                        Server
  |--- FIN (seq=u) ---------->|    Client: FIN_WAIT_1
  |<-- ACK (ack=u+1) --------|    Client: FIN_WAIT_2
  |                           |    Server: CLOSE_WAIT
  |<-- FIN (seq=v) ----------|    Server: LAST_ACK
  |--- ACK (ack=v+1) -------->|    Client: TIME_WAIT
  |      (wait 2*MSL)         |    Server: CLOSED

TIME_WAIT. Client waits $2 \times \mathrm{MSL}$ (Maximum Segment Lifetime, 60 s) Before closing. Ensures: (1) the last ACK reaches the server; (2) old segments have expired.

TCP state diagram (state transitions):

TCP uses a sliding window. The receiver advertises rwnd (receive window). The sender never has More than rwnd bytes of unacknowledged data in flight.

$\mathrm{Effective}\;window = \min(\mathrm{cwnd},\, \mathrm{rwnd})$

Example. Buffer size 4096, 1024 unprocessed bytes: rwnd = 3072. The window slides as data is Acknowledged and the receiver processes data.

TCP adapts its sending rate based on perceived network congestion.

Slow start. cwnd = 1 MSS. Double cwnd per ACK (exponential growth). Until cwnd reaches ssthresh or loss occurs.

Congestion avoidance. When $\mathrm{cwnd} \geq \mathrm{ssthresh}$Increase cwnd by $\mathrm{MSS} \times (\mathrm{MSS} / \mathrm{cwnd})$ per ACK (linear growth, approximately 1 MSS Per RTT).

Fast retransmit. Three duplicate ACKs trigger immediate retransmission of the missing segment.

Fast recovery. After fast retransmit: $\mathrm{ssthresh} = \mathrm{cwnd}/2$ $\mathrm{cwnd} = \mathrm{ssthresh} + 3$. Enter congestion avoidance (not slow start).

TCP Reno state transitions:

Slow Start: cwnd doubles each RTT
  |
  v  (cwnd >= ssthresh)
Congestion Avoidance: cwnd += 1 MSS/RTT
  |
  v  (3 dup ACKs)
Fast Retransmit + Recovery: ssthresh = cwnd/2, cwnd = ssthresh + 3
  |
  v  (new ACK)
Congestion Avoidance
  |
  v  (timeout)
Slow Start: ssthresh = cwnd/2, cwnd = 1

TCP Cubic. Default in Linux since 2.6.19. Uses a cubic function of time since last congestion Event. Better performance on high-bandwidth, high-latency networks.

$\mathrm{RTT_s} = (1 - \alpha)\,\mathrm{RTT_s} + \alpha \cdot \mathrm{RTT_m}$

$\mathrm{RTT_d} = (1 - \beta)\,\mathrm{RTT_d} + \beta\,|\mathrm{RTT_m} - \mathrm{RTT_s}|$

$\mathrm{RTO} = \mathrm{RTT_s} + 4 \cdot \mathrm{RTT_d}$

Where $\mathrm{RTT_m}$ = measured RTT, $\alpha = 1/8$, $\beta = 1/4$. Initial RTO = 1 s; minimum RTO = 200 ms.

• Network Layer: IP addressing and routing protocols.

• Application Layer: HTTP and application protocols.

• Network Security: TLS and transport security.

• Discrete Mathematics

• Algorithm Implementation

• Confusing flow control with congestion control: Flow control prevents the sender from overwhelming the receiver (per-connection); congestion control prevents the sender from overwhelming the network (global). They solve different problems with different mechanisms.
• Assuming TCP retransmission is always reliable: TCP retransmits lost segments, but if the network is severely congested, retransmissions can make the problem worse (congestion collapse). Slow start and congestion avoidance are designed to prevent this.
• Forgetting that the three-way handshake adds latency: A TCP connection requires one full RTT before data can be sent. For short-lived connections (e.g., HTTP requests), this overhead is significant. HTTP/2 and QUIC reduce this by multiplexing or using 0-RTT handshakes.
• Mixing up port numbers and IP addresses: An IP address identifies a host; a port number identifies a process on that host. Two connections can have the same IP addresses but different port numbers (multiplexing), or the same port numbers but different IP addresses.