TCP and UDP

1. Learning Objectives

By the end of this lesson, you will be able to:

• Differentiate between TCP and UDP at Layer 4 of the OSI model, detailing state management, header overhead, and data-unit properties (streams vs. datagrams).
• Explain the mechanics of the TCP 3-way handshake, sequence numbers, flow control (sliding window), congestion control (Slow Start, Congestion Avoidance, Fast Retransmit), and the 4-way connection teardown.
• Understand UDP's lightweight architecture and why it acts as the foundation for modern transport innovations like QUIC (HTTP/3).
• Evaluate real-world engineering trade-offs between reliability and latency to confidently select the appropriate protocol during system design interviews and production deployments.

2. Prerequisites

To fully absorb this material, you should have a baseline understanding of:

• The OSI Model: Specifically Layer 3 (Network Layer, responsible for routing packets across IP addresses) and Layer 4 (Transport Layer, managing host-to-host communication).
• Client-Server Architecture: The concepts of ports, IP addresses, and sockets binding together to enable process-to-process communication.
• Network Latency: The concept of Round-Trip Time (RTT) and basic packet loss dynamics on public networks.

3. Why This Topic Matters

At the scale of modern distributed systems, choosing the incorrect Transport Layer protocol can severely impact application performance, cost, and reliability.

Traditional web traffic (HTTP/1.1, HTTP/2) and critical infrastructure (databases, file transfers, remote shells) rely on TCP to ensure that not a single bit of data is corrupted or lost. However, TCP's focus on reliability introduces significant head-of-line blocking and handshake latencies. For real-time applications such as video conferencing, high-frequency telemetry, live-action multiplayer gaming, and IoT data ingestion, these delays can make services completely unusable.

Furthermore, the modern web is actively transitioning to HTTP/3, which is built on QUIC—a protocol running over UDP rather than TCP. Having a deep, production-level knowledge of Layer 4 behaviors is essential for debugging microservice communication, tuning network performance, and passing system design interviews.

4. Real-world Analogy

Think of the transport protocols like two different ways to deliver a message across a country:

• TCP is Certified Mail with Delivery Tracking: Before you can send a parcel, you call the recipient and confirm they are home to receive it. Every package is assigned an explicit sequence number. The mail carrier tracks each delivery, and the recipient signs for every package. If a package is damaged or lost along the way, the carrier automatically goes back to the warehouse, recreates the package, and delivers it again. The recipient receives packages in the exact order they were sent. This process guarantees delivery but requires significant coordination, time, and paperwork.
• UDP is dropping postcards into a collection box: You write messages on postcards, stamp them, and drop them in the mailbox. You do not check if the recipient is currently home or if the mail carrier is overloaded. There are no tracking numbers, signatures, or guarantees. Postcards might arrive out of order, or some might get lost in transit. However, this process is incredibly fast, simple, and has minimal cost. If a postcard is lost, you do not try to resend it unless the recipient specifically asks.

5. Core Concepts

To understand how these protocols operate under the hood, we must establish several foundational concepts:

• Connection-Oriented vs. Connectionless: Connection-oriented protocols (TCP) establish a logical session state between two endpoints before any application data is sent. Connectionless protocols (UDP) treat each packet as an independent entity, maintaining no state about the path or the remote peer.
• Byte Streams vs. Datagrams: TCP is a byte-stream protocol. It views data as an unstructured, continuous flow of bytes. It may bundle multiple application-layer writes into a single segment or split a single write across multiple segments. UDP is a datagram protocol. It preserves message boundaries: one write by the application corresponds to one transmitted UDP packet.
• Reliability and Ordering: Reliability means the protocol guarantees that data sent is eventually received, using techniques like Acknowledgments (ACKs) and Automatic Repeat Requests (ARQ). Ordering guarantees that bytes are delivered to the application layer in the exact sequence they were transmitted, using Sequence Numbers to reassemble out-of-order packets.
• Flow Control: A mechanism (implemented via TCP's Sliding Window) that prevents a fast sender from overwhelming a slow receiver's internal buffer.
• Congestion Control: A mechanism that prevents the sender from overwhelming the shared network infrastructure (routers, switches, links) by throttling output when packet drops or latency spikes are detected.
• MTU and MSS:
  • MTU (Maximum Transmission Unit): The largest physical frame size a network interface can transmit (typically 1500 bytes on Ethernet).
  • MSS (Maximum Segment Size): The maximum payload size TCP can fit in a single segment without IP fragmentation (typically 1460 bytes: 1500 - 20 bytes IP header - 20 bytes TCP header).

6. Visualization

The diagram below outlines the core lifecycle and packet flow differences. Notice the multi-step handshake and tear-down sequences required by TCP compared to the immediate, direct transmission of UDP:

7. How It Works

The TCP Connection Lifecycle

TCP operates through three major phases: connection establishment, active data transfer, and connection teardown.

1. Connection Establishment (3-Way Handshake)

1. SYN (Synchronize): The client selects an Initial Sequence Number (ISN), say X, and sends a packet with the SYN flag set to the server. This signals the client's intent to connect and defines its starting sequence.
2. SYN-ACK (Synchronize-Acknowledge): The server receives the SYN, generates its own Initial Sequence Number (ISN), say Y, and sends a packet with both SYN and ACK flags set. The acknowledgment number is set to X + 1, indicating it expects sequence number X + 1 next.
3. ACK (Acknowledge): The client receives the SYN-ACK, increments the sequence number to X + 1, and sends an ACK packet back to the server with the acknowledgment number set to Y + 1.

Once the server receives the final ACK, both sides have verified bidirectional connectivity and established the initial window sizes.

2. Data Transfer

During data transmission, TCP ensures reliability via several mechanisms:

• Sequence and ACK Tracking: Every byte sent is tracked. If Client sends 1000 bytes starting at sequence 1001, the server responds with ACK 2001 once received.
• Retransmission Timeout (RTO): If an ACK for a sent packet does not arrive within a dynamically calculated RTO period, the client assumes the packet was dropped and retransmits it.
• Sliding Window: The receiver advertises its available buffer size (Receive Window) in every ACK. The sender guarantees that the total unacknowledged bytes in flight never exceed this advertised limit.

3. Connection Teardown (4-Way Handshake)

Since TCP is full-duplex (data can flow both ways independently), closing a connection requires each direction to be terminated separately:

1. FIN: Host A has finished sending data and transmits a segment with the FIN flag set.
2. ACK: Host B receives the FIN and sends an ACK. Host B can still send remaining data to Host A.
3. FIN: Once Host B finishes sending its own data, it transmits a FIN to Host A.
4. ACK: Host A receives the FIN and responds with an ACK.

After sending the final ACK, Host A transitions into the TIME_WAIT state. It keeps the port locked for 2 * MSL (Maximum Segment Lifetime, typically 1 to 4 minutes) to ensure that any delayed, duplicate packets remaining in the network are discarded and do not corrupt a future connection on the same socket combination.

The UDP Lifecycle

UDP requires no handshake, no teardown, and maintains zero session state.

• The application creates a socket and calls sendto(), supplying the target IP address and port.
• The operating system attaches the 8-byte UDP header and hands the datagram directly to the IP layer.
• The receiving application binds a socket to a port and calls recvfrom() to read datagrams as they arrive. If the read buffer is full or the network drops a packet, it is discarded without warning or recovery.

8. Internal Architecture

Segment Headers

The differing internal architectures of TCP and UDP are clearly reflected in their headers:

The TCP Header (20 to 60 Bytes)

The complexity of TCP requires a substantial header payload:

• Source & Destination Ports (16 bits each): Route segments to the correct application sockets.
• Sequence Number (32 bits): Tracks the location of the first byte of this segment in the overall stream.
• Acknowledgment Number (32 bits): Indicates the next byte number the sender of this segment expects to receive.
• Data Offset (4 bits): Length of the TCP header (necessary since Options can vary the size).
• Control Flags (9 bits): Includes SYN, ACK, FIN, RST (reset connection), PSH (push data immediately to app), and URG (urgent data).
• Window Size (16 bits): Tells the peer how many bytes the receiver is willing to accept (used for flow control).
• Checksum (16 bits): Validates that the header and payload were not corrupted in transit.
• Options (Variable, 0 to 40 bytes): Used for advanced features like Window Scaling (allowing windows larger than 64KB) and Selective Acknowledgments (SACK).

The UDP Header (Exactly 8 Bytes)

UDP requires only four fields, totaling 8 bytes:

1. Source Port (16 bits): Identifies the sending port (optional; can be set to zero if no reply is expected).
2. Destination Port (16 bits): Identifies the receiving port.
3. Length (16 bits): Specifies the total size of the UDP header plus payload in bytes (minimum 8).
4. Checksum (16 bits): Performs basic error-detection on the header and payload (optional in IPv4, mandatory in IPv6).

Architectural Comparison

9. Request Lifecycle

What happens when an application transmits data over a network socket? Let's trace the precise path of a payload:

The TCP Path

1. Application Write: The application invokes a system call (e.g., write() or send()) passing a buffer of data. The operating system copies this payload from user-space memory into the kernel's Socket Send Buffer.
2. TCP Segment Creation: The TCP driver segments the buffered stream into blocks no larger than the negotiated MSS (Maximum Segment Size). It attaches a TCP header containing the correct sequence numbers.
3. IP Packaging: The segment is passed down to the IP (Layer 3) driver, which wraps the segment in an IP packet containing the source and destination IP addresses.
4. Physical Interface: The IP packet goes to the Network Interface Card (NIC) driver, which converts the packet into an Ethernet/Wi-Fi frame (Layer 2) and sends it over the physical medium.
5. Transit: Switches and routers process the packet hop-by-hop.
6. Receiver Processing: The receiver's NIC validates the frame checksum, strips the Layer 2 header, and passes the IP packet to the kernel's TCP stack.
7. Reassembly: The TCP stack verifies the checksum, validates the sequence number, and responds with an ACK. Out-of-order segments are held in the Socket Receive Buffer until missing segments arrive.
8. Application Read: The receiving application calls read(), and the kernel copies the ordered, reconstructed byte stream into the application's user-space memory.

The UDP Path

1. Application Write: The application calls sendto().
2. Immediate Dispatch: The kernel does not buffer this data for flow control. It immediately attaches the 8-byte UDP header, creating a datagram, and sends it directly to Layer 3.
3. Transmission: The packet is placed on the network wire.
4. Receiver Processing: The destination OS checks the checksum and ports. If correct, it places the entire datagram into the socket's receive queue.
5. Immediate Delivery: The receiving application reads the packet. If the application does not read from the socket fast enough and the kernel's receive buffer fills up, incoming datagrams are silently dropped.

10. Deep Dive

1. TCP Congestion Control Algorithms

Congestion control stops a TCP connection from collapsing the network under load. The window size used to pace data is governed by the Congestion Window (cwnd):

• Slow Start: The sender starts with a small cwnd (e.g., 10 MSS). For every ACK received, cwnd is doubled. This leads to exponential growth to quickly determine the network's capacity.
• Congestion Avoidance: Once cwnd hits the Slow Start Threshold (ssthresh), the protocol transitions to linear growth. It increases cwnd by 1 MSS per RTT. This is called Additive Increase.
• Fast Retransmit & Recovery: If a packet is lost, the receiver will send duplicate ACKs for the last successfully received in-order packet. If the sender receives three duplicate ACKs, it immediately retransmits the missing segment (Fast Retransmit) without waiting for a retransmission timeout (RTO) to expire. It then reduces cwnd by half (Multiplicative Decrease) rather than dropping it to 1, resuming data transfer quickly (Fast Recovery).

Modern production systems often use algorithms like CUBIC (which uses a cubic function to scale window size aggressively) or BBR (Bottleneck Bandwidth and RTT), developed by Google, which models the physical properties of the path to maximize throughput and minimize buffering latency.

2. Nagle's Algorithm vs. TCP_NODELAY

In the early days of the internet, applications sending tiny payloads (like single keystrokes in Telnet) created massive overhead: sending 1 byte of payload inside 40 bytes of headers (TCP + IP).

Nagle's Algorithm solves this by holding back small outbound packets until the sender has enough data to fill a maximum-sized segment, or until all sent data has been acknowledged.

However, when combined with Delayed ACKs (where a receiver waits up to 200ms before sending an ACK to see if it can combine it with an outgoing data segment), Nagle's algorithm can cause latency spikes of 40ms to 200ms. For modern APIs, WebSockets, or database calls, this latency is unacceptable. Engineers resolve this by enabling the TCP_NODELAY socket option, which disables Nagle's algorithm and forces the TCP stack to send segments immediately.

3. Head-of-Line (HoL) Blocking

Because TCP guarantees ordered delivery, the kernel cannot pass a received segment to the application layer if a preceding segment is missing. If Segment 3 is dropped, Segments 4, 5, and 6 are buffered in kernel memory and cannot be read by the application. This is known as Transport-Layer Head-of-Line Blocking.

Under HTTP/2, multiple requests are multiplexed over a single TCP connection. If one packet is lost, all multiplexed requests are blocked until the lost packet is retransmitted. UDP is immune to this issue because it does not enforce ordering; if a packet is lost, other packets continue to be processed.

11. Production Example

Case 1: HTTP/3 and QUIC (Google, Cloudflare)

To eliminate Transport-Layer Head-of-Line Blocking while maintaining reliability, Google designed the QUIC protocol, which serves as the foundation for HTTP/3.

Because updating TCP requires modifying operating system kernels on billions of devices globally, Google built QUIC in user-space, running on top of UDP. QUIC handles reliability, encryption, and congestion control internally. It processes multiplexed streams independently. If a packet belonging to stream A is lost, stream B and C continue uninterrupted. This reduces connection establishment latency to a single round trip (or 0-RTT for resumed connections) and allows seamless connection migration (e.g., switching from Wi-Fi to cellular without renegotiating).

Case 2: Live Video Streaming (WebRTC)

For video-on-demand services (like Netflix), video player clients download chunks of video over TCP (HLS/DASH over HTTP). Buffering is acceptable because the client can pre-buffer a few seconds of video, making TCP's reliability ideal.

However, for live interactive video (like Zoom, Microsoft Teams, or WebRTC streams), a delay of more than 200ms makes real-time communication difficult. If packet loss occurs, retransmitting the lost frame is useless because the playhead has moved forward. These platforms stream video using UDP. They handle packet loss in the application layer, using techniques like Forward Error Correction (FEC, sending redundant data to reconstruct lost packets) or frame interpolation to conceal drops, prioritizing low latency over perfect visual fidelity.

12. Advantages

TCP Advantages

• Guaranteed Delivery: Lost data is automatically detected and retransmitted, protecting application logic from transient network issues.
• Preserved Ordering: Senders write structured streams, and receivers read them in the exact order they were sent.
• Dynamic Congestion Avoidance: Adapts to network path congestion dynamically, protecting network infrastructure from collapse.
• Simpler Application Logic: Developers do not need to write code to handle packet loss, duplicate packets, or out-of-order delivery.

UDP Advantages

• Ultra-Low Latency: No handshake overhead means data transmission can begin immediately.
• Minimal Header Overhead: The 8-byte header leaves more room for payload and reduces network bandwidth consumption.
• No Head-of-Line Blocking: One dropped packet does not stall subsequent datagrams.
• Customizable Reliability: Applications can implement custom reliability patterns in user-space (like QUIC or custom game protocols).
• Broadcasting & Multicasting: Supports sending a single message to multiple hosts on a local network, which TCP cannot do.

13. Limitations

TCP Limitations

• Connection Setup Overhead: The 3-way handshake adds 1 RTT of latency before data is sent. Combining this with TLS handshakes can add up to 2-3 RTTs of delay.
• Memory Footprint: The kernel must allocate memory for send and receive buffers for every open connection, limiting server scalability.
• Head-of-Line Blocking: A single lost packet stalls the delivery of all subsequent segments on that socket.
• State Vulnerability: Servers must track connection states, making them vulnerable to resource-exhaustion attacks like SYN flooding.

UDP Limitations

• No Delivery Guarantees: Packets can be lost, duplicated, or silently dropped.
• No Ordering: Packets may arrive at the destination in any sequence.
• Risk of Network Congestion: Since UDP does not have built-in congestion control, a poorly designed application can flood the network and cause packet drops across other services.
• IP Fragmentation: If a UDP datagram exceeds the path's MTU, the IP layer will fragment it. If even one fragment is lost, the entire datagram is discarded.

14. Trade-offs

When choosing between TCP and UDP, you are making several key trade-offs:

• Reliability vs. Latency: Do you need to ensure every byte arrives correctly (TCP), or do you need to send updates as fast as possible, where stale data can be discarded (UDP)?
• OS Kernel Control vs. Application-Space Control: TCP relies on the OS kernel for flow control, congestion management, and ordering. UDP gives full control to the application layer, allowing developers to build custom congestion control and recovery logic (e.g. QUIC).
• Bandwidth Efficiency vs. Header Overhead: UDP uses an 8-byte header, making it highly efficient for sending small payloads. TCP's 20-60 byte header can introduce significant overhead if you are only sending small, frequent updates.
• Stateful Scale vs. Stateless Throughput: Stateful servers (TCP) require tracking connection states, which consumes kernel memory. Stateless UDP servers do not track connection states, allowing them to handle a higher volume of incoming packets with lower memory overhead.

15. Performance Considerations

To run these transport protocols at scale, engineers must tune several key performance parameters:

1. Bandwidth-Delay Product (BDP)

The Bandwidth-Delay Product defines the volume of data that can be in flight on a network link at any given moment:

BDP (bits) = Link Bandwidth (bits/sec) × Round-Trip Time (sec)

To maximize network throughput, TCP's receive window size must be at least as large as the BDP. If it is smaller, the sender will pause and wait for ACKs before sending more data, leaving available bandwidth unused. Modern operating systems use Window Scaling options in the TCP header to support window sizes up to 1GB to handle high-latency, high-bandwidth links.

2. TIME_WAIT Accumulation

When a high-throughput server makes thousands of outgoing TCP connections (e.g., to a database or external API) and closes them quickly, ports remain locked in the TIME_WAIT state for up to 4 minutes. This can lead to ephemeral port exhaustion, causing new connection attempts to fail.

To prevent this, production systems use connection pooling to reuse existing connections, enable SO_REUSEADDR to allow immediate binding to the same address, or configure kernel parameters like net.ipv4.tcp_tw_reuse to recycle ports safely.

3. Kernel Offloading (TSO/LRO)

Processing network interrupts for every packet at high speeds (e.g. 10Gbps or 40Gbps) can consume significant CPU resources. Production servers offload this processing to the network card:

• TCP Segmentation Offload (TSO): The CPU passes large blocks of data to the NIC, and the NIC handles segmenting the data into MTU-sized packets.
• Large Receive Offload (LRO): The NIC aggregates incoming TCP segments into a single large buffer before passing it to the OS kernel, reducing interrupt overhead.

16. Failure Scenarios

Understanding how these protocols behave under stress is critical for troubleshooting system failures:

1. SYN Flood DDoS Attacks

In a SYN flood attack, attackers send thousands of SYN packets to a server but ignore the server's SYN-ACK responses. The server allocates resources in its half-open connection queue (SYN Backlog) for each request, waiting for the final ACK. This queue quickly fills up, blocking legitimate clients from establishing new connections.

Mitigation: Servers use SYN Cookies. Instead of allocating resources immediately, the server encodes connection state information into the initial sequence number (ISN) of the SYN-ACK response. When the client returns the final ACK, the server validates the sequence number and allocates resources only then.

2. Ephemeral Port Exhaustion

Outbound connections require an ephemeral source port. If a service establishes and teardown connections to a database or proxy at a high rate, it can exhaust its available ephemeral ports (typically 28,000 ports). New connection requests will fail with errors like "Cannot assign requested address."

Mitigation: Use persistent connection pools, configure multiple virtual IP addresses on the client, or tune the kernel's local port range settings.

3. Path MTU Black Holes

If a router along the network path has a lower MTU than the sender's MSS, and the sender has set the "Don't Fragment" (DF) flag in the IP header, the router will drop the packet. Normally, the router sends back an ICMP "Fragmentation Needed" packet, allowing the sender to adjust its MSS.

If a firewall blocks these ICMP packets, the sender continues to retransmit the oversized packet, waiting for ACKs that never arrive. This results in a "Black Hole" where the TCP connection establishes successfully (since handshakes are small) but hangs indefinitely when transmitting large payloads.

Mitigation: Implement Path MTU Discovery (PMTUD) or manually configure MSS clamping on routers and firewalls.

17. Best Practices

Apply the following best practices when configuring and designing network-facing applications:

• Use TCP by Default: Unless you have clear latency constraints and can handle packet loss, default to TCP to guarantee reliability, delivery, and ordering.
• Tune TCP Backlog Limits: For high-traffic servers, increase the maximum queue size of pending connections in the OS kernel by adjusting:

Enable TCP Keepalives: Keepalives send periodic packets on idle sockets, allowing the server to detect dead clients and reclaim resources.

Leverage SO_REUSEPORT: Enable SO_REUSEPORT to allow multiple server worker processes to bind to the same IP and port. The OS kernel will automatically load-balance incoming connections across these workers.

Disable Nagle's Algorithm for APIs: For interactive web APIs, WebSockets, or database queries, set TCP_NODELAY to ensure small, frequent payloads are sent without delay.

18. Common Mistakes

19. Implementation (Only If Applicable)

Below are complete, production-ready examples of a TCP and UDP server in Node.js, highlighting the differences in API usage, state management, and data boundary handling:

TCP Server (Reliable & Connection-Oriented)

UDP Server (Connectionless & Fast)

20. Interview Questions

Easy Questions

Q1: What are the main differences between TCP and UDP?

Answer: TCP is a stateful, connection-oriented protocol that guarantees reliable, ordered delivery of data via handshakes and acknowledgments, though it is slower and has higher header overhead (20-60 bytes). UDP is a connectionless, best-effort protocol that does not guarantee delivery or ordering, but is faster, lightweight, has lower overhead (8 bytes), and does not establish a connection before sending data.

Medium Questions

Q2: Why does TCP use a 3-way handshake to establish a connection instead of a 2-way handshake?

Answer: A 3-way handshake is necessary because both sides must agree on initial sequence numbers (ISNs) and confirm bidirectional connectivity before sending data. In a 2-way handshake (e.g., Client sends SYN, Server sends SYN-ACK), the client knows the server can receive its data, but the server cannot verify if the client received its SYN-ACK. If the client's connection request was delayed and arrived after the client had already disconnected, a 2-way handshake would force the server to allocate resources for a dead connection. The third step (ACK from the client) confirms that the client is active and has received the server's sequence parameters.

Hard Questions

Q3: Explain the purpose of the TCP TIME_WAIT state. What problems does it solve, and how do you handle port exhaustion caused by too many sockets sitting in TIME_WAIT?

Answer: The TIME_WAIT state occurs on the side that initiates the active close. It lasts for 2 * MSL (Maximum Segment Lifetime). It serves two main purposes:

1. It ensures the final ACK is received by the peer. If the peer drops the final ACK, it will retransmit its FIN, which the closing host can only acknowledge if it has kept the socket state open.
2. It allows delayed, duplicate segments in transit to expire, preventing them from corrupting future connections that might open on the same IP and port combination.

Mitigation for Port Exhaustion:

• Use Connection Pooling to avoid constantly opening and closing connections.
• Enable the SO_REUSEADDR socket option, allowing a local port to be reused immediately.
• Tune the kernel parameters net.ipv4.tcp_tw_reuse to safely recycle ports in the TIME_WAIT state for outgoing connections to the same host when sequence numbers confirm it is safe.
• Increase the range of ephemeral ports by updating net.ipv4.ip_local_port_range.

21. Practice Exercises

Solve these exercises on your own to reinforce your understanding:

• Easy Exercise: Calculate the header overhead percentage for a UDP packet carrying a 20-byte payload versus a TCP packet (assuming no options) carrying the same 20-byte payload.
• Medium Exercise: Write a pseudo-code implementation of an application-layer sliding window protocol over a raw UDP socket. Explain how you will handle packet sequence numbers, buffer storage, and retransmission timeouts.
• Hard Exercise: A server located in New York communicates with a client in London (RTT = 80ms) over a 1Gbps network link. If the TCP Receive Window size is capped at 64KB (without Window Scaling), calculate the maximum theoretical throughput. Then, calculate the window size needed to fully saturate the 1Gbps network link.

22. Challenge Problem

System Design Scenario:

You are the Lead Systems Architect designing a globally distributed IoT telemetry platform. The platform ingest small, 100-byte status packets from 10 million active smart meters once every 5 seconds. These meters operate over low-cost, unstable cellular networks with an average packet loss rate of 5%.

If you use TCP for all telemetry, the constant handshakes, retransmissions, and socket allocations will quickly exhaust server resources and increase data ingestion costs. If you use UDP, you will lose critical data, packets will arrive out of order, and the system could suffer from network congestion.

Design a hybrid network architecture and application-layer transport protocol that:

1. Allows meters to send telemetry updates with sub-50ms connection overhead.
2. Guarantees delivery of critical events (like "Power Outage Alert") while allowing non-critical, periodic metric updates to be dropped if newer metrics are available.
3. Protects the platform from network congestion collapse using an application-level congestion control mechanism.
4. Safeguards the data against packet spoofing without the heavy overhead of a standard TLS handshake for every transmission.

23. Summary

TCP and UDP are the foundations of internet transport. TCP provides reliable, ordered byte streams at the expense of handshake latency, header overhead, and head-of-line blocking. UDP provides fast, connectionless datagram delivery, giving control over reliability and congestion to the application layer. Choosing between them requires balancing the need for data completeness and ordering against the need for low latency and high connection throughput.

24. Cheat Sheet

25. Quiz

26. Further Reading

Deepen your knowledge of Transport Layer protocols with these resources:

• RFC 793 (TCP): The official specification for the Transmission Control Protocol.
• RFC 768 (UDP): The official specification for the User Datagram Protocol.
• RFC 9000 (QUIC): The specification detailing QUIC's transport architecture.
• "Computer Networking: A Top-Down Approach" (Kurose & Ross): An excellent textbook covering transport layers, congestion control, and network architecture.
• "UNIX Network Programming, Volume 1" (W. Richard Stevens): The definitive guide for understanding socket programming and kernel-level network architectures.

27. Next Lesson Preview

In the next lesson, we will explore DNS (Domain Name System). We will examine how human-readable hostnames are translated into IP addresses, trace recursive and authoritative lookup cycles, and study how DNS load balancing is used to route traffic across globally distributed data centers.