UDP: When Speed Trumps Reliability

The Live Stream That Couldn't Wait

TCP's Reliability Tax

What Problem Does UDP Solve?

1. Guaranteed delivery: Packets are retransmitted if lost
2. Ordered delivery: Packets arrive in the exact order sent
3. Connection state: Three-way handshake before data transfer
4. Flow control: Prevents overwhelming the receiver
5. Congestion control: Adapts to network conditions

• A lost video frame from 100ms ago is useless—don't retransmit it
• Voice packets out of order are better than delayed packets
• Gaming input needs to arrive NOW, not reliably in 200ms

Flow diagram showing process

Real-World Analogy

• Requires signature confirmation
• Tracked at every step
• Guaranteed delivery or money back
• Takes longer, costs more
• Perfect for legal documents

• Drop in mailbox and forget
• Fast delivery
• No confirmation needed
• Might get lost (rarely)
• Perfect for holiday greetings

UDP's Minimalist Approach

How Does UDP Solve the Problem?

1. Port numbers: Multiplex multiple applications on one IP
2. Checksum: Detect corrupted packets (optional!)
3. Length field: Know where the packet ends

Flow diagram showing process

Understanding UDP's Flow

The UDP Communication Lifecycle

No Connection Setup (Unlike TCP)

1. No handshake: UDP starts sending immediately
2. Fire and forget: Sender doesn't wait for acknowledgment
3. Stateless: No connection state to maintain
4. Application responsibility: App must handle losses, ordering, duplicates

UDP Packet Structure

Diagram 4

• UDP header: 8 bytes
• TCP header: 20-60 bytes (5-15x larger!)

• Less bandwidth waste
• Faster processing
• More payload per packet

State Diagram: UDP Connection Lifecycle

Flow diagram showing process

• You can receive mail from anyone
• You can send mail to anyone
• No "connection" required
• Just drop your message and go

Deep Technical Dive

UDP Header Breakdown

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Data                              |
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1. Source Port (16 bits)
   • Identifies sending application
   • Range: 0-65,535
   • Why it matters: Allows multiplexing multiple apps on one IP
   • Can be 0 if sender doesn't need replies
2. Destination Port (16 bits)
   • Identifies receiving application
   • Why it matters: Directs packet to correct app
   • Well-known ports: DNS (53), DHCP (67/68), NTP (123)
3. Length (16 bits)
   • Total length: header + data
   • Minimum: 8 bytes (header only)
   • Maximum: 65,535 bytes
   • Why it matters: Receiver knows where packet ends
4. Checksum (16 bits)
   • Detects corruption in header + data
   • Optional in IPv4 (can be 0)
   • Mandatory in IPv6
   • Why it matters: Prevents delivering corrupted data

1. Compute 16-bit one's complement sum of:
   - Pseudo IP header (source IP, dest IP, protocol, UDP length)
   - UDP header
   - UDP data (padded to 16-bit boundary)
2. Take one's complement of the result
3. If result is 0, use 0xFFFF

Code Deep Dive: Building a UDP Client-Server

Example 1: UDP Echo Server

go
package main

import (
	"fmt"
	"net"
	"os"
)

func main() {
	// Create UDP address
	// Why UDP? We want fast, connectionless communication
	serverAddr, err := net.ResolveUDPAddr("udp", ":8080")
	if err != nil {
		fmt.Println("Error resolving address:", err)
		os.Exit(1)
	}

	// Create UDP socket and bind to port
	// Unlike TCP, this doesn't "listen" - it just opens a mailbox
	conn, err := net.ListenUDP("udp", serverAddr)
	if err != nil {
		fmt.Println("Error listening:", err)
		os.Exit(1)
	}
	defer conn.Close()

	fmt.Println("UDP Server listening on :8080")

	// Buffer for incoming packets
	// Why 1024? Common MTU is 1500 bytes, safe size for most packets
	buffer := make([]byte, 1024)

	for {
		// Read from UDP socket
		// This blocks until a packet arrives
		// No connection needed - we receive from anyone!
		n, clientAddr, err := conn.ReadFromUDP(buffer)
		if err != nil {
			fmt.Println("Error reading:", err)
			continue
		}

		// Log what we received
		message := string(buffer[:n])
		fmt.Printf("Received %d bytes from %s: %s\n",
			n, clientAddr.String(), message)

		// Echo back to sender
		// No connection state - just send to the address we got
		_, err = conn.WriteToUDP(buffer[:n], clientAddr)
		if err != nil {
			fmt.Println("Error writing:", err)
			continue
		}

		fmt.Printf("Echoed back to %s\n", clientAddr.String())
	}
}

1. ListenUDP() creates a UDP socket and binds to port 8080
   • Kernel allocates a socket buffer
   • No SYN/ACK handshake like TCP
   • Socket is immediately ready to receive
2. ReadFromUDP() blocks waiting for a packet
   • Packet arrives at network interface
   • IP layer verifies IP checksum, routes to UDP
   • UDP verifies checksum (if non-zero)
   • Packet queued in socket receive buffer
   • Application woken up with data + sender address
3. WriteToUDP() sends response
   • UDP adds 8-byte header
   • Passes to IP layer with destination address
   • No ACK expected, no retransmission logic

Example 2: UDP Client

go
package main

import (
	"bufio"
	"fmt"
	"net"
	"os"
	"time"
)

func main() {
	// Resolve server address
	serverAddr, err := net.ResolveUDPAddr("udp", "localhost:8080")
	if err != nil {
		fmt.Println("Error resolving address:", err)
		os.Exit(1)
	}

	// Create UDP connection
	// "Connection" is a misnomer - UDP is connectionless
	// This just associates the socket with a remote address
	conn, err := net.DialUDP("udp", nil, serverAddr)
	if err != nil {
		fmt.Println("Error dialing:", err)
		os.Exit(1)
	}
	defer conn.Close()

	fmt.Println("Connected to UDP server at localhost:8080")
	fmt.Println("Type messages to send (Ctrl+C to exit):")

	// Read user input
	scanner := bufio.NewScanner(os.Stdin)

	for scanner.Scan() {
		message := scanner.Text()

		// Send to server
		// No handshake, no ACK, just fire and forget
		start := time.Now()
		_, err := conn.Write([]byte(message))
		if err != nil {
			fmt.Println("Error sending:", err)
			continue
		}

		fmt.Printf("Sent: %s\n", message)

		// Set read deadline to timeout if server doesn't respond
		// Why? UDP doesn't know if packet was lost - we must handle it
		conn.SetReadDeadline(time.Now().Add(2 * time.Second))

		// Wait for response
		buffer := make([]byte, 1024)
		n, err := conn.Read(buffer)
		if err != nil {
			// This could be timeout or actual error
			if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
				fmt.Println("Timeout - packet may have been lost")
			} else {
				fmt.Println("Error reading:", err)
			}
			continue
		}

		elapsed := time.Since(start)

		// Display response
		response := string(buffer[:n])
		fmt.Printf("Received: %s (RTT: %v)\n", response, elapsed)
	}
}

bash
# Terminal 1: Start server
go run udp_server.go
# Output: UDP Server listening on :8080

# Terminal 2: Start client
go run udp_client.go
# Type: Hello UDP!
# Output:
# Sent: Hello UDP!
# Received: Hello UDP! (RTT: 423µs)

Example 3: UDP Packet Loss Simulation

go
package main

import (
	"fmt"
	"math/rand"
	"net"
	"time"
)

// Simulates unreliable network with packet loss
type UnreliableUDP struct {
	conn        *net.UDPConn
	lossRate    float64 // 0.0 to 1.0 (0% to 100%)
	delayMs     int     // Artificial delay in ms
	rand        *rand.Rand
}

func NewUnreliableUDP(conn *net.UDPConn, lossRate float64, delayMs int) *UnreliableUDP {
	return &UnreliableUDP{
		conn:     conn,
		lossRate: lossRate,
		delayMs:  delayMs,
		rand:     rand.New(rand.NewSource(time.Now().UnixNano())),
	}
}

func (u *UnreliableUDP) WriteToUDP(data []byte, addr *net.UDPAddr) (int, error) {
	// Simulate packet loss
	// This is what happens in real networks!
	if u.rand.Float64() < u.lossRate {
		fmt.Printf("[SIMULATED LOSS] Dropped packet to %s\n", addr.String())
		// Pretend we sent it (app doesn't know it was lost)
		return len(data), nil
	}

	// Simulate network delay
	if u.delayMs > 0 {
		time.Sleep(time.Duration(u.delayMs) * time.Millisecond)
	}

	return u.conn.WriteToUDP(data, addr)
}

func main() {
	serverAddr, _ := net.ResolveUDPAddr("udp", ":8080")
	conn, _ := net.ListenUDP("udp", serverAddr)
	defer conn.Close()

	// Create unreliable UDP with 30% loss rate and 50ms delay
	// This simulates a poor quality network
	unreliable := NewUnreliableUDP(conn, 0.3, 50)

	fmt.Println("Unreliable UDP Server (30% loss, 50ms delay)")

	buffer := make([]byte, 1024)

	for {
		n, clientAddr, err := conn.ReadFromUDP(buffer)
		if err != nil {
			continue
		}

		message := string(buffer[:n])
		fmt.Printf("Received: %s from %s\n", message, clientAddr)

		// Try to echo back (but might be lost!)
		_, err = unreliable.WriteToUDP(buffer[:n], clientAddr)
		if err != nil {
			fmt.Println("Error:", err)
		}
	}
}

Unreliable UDP Server (30% loss, 50ms delay)
Received: packet 1 from 127.0.0.1:54321
Received: packet 2 from 127.0.0.1:54321
[SIMULATED LOSS] Dropped packet to 127.0.0.1:54321
Received: packet 3 from 127.0.0.1:54321
Received: packet 4 from 127.0.0.1:54321
[SIMULATED LOSS] Dropped packet to 127.0.0.1:54321

• UDP provides no retransmission
• Packets can be lost silently
• Application must detect and handle losses
• This is exactly what happens in real networks!

Benefits & Why UDP Matters

Performance Benefits

Diagram 6

• On a 100ms RTT network: TCP wastes 150ms before sending data
• For DNS query: UDP responds in ~50ms, TCP would need 200ms+
• For gaming: Every millisecond matters for responsiveness

Packets sent: 1, 2, 3, 4, 5
Packet 3 lost
Packets 4 and 5 must wait for packet 3 to be retransmitted
Total delay: RTT + retransmission time

Packets sent: 1, 2, 3, 4, 5
Packet 3 lost
Packets 4 and 5 delivered immediately
Total delay: 0 (app handles the gap)

• Video streaming: Drop one frame, show the next (60fps = 16ms per frame)
• Gaming: Latest position update is what matters, not old ones
• VoIP: Small gaps in audio are less noticeable than stuttering

go
// Send one packet to multiple receivers
func multicastExample() {
    // Join multicast group 239.0.0.1
    addr, _ := net.ResolveUDPAddr("udp", "239.0.0.1:9999")
    conn, _ := net.DialUDP("udp", nil, addr)

    // One send reaches all subscribers!
    conn.Write([]byte("Hello everyone!"))
}

• Stock price updates to thousands of traders
• Video streaming to multiple viewers
• Service discovery (mDNS, SSDP)
• Game state updates to all players

Developer Experience

go
// TCP: Complex connection management
listener, _ := net.Listen("tcp", ":8080")
for {
    conn, _ := listener.Accept() // Wait for connection
    go handleConnection(conn)    // Spawn goroutine per connection
}

// UDP: Simple datagram handling
conn, _ := net.ListenUDP("udp", addr)
for {
    n, addr, _ := conn.ReadFromUDP(buffer) // Read from anyone
    conn.WriteToUDP(buffer[:n], addr)      // Reply
}

• No need to track connections
• No cleanup on disconnect
• No TIME_WAIT sockets

Real-World Success Stories

• Uses UDP port 53
• Typical query: < 50 bytes
• Typical response: < 512 bytes
• Adding TCP overhead would double latency
• Result: Billions of queries/day with minimal latency

• Built on UDP to avoid TCP's limitations
• Implements reliability in userspace
• Enables 0-RTT connection establishment
• Powers 75% of Chrome's HTTPS traffic

• Audio/video over UDP (RTP/SRTP)
• Tolerates 1-2% packet loss
• Adaptive bitrate compensates for losses
• TCP would cause stuttering from retransmissions

• Game state updates over UDP
• 60Hz update rate (16ms per update)
• Old updates are worthless
• TCP's retransmission would cause lag

Trade-offs & Gotchas

When to Use UDP

1. Real-time applications where latency > reliability
   • Video/audio streaming
   • Online gaming
   • VoIP calls
   • Live sports broadcasts
2. Small, independent requests
   • DNS queries
   • NTP time synchronization
   • DHCP configuration
   • Simple RPC calls
3. Multicast/broadcast scenarios
   • Service discovery
   • Cluster communication
   • Live data feeds
4. Custom reliability protocols
   • QUIC (HTTP/3)
   • Gaming protocols with custom ACKs
   • Video streaming with FEC (Forward Error Correction)

When NOT to Use UDP

1. File transfers
   • Why: Need guaranteed delivery of every byte
   • Use: TCP, SFTP, rsync
2. Financial transactions
   • Why: Cannot afford data loss
   • Use: TCP with TLS
3. Email, messaging
   • Why: Messages must arrive in order
   • Use: TCP (SMTP, IMAP)
4. API calls with large responses
   • Why: Fragmentation issues, no retry logic
   • Use: HTTP/1.1 (TCP) or HTTP/3 (QUIC over UDP)

Common Mistakes

Mistake 1: Not Handling Packet Loss

go
// BAD: Assumes packet always arrives
func sendCommand(conn *net.UDPConn, cmd string) {
    conn.Write([]byte(cmd))
    // What if this packet is lost?
}

// GOOD: Retry with timeout
func sendCommandReliable(conn *net.UDPConn, cmd string) error {
    maxRetries := 3
    timeout := 1 * time.Second

    for i := 0; i < maxRetries; i++ {
        conn.Write([]byte(cmd))

        conn.SetReadDeadline(time.Now().Add(timeout))
        buffer := make([]byte, 1024)

        n, err := conn.Read(buffer)
        if err == nil {
            // Got response
            return nil
        }

        fmt.Printf("Retry %d/%d\n", i+1, maxRetries)
    }

    return fmt.Errorf("failed after %d retries", maxRetries)
}

Mistake 2: Sending Large Packets

go
// BAD: Sending 10KB packet
largeData := make([]byte, 10000)
conn.Write(largeData) // Will fragment across multiple IP packets

// GOOD: Keep packets under MTU
func sendInChunks(conn *net.UDPConn, data []byte) {
    const MTU = 1400 // Safe size under typical 1500 MTU

    for i := 0; i < len(data); i += MTU {
        end := i + MTU
        if end > len(data) {
            end = len(data)
        }

        chunk := data[i:end]
        conn.Write(chunk)
    }
}

• IP can fragment large UDP packets
• If ANY fragment is lost, entire packet is lost
• Fragmentation is often blocked by firewalls

Mistake 3: Not Validating Data

go
// BAD: Trusting received data
buffer := make([]byte, 1024)
n, _ := conn.Read(buffer)
value := binary.LittleEndian.Uint32(buffer[:4]) // Could panic!

// GOOD: Validate before using
buffer := make([]byte, 1024)
n, err := conn.Read(buffer)
if err != nil {
    return err
}

if n < 4 {
    return fmt.Errorf("packet too short")
}

value := binary.LittleEndian.Uint32(buffer[:4])

• Checksum is optional in IPv4
• Even with checksum, malicious packets can be sent
• Network errors can corrupt data in complex ways

Mistake 4: Ignoring Packet Reordering

go
// BAD: Assuming packets arrive in order
type Message struct {
    SequenceNum uint32
    Data        []byte
}

var lastSeq uint32 = 0

func handlePacket(msg Message) {
    lastSeq++
    // Assuming msg.SequenceNum == lastSeq (WRONG!)
    processData(msg.Data)
}

// GOOD: Handle out-of-order packets
type ReorderBuffer struct {
    buffer  map[uint32][]byte
    nextSeq uint32
}

func (rb *ReorderBuffer) AddPacket(seq uint32, data []byte) [][]byte {
    rb.buffer[seq] = data

    var ready [][]byte
    for {
        if data, ok := rb.buffer[rb.nextSeq]; ok {
            ready = append(ready, data)
            delete(rb.buffer, rb.nextSeq)
            rb.nextSeq++
        } else {
            break
        }
    }

    return ready
}

Mistake 5: Not Implementing Flow Control

go
// BAD: Sending as fast as possible
for i := 0; i < 1000000; i++ {
    conn.Write([]byte(fmt.Sprintf("packet %d", i)))
    // Overwhelming receiver!
}

// GOOD: Rate limiting
func sendWithRateLimit(conn *net.UDPConn, packets [][]byte, ratePerSec int) {
    ticker := time.NewTicker(time.Second / time.Duration(ratePerSec))
    defer ticker.Stop()

    for _, packet := range packets {
        <-ticker.C // Wait for next tick
        conn.Write(packet)
    }
}

• Receiver buffer can overflow
• Packets dropped by receiver's OS
• Network congestion from flood

Mistake 6: Not Handling Duplicates

go
// BAD: Processing every packet
func handlePacket(data []byte) {
    executeCommand(data) // Might execute twice!
}

// GOOD: Deduplication
type DeduplicationCache struct {
    seen map[uint32]bool
    mu   sync.Mutex
}

func (dc *DeduplicationCache) IsNew(seqNum uint32) bool {
    dc.mu.Lock()
    defer dc.mu.Unlock()

    if dc.seen[seqNum] {
        return false // Duplicate
    }

    dc.seen[seqNum] = true

    // Clean old entries periodically
    if len(dc.seen) > 10000 {
        dc.seen = make(map[uint32]bool)
    }

    return true
}

Performance Considerations

go
// Check and increase socket buffer size
conn.SetReadBuffer(4 * 1024 * 1024)  // 4MB receive buffer
conn.SetWriteBuffer(4 * 1024 * 1024) // 4MB send buffer

go
// BAD: One syscall per packet
for i := 0; i < 1000; i++ {
    conn.Write(packets[i])
}

// GOOD: Batch with sendmmsg (Linux)
// Use libraries like golang.org/x/net/ipv4

go
// BAD: Allocating on every read
for {
    buffer := make([]byte, 1024) // New allocation!
    conn.Read(buffer)
}

// GOOD: Reuse buffers
bufferPool := sync.Pool{
    New: func() interface{} {
        return make([]byte, 1024)
    },
}

for {
    buffer := bufferPool.Get().([]byte)
    conn.Read(buffer)
    // Process...
    bufferPool.Put(buffer)
}

Security Considerations

go
// Vulnerable server
func vulnerableServer() {
    conn, _ := net.ListenUDP("udp", addr)
    buffer := make([]byte, 10)

    for {
        n, clientAddr, _ := conn.ReadFromUDP(buffer)
        if n > 0 {
            // Sending large response to small request
            largeResponse := make([]byte, 10000)
            conn.WriteToUDP(largeResponse, clientAddr)
            // Attacker can spoof clientAddr, amplifying attack!
        }
    }
}

// Mitigation: Rate limiting + response size limits

go
// Cannot trust source IP with UDP
// Implement application-level authentication
type AuthenticatedPacket struct {
    Signature [32]byte
    Timestamp int64
    Data      []byte
}

func verifyPacket(packet AuthenticatedPacket, secretKey []byte) bool {
    // HMAC verification
    // Timestamp check (prevent replay)
    return true
}

• Rate limiting per source IP
• Connection puzzles (proof of work)
• Stateless cookie exchange
• Traffic shaping

Comparison with Alternatives

Flow diagram showing process

Hands-On Example: UDP Chat Application

go
// chat_server.go
package main

import (
	"fmt"
	"net"
	"sync"
)

type Client struct {
	addr *net.UDPAddr
	name string
}

type ChatServer struct {
	conn    *net.UDPConn
	clients map[string]*Client
	mu      sync.RWMutex
}

func NewChatServer(port string) (*ChatServer, error) {
	addr, err := net.ResolveUDPAddr("udp", ":"+port)
	if err != nil {
		return nil, err
	}

	conn, err := net.ListenUDP("udp", addr)
	if err != nil {
		return nil, err
	}

	return &ChatServer{
		conn:    conn,
		clients: make(map[string]*Client),
	}, nil
}

func (s *ChatServer) Start() {
	fmt.Println("Chat server started")
	buffer := make([]byte, 1024)

	for {
		n, clientAddr, err := s.conn.ReadFromUDP(buffer)
		if err != nil {
			continue
		}

		message := string(buffer[:n])
		s.handleMessage(clientAddr, message)
	}
}

func (s *ChatServer) handleMessage(addr *net.UDPAddr, message string) {
	addrStr := addr.String()

	// Handle JOIN command
	if len(message) > 5 && message[:5] == "JOIN:" {
		name := message[5:]
		s.mu.Lock()
		s.clients[addrStr] = &Client{addr: addr, name: name}
		s.mu.Unlock()

		fmt.Printf("%s joined as %s\n", addrStr, name)
		s.broadcast(fmt.Sprintf("%s joined the chat", name), nil)
		return
	}

	// Broadcast message to all clients
	s.mu.RLock()
	client, exists := s.clients[addrStr]
	s.mu.RUnlock()

	if exists {
		fullMessage := fmt.Sprintf("%s: %s", client.name, message)
		s.broadcast(fullMessage, client)
	}
}

func (s *ChatServer) broadcast(message string, sender *Client) {
	s.mu.RLock()
	defer s.mu.RUnlock()

	for _, client := range s.clients {
		// Don't echo back to sender
		if sender != nil && client.addr.String() == sender.addr.String() {
			continue
		}

		// Fire and forget - no guarantee of delivery!
		s.conn.WriteToUDP([]byte(message), client.addr)
	}
}

func main() {
	server, err := NewChatServer("8080")
	if err != nil {
		panic(err)
	}
	server.Start()
}

bash
# Terminal 1
go run chat_server.go
# Output: Chat server started

# Terminal 2
echo "JOIN:Alice" | nc -u localhost 8080
echo "Hello everyone!" | nc -u localhost 8080

# Terminal 3
echo "JOIN:Bob" | nc -u localhost 8080
echo "Hi Alice!" | nc -u localhost 8080

• UDP for real-time messaging
• Broadcast to multiple clients
• No guaranteed delivery (messages might be lost)
• Stateless server (tracks clients via address)

Interview Preparation

Question 1: Explain UDP vs TCP and when to use each

• Real-time applications (gaming, VoIP)
• Broadcasting (service discovery)
• Small request-response (DNS)
• Application implements custom reliability

• File transfers
• Email, messaging
• Financial transactions
• Any data that must arrive reliably

• "UDP is always faster" (not always true in all scenarios)
• "TCP is always better because it's reliable" (misses UDP use cases)
• Not mentioning head-of-line blocking

Question 2: What is the UDP header structure?

|Source Port (16 bits)|Dest Port (16 bits)|
|Length (16 bits)     |Checksum (16 bits) |

1. Source Port: Sender's port (0-65535), can be 0
2. Destination Port: Receiver's port (0-65535)
3. Length: Total length including header + data (min 8 bytes)
4. Checksum: Optional in IPv4, mandatory in IPv6

• Ports enable multiplexing multiple applications
• Length tells receiver where packet ends
• Checksum detects corruption (though optional)

• Confusing with TCP header (20+ bytes)
• Not knowing checksum is optional in IPv4
• Not understanding minimum packet size

Question 3: How would you implement reliability on top of UDP?

1. Sequence numbers: Track packet order
2. Acknowledgments (ACKs): Confirm receipt
3. Timeouts: Detect lost packets
4. Retransmission: Resend lost packets
5. Duplicate detection: Ignore retransmitted packets

go
type ReliableUDP struct {
    conn        *net.UDPConn
    pendingACKs map[uint32]chan bool
    sequenceNum uint32
}

func (r *ReliableUDP) SendReliable(data []byte, addr *net.UDPAddr) error {
    seqNum := atomic.AddUint32(&r.sequenceNum, 1)

    packet := Packet{
        SeqNum: seqNum,
        Data:   data,
    }

    maxRetries := 3
    timeout := 1 * time.Second

    for i := 0; i < maxRetries; i++ {
        r.conn.WriteToUDP(packet.Encode(), addr)

        // Wait for ACK with timeout
        select {
        case <-time.After(timeout):
            continue // Retry
        case <-r.pendingACKs[seqNum]:
            return nil // Success
        }
    }

    return errors.New("failed after retries")
}

• Saying "just use TCP" (misses the point)
• Not mentioning timeouts
• Ignoring duplicate packets

Question 4: What are the security concerns with UDP?

1. Amplification Attacks
   • Small request triggers large response
   • Attacker spoofs source IP
   • Victim receives amplified traffic
   • Example: DNS amplification (10x-100x amplification)
2. Source IP Spoofing
   • UDP doesn't verify source address
   • Attacker can fake sender IP
   • Used in DDoS attacks
   • Mitigation: Application-level authentication
3. UDP Flood DDoS
   • Send massive UDP packets to target
   • Overwhelm network or application
   • No handshake means easy to generate
   • Mitigation: Rate limiting, firewalls
4. No Encryption
   • UDP itself has no encryption
   • Data sent in plaintext
   • Mitigation: DTLS (Datagram TLS)

go
// Rate limiting per IP
rateLimiter := make(map[string]*time.Ticker)

// Authentication
type AuthPacket struct {
    HMAC      [32]byte
    Timestamp int64
    Data      []byte
}

// Response size limiting
if len(response) > 10*len(request) {
    // Potential amplification attack
    return
}

• Not mentioning spoofing
• Saying "UDP is inherently insecure" (protocol-agnostic)
• Ignoring application-layer mitigations

Question 5: How does UDP handle packet loss in practice?

1. Sequence numbers: Gap indicates loss
2. Timeouts: Expected packet doesn't arrive
3. Heartbeats: Missing heartbeats suggest loss

1. Ignore it (streaming)
   • Lost video frames are acceptable
   • Show newer frames instead
2. Forward Error Correction (FEC)
   • Send redundant data
   • Reconstruct lost packets from redundancy
   • Used in video conferencing
3. Selective retransmission
   • Track lost packets
   • Request retransmission
   • Used in QUIC, gaming protocols
4. Interpolation (gaming, VoIP)
   • Predict missing data from adjacent packets
   • Smooth out gaps

go
// FEC: Send 3 packets, any 2 can reconstruct data
func sendWithFEC(data []byte, conn *net.UDPConn, addr *net.UDPAddr) {
    chunk1 := data[:len(data)/2]
    chunk2 := data[len(data)/2:]
    redundant := xor(chunk1, chunk2)

    conn.WriteToUDP(chunk1, addr)
    conn.WriteToUDP(chunk2, addr)
    conn.WriteToUDP(redundant, addr)

    // Receiver can reconstruct from any 2 packets
}

• "UDP always retransmits" (it doesn't)
• Not knowing different loss-handling strategies
• Assuming loss is always a problem

Question 6: Explain UDP's role in QUIC/HTTP3

1. Avoid TCP ossification
   • Middle boxes (routers, firewalls) expect TCP behavior
   • Changing TCP is nearly impossible
   • UDP is simpler, less interfered with
2. Userspace implementation
   • TCP is in kernel (slow to update)
   • UDP allows protocol in userspace
   • Faster iteration and improvements
3. 0-RTT connection establishment
   • TCP requires handshake (1.5 RTT)
   • QUIC can send data immediately
   • Huge latency improvement

• Reliability (ACKs, retransmission)
• Flow control
• Congestion control
• Stream multiplexing (no head-of-line blocking)
• Built-in TLS 1.3 encryption

HTTP/3 → QUIC → UDP → IP

• 75% of Google Chrome traffic uses HTTP/3
• Faster page loads (especially on mobile)
• Better performance on lossy networks

• "QUIC is just HTTP/2 over UDP" (it's the transport layer)
• Not understanding why UDP was chosen
• Confusing QUIC with HTTP/3

Key Takeaways

Insights & Reflection

The Philosophy of UDP

Connection to Broader Concepts

Evolution and Future

• 1980s: DNS, TFTP (simple protocols)
• 1990s: Streaming media emerges
• 2000s: VoIP, gaming become mainstream
• 2010s: QUIC invented, HTTP/3 standardized
• 2020s: WebRTC, cloud gaming, 5G networks