Udp Vs Tcp - Learning Module

Loading content...

0/228

Connection Handling — Architectural Implications

Two Philosophies of Network Communication

The choice between connectionless and connection-oriented communication isn't merely a low-level protocol detail—it's an architectural decision that ripples through every layer of your application. How you handle connections determines your scaling patterns, failure modes, state management strategies, and even your deployment architecture.

UDP treats each datagram as an independent unit, like individual letters in the mail—each complete in itself, with no memory of what came before or expectation of what comes next. TCP establishes a virtual circuit between endpoints, like a phone call—a continuous relationship that must be opened, maintained, and eventually closed.

These fundamentally different philosophies create vastly different engineering challenges and opportunities.

What You Will Master

By the end of this page, you will understand how connectionless and connection-oriented paradigms affect application architecture, how each approach handles failures, the scaling implications of connection state, and how to choose the right model for different system designs.

The UDP Connectionless Model

UDP provides datagram service—each UDP packet (datagram) is self-contained and independent. There is no concept of 'connection' at the protocol level.

What 'Connectionless' Really Means

UDP Connectionless Characteristics

•No handshake required — You can send a datagram to any IP:port combination immediately. No permission, no negotiation, no setup delay.
•No maintained state — UDP endpoints don't track conversations. Each incoming datagram is processed independently of all others.
•No teardown needed — When you're done sending, just stop. There's nothing to close, no goodbye to send, no resources to release.
•Sender doesn't know if receiver exists — You can send datagrams to IP addresses where nothing is listening. UDP will happily dispatch them into the void.
•Each datagram carries full addressing — Source/destination ports in every packet. The receiver knows where each datagram came from.
•Datagrams can go to different destinations — A single UDP socket can send to and receive from multiple remote endpoints simultaneously.

UDP Communication Model
UDP Datagram Independence:
═══════════════════════════════════════════════════════════════════════════════
 
Sender                                                    Receivers
┌─────────────────────┐
│   UDP Socket        │
│   Port: 5000        │
│                     │
│ send(datagram_1,    │ ──────────────────────────────▶  Host A:53 (DNS)
│      host_A:53)     │
│                     │
│ send(datagram_2,    │ ──────────────────────────────▶  Host B:123 (NTP)
│      host_B:123)    │
│                     │
│ send(datagram_3,    │ ──────────────────────────────▶  Host C:5001 (App)
│      host_C:5001)   │
│                     │
│ send(datagram_4,    │ ──────────────────────────────▶  Host A:53 (DNS)
│      host_A:53)     │
└─────────────────────┘
 
Key Observations:
• ONE socket sends to THREE different hosts
• No concept of "connections" to any of them
• Each datagram independently addressed
• Order of operations is completely arbitrary
• Could receive responses from any/all/none
 
This model is Fundamentally Different from TCP's 1:1 connection binding.

The Programming Model

UDP's connectionless nature creates a simple programming interface:

UDP Socket Programming (Conceptual)
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
import socket
 
# Create UDP socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
 
# Optionally bind to local address (required for servers)
sock.bind(('0.0.0.0', 5000))
 
# Send to ANY host without prior connection
sock.sendto(b'Query 1', ('dns-server.example.com', 53))
sock.sendto(b'Query 2', ('ntp-server.example.com', 123))
sock.sendto(b'Query 3', ('my-app-server.example.com', 8080))
 
# Receive from ANY host - returns data AND sender address
while True:
    data, sender_address = sock.recvfrom(65535)
    print(f"Received {len(data)} bytes from {sender_address}")
    
    # Process based on who sent it
    # No "connection" object - just raw (data, address) pairs
 
# Note: The "connect()" call on UDP sockets is a local filter only
# It doesn't send any packets or establish any protocol-level connection
connected_sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
connected_sock.connect(('specific-host.com', 9000))
# Now send() and recv() imply that specific destination
# But it's purely local convenience - no handshake occurred

UDP connect() Is Not a Connection

Using connect() on a UDP socket doesn't create a network connection or send any packets. It merely tells the local kernel to filter incoming datagrams to only those from the specified address and allows using send()/recv() instead of sendto()/recvfrom(). It's a local convenience, not a protocol-level operation.

The TCP Connection-Oriented Model

TCP provides a virtual circuit—a bidirectional communication channel established between two specific endpoints. This connection has a lifecycle: establishment, data transfer, and termination.

What 'Connection-Oriented' Really Means

TCP Connection Characteristics

•Explicit establishment — Three-way handshake (SYN → SYN-ACK → ACK) before any application data can flow. Both sides must agree to communicate.
•State maintained throughout — Both endpoints track sequence numbers, acknowledgments, windows, timers, and buffers for the duration.
•Explicit termination — Four-way handshake (FIN → ACK → FIN → ACK) to gracefully close. Resources remain allocated until termination completes.
•Sender knows receiver exists — Successful handshake proves the receiver is present and willing to accept data.
•Each socket bound to one connection — A connected TCP socket cannot communicate with any other endpoint. It's a dedicated pipe.
•Full-duplex operation — Data flows independently in both directions on the same connection, using separate sequence number spaces.

TCP Connection Lifecycle
TCP Connection States and Transitions:
═══════════════════════════════════════════════════════════════════════════════
 
                           ┌─────────────────┐
                           │     CLOSED      │
                           └────────┬────────┘
                                    │
           ┌────────────────────────┼────────────────────────┐
           │                        │                        │
           ▼                        │                        ▼
   ┌───────────────┐               │               ┌───────────────┐
   │    LISTEN     │◀──────────────┘               │   SYN_SENT    │
   │   (Server)    │                               │   (Client)    │
   └───────┬───────┘                               └───────┬───────┘
           │ recv SYN                                      │
           │ send SYN+ACK                                  │
           ▼                                               │
   ┌───────────────┐                                      │
   │  SYN_RECEIVED │                                      │
   └───────┬───────┘                                      │
           │ recv ACK                    recv SYN+ACK     │
           │                             send ACK         │
           ▼                                               │
   ┌───────────────────────────────────────────────────────┘
   │
   ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                              ESTABLISHED                                     │
│                                                                              │
│  • Full duplex data transfer                                                │
│  • Both sides can send and receive simultaneously                           │
│  • Connection persists until explicitly terminated                          │
│  • State: SEQ numbers, ACK numbers, windows, timers all active             │
└──────────────────────────────────┬──────────────────────────────────────────┘
                                   │
                                   │ Close initiated
                                   ▼
        ┌──────────────────────────────────────────────────────────┐
        │                  CLOSE SEQUENCE                          │
        │                                                          │
        │  FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED           │
        │  (active closer)                                         │
        │                                                          │
        │  CLOSE_WAIT → LAST_ACK → CLOSED                         │
        │  (passive closer)                                        │
        └──────────────────────────────────────────────────────────┘
 
Time in TIME_WAIT: 2 × MSL (Maximum Segment Lifetime) ≈ 60-120 seconds

The Programming Model

TCP's connection-oriented nature creates a different programming paradigm:

TCP Socket Programming (Conceptual)
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
import socket
 
# ═══════════════════════════════════════════════════════════════
# SERVER SIDE
# ═══════════════════════════════════════════════════════════════
 
# Create TCP socket
server_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 
# Bind to local address
server_sock.bind(('0.0.0.0', 8080))
 
# Enter LISTEN state - prepare to accept connections
server_sock.listen(128)  # backlog queue size
 
while True:
    # BLOCKING: Wait for client connection (three-way handshake)
    # Returns a NEW socket specifically for this connection
    client_sock, client_address = server_sock.accept()
    
    # client_sock is BOUND to this specific client
    # Cannot communicate with any other host through this socket
    
    # Stream-oriented: data is a continuous byte stream
    data = client_sock.recv(4096)  # No address returned - we know who it's from
    client_sock.send(b'Response')
    
    # Must explicitly close when done
    client_sock.close()  # Initiates FIN handshake
 
# ═══════════════════════════════════════════════════════════════
# CLIENT SIDE
# ═══════════════════════════════════════════════════════════════
 
# Create TCP socket
client_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 
# Connect to specific server (three-way handshake happens here)
# This BLOCKS until connection established or fails
client_sock.connect(('server.example.com', 8080))  # SYN → SYN-ACK → ACK
 
# Now bound to this specific connection
# Cannot use this socket to talk to anyone else
client_sock.send(b'Request')
response = client_sock.recv(4096)
 
# Must close when done
client_sock.close()  # FIN → ACK → FIN → ACK

One Connection, One Socket in TCP

In TCP, the listening socket and connected sockets are separate. accept() creates NEW sockets for each connection. This is fundamentally different from UDP where one socket handles all communications. A server with 10,000 clients needs 10,001 TCP sockets (1 listener + 10,000 connections).

Architectural Implications

The connection model fundamentally shapes how you design systems. Let's explore the architectural consequences.

Server Architecture Patterns

UDP Server Patterns

•Single socket handles all clients
•No per-client kernel resources
•Event loop reads datagrams, dispatches by address
•Application maintains any needed session state
•Stateless protocols fit naturally
•Scales to millions of 'clients' trivially

TCP Server Patterns

•One socket per active connection
•Kernel allocates per-connection state
•Thread-per-connection, or async I/O required
•Connection objects represent sessions
•Stateful protocols fit naturally
•OS limits may cap concurrent connections

Server Architecture Comparison
UDP Server Architecture:
═══════════════════════════════════════════════════════════════════════════════
 
                     ┌────────────────────────────────┐
                     │        Application Logic       │
                     │   (routes datagrams by sender) │
                     └───────────────┬────────────────┘
                                     │
                     ┌───────────────▼────────────────┐
                     │      Single UDP Socket          │
                     │      Bound to Port 5000         │
                     └───────────────┬────────────────┘
                                     │
         ┌───────────────────────────┼───────────────────────────┐
         │                           │                           │
    Client A:40001             Client B:40002             Client C:40003
    
Resources: 1 socket, 1 port, O(1) kernel state
 
 
TCP Server Architecture:
═══════════════════════════════════════════════════════════════════════════════
 
                     ┌────────────────────────────────┐
                     │        Application Logic       │
                     │  (one handler per connection)  │
                     └───────────────┬────────────────┘
                                     │
         ┌───────────────────────────┼───────────────────────────┐
         │                           │                           │
┌────────▼────────┐       ┌──────────▼────────┐       ┌──────────▼────────┐
│ Connected Socket│       │ Connected Socket  │       │ Connected Socket  │
│ Client A:40001  │       │ Client B:40002    │       │ Client C:40003    │
│ (full TCB state)│       │ (full TCB state)  │       │ (full TCB state)  │
└─────────────────┘       └───────────────────┘       └───────────────────┘
         │                           │                           │
         └───────────────────────────┼───────────────────────────┘
                                     │
                     ┌───────────────▼────────────────┐
                     │      Listening Socket           │
                     │      Bound to Port 8080         │
                     └────────────────────────────────┘
 
Resources: N+1 sockets, 1 port, O(N) kernel state

Architecture Comparison by Use Case
Aspect	UDP Approach	TCP Approach
Client identification	Extract from datagram source address	Implicit - socket IS the client
Session state	Application-managed (if needed)	Connection IS the session
Timeouts	Application timers for 'sessions'	Kernel-managed keepalive timers
Resource cleanup	Application garbage collection	Kernel handles on connection close
Security context	Must re-authenticate per datagram (or persist)	Established once at connection setup
Load balancing	Any datagram can go to any server	Connection affinity required

Session State vs Connection State

Don't confuse TCP connection state (kernel-managed, for reliability) with application session state (user identity, shopping cart, etc.). UDP applications often need session state but not connection state. TCP applications get connection state for free but still need to manage session state.

Scalability Implications

Connection handling directly impacts scalability. The numbers at scale reveal stark differences.

The Connection Scaling Problem

Resource Consumption at Scale
Concurrent Clients	UDP Resources	TCP Resources	TCP/UDP Ratio
100	1 socket, ~1 MB	101 sockets, ~6 MB	6×
1,000	1 socket, ~1 MB	1,001 sockets, ~64 MB	64×
10,000	1 socket, ~1 MB	10,001 sockets, ~640 MB	640×
100,000	1 socket, ~1 MB	100,001 sockets, ~6.4 GB	6,400×
1,000,000	1 socket, ~1 MB	1,000,001 sockets, ~64 GB	64,000×

TCP Scalability Limits

TCP faces several scaling challenges that UDP avoids:

TCP Scaling Bottlenecks

•File descriptor limits — Each socket is a file descriptor. Default limits (1024 on many systems) must be raised. Hard limits at kernel build time may exist.
•Port exhaustion — Client-side connections consume ephemeral ports. ~30,000 ports per destination IP before exhaustion (mitigated by SO_REUSEADDR/SO_REUSEPORT).
•Memory pressure — Per-connection buffers consume RAM. 64KB × 1,000,000 connections = 64 GB just for receive buffers.
•Connection table overhead — Kernel hash tables for connection lookup grow with connections. O(1) lookup but O(n) memory.
•TIME_WAIT accumulation — Closed connections remain in TIME_WAIT for 60+ seconds. High connection churn can exhaust resources.
•Accept queue limits — SYN flood or burst traffic can overflow the accept queue, causing connection failures.

TIME_WAIT Accumulation Problem
TIME_WAIT State Accumulation:
═══════════════════════════════════════════════════════════════════════════════
 
Scenario: Web server handling 1,000 requests/second, each connection closes after response
 
TIME_WAIT duration: 60 seconds (2 × MSL)
Rate of new connections: 1,000/second
Rate of connections entering TIME_WAIT: 1,000/second
 
Steady-state TIME_WAIT sockets: 1,000 × 60 = 60,000 sockets
 
Each TIME_WAIT socket consumes:
  • File descriptor (until closed)
  • ~180 bytes of kernel memory
  • Entry in connection hash table
 
At steady state: 60,000 × 180 bytes = ~10.8 MB (memory alone)
                 60,000 file descriptors consumed
 
If connection rate increases to 10,000/second:
  • 600,000 TIME_WAIT sockets
  • ~108 MB memory
  • May exceed file descriptor limits
 
Solutions:
  1. TCP_REUSE (allows reusing TIME_WAIT ports)
  2. TCP_FIN_TIMEOUT reduction (Linux-specific)
  3. Connection pooling (fewer connections, longer-lived)
  4. Use UDP where appropriate
 
UDP: No TIME_WAIT (no connections). 10,000 requests/second uses 1 socket.

When UDP Scaling Shines

UDP's connectionless model excels in specific high-scale scenarios:

UDP Scaling Advantages

•DNS servers — Handle millions of queries/second from millions of unique clients. UDP + single socket = massive scale.
•Game servers — Track thousands of player positions per second. Connection overhead would be crippling.
•IoT gateways — Receive telemetry from hundreds of thousands of sensors. Per-device TCP connections impossible.
•Logging/metrics collection — Ingest events from entire data centers. UDP + structured logs = simple scaling.
•Broadcast/multicast — One packet from one socket reaches millions of receivers. Impossible with TCP.

Modern TCP Scaling Techniques

Linux and other modern operating systems have extensive TCP scaling optimizations: SO_REUSEPORT for multi-socket load balancing, TCP_FASTOPEN for reduced handshake latency, kernel bypass (DPDK, XDP) for extreme performance, and epoll/kqueue for efficient I/O multiplexing. These mitigate but don't eliminate TCP's fundamental per-connection overhead.

Failure Handling and Recovery

Connection models dramatically affect how failures are detected, reported, and recovered from.

UDP Failure Characteristics

UDP Failure Behavior

•Silent failure by default — Lost datagrams disappear without notification. The sender never knows unless the application implements acknowledgments.
•No remote peer detection — UDP cannot tell if the remote peer is alive, dead, or never existed. Datagrams sent to unreachable hosts simply vanish.
•ICMP may provide hints — 'Port unreachable' ICMP messages may arrive if nothing is listening. But ICMP is often filtered by firewalls.
•Fast failure at send time — If the local network is down, sendto() may fail immediately. But this only detects local problems.
•Application-layer timeouts required — Any meaningful failure detection requires application timers watching for expected responses.
•Instant recovery possible — No connection state means nothing to re-establish. Just start sending to a new endpoint if the old one failed.

TCP Failure Characteristics

TCP Failure Behavior

•Guaranteed failure notification — If data cannot be delivered after retry attempts, TCP will eventually report an error to the application.
•Connection reset (RST) — Remote peer can forcibly terminate a connection. Application receives immediate error on next send/receive.
•Keepalive detection — Optional keepalive probes can detect dead connections even without data flow (though default timeout is often hours).
•Retransmission exhaustion — After ~13-30 retransmissions (implementation-dependent), TCP gives up and reports connection failure.
•Slow failure detection — Retransmission timeouts back off exponentially. Detecting a dead peer can take minutes.
•Connection re-establishment required — After failure, the connection is gone. A completely new handshake is required to communicate again.

TCP Failure Detection Timeline
TCP Connection Failure Detection:
═══════════════════════════════════════════════════════════════════════════════
 
Scenario: Network cable unplugged during active data transfer
 
T=0s      Data sent, waiting for ACK
T=1s      RTO expires, retransmit #1 (RTO = ~1s initially)
T=3s      RTO expires, retransmit #2 (RTO doubled to ~2s)
T=7s      RTO expires, retransmit #3 (RTO = ~4s)
T=15s     RTO expires, retransmit #4 (RTO = ~8s)
T=31s     RTO expires, retransmit #5 (RTO = ~16s)
T=63s     RTO expires, retransmit #6 (RTO = ~32s)
T=127s    RTO expires, retransmit #7 (RTO = ~64s)
...
T=~10-15 minutes: TCP gives up, ETIMEDOUT returned to application
 
During this entire time:
  • Application send() calls may succeed (buffered)
  • Application recv() calls block or return nothing
  • Application has no idea connection is dead
  • Resources remain allocated
 
Compare to UDP:
  • Application request timeout: ~1-5 seconds
  • Application decides failure handling policy
  • Switch to backup server immediately
  • Resources freed as soon as application decides

Failure Recovery Comparison
Failure Type	UDP Behavior	TCP Behavior
Remote peer crashes	No detection (silent)	Eventually detects (~minutes)
Network partition	No detection (silent)	Eventually detects (~minutes)
Remote peer restarts	Seamless (no state)	RST on first packet; reconnect needed
Port closed remotely	ICMP may arrive	RST received immediately
Firewall blocks traffic	No detection	Timeout after retransmissions
Routing changes	Transparent	Transparent (connection survives)

TCP's Slow Failure Detection

TCP's retry behavior, while reliable, can hide failures for minutes. Production systems often implement application-layer health checks (heartbeats) with shorter timeouts to detect failures faster than TCP's built-in mechanisms. This is essentially reimplementing UDP's 'no assumption' model on top of TCP.

NAT and Firewall Traversal

Network Address Translation (NAT) and firewalls treat UDP and TCP connections very differently, with significant implications for application design.

How NAT Tracks Connections

NAT Connection Tracking
NAT Connection Table:
═══════════════════════════════════════════════════════════════════════════════
 
TCP Entry (Long-lived, state-tracked):
┌─────────────────────────────────────────────────────────────────────────────┐
│ Internal: 192.168.1.100:45678 → External: 1.2.3.4:80                       │
│ Mapped to: 203.0.113.50:23456 → 1.2.3.4:80                                 │
│ State: ESTABLISHED                                                          │
│ Timeout: 7200 seconds (2 hours) since last activity                        │
│ Created: When SYN observed                                                  │
│ Destroyed: When FIN-ACK exchange complete OR timeout                       │
└─────────────────────────────────────────────────────────────────────────────┘
 
UDP Entry (Connectionless, timeout-based):
┌─────────────────────────────────────────────────────────────────────────────┐
│ Internal: 192.168.1.100:45679 → External: 8.8.8.8:53                       │
│ Mapped to: 203.0.113.50:23457 → 8.8.8.8:53                                 │
│ State: None (UDP is stateless)                                             │
│ Timeout: 30-180 seconds (implementation-dependent)                         │
│ Created: When first outbound packet observed                               │
│ Destroyed: Timeout expiration (no explicit close)                          │
└─────────────────────────────────────────────────────────────────────────────┘
 
Key Difference: TCP mappings survive long inactivity (connection exists)
                UDP mappings expire quickly (no connection state to persist)

UDP NAT Challenges

UDP NAT Traversal Issues

•Short timeouts — UDP NAT mappings typically expire in 30-180 seconds. Long-inactive 'connections' require keepalive pings.
•Mapping unpredictability — Different NAT types (Full Cone, Restricted Cone, Symmetric) create mappings differently. P2P applications must probe to discover behavior.
•No inbound connection initiation — NAT mapping must be created by outbound traffic first. Servers behind NAT cannot receive unsolicited UDP.
•Keepalive overhead — To maintain NAT mappings, UDP applications must send periodic traffic even when idle. Every 20-30 seconds is common.
•Hole punching complexity — P2P UDP connections require sophisticated STUN/TURN/ICE procedures to traverse NAT. Failure rate is significant.

TCP NAT Advantages

TCP NAT Traversal Advantages

•Long timeouts — ESTABLISHED TCP connections often have 2+ hour NAT timeouts. Reasonable for active sessions.
•State visibility — NAT can track connection state (SYN, ESTABLISHED, FIN). Mappings cleaned up properly on connection close.
•Keepalive support — TCP keepalive probes (if enabled) automatically maintain NAT mappings. No application changes needed.
•Predictable behavior — TCP connection semantics are universal. NAT implementations handle TCP consistently.
•Firewall friendliness — Stateful firewalls understand TCP. Established connections receive return traffic automatically.

NAT Timeout Comparison (Typical Values)
Protocol/State	Typical NAT Timeout	Notes
TCP ESTABLISHED	7200 seconds (2 hours)	Long-lived; may be shorter on busy NATs
TCP SYN_SENT	120 seconds	Connection attempt pending
TCP FIN_WAIT	120 seconds	Closing, waiting for final ACKs
TCP TIME_WAIT	240 seconds	Matches 2×MSL
UDP Stream	30-180 seconds	Varies widely by implementation
UDP Single	30-60 seconds	Some NATs: 'expected reply' window

Modern Solution: QUIC

QUIC (the protocol underlying HTTP/3) builds connection semantics on UDP, inheriting UDP's flexibility while implementing its own connection state. QUIC includes connection migration, allowing connections to survive NAT rebinding and IP address changes—a capability impossible with TCP.

Load Balancing Implications

How connections are handled fundamentally shapes load balancing strategies and possibilities.

UDP Load Balancing

UDP Load Balancing Characteristics

•Per-datagram distribution — Each datagram can be independently routed to any server. True horizontal scaling.
•No affinity requirement (for stateless) — If the application is stateless, any datagram can go to any server. Simple round-robin works.
•Source-hash affinity (for stateful) — Hash of source IP/port can ensure all datagrams from one client go to same server.
•Easy server addition/removal — Add servers to the pool; new datagrams may route to them. No connection state to migrate.
•Direct Server Return (DSR) — Responses can go directly to client, bypassing the load balancer. Reduces balancer bottleneck.
•Multicast capability — One datagram can be distributed to ALL servers simultaneously if needed.

TCP Load Balancing

TCP Load Balancing Characteristics

•Connection-level distribution — Decision made once at connection establishment. All packets for that connection go to same server.
•Mandatory connection affinity — TCP state (sequence numbers, windows) exists only on the chosen server. Must route all packets there.
•L4 vs L7 trade-offs — L4 balancers route by 4-tuple (fast, stateless). L7 balancers terminate TCP, make application-aware decisions (slower, stateful).
•Server removal requires draining — Can't remove server with active connections without breaking them. Gradual drain required.
•Connection state synchronization — Active-active HA requires sharing TCP state between balancers. Complex and expensive.
•No DSR for new connections — Handshake responses must traverse the balancer. Only established traffic can sometimes bypass.

Load Balancing Architecture Comparison
UDP Load Balancing (Per-Datagram):
═══════════════════════════════════════════════════════════════════════════════
 
Client A ─┐                                  ┌→ Server 1 (handles datagram 1, 4, 7...)
Client B ─┼─→ Load Balancer ─→ distribute ─┼→ Server 2 (handles datagram 2, 5, 8...)
Client C ─┘                                  └→ Server 3 (handles datagram 3, 6, 9...)
 
• Each datagram independently routed
• Server failure: next datagram goes elsewhere (automatic failover)
• Add server: immediately receives ~1/(n+1) traffic
• Remove server: no drain needed (no persistent state)
 
 
TCP Load Balancing (Per-Connection):
═══════════════════════════════════════════════════════════════════════════════
 
Client A ═══════════════════════════════════════════════════════→ Server 1
                                    ▲
Client B ════╗                      │                           → Server 2  
             ║                      │ (all packets for this
             ╠═══→ Load Balancer ═══╝  connection must go
             ║                         to the same server)
Client C ════╝═══════════════════════════════════════════════════→ Server 3
 
• Connection routed at setup, locked for duration
• Server failure: connection breaks, client must reconnect
• Add server: only new connections benefit
• Remove server: must drain existing connections (potentially hours)

Consistent Hashing for Stateful UDP

When UDP applications have session state (like game servers), consistent hashing ensures clients reach the same server while minimizing redistribution when servers are added/removed. This provides connection-like affinity without connection overhead.

Summary: Connection Handling

We've explored how connectionless versus connection-oriented paradigms shape every aspect of system design. Here are the key insights:

Key Takeaways

•UDP is datagram-oriented, TCP is connection-oriented — UDP treats each packet as independent; TCP maintains a continuous byte stream over an established connection.
•Architecture mirrors the model — UDP servers use single sockets handling all clients; TCP servers maintain per-client sockets with kernel state.
•Scaling characteristics differ dramatically — UDP scales to millions of 'clients' with constant resources; TCP scales linearly with O(n) resources per connection.
•Failure detection is inverted — UDP requires application-layer timeouts but fails fast; TCP detects failure automatically but may take minutes.
•NAT treats them differently — TCP connections survive long periods; UDP mappings expire quickly, requiring keepalives.
•Load balancing flexibility varies — UDP enables per-datagram routing; TCP requires connection affinity throughout the connection lifetime.
•Neither model is universally better — The right choice depends on your application's requirements for state, reliability, latency, and scale.

What's Next:

Now we'll examine ordering guarantees—how UDP's lack of ordering and TCP's strict ordering affect applications, and when each approach is appropriate.

Connection Handling Mastered

You now understand the architectural implications of connectionless versus connection-oriented communication. You can design systems that leverage each model's strengths and mitigate their weaknesses. This architectural awareness is essential for building scalable, resilient networked systems.

Connection Handling — Architectural Implications

Two Philosophies of Network Communication

These fundamentally different philosophies create vastly different engineering challenges and opportunities.

What You Will Master

The UDP Connectionless Model

UDP provides datagram service—each UDP packet (datagram) is self-contained and independent. There is no concept of 'connection' at the protocol level.

What 'Connectionless' Really Means

UDP Connectionless Characteristics

•No handshake required — You can send a datagram to any IP:port combination immediately. No permission, no negotiation, no setup delay.
•No maintained state — UDP endpoints don't track conversations. Each incoming datagram is processed independently of all others.
•No teardown needed — When you're done sending, just stop. There's nothing to close, no goodbye to send, no resources to release.
•Sender doesn't know if receiver exists — You can send datagrams to IP addresses where nothing is listening. UDP will happily dispatch them into the void.
•Each datagram carries full addressing — Source/destination ports in every packet. The receiver knows where each datagram came from.
•Datagrams can go to different destinations — A single UDP socket can send to and receive from multiple remote endpoints simultaneously.

UDP Communication Model
UDP Datagram Independence:
═══════════════════════════════════════════════════════════════════════════════
 
Sender                                                    Receivers
┌─────────────────────┐
│   UDP Socket        │
│   Port: 5000        │
│                     │
│ send(datagram_1,    │ ──────────────────────────────▶  Host A:53 (DNS)
│      host_A:53)     │
│                     │
│ send(datagram_2,    │ ──────────────────────────────▶  Host B:123 (NTP)
│      host_B:123)    │
│                     │
│ send(datagram_3,    │ ──────────────────────────────▶  Host C:5001 (App)
│      host_C:5001)   │
│                     │
│ send(datagram_4,    │ ──────────────────────────────▶  Host A:53 (DNS)
│      host_A:53)     │
└─────────────────────┘
 
Key Observations:
• ONE socket sends to THREE different hosts
• No concept of "connections" to any of them
• Each datagram independently addressed
• Order of operations is completely arbitrary
• Could receive responses from any/all/none
 
This model is Fundamentally Different from TCP's 1:1 connection binding.

The Programming Model

UDP's connectionless nature creates a simple programming interface:

UDP Socket Programming (Conceptual)
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
import socket
 
# Create UDP socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
 
# Optionally bind to local address (required for servers)
sock.bind(('0.0.0.0', 5000))
 
# Send to ANY host without prior connection
sock.sendto(b'Query 1', ('dns-server.example.com', 53))
sock.sendto(b'Query 2', ('ntp-server.example.com', 123))
sock.sendto(b'Query 3', ('my-app-server.example.com', 8080))
 
# Receive from ANY host - returns data AND sender address
while True:
    data, sender_address = sock.recvfrom(65535)
    print(f"Received {len(data)} bytes from {sender_address}")
    
    # Process based on who sent it
    # No "connection" object - just raw (data, address) pairs
 
# Note: The "connect()" call on UDP sockets is a local filter only
# It doesn't send any packets or establish any protocol-level connection
connected_sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
connected_sock.connect(('specific-host.com', 9000))
# Now send() and recv() imply that specific destination
# But it's purely local convenience - no handshake occurred

UDP connect() Is Not a Connection

The TCP Connection-Oriented Model

TCP provides a virtual circuit—a bidirectional communication channel established between two specific endpoints. This connection has a lifecycle: establishment, data transfer, and termination.

What 'Connection-Oriented' Really Means

TCP Connection Characteristics

•Explicit establishment — Three-way handshake (SYN → SYN-ACK → ACK) before any application data can flow. Both sides must agree to communicate.
•State maintained throughout — Both endpoints track sequence numbers, acknowledgments, windows, timers, and buffers for the duration.
•Explicit termination — Four-way handshake (FIN → ACK → FIN → ACK) to gracefully close. Resources remain allocated until termination completes.
•Sender knows receiver exists — Successful handshake proves the receiver is present and willing to accept data.
•Each socket bound to one connection — A connected TCP socket cannot communicate with any other endpoint. It's a dedicated pipe.
•Full-duplex operation — Data flows independently in both directions on the same connection, using separate sequence number spaces.

TCP Connection Lifecycle
TCP Connection States and Transitions:
═══════════════════════════════════════════════════════════════════════════════
 
                           ┌─────────────────┐
                           │     CLOSED      │
                           └────────┬────────┘
                                    │
           ┌────────────────────────┼────────────────────────┐
           │                        │                        │
           ▼                        │                        ▼
   ┌───────────────┐               │               ┌───────────────┐
   │    LISTEN     │◀──────────────┘               │   SYN_SENT    │
   │   (Server)    │                               │   (Client)    │
   └───────┬───────┘                               └───────┬───────┘
           │ recv SYN                                      │
           │ send SYN+ACK                                  │
           ▼                                               │
   ┌───────────────┐                                      │
   │  SYN_RECEIVED │                                      │
   └───────┬───────┘                                      │
           │ recv ACK                    recv SYN+ACK     │
           │                             send ACK         │
           ▼                                               │
   ┌───────────────────────────────────────────────────────┘
   │
   ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                              ESTABLISHED                                     │
│                                                                              │
│  • Full duplex data transfer                                                │
│  • Both sides can send and receive simultaneously                           │
│  • Connection persists until explicitly terminated                          │
│  • State: SEQ numbers, ACK numbers, windows, timers all active             │
└──────────────────────────────────┬──────────────────────────────────────────┘
                                   │
                                   │ Close initiated
                                   ▼
        ┌──────────────────────────────────────────────────────────┐
        │                  CLOSE SEQUENCE                          │
        │                                                          │
        │  FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED           │
        │  (active closer)                                         │
        │                                                          │
        │  CLOSE_WAIT → LAST_ACK → CLOSED                         │
        │  (passive closer)                                        │
        └──────────────────────────────────────────────────────────┘
 
Time in TIME_WAIT: 2 × MSL (Maximum Segment Lifetime) ≈ 60-120 seconds

The Programming Model

TCP's connection-oriented nature creates a different programming paradigm:

TCP Socket Programming (Conceptual)
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
import socket
 
# ═══════════════════════════════════════════════════════════════
# SERVER SIDE
# ═══════════════════════════════════════════════════════════════
 
# Create TCP socket
server_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 
# Bind to local address
server_sock.bind(('0.0.0.0', 8080))
 
# Enter LISTEN state - prepare to accept connections
server_sock.listen(128)  # backlog queue size
 
while True:
    # BLOCKING: Wait for client connection (three-way handshake)
    # Returns a NEW socket specifically for this connection
    client_sock, client_address = server_sock.accept()
    
    # client_sock is BOUND to this specific client
    # Cannot communicate with any other host through this socket
    
    # Stream-oriented: data is a continuous byte stream
    data = client_sock.recv(4096)  # No address returned - we know who it's from
    client_sock.send(b'Response')
    
    # Must explicitly close when done
    client_sock.close()  # Initiates FIN handshake
 
# ═══════════════════════════════════════════════════════════════
# CLIENT SIDE
# ═══════════════════════════════════════════════════════════════
 
# Create TCP socket
client_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 
# Connect to specific server (three-way handshake happens here)
# This BLOCKS until connection established or fails
client_sock.connect(('server.example.com', 8080))  # SYN → SYN-ACK → ACK
 
# Now bound to this specific connection
# Cannot use this socket to talk to anyone else
client_sock.send(b'Request')
response = client_sock.recv(4096)
 
# Must close when done
client_sock.close()  # FIN → ACK → FIN → ACK

One Connection, One Socket in TCP

Architectural Implications

The connection model fundamentally shapes how you design systems. Let's explore the architectural consequences.

Server Architecture Patterns

UDP Server Patterns

•Single socket handles all clients
•No per-client kernel resources
•Event loop reads datagrams, dispatches by address
•Application maintains any needed session state
•Stateless protocols fit naturally
•Scales to millions of 'clients' trivially

TCP Server Patterns

•One socket per active connection
•Kernel allocates per-connection state
•Thread-per-connection, or async I/O required
•Connection objects represent sessions
•Stateful protocols fit naturally
•OS limits may cap concurrent connections

Server Architecture Comparison
UDP Server Architecture:
═══════════════════════════════════════════════════════════════════════════════
 
                     ┌────────────────────────────────┐
                     │        Application Logic       │
                     │   (routes datagrams by sender) │
                     └───────────────┬────────────────┘
                                     │
                     ┌───────────────▼────────────────┐
                     │      Single UDP Socket          │
                     │      Bound to Port 5000         │
                     └───────────────┬────────────────┘
                                     │
         ┌───────────────────────────┼───────────────────────────┐
         │                           │                           │
    Client A:40001             Client B:40002             Client C:40003
    
Resources: 1 socket, 1 port, O(1) kernel state
 
 
TCP Server Architecture:
═══════════════════════════════════════════════════════════════════════════════
 
                     ┌────────────────────────────────┐
                     │        Application Logic       │
                     │  (one handler per connection)  │
                     └───────────────┬────────────────┘
                                     │
         ┌───────────────────────────┼───────────────────────────┐
         │                           │                           │
┌────────▼────────┐       ┌──────────▼────────┐       ┌──────────▼────────┐
│ Connected Socket│       │ Connected Socket  │       │ Connected Socket  │
│ Client A:40001  │       │ Client B:40002    │       │ Client C:40003    │
│ (full TCB state)│       │ (full TCB state)  │       │ (full TCB state)  │
└─────────────────┘       └───────────────────┘       └───────────────────┘
         │                           │                           │
         └───────────────────────────┼───────────────────────────┘
                                     │
                     ┌───────────────▼────────────────┐
                     │      Listening Socket           │
                     │      Bound to Port 8080         │
                     └────────────────────────────────┘
 
Resources: N+1 sockets, 1 port, O(N) kernel state

Architecture Comparison by Use Case
Aspect	UDP Approach	TCP Approach
Client identification	Extract from datagram source address	Implicit - socket IS the client
Session state	Application-managed (if needed)	Connection IS the session
Timeouts	Application timers for 'sessions'	Kernel-managed keepalive timers
Resource cleanup	Application garbage collection	Kernel handles on connection close
Security context	Must re-authenticate per datagram (or persist)	Established once at connection setup
Load balancing	Any datagram can go to any server	Connection affinity required

Session State vs Connection State

Scalability Implications

Connection handling directly impacts scalability. The numbers at scale reveal stark differences.

The Connection Scaling Problem

Resource Consumption at Scale
Concurrent Clients	UDP Resources	TCP Resources	TCP/UDP Ratio
100	1 socket, ~1 MB	101 sockets, ~6 MB	6×
1,000	1 socket, ~1 MB	1,001 sockets, ~64 MB	64×
10,000	1 socket, ~1 MB	10,001 sockets, ~640 MB	640×
100,000	1 socket, ~1 MB	100,001 sockets, ~6.4 GB	6,400×
1,000,000	1 socket, ~1 MB	1,000,001 sockets, ~64 GB	64,000×

TCP Scalability Limits

TCP faces several scaling challenges that UDP avoids:

TCP Scaling Bottlenecks

•File descriptor limits — Each socket is a file descriptor. Default limits (1024 on many systems) must be raised. Hard limits at kernel build time may exist.
•Port exhaustion — Client-side connections consume ephemeral ports. ~30,000 ports per destination IP before exhaustion (mitigated by SO_REUSEADDR/SO_REUSEPORT).
•Memory pressure — Per-connection buffers consume RAM. 64KB × 1,000,000 connections = 64 GB just for receive buffers.
•Connection table overhead — Kernel hash tables for connection lookup grow with connections. O(1) lookup but O(n) memory.
•TIME_WAIT accumulation — Closed connections remain in TIME_WAIT for 60+ seconds. High connection churn can exhaust resources.
•Accept queue limits — SYN flood or burst traffic can overflow the accept queue, causing connection failures.

TIME_WAIT Accumulation Problem
TIME_WAIT State Accumulation:
═══════════════════════════════════════════════════════════════════════════════
 
Scenario: Web server handling 1,000 requests/second, each connection closes after response
 
TIME_WAIT duration: 60 seconds (2 × MSL)
Rate of new connections: 1,000/second
Rate of connections entering TIME_WAIT: 1,000/second
 
Steady-state TIME_WAIT sockets: 1,000 × 60 = 60,000 sockets
 
Each TIME_WAIT socket consumes:
  • File descriptor (until closed)
  • ~180 bytes of kernel memory
  • Entry in connection hash table
 
At steady state: 60,000 × 180 bytes = ~10.8 MB (memory alone)
                 60,000 file descriptors consumed
 
If connection rate increases to 10,000/second:
  • 600,000 TIME_WAIT sockets
  • ~108 MB memory
  • May exceed file descriptor limits
 
Solutions:
  1. TCP_REUSE (allows reusing TIME_WAIT ports)
  2. TCP_FIN_TIMEOUT reduction (Linux-specific)
  3. Connection pooling (fewer connections, longer-lived)
  4. Use UDP where appropriate
 
UDP: No TIME_WAIT (no connections). 10,000 requests/second uses 1 socket.

When UDP Scaling Shines

UDP's connectionless model excels in specific high-scale scenarios:

UDP Scaling Advantages

•DNS servers — Handle millions of queries/second from millions of unique clients. UDP + single socket = massive scale.
•Game servers — Track thousands of player positions per second. Connection overhead would be crippling.
•IoT gateways — Receive telemetry from hundreds of thousands of sensors. Per-device TCP connections impossible.
•Logging/metrics collection — Ingest events from entire data centers. UDP + structured logs = simple scaling.
•Broadcast/multicast — One packet from one socket reaches millions of receivers. Impossible with TCP.

Modern TCP Scaling Techniques

Failure Handling and Recovery

Connection models dramatically affect how failures are detected, reported, and recovered from.

UDP Failure Characteristics

UDP Failure Behavior

•Silent failure by default — Lost datagrams disappear without notification. The sender never knows unless the application implements acknowledgments.
•No remote peer detection — UDP cannot tell if the remote peer is alive, dead, or never existed. Datagrams sent to unreachable hosts simply vanish.
•ICMP may provide hints — 'Port unreachable' ICMP messages may arrive if nothing is listening. But ICMP is often filtered by firewalls.
•Fast failure at send time — If the local network is down, sendto() may fail immediately. But this only detects local problems.
•Application-layer timeouts required — Any meaningful failure detection requires application timers watching for expected responses.
•Instant recovery possible — No connection state means nothing to re-establish. Just start sending to a new endpoint if the old one failed.

TCP Failure Characteristics

TCP Failure Behavior

•Guaranteed failure notification — If data cannot be delivered after retry attempts, TCP will eventually report an error to the application.
•Connection reset (RST) — Remote peer can forcibly terminate a connection. Application receives immediate error on next send/receive.
•Keepalive detection — Optional keepalive probes can detect dead connections even without data flow (though default timeout is often hours).
•Retransmission exhaustion — After ~13-30 retransmissions (implementation-dependent), TCP gives up and reports connection failure.
•Slow failure detection — Retransmission timeouts back off exponentially. Detecting a dead peer can take minutes.
•Connection re-establishment required — After failure, the connection is gone. A completely new handshake is required to communicate again.

TCP Failure Detection Timeline
TCP Connection Failure Detection:
═══════════════════════════════════════════════════════════════════════════════
 
Scenario: Network cable unplugged during active data transfer
 
T=0s      Data sent, waiting for ACK
T=1s      RTO expires, retransmit #1 (RTO = ~1s initially)
T=3s      RTO expires, retransmit #2 (RTO doubled to ~2s)
T=7s      RTO expires, retransmit #3 (RTO = ~4s)
T=15s     RTO expires, retransmit #4 (RTO = ~8s)
T=31s     RTO expires, retransmit #5 (RTO = ~16s)
T=63s     RTO expires, retransmit #6 (RTO = ~32s)
T=127s    RTO expires, retransmit #7 (RTO = ~64s)
...
T=~10-15 minutes: TCP gives up, ETIMEDOUT returned to application
 
During this entire time:
  • Application send() calls may succeed (buffered)
  • Application recv() calls block or return nothing
  • Application has no idea connection is dead
  • Resources remain allocated
 
Compare to UDP:
  • Application request timeout: ~1-5 seconds
  • Application decides failure handling policy
  • Switch to backup server immediately
  • Resources freed as soon as application decides

Failure Recovery Comparison
Failure Type	UDP Behavior	TCP Behavior
Remote peer crashes	No detection (silent)	Eventually detects (~minutes)
Network partition	No detection (silent)	Eventually detects (~minutes)
Remote peer restarts	Seamless (no state)	RST on first packet; reconnect needed
Port closed remotely	ICMP may arrive	RST received immediately
Firewall blocks traffic	No detection	Timeout after retransmissions
Routing changes	Transparent	Transparent (connection survives)

TCP's Slow Failure Detection

NAT and Firewall Traversal

Network Address Translation (NAT) and firewalls treat UDP and TCP connections very differently, with significant implications for application design.

How NAT Tracks Connections

NAT Connection Tracking
NAT Connection Table:
═══════════════════════════════════════════════════════════════════════════════
 
TCP Entry (Long-lived, state-tracked):
┌─────────────────────────────────────────────────────────────────────────────┐
│ Internal: 192.168.1.100:45678 → External: 1.2.3.4:80                       │
│ Mapped to: 203.0.113.50:23456 → 1.2.3.4:80                                 │
│ State: ESTABLISHED                                                          │
│ Timeout: 7200 seconds (2 hours) since last activity                        │
│ Created: When SYN observed                                                  │
│ Destroyed: When FIN-ACK exchange complete OR timeout                       │
└─────────────────────────────────────────────────────────────────────────────┘
 
UDP Entry (Connectionless, timeout-based):
┌─────────────────────────────────────────────────────────────────────────────┐
│ Internal: 192.168.1.100:45679 → External: 8.8.8.8:53                       │
│ Mapped to: 203.0.113.50:23457 → 8.8.8.8:53                                 │
│ State: None (UDP is stateless)                                             │
│ Timeout: 30-180 seconds (implementation-dependent)                         │
│ Created: When first outbound packet observed                               │
│ Destroyed: Timeout expiration (no explicit close)                          │
└─────────────────────────────────────────────────────────────────────────────┘
 
Key Difference: TCP mappings survive long inactivity (connection exists)
                UDP mappings expire quickly (no connection state to persist)

UDP NAT Challenges

UDP NAT Traversal Issues

•Short timeouts — UDP NAT mappings typically expire in 30-180 seconds. Long-inactive 'connections' require keepalive pings.
•Mapping unpredictability — Different NAT types (Full Cone, Restricted Cone, Symmetric) create mappings differently. P2P applications must probe to discover behavior.
•No inbound connection initiation — NAT mapping must be created by outbound traffic first. Servers behind NAT cannot receive unsolicited UDP.
•Keepalive overhead — To maintain NAT mappings, UDP applications must send periodic traffic even when idle. Every 20-30 seconds is common.
•Hole punching complexity — P2P UDP connections require sophisticated STUN/TURN/ICE procedures to traverse NAT. Failure rate is significant.

TCP NAT Advantages

TCP NAT Traversal Advantages

•Long timeouts — ESTABLISHED TCP connections often have 2+ hour NAT timeouts. Reasonable for active sessions.
•State visibility — NAT can track connection state (SYN, ESTABLISHED, FIN). Mappings cleaned up properly on connection close.
•Keepalive support — TCP keepalive probes (if enabled) automatically maintain NAT mappings. No application changes needed.
•Predictable behavior — TCP connection semantics are universal. NAT implementations handle TCP consistently.
•Firewall friendliness — Stateful firewalls understand TCP. Established connections receive return traffic automatically.

NAT Timeout Comparison (Typical Values)
Protocol/State	Typical NAT Timeout	Notes
TCP ESTABLISHED	7200 seconds (2 hours)	Long-lived; may be shorter on busy NATs
TCP SYN_SENT	120 seconds	Connection attempt pending
TCP FIN_WAIT	120 seconds	Closing, waiting for final ACKs
TCP TIME_WAIT	240 seconds	Matches 2×MSL
UDP Stream	30-180 seconds	Varies widely by implementation
UDP Single	30-60 seconds	Some NATs: 'expected reply' window

Modern Solution: QUIC

Load Balancing Implications

How connections are handled fundamentally shapes load balancing strategies and possibilities.

UDP Load Balancing

UDP Load Balancing Characteristics

•Per-datagram distribution — Each datagram can be independently routed to any server. True horizontal scaling.
•No affinity requirement (for stateless) — If the application is stateless, any datagram can go to any server. Simple round-robin works.
•Source-hash affinity (for stateful) — Hash of source IP/port can ensure all datagrams from one client go to same server.
•Easy server addition/removal — Add servers to the pool; new datagrams may route to them. No connection state to migrate.
•Direct Server Return (DSR) — Responses can go directly to client, bypassing the load balancer. Reduces balancer bottleneck.
•Multicast capability — One datagram can be distributed to ALL servers simultaneously if needed.

TCP Load Balancing

TCP Load Balancing Characteristics

•Connection-level distribution — Decision made once at connection establishment. All packets for that connection go to same server.
•Mandatory connection affinity — TCP state (sequence numbers, windows) exists only on the chosen server. Must route all packets there.
•L4 vs L7 trade-offs — L4 balancers route by 4-tuple (fast, stateless). L7 balancers terminate TCP, make application-aware decisions (slower, stateful).
•Server removal requires draining — Can't remove server with active connections without breaking them. Gradual drain required.
•Connection state synchronization — Active-active HA requires sharing TCP state between balancers. Complex and expensive.
•No DSR for new connections — Handshake responses must traverse the balancer. Only established traffic can sometimes bypass.

Load Balancing Architecture Comparison
UDP Load Balancing (Per-Datagram):
═══════════════════════════════════════════════════════════════════════════════
 
Client A ─┐                                  ┌→ Server 1 (handles datagram 1, 4, 7...)
Client B ─┼─→ Load Balancer ─→ distribute ─┼→ Server 2 (handles datagram 2, 5, 8...)
Client C ─┘                                  └→ Server 3 (handles datagram 3, 6, 9...)
 
• Each datagram independently routed
• Server failure: next datagram goes elsewhere (automatic failover)
• Add server: immediately receives ~1/(n+1) traffic
• Remove server: no drain needed (no persistent state)
 
 
TCP Load Balancing (Per-Connection):
═══════════════════════════════════════════════════════════════════════════════
 
Client A ═══════════════════════════════════════════════════════→ Server 1
                                    ▲
Client B ════╗                      │                           → Server 2  
             ║                      │ (all packets for this
             ╠═══→ Load Balancer ═══╝  connection must go
             ║                         to the same server)
Client C ════╝═══════════════════════════════════════════════════→ Server 3
 
• Connection routed at setup, locked for duration
• Server failure: connection breaks, client must reconnect
• Add server: only new connections benefit
• Remove server: must drain existing connections (potentially hours)

Consistent Hashing for Stateful UDP

Summary: Connection Handling

We've explored how connectionless versus connection-oriented paradigms shape every aspect of system design. Here are the key insights:

Key Takeaways

•UDP is datagram-oriented, TCP is connection-oriented — UDP treats each packet as independent; TCP maintains a continuous byte stream over an established connection.
•Architecture mirrors the model — UDP servers use single sockets handling all clients; TCP servers maintain per-client sockets with kernel state.
•Scaling characteristics differ dramatically — UDP scales to millions of 'clients' with constant resources; TCP scales linearly with O(n) resources per connection.
•Failure detection is inverted — UDP requires application-layer timeouts but fails fast; TCP detects failure automatically but may take minutes.
•NAT treats them differently — TCP connections survive long periods; UDP mappings expire quickly, requiring keepalives.
•Load balancing flexibility varies — UDP enables per-datagram routing; TCP requires connection affinity throughout the connection lifetime.
•Neither model is universally better — The right choice depends on your application's requirements for state, reliability, latency, and scale.

What's Next:

Now we'll examine ordering guarantees—how UDP's lack of ordering and TCP's strict ordering affect applications, and when each approach is appropriate.

Connection Handling Mastered