Networking Fundamentals

The Transport Layer Foundation

Understanding networking fundamentals is crucial for designing distributed systems. The transport layer protocols you choose directly impact:

• Latency: How fast data travels
• Throughput: How much data can be sent
• Reliability: Whether data arrives correctly
• Application design: How you structure your code

TCP vs UDP

TCP (Transmission Control Protocol)

TCP is connection-oriented and provides reliable, ordered delivery of data.

Characteristics:

• Connection-oriented: Establishes connection before data transfer
• Reliable: Guarantees delivery (acknowledgments, retransmissions)
• Ordered: Data arrives in order
• Flow control: Prevents sender from overwhelming receiver
• Congestion control: Adapts to network conditions

Use Cases:

• Web browsing (HTTP/HTTPS)
• File transfers
• Email (SMTP)
• Database connections
• Any application requiring reliable delivery

Trade-offs:

• Higher latency (connection establishment, acknowledgments)
• More overhead (headers, control messages)
• Slower for small messages (connection setup cost)

UDP (User Datagram Protocol)

UDP is connectionless and provides unreliable, unordered delivery.

Characteristics:

• Connectionless: No connection establishment
• Unreliable: No delivery guarantees
• Unordered: Data may arrive out of order
• No flow control: Can overwhelm receiver
• No congestion control: Can congest network

Use Cases:

• Real-time gaming
• Video streaming
• DNS queries
• Voice over IP (VoIP)
• Any application prioritizing speed over reliability

Trade-offs:

• Lower latency (no connection setup)
• Less overhead (smaller headers)
• Faster for small messages
• No delivery guarantees

DNS (Domain Name System)

DNS translates human-readable domain names (like example.com) to IP addresses (like 192.0.2.1).

How DNS Works

DNS Resolution Steps:

1. Client queries local DNS server (usually ISP or configured resolver)
2. If not cached, local DNS queries root DNS server
3. Root server refers to TLD server (.com, .org, etc.)
4. TLD server refers to authoritative DNS server
5. Authoritative server returns IP address
6. Response cached at multiple levels

Performance Impact:

• First lookup: 20-120ms (multiple round trips)
• Cached lookup: less than 1ms (from cache)
• DNS failures: Complete service outage (can’t resolve domain names)

Best Practices:

• Cache DNS responses (TTL-based)
• Use multiple DNS servers for redundancy
• Monitor DNS resolution time
• Consider DNS prefetching for web applications

HTTP/2

HTTP/2 is a binary protocol that improves upon HTTP/1.1 with multiplexing, header compression, and server push.

Key Features

Multiplexing:

• Multiple requests over single TCP connection
• Eliminates head-of-line blocking
• Better connection utilization

Header Compression:

• HPACK compression reduces header size
• Especially beneficial for small requests with large headers

Server Push:

• Server can push resources before client requests them
• Reduces round trips

Binary Protocol:

• More efficient than text-based HTTP/1.1
• Easier to parse

Impact on Application Design:

• Connection pooling less critical (single connection handles multiple requests)
• Reduced latency for multiple requests
• Better for applications making many small requests

QUIC

QUIC (Quick UDP Internet Connections) is a UDP-based transport protocol developed by Google. It provides TCP-like reliability with lower latency.

Key Features

Built-in Encryption:

• TLS 1.3 encryption built into protocol
• Reduces connection establishment overhead

Connection Migration:

• Connection survives IP address changes
• Better for mobile devices switching networks

Multiplexing:

• Multiple streams over single connection
• Eliminates head-of-line blocking

Faster Connection Establishment:

• 0-RTT for repeat connections
• 1-RTT for new connections (vs 3-RTT for TCP+TLS)

Use Cases:

• HTTP/3 (replaces TCP+TLS for HTTP)
• Mobile applications (handles network changes)
• High-latency networks (faster connection establishment)
• Applications requiring low latency

Networking Impact on Application Design

Connection Pooling

Problem: Creating new TCP connections is expensive (3-way handshake).

Solution: Reuse connections via connection pooling.

💡 Tip: Click dropdown to switch between languages

Python

Python

"connection_pool.py

import httpx
from typing import Optional

class ConnectionPool:
    """HTTP connection pool"""

    def __init__(self, base_url: str, max_connections: int = 10):
        self.client = httpx.Client(
            base_url=base_url,
            limits=httpx.Limits(
                max_connections=max_connections,
                max_keepalive_connections=5
            ),
            timeout=httpx.Timeout(10.0)
        )

    def get(self, path: str) -> dict:
        """GET request using pooled connection"""
        response = self.client.get(path)
        response.raise_for_status()
        return response.json()

    def close(self):
        """Close connection pool"""
        self.client.close()

# Usage
pool = ConnectionPool("https://api.example.com")

# Reuses connections
data1 = pool.get("/users/1")
data2 = pool.get("/users/2")
data3 = pool.get("/orders/123")

pool.close()

Java

"ConnectionPool.java

import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.URI;
import java.time.Duration;

public class ConnectionPool {
    private final HttpClient client;
    private final String baseUrl;

    public ConnectionPool(String baseUrl) {
        this.baseUrl = baseUrl;
        this.client = HttpClient.newBuilder()
            .connectTimeout(Duration.ofSeconds(10))
            .build();
    }

    public String get(String path) throws Exception {
        // GET request using pooled connection
        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create(baseUrl + path))
            .timeout(Duration.ofSeconds(10))
            .build();

        HttpResponse<String> response = client.send(
            request,
            HttpResponse.BodyHandlers.ofString()
        );

        return response.body();
    }
}

// Usage
ConnectionPool pool = new ConnectionPool("https://api.example.com");

// Reuses connections
String data1 = pool.get("/users/1");
String data2 = pool.get("/users/2");
String data3 = pool.get("/orders/123");

TypeScript

connection-pool.ts

import axios, { AxiosInstance } from 'axios';

class ConnectionPool {
    // HTTP connection pool
    private client: AxiosInstance;

    constructor(baseUrl: string) {
        this.client = axios.create({
            baseURL: baseUrl,
            timeout: 10000,
            // Reuse connections
            httpAgent: new (require('http').Agent)({
                keepAlive: true,
                maxSockets: 10
            }),
            httpsAgent: new (require('https').Agent)({
                keepAlive: true,
                maxSockets: 10
            })
        });
    }

    async get(path: string): Promise<any> {
        // GET request using pooled connection
        const response = await this.client.get(path);
        return response.data;
    }
}

// Usage
const pool = new ConnectionPool("https://api.example.com");

// Reuses connections
const data1 = await pool.get("/users/1");
const data2 = await pool.get("/users/2");
const data3 = await pool.get("/orders/123");

C++

"connection_pool.cpp

#include <curl/curl.h>
#include <string>
#include <memory>

class ConnectionPool {
private:
    CURL* curl;
    std::string baseUrl;

public:
    ConnectionPool(const std::string& baseUrl) : baseUrl(baseUrl) {
        curl = curl_easy_init();
        // Enable connection reuse
        curl_easy_setopt(curl, CURLOPT_TCP_KEEPALIVE, 1L);
        curl_easy_setopt(curl, CURLOPT_TCP_KEEPIDLE, 120L);
    }

    std::string get(const std::string& path) {
        std::string url = baseUrl + path;
        std::string response;

        curl_easy_setopt(curl, CURLOPT_URL, url.c_str());
        curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writeCallback);
        curl_easy_setopt(curl, CURLOPT_WRITEDATA, &response);

        curl_easy_perform(curl);
        return response;
    }

    ~ConnectionPool() {
        curl_easy_cleanup(curl);
    }

private:
    static size_t writeCallback(void* contents, size_t size, size_t nmemb, void* userp) {
        ((std::string*)userp)->append((char*)contents, size * nmemb);
        return size * nmemb;
    }
};

// Usage
ConnectionPool pool("https://api.example.com");

// Reuses connections
std::string data1 = pool.get("/users/1");
std::string data2 = pool.get("/users/2");
std::string data3 = pool.get("/orders/123");

C#

ConnectionPool.cs

using System;
using System.Net.Http;
using System.Threading.Tasks;

public class ConnectionPool {
    // HTTP connection pool
    private readonly HttpClient client;
    private readonly string baseUrl;

    public ConnectionPool(string baseUrl) {
        this.baseUrl = baseUrl;
        this.client = new HttpClient {
            BaseAddress = new Uri(baseUrl),
            Timeout = TimeSpan.FromSeconds(10)
        };
        // Connection reuse handled by HttpClient
    }

    public async Task<string> GetAsync(string path) {
        // GET request using pooled connection
        var response = await client.GetAsync(path);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }

    public void Dispose() {
        client?.Dispose();
    }
}

// Usage
using var pool = new ConnectionPool("https://api.example.com");

// Reuses connections
var data1 = await pool.GetAsync("/users/1");
var data2 = await pool.GetAsync("/users/2");
var data3 = await pool.GetAsync("/orders/123");

Async I/O

For high-throughput applications, use async I/O to handle many connections efficiently.

Benefits:

• Handle thousands of connections with few threads
• Better resource utilization
• Lower latency (no blocking on I/O)

Use Cases:

• High-concurrency servers
• Real-time applications
• Microservices with many connections

Protocol Selection Guide

Choose TCP when:

• Reliability is critical (database, file transfer)
• Order matters (streaming, transactions)
• Flow control needed (large transfers)

Choose UDP when:

• Speed/latency is critical (gaming, VoIP)
• Small messages (DNS queries)
• Can tolerate packet loss (real-time streaming)
• Need multicast (broadcasting)

Choose HTTP/2 when:

• Making many requests to same server
• Want to reduce latency
• Need header compression benefits

Choose QUIC/HTTP/3 when:

• Mobile applications (network switching)
• High latency networks
• Want fastest connection establishment
• Need connection migration

Key Takeaways

TCP vs UDP

TCP provides reliability and ordering at cost of latency. UDP provides speed at cost of reliability. Choose based on requirements.

DNS Impact

DNS resolution adds latency (20-120ms first lookup). Cache DNS responses. DNS failures cause complete outages.

HTTP/2 Benefits

Multiplexing, header compression, server push reduce latency. Single connection handles multiple requests efficiently.

QUIC Advantages

Faster connection establishment, built-in encryption, connection migration. Better for mobile and high-latency networks.

---

Next Steps

• Learn API Design - HTTP protocols used in APIs
• Master Load Balancing - networking affects load balancing
• Understand Rate Limiting - protocol choice affects rate limiting strategies