CS 350 — Computer Networks

The Transport Layer & TCP

Class Notes • July 27, 2026

1. Role of the Transport Layer

The transport layer sits between the application layer and the network layer in both the OSI and
TCP/IP models. Its job is to provide end-to-end communication between processes (not just hosts) —
this is where port numbers come in, letting many applications on one machine share a single IP
address. The two dominant transport protocols on the internet are TCP and UDP, and the choice
between them shapes almost every design decision an application makes about networking.

2. TCP vs. UDP

Feature TCP UDP
Connection Connection-oriented (handshake) Connectionless
Reliability Guaranteed delivery & ordering Best-effort, no guarantees
Speed / overhead Slower, more overhead Faster, minimal overhead
Flow/congestion control Yes No (application must handle it)
Header size 20 bytes minimum 8 bytes
Typical uses Web (HTTP/HTTPS), email, file Streaming, DNS, VoIP, gaming
transfer
Neither protocol is strictly 'better' — TCP is the right choice whenever correctness and completeness
of data matter more than latency, while UDP is the right choice whenever low latency matters more
than occasional lost or out-of-order data (a dropped video frame is often less noticeable than the stall
caused by waiting for a retransmission).

3. The TCP Segment Header

Every TCP segment carries a header with fields the two endpoints use to keep the connection reliable
and well-ordered:

• Source port / Destination port — identify the sending and receiving application.

• Sequence number — the byte offset of the first byte in this segment, within the overall stream.
 • Acknowledgment number — the next byte the receiver expects, confirming everything before it

has arrived.

• Flags (SYN, ACK, FIN, RST, PSH, URG) — control bits used to establish, maintain, and tear

down connections.

• Window size — how many bytes the receiver is currently willing to accept (used for flow

control).

• Checksum — detects corruption in the header and data.

4. The TCP Three-Way Handshake

Before any data flows, TCP establishes a connection so both sides agree on starting sequence
numbers:

1. Client sends SYN with an initial sequence number (ISN).

2. Server responds with SYN-ACK: it acknowledges the client's SYN and sends its own ISN.

3. Client responds with ACK, acknowledging the server's SYN. The connection is now established

(ESTABLISHED state).

Closing a connection is typically a four-step exchange of FIN/ACK segments, because each direction
of the connection is closed independently — a host can stop sending while still receiving (this is
sometimes called a 'half-close').

5. Reliability Mechanisms
• Sequence numbers — every byte in the stream is numbered, so the receiver can detect gaps and

reorder segments that arrive out of order.

• Acknowledgements (ACKs) — the receiver confirms which bytes it has received;

unacknowledged data is retransmitted after a timeout.

• Checksums — detect corrupted segments so they can be discarded and retransmitted rather than

delivered silently wrong.

 • Retransmission timers — if an ACK doesn't arrive in time, the sender assumes the segment was

lost and resends it.

• Duplicate ACK detection — three duplicate ACKs for the same byte are treated as a strong signal

of loss, triggering fast retransmit without waiting for a full timeout.

6. Flow Control
Flow control prevents a fast sender from overwhelming a slow receiver's buffer. The receiver
advertises a window size in every ACK, telling the sender how many more bytes it can currently
accept; the sender must not have more than that many unacknowledged bytes in flight. As the
receiver's application consumes buffered data, the advertised window grows again. This is a purely
receiver-driven mechanism, distinct from congestion control below.

7. Congestion Control
Where flow control protects the receiver, congestion control protects the network itself from being
overloaded by protecting against a sender flooding a shared link faster than routers along the path can
forward the data.

7.1 Slow Start

The congestion window (cwnd) starts small — often just a few segments — and roughly doubles
every round-trip time until it reaches a slow-start threshold or a loss is detected. This exponential
growth lets a connection quickly discover how much bandwidth is available without a long, slow
ramp-up.

7.2 Congestion Avoidance

After the threshold is reached, growth switches to linear (additive increase): cwnd grows by roughly
one segment per round-trip time. This more cautious probing continues until a loss event signals that
the network's capacity has been found.
7.3 Fast Retransmit and Fast Recovery

Instead of waiting for a full retransmission timeout after a loss, three duplicate ACKs trigger an
immediate retransmission of the missing segment (fast retransmit). Rather than resetting cwnd all the
way back to the slow-start minimum, fast recovery halves it and resumes congestion avoidance from
there, avoiding an unnecessarily drastic throughput drop for an isolated loss.

7.4 Additive Increase, Multiplicative Decrease (AIMD)

The overall pattern — linear growth, then a sharp cut on loss — is called AIMD, and it produces the
characteristic 'sawtooth' shape of TCP throughput over time. AIMD is provably fair: independent of
starting conditions, competing TCP flows sharing a bottleneck converge toward roughly equal shares
of the available bandwidth.

8. TCP and the Socket API

Applications interact with TCP through sockets, an abstraction exposed by the OS. A typical server-
side flow: socket() creates an endpoint, bind() attaches it to a local address/port, listen() marks it
ready to accept connections, and accept() blocks until a client connects, returning a new socket
dedicated to that connection. A client instead calls connect(), which triggers the three-way handshake
described above.

9. Where TCP Fits: A Layered View

Layer Examples Unit
Application HTTP, DNS, SMTP, TLS Message
Transport TCP, UDP Segment / Datagram
Network IP, ICMP Packet
Link Ethernet, Wi-Fi Frame
HTTPS, for example, layers TLS encryption on top of TCP: the TCP handshake establishes a reliable
byte stream first, and then a separate TLS handshake negotiates encryption keys over that stream
before any HTTP request is sent.

10. Key Takeaways

• TCP trades speed for reliability and ordering; UDP trades reliability for speed and minimal

overhead.
 • The three-way handshake establishes shared initial sequence numbers before any data flows, and

closing is typically a four-step FIN/ACK exchange.

• Flow control protects the receiver's buffer; congestion control protects the shared network —

they are related but distinct mechanisms.

• Congestion control (slow start, congestion avoidance, AIMD) is what keeps the internet stable

under heavy, competing load, and is arguably as important as TCP's reliability guarantees.

11. Practice Problems

4. Draw the sequence of segments exchanged during a full TCP connection open (three-way

handshake) and close (four-way FIN exchange).

5. Explain the difference between flow control and congestion control, and give a scenario where

each would kick in independently.

6. If a TCP sender's cwnd is 16 segments when it detects a loss via three duplicate ACKs, what will

cwnd be immediately after fast recovery kicks in?

7. Why is UDP, not TCP, typically used for live video calls, even though it can drop or reorder

packets?

12. Worked Solutions

Solution 1

Opening: SYN (client to server) → SYN-ACK (server to client) → ACK (client to server). Closing:
FIN (initiator) → ACK (acknowledging that FIN) → FIN (from the other side, once it's also done
sending) → ACK (acknowledging that FIN). The connection is fully closed once both FINs have
been acknowledged.

Solution 2

Flow control protects the receiver: it kicks in when a receiver's buffer is filling up faster than its
application reads from it, shrinking the advertised window to slow the sender. Congestion control
protects the network: it kicks in when packets are being lost or delayed somewhere along the path,
independent of how fast the receiver itself can consume data, and reduces the sender's congestion
window accordingly.

Solution 3

Fast recovery halves the congestion window rather than resetting it to the slow-start minimum, so
cwnd goes from 16 to 8 segments, and the connection resumes in congestion avoidance (linear
growth) from that point rather than restarting slow start from scratch.

Solution 4

A live video call cares more about low, predictable latency than about every single frame arriving.
TCP's retransmission and strict ordering means a single lost segment stalls delivery of everything
after it until the retransmission arrives, which is far more disruptive to a live call than simply
skipping the corrupted frame and moving on, which is what UDP-based protocols typically do.

13. Glossary
• ACK — acknowledgment; confirms receipt of data up to a given sequence number.

• Congestion window (cwnd) — the sender's self-imposed limit on unacknowledged data, used for

congestion control.

• Datagram — a self-contained UDP unit of data with no guarantee of delivery or order.

• Handshake — an initial exchange of messages used to set up a connection's shared state.

• Port — a number identifying a specific application/process on a host.

• Segment — a TCP unit of data, carrying a portion of the byte stream plus header fields.

• Socket — an OS-level abstraction representing one endpoint of a network connection.

• Window size — how many bytes a receiver is currently willing to accept, used for flow control.
14. Frequently Asked Questions
Does TCP guarantee packets arrive in the order they were sent?

TCP guarantees that data is delivered to the receiving application in order, even if individual IP
packets arrive out of order over the network — the receiver buffers and reorders segments using their
sequence numbers before handing bytes up to the application.

What happens if an ACK itself is lost?

If the sender doesn't receive an ACK before its retransmission timer expires, it simply retransmits the
segment. If the original segment actually did arrive and only the ACK was lost, the receiver will
typically re-acknowledge the duplicate, and TCP's design ensures this causes no harm to correctness,
only a small amount of wasted bandwidth.

Why does HTTP/3 use UDP instead of TCP?

HTTP/3 runs over QUIC, which is built on UDP so it can implement its own reliability and
congestion control in user space, avoiding TCP's head-of-line blocking where one lost segment stalls
all streams multiplexed over the same connection. QUIC gives each stream independent loss
recovery while still providing TCP-like reliability overall.

15. Extended Case Study: Debugging a Slow File Download

To see these mechanisms working together, consider a support ticket: a user reports that downloading
a large file over the office Wi-Fi is much slower than expected, even though a wired connection in
the same building is fast. Diagnosing this is a good exercise in tracing through the transport-layer
concepts above rather than guessing.

The first thing to check is which phase of the transfer is slow. If the connection takes an unusually
long time before any data starts flowing at all, the three-way handshake itself might be delayed — a
sign of high round-trip latency to the server, perhaps because of a distant CDN endpoint or a
congested upstream link, rather than a transport-layer bug per se. If data starts quickly but then
crawls, the more likely culprits are flow control or congestion control, and distinguishing between
them narrows the investigation considerably.
A flow-control-limited transfer typically shows a small, fairly constant advertised window from the
receiver — often because the receiving application (or its socket buffer configuration) isn't draining
data fast enough, throttling the sender regardless of how much bandwidth the network path could
otherwise support. This would explain why the wired connection, likely talking to the same receiving
application and OS configuration, is also affected — but the ticket says only Wi-Fi is slow, which
points elsewhere.

A congestion-control-limited transfer instead shows the classic AIMD sawtooth: throughput climbing
during slow start and congestion avoidance, then dropping sharply on a loss event, repeating in a
cycle. Wi-Fi links are considerably more prone to packet loss than wired Ethernet — interference,
distance from the access point, and contention with other devices on the same channel all cause drops
that a wired link simply doesn't experience. Each loss triggers fast retransmit and a congestion-
window cut, and if losses are frequent enough, the connection never has time to climb back to a high
throughput before being cut again, capping the effective transfer rate well below the link's raw
capacity.

The fix in a case like this usually isn't a transport-layer bug at all — TCP is behaving exactly as
designed — but rather addressing the underlying loss: moving closer to the access point, switching to
a less congested Wi-Fi channel, or in some cases enabling a more loss-tolerant congestion control
algorithm (e.g., BBR instead of classic loss-based algorithms) that reacts to measured latency
increases rather than waiting for outright packet loss as its primary signal. This case study is a
reminder that TCP's reliability and congestion-control machinery, covered abstractly above, has very
direct, observable consequences on ordinary user-facing performance.

16. Appendix: The Transport Layer in the Broader Stack

It's worth explicitly connecting the transport layer to the layers above and below it, since exam
questions and real debugging both tend to require reasoning across layer boundaries rather than
treating each layer in isolation.
Below: The Network Layer

TCP relies on IP to actually route packets from source to destination across intermediate routers;
TCP itself has no concept of routing at all. This division is deliberate: IP handles best-effort delivery
across arbitrary, unreliable networks, while TCP layers reliability, ordering, flow control, and
congestion control on top, without needing to know anything about the physical path packets take.
This separation of concerns is what lets the same TCP implementation work identically whether the
underlying network is Ethernet, Wi-Fi, or a satellite link, even though those links have wildly
different loss and latency characteristics.

Above: The Application Layer

Application protocols like HTTP, SMTP, and FTP are built as a sequence of bytes sent over a TCP
connection, treating TCP's guarantee of an in-order, reliable byte stream as a foundation they don't
have to re-implement themselves. This is precisely why so many application protocols historically
chose TCP over UDP by default — reliability and ordering are useful properties for almost any
application, and reimplementing them at the application layer on top of UDP (as QUIC eventually
did, deliberately, for specific latency reasons) is significant extra engineering effort most applications
don't need to take on.

Encryption: Where TLS Fits

TLS sits between the transport and application layers conceptually, though it runs as a library the
application calls into rather than as a separate OS-level layer. A TLS-secured connection first
completes the ordinary TCP three-way handshake, and only then performs a separate TLS handshake
over that now-established, reliable byte stream to negotiate encryption keys — meaning an HTTPS
request always pays the latency cost of two sequential handshakes (TCP, then TLS) before any actual
HTTP data is exchanged, which is part of the motivation behind protocols like TLS 1.3 and QUIC
that work to reduce or overlap that handshake latency.

17. Appendix: Quick Reference Summary

Concept One-line summary
Three-way handshake SYN, SYN-ACK, ACK — establishes shared initial sequence numbers
Flow control Receiver-driven; protects the receiver's buffer via advertised window
Congestion control Sender-driven; protects the shared network via cwnd and AIMD
 Concept One-line summary
Slow start Exponential cwnd growth until threshold or loss
Fast retransmit Triggered by 3 duplicate ACKs, skips waiting for timeout
TCP vs UDP Reliable & ordered vs. fast & best-effort

18. Study Summary

The transport layer's whole story can be reconstructed from one core tension: applications want a
simple, reliable, ordered stream of bytes, but the underlying network only promises best-effort,
possibly-out-of-order, possibly-dropped packets. TCP is the protocol that bridges that gap, and every
mechanism covered above exists to solve one specific piece of it — sequence numbers and ACKs
solve ordering and loss detection, retransmission timers and fast retransmit solve recovery from loss,
the receiver's advertised window solves protecting a slow receiver, and the congestion window with
slow start, congestion avoidance, and AIMD solves protecting the shared network from an aggressive
sender.

UDP exists because not every application wants that tradeoff: when latency matters more than
completeness, skipping TCP's reliability machinery entirely and handling loss at the application layer
(or not at all) is the better fit. Keeping this underlying tension in mind — reliable-but-slower versus
fast-but-best-effort — makes it much easier to reason about new protocols (like QUIC) or unfamiliar
exam scenarios, since almost every design decision in this space traces back to where a protocol
lands on that same spectrum.