Transport-Layer Communication

Introduction and Context

The transport layer provides end-to-end communication between application processes running on different hosts. Whereas the network layer delivers packets between devices, the transport layer delivers data to the correct application, manages conversations, and may provide reliability, ordering, flow control, and congestion control. In the Internet protocol suite, the principal transport protocols are the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and the newer QUIC protocol.

Transport-layer design involves a central trade-off. Applications may require dependable, ordered delivery, but reliability mechanisms add delay, state, acknowledgements, and processing overhead. Other applications prefer low latency and can tolerate loss or can implement their own recovery. Selecting a transport service therefore requires understanding both protocol mechanisms and application requirements.

Learning Objectives

After studying this chapter, you should be able to:

• explain ports, sockets, multiplexing, and demultiplexing;
• describe TCP connection establishment, data transfer, and termination;
• compare TCP, UDP, and QUIC;
• explain reliability, retransmission, flow control, and congestion control;
• calculate basic throughput and bandwidth-delay relationships;
• select an appropriate transport service for practical applications;
• identify security, performance, and operational limitations.

1. Transport-Layer Services

1.1 Process-to-process delivery

An IP address identifies a host interface, not an individual application. A transport protocol adds a port number so that arriving data can be delivered to the appropriate process. A transport segment or datagram normally contains source and destination port fields, together with protocol-specific control information.

Transport protocols support two forms of multiplexing. At the sender, data from many applications are collected and transmitted through the network interface. At the receiver, demultiplexing examines the destination address, protocol, and port information to deliver data to the correct socket.

1.2 Ports and sockets

A port is a 16-bit number from 0 to 65,535. Ports 0–1,023 are commonly known as well-known ports; operating systems often restrict their use to privileged services. Registered and dynamic/private ranges are used for applications and temporary client ports. Port conventions are administrative agreements, not guarantees that a service is actually running.

A socket is an operating-system communication endpoint. In practical networking, a TCP connection is identified by a four-tuple:

(source IP address, source port, destination IP address, destination port)

The transport protocol is also relevant when distinguishing TCP and UDP endpoints. A listening TCP server may accept many simultaneous connections on one server port because each connection has a different client address and client port. UDP commonly uses a local port for receiving datagrams, but it does not establish a connection in the TCP sense.

1.3 Service properties

Transport services can be characterized by:

• connection orientation: whether state is established before data transfer;
• reliability: whether lost data are detected and recovered;
• ordering: whether data are delivered in sending order;
• flow control: protection of a receiver from sender overload;
• congestion control: protection of the network from excessive offered load;
• latency and overhead: time and bandwidth added by protocol mechanisms;
• security: encryption, authentication, and resistance to attacks.

No transport protocol is universally best. Voice, file transfer, web browsing, DNS, industrial control, and online gaming have different requirements.

2. UDP: Minimal Datagram Transport

UDP is connectionless and message-oriented. Each datagram is transmitted independently and contains source and destination ports, length, checksum, and application data. UDP does not guarantee delivery, ordering, duplicate suppression, or retransmission. It has no standard transport-level flow-control or congestion-control algorithm.

UDP is useful when low overhead and application control are more important than built-in reliability. Examples include real-time audio and video, DNS queries, DHCP, network discovery, telemetry, and some interactive games. An application can add sequence numbers, acknowledgements, timestamps, or forward-error correction if required.

UDP is not automatically faster than TCP. A UDP application that sends aggressively can experience loss, incur queueing delay, or be rate-limited. Responsible UDP applications should implement suitable rate adaptation, especially across the public Internet.

The UDP checksum detects corruption in transit. A checksum is an error-detection mechanism, not a recovery mechanism: a damaged datagram may be discarded, but UDP does not retransmit it.

3. TCP: Reliable Byte-Stream Transport

TCP is connection-oriented and presents applications with a reliable, ordered byte stream. It divides application data into segments, assigns sequence numbers, acknowledges received data, retransmits data believed to be lost, and regulates transmission using receiver and congestion windows.

TCP does not preserve application message boundaries. If an application writes two messages, the receiver may read them as one larger block or several smaller blocks. Applications requiring message framing must encode lengths, delimiters, or records themselves.

3.1 The TCP segment

A TCP segment includes source and destination ports, sequence and acknowledgement numbers, control flags, receive-window information, checksum, urgent-pointer information, and optional parameters. Common flags include SYN, ACK, FIN, and RST. Options such as maximum segment size (MSS), window scaling, selective acknowledgement (SACK), and timestamps improve operation.

3.2 Connection establishment

TCP normally uses a three-way handshake:

1. The client sends a SYN containing an initial sequence number.
2. The server replies with SYN+ACK, acknowledging the client’s sequence number and proposing its own.
3. The client sends an ACK acknowledging the server’s sequence number.

The handshake confirms reachability in both directions, synchronizes sequence-number spaces, and negotiates options. It also creates state in the endpoint operating systems. A server that receives many spoofed SYNs may suffer a SYN-flood attack; SYN cookies and filtering are common defenses.

3.3 Reliable delivery

TCP acknowledgements normally indicate the next byte expected. If a segment carrying bytes 1,001–2,000 arrives, an acknowledgement may indicate 2,001 as the next expected byte. Duplicate acknowledgements and retransmission timers provide evidence of loss. Selective acknowledgement allows a receiver to report non-contiguous blocks, reducing unnecessary retransmission.

A simplified retransmission-timeout relationship is:

Here, SRTT is the smoothed round-trip time, RTTVAR is the smoothed variation in round-trip time, G is the clock granularity, and K is a protocol constant. Actual TCP algorithms specify how these estimates are updated and impose minimum and maximum bounds. The equation is a conceptual form of the standards-based calculation, not a license to use arbitrary timer values.

Retransmission cannot distinguish perfectly between congestion, wireless corruption, route changes, and receiver delay. Consequently, TCP uses conservative timers and congestion responses.

3.4 Connection termination

TCP termination is usually a four-segment exchange because each direction of the full-duplex byte stream closes independently. A FIN indicates that an endpoint has no more data to send; the peer acknowledges it and may continue sending data before issuing its own FIN. RST aborts a connection, often because of an invalid or unexpected condition.

The TIME-WAIT state helps prevent delayed duplicate segments from being confused with a later connection using the same tuple. It also allows the endpoint that sent the final ACK to retransmit that ACK if necessary.

4. Flow Control and Congestion Control

These mechanisms are related but solve different problems.

4.1 Flow control

Flow control protects the receiving host. TCP advertises a receive window, rwnd, representing the buffer space currently available. The sender should not have more unacknowledged data in flight than the permitted window. A zero receive window temporarily causes the sender to pause, although TCP uses probes to discover when space becomes available.

The receiver’s buffer, application reading rate, and operating-system configuration influence flow control. A slow application can advertise a small window even when the network is uncongested.

4.2 Congestion control

Congestion control protects the shared network. TCP maintains a congestion window, cwnd, based on observations such as acknowledgements, loss, and delay. A useful conceptual limit is:

FlightSize is the amount of unacknowledged data in transit, cwnd is the sender’s congestion window, and rwnd is the receiver-advertised window. The inequality applies to ordinary TCP window control; implementation details include acknowledgement behavior, segmentation, and loss-recovery rules.

During slow start, the congestion window grows rapidly, approximately doubling each round-trip time when acknowledgements arrive without congestion. During congestion avoidance, growth is approximately additive. On detecting loss, TCP reduces its sending rate; the exact response depends on the loss signal and algorithm, such as NewReno or CUBIC. Modern implementations may use explicit congestion notification (ECN), allowing routers to mark packets rather than discard them.

A basic bandwidth-delay product is:

BDP is the amount of data needed to keep a path busy, C is capacity in bits per second, and RTT is round-trip time in seconds. The result is in bits. For example, on a 100 Mb/s path with an RTT of 40 ms:

BDP = 100,000,000 × 0.040 = 4,000,000 bits, or 500,000 bytes (approximately 488 KiB). This is the approximate in-flight data required to fill the path, assuming the path can sustain the stated capacity and ignoring protocol overhead.

A simplified upper-bound throughput relationship for a loss-based TCP model is sometimes written:

where MSS is maximum segment size in bytes, RTT is in seconds, and p is the steady-state loss probability. This is only a rough model under assumptions such as long-lived traffic, independent losses, congestion avoidance, and a particular TCP behavior. It should not be used as an exact performance prediction.

5. QUIC: Secure, Multiplexed Transport over UDP

QUIC is a modern transport protocol commonly implemented in user space and carried in UDP datagrams. It provides reliable streams, congestion control, connection identifiers, integrated cryptographic handshake using TLS 1.3, and connection migration. HTTP/3 uses QUIC.

QUIC is not simply “UDP with encryption.” It defines substantial transport behavior above UDP while using UDP for deployability through existing network infrastructure. QUIC packets are protected against tampering, and packet-number spaces and acknowledgements support loss recovery.

5.1 Streams and head-of-line blocking

A QUIC connection can contain multiple independent streams. Loss on one stream need not prevent delivery of data on another stream, although congestion control still limits the connection as a whole. This reduces the transport-level head-of-line blocking associated with a single TCP byte stream. An application protocol may still impose its own ordering dependencies.

5.2 Handshake and migration

QUIC integrates TLS 1.3, reducing the number of round trips needed for secure connection establishment compared with separately layering a security handshake over TCP. QUIC uses connection IDs so that a connection can survive a change of client address, such as movement from Wi-Fi to cellular. Migration must still be validated to prevent address-spoofing and amplification attacks.

QUIC encrypts most transport metadata, but packet sizes, timing, and some headers may remain observable. It can also increase CPU, memory, and operational complexity, and middleboxes may treat unfamiliar traffic unpredictably.

6. Comparing TCP, UDP, and QUIC

7. Choosing a Transport Service

Selection should begin with application requirements rather than protocol popularity.

• Choose TCP when a reliable ordered byte stream is appropriate and broad compatibility is important, such as file transfer, database sessions, and traditional web services.
• Choose UDP when individual datagrams are meaningful, low overhead matters, and the application can tolerate loss or provide its own recovery. Rate control and security must be designed deliberately.
• Choose QUIC when encrypted multiplexed streams, reduced handshake latency, connection migration, or avoidance of TCP head-of-line blocking is valuable, particularly for HTTP/3 and mobile clients.

Real-time media often uses RTP over UDP with application-level timing and loss handling. A live voice call may prefer a late but missing voice frame to a retransmitted frame that arrives after its playback deadline. A financial transaction, by contrast, normally needs reliable, ordered delivery and explicit application confirmation.

A decision should also consider firewall and enterprise policy, operating-system support, observability, server libraries, CPU cost, NAT behavior, and regulatory requirements for encryption and logging.

8. Applied Case: A Mobile Learning Platform

The following is an illustrative case.

Background

A university learning platform delivers recorded lectures, live classroom audio, quizzes, and account services to students using campus Wi-Fi and mobile networks. Initial deployment uses TCP for all traffic.

Problem

Recorded video works well, but live sessions experience delay when packets are lost. A single lost unit in a TCP stream can delay later data until retransmission. Students moving between Wi-Fi and cellular networks also experience connection resets. Quiz submission requires dependable delivery and clear confirmation.

Analysis

The traffic has three different service profiles. Video can use adaptive bitrate and may benefit from QUIC’s multiplexed streams and connection migration. Live audio is delay-sensitive; waiting indefinitely for retransmission is undesirable, so a datagram-based media design with sequence numbers and jitter buffering is suitable. Quiz submissions require reliable, authenticated delivery and an application-level confirmation.

Approach and solution

The platform adopts HTTP/3 over QUIC for web pages, authentication, and adaptive video. Separate media transport uses UDP-based real-time protocols with encryption, sequence numbers, timestamps, and a bounded jitter buffer. The media sender adapts its rate to congestion and does not transmit without limit. Quiz operations use a reliable QUIC stream, with unique transaction identifiers so that a retry cannot create duplicate submissions.

Monitoring records handshake failures, retransmissions, round-trip time, loss, congestion signals, and application completion rates without storing unnecessary personal content. Network policy permits approved UDP traffic while retaining a controlled TCP fallback.

Outcome

The design reduces disruption during address changes and prevents a delayed video stream from blocking unrelated control streams. Audio remains responsive because its playback deadline guides recovery decisions. Quiz data receives reliable delivery and explicit acknowledgement.

Learning points

Transport choice should be made per traffic class, not necessarily per application. Reliability, security, congestion behavior, and user experience must be considered together. A protocol feature is valuable only when the application can use it correctly and the surrounding network permits it.

9. Challenges, Security, and Best Practices

Transport protocols face loss, delay variation, packet reordering, NAT, asymmetric paths, limited buffers, and changing link capacity. High-speed and high-latency paths can require large windows and careful buffer management. Excessive buffering creates bufferbloat, increasing delay even when throughput appears high.

Important attacks include port scanning, TCP SYN floods, UDP reflection and amplification, connection exhaustion, spoofing, and denial of service. Encryption authenticates and protects content but does not eliminate traffic analysis or availability attacks. Services should validate input, limit connection rates, use sensible timeouts, authenticate peers, and avoid exposing unnecessary ports.

Best practices include:

1. Define whether the application needs streams, messages, ordering, or deadlines.
2. Use TLS or QUIC security rather than inventing cryptography.
3. Implement congestion-aware behavior for UDP-based applications.
4. Set receive buffers and timeouts based on measured network conditions.
5. Instrument RTT, loss, retransmissions, throughput, and application latency.
6. Test under loss, reordering, delay, mobility, and partial outages.
7. Preserve message boundaries explicitly when using TCP.
8. Treat retries as potentially duplicating operations; use idempotency keys for important transactions.
9. Keep protocol libraries and cryptographic implementations updated.
10. Apply privacy, retention, and lawful-interception policies consistently with institutional and national requirements.

10. Contemporary Developments

HTTP/3 has made QUIC important in web delivery, while QUIC DATAGRAM supports applications that need unreliable messages alongside reliable streams. Multipath transport research aims to use several network paths simultaneously. Modern congestion-control research explores delay signals, explicit congestion notification, fairness, and performance on wireless and data-centre networks.

Artificial intelligence does not replace transport protocols, but it can assist operations by detecting unusual RTT, loss, or traffic patterns and predicting capacity demand. Such systems should not autonomously alter congestion behavior without safeguards: a faulty model could increase congestion, violate fairness, or obscure accountability. Measurements must also be collected and processed in accordance with privacy and governance requirements.

Chapter Summary

The transport layer delivers data between application processes using ports and sockets. UDP offers lightweight datagrams without built-in reliability, while TCP provides a reliable ordered byte stream with acknowledgements, retransmission, flow control, and congestion control. QUIC uses UDP as a substrate but supplies encrypted, multiplexed streams, congestion control, connection migration, and integrated TLS 1.3.

Flow control protects the receiver through rwnd, whereas congestion control protects the network through cwnd. The usable in-flight data is conceptually bounded by min(cwnd, rwnd), and the bandwidth-delay product estimates the data needed to fill a path. TCP is appropriate for dependable stream-oriented services; UDP suits carefully designed low-latency or datagram applications; QUIC is attractive for secure, multiplexed, mobile, and modern web communication. Correct selection requires attention to application deadlines, ordering, security, network behavior, operational constraints, and user experience.

Key Terms

Port: A 16-bit transport-layer identifier used to select an application process.

Socket: An operating-system endpoint through which an application communicates.

Multiplexing: Combining data from multiple applications for transport.

Demultiplexing: Delivering received data to the correct application socket.

TCP: A reliable, ordered, connection-oriented byte-stream protocol.

UDP: A connectionless datagram protocol with minimal transport services.

QUIC: An encrypted, multiplexed transport protocol carried over UDP.

Segment: A TCP protocol data unit.

Datagram: An independent UDP protocol data unit.

Three-way handshake: TCP exchange of SYN, SYN+ACK, and ACK.

Sequence number: A number identifying a position in a TCP or QUIC data sequence.

Acknowledgement: Control information indicating successfully received data.

Retransmission: Sending data again after suspected loss.

Flow control: Regulation that prevents sender overload of the receiver.

Congestion control: Regulation that limits offered load to protect the network.

Receive window: Receiver-advertised available buffer capacity.

Congestion window: Sender estimate of permitted in-flight data due to network conditions.

Bandwidth-delay product: Link capacity multiplied by round-trip time.

Head-of-line blocking: Delay of later data because earlier required data is missing.

Connection migration: Continuation of a QUIC connection after an address change.

Review Questions

Short Answer Questions

1. What is the purpose of a transport-layer port?
2. Why does TCP not preserve application message boundaries?
3. Distinguish flow control from congestion control.
4. What does the TCP three-way handshake accomplish?
5. State two advantages of QUIC over a conventional TCP-based secure connection.

Long Answer Questions

1. Explain TCP reliable delivery, including sequence numbers, acknowledgements, timers, and retransmission.
2. Compare TCP, UDP, and QUIC in terms of connection model, reliability, ordering, security, and typical applications.
3. Explain how cwnd and rwnd jointly limit TCP data in flight.
4. Discuss the design consequences of TCP head-of-line blocking and QUIC streams.
5. Describe security and operational practices for deploying UDP or QUIC services on the public Internet.

Analytical / Application Questions

1. A video application experiences unacceptable delay whenever a packet is lost, while its account service requires exact, reliable transactions. Recommend transport choices for both traffic classes and justify them.
2. A path has capacity of 200 Mb/s and RTT of 50 ms. Calculate its bandwidth-delay product in bits and bytes, stating assumptions, and explain why a small TCP window may limit throughput.
3. A mobile user changes from Wi-Fi to cellular while watching a lecture. Compare how TCP and QUIC would normally handle the change and identify one remaining limitation of QUIC.

Multiple Choice Questions with Answers

Question 1

Which transport-layer identifier directs received data to an application process?

A. MAC address

B. Port number

C. TTL value

D. Frame check sequence

Correct Answer: B. Port number

Question 2

Which statement correctly describes UDP?

A. It guarantees ordered delivery and retransmission.

B. It provides a reliable byte stream.

C. It provides independent datagrams without built-in delivery guarantees.

D. It requires a three-way handshake before every exchange.

Correct Answer: C. It provides independent datagrams without built-in delivery guarantees.

Question 3

What is the main purpose of TCP flow control?

A. To encrypt application data

B. To prevent a sender from overwhelming the receiver

C. To select the shortest IP route

D. To assign well-known ports

Correct Answer: B. To prevent a sender from overwhelming the receiver

Question 4

In the conceptual TCP window relationship, which quantity limits in-flight data together with the receive window?

A. MSS only

B. SRTT only

C. Congestion window

D. Source port

Correct Answer: C. Congestion window

Question 5

What is the correct order of the normal TCP connection-establishment exchange?

A. ACK, SYN, FIN

B. SYN, SYN+ACK, ACK

C. FIN, ACK, SYN

D. SYN+ACK, FIN, ACK

Correct Answer: B. SYN, SYN+ACK, ACK

Question 6

A TCP connection provides an application with which abstraction?

A. An unordered collection of independent datagrams

B. A reliable, ordered byte stream

C. A broadcast channel

D. A physical circuit

Correct Answer: B. A reliable, ordered byte stream

Question 7

Which feature is particularly associated with QUIC?

A. No congestion control

B. Integrated TLS 1.3 and multiplexed streams

C. Mandatory preservation of UDP datagram delivery

D. Operation only on dedicated physical links

Correct Answer: B. Integrated TLS 1.3 and multiplexed streams

Question 8

A path has capacity 100 Mb/s and RTT 0.040 s. What is its bandwidth-delay product?

A. 40,000 bits

B. 400,000 bits

C. 4,000,000 bits

D. 40,000,000 bits

Correct Answer: C. 4,000,000 bits

Question 9

Why might a real-time voice application avoid waiting for every lost packet to be retransmitted?

A. Late audio may be less useful than a missing audio frame

B. Voice never uses sequence numbers

C. Retransmission always increases bandwidth capacity

D. UDP cannot carry audio

Correct Answer: A. Late audio may be less useful than a missing audio frame

Question 10

What problem does QUIC connection migration address?

A. Changing an application message into a byte stream

B. Continuing a connection after a client address changes

C. Converting IPv4 into a MAC address

D. Removing all congestion from a network

Correct Answer: B. Continuing a connection after a client address changes