Networking

Key features

• An IPv4 address is 32 bits, written as four dotted decimal octets (192.168.1.10); IPv6 is 128 bits, written in colon-separated hex groups
• A port is a 16-bit number (0-65535) identifying a specific process on a host — 0-1023 are well-known ports (80 HTTP, 443 HTTPS, 22 SSH), assigned by IANA
• A TCP/UDP connection endpoint is the PAIR (IP address, port) — the same host can run many independent services, one per port
• The internet protocol stack layers roughly: Link (Ethernet/Wi-Fi) -> Internet (IP) -> Transport (TCP/UDP) -> Application (HTTP, DNS, ...), each layer only trusting the guarantees of the one below it
• IP itself is unreliable and connectionless — it does not guarantee a packet arrives, arrives once, or arrives in order; TCP is the layer that adds those guarantees on top

Command

import ipaddress

ip = ipaddress.ip_address('192.168.1.10')      # ValueError if not a valid IPv4/IPv6 address
net = ipaddress.ip_network('192.168.1.0/24')   # a whole subnet
port = 443                                     # just an int in [0, 65535] -- no dedicated type

Key features

• socket.socket(socket.AF_INET, socket.SOCK_STREAM) creates a TCP socket over IPv4; SOCK_DGRAM creates a UDP socket instead
• Server side: .bind((host, port)) claims an address, .listen() marks it ready to accept connections, .accept() blocks until a client connects and returns a NEW socket for that one connection
• Client side: .connect((host, port)) performs the TCP three-way handshake before returning
• .send()/.recv() (TCP) or .sendto()/.recvfrom() (UDP) move bytes -- sockets work in bytes, not str, so encode/decode text explicitly
• .close() releases the underlying OS file descriptor -- an unclosed socket leaks resources exactly like an unclosed file

Command

import socket

# server
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('0.0.0.0', 8080))
s.listen(5)
conn, addr = s.accept()      # blocks until a client connects

# client
c = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
c.connect(('example.com', 8080))

Key features

• TCP (SOCK_STREAM) requires a handshake (connect()/accept()) before any data moves; UDP (SOCK_DGRAM) sends a datagram immediately with sendto(), no connection setup
• TCP guarantees delivery, ordering, and no duplication via acknowledgment and retransmission; UDP guarantees none of these -- a datagram can be lost, duplicated, or arrive out of order
• TCP has per-packet overhead (headers, ACKs, retransmission logic) that adds latency; UDP has a much smaller header and no retransmission delay
• Typical TCP uses: HTTP, database connections, file transfer -- anywhere a dropped byte must not be silently ignored
• Typical UDP uses: DNS queries, video/voice calls, online games -- anywhere a late retransmit is worse than just losing that one packet and moving on

Command

import socket

tcp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)   # reliable, ordered, connection-based
udp = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)    # best-effort, connectionless

Key features

• socket.gethostbyname(host) returns one IPv4 address as a string, resolved through the OS DNS resolver
• socket.getaddrinfo(host, port) is the more complete API -- it can return multiple addresses (IPv4 and IPv6) and the info needed to open a socket to each
• DNS lookups are cached at multiple layers (OS, browser, resolver) with a Time To Live (TTL) set by the domain owner -- a changed IP is not visible everywhere instantly
• A failed lookup raises socket.gaierror ("getaddrinfo error"), not a generic connection error -- distinguishing "name did not resolve" from "server did not respond"
• connect()ing to a hostname (not a bare IP) always performs a DNS lookup first, even though it looks like one step in code

Command

import socket

ip = socket.gethostbyname('www.python.org')          # one IPv4 address
infos = socket.getaddrinfo('www.python.org', 443)     # full list, IPv4 + IPv6

Key features

• HTTP is application-layer; it needs an already-open, reliable byte stream underneath -- in practice, a TCP connection
• HTTPS = HTTP + TLS: the TCP handshake completes first, then a separate TLS handshake negotiates encryption before any HTTP bytes are sent
• TLS operates below HTTP and above TCP -- it does not know or care about HTTP methods, headers, or status codes; it only encrypts whatever bytes the layer above hands it
• HTTP method/status/header semantics, HTTPS deployment, and application-level TLS/same-origin concerns are covered in full in Web and HTTP Fundamentals -- this concept is the transport-layer view only
• The default ports reflect the layering: HTTP defaults to port 80 (no TLS step), HTTPS defaults to port 443 (TLS handshake first)

Command

import ssl, socket

ctx = ssl.create_default_context()                          # sensible defaults: verify cert, check hostname
with socket.create_connection((host, 443)) as sock:          # TCP handshake first
    with ctx.wrap_socket(sock, server_hostname=host) as tls: # TLS handshake wraps the open TCP socket
        ...                                                  # only now is it safe to send HTTP bytes

Key features

• A FORWARD proxy sits in front of CLIENTS, hiding the client from the server; a REVERSE proxy sits in front of SERVERS, hiding the server from the client -- opposite sides of the connection
• nginx and HAProxy are common reverse proxies; a reverse proxy commonly also handles TLS termination, request buffering, and static file serving so the application server does not have to
• A load balancer distributes requests across multiple backend instances using a strategy: round robin (rotate through instances), least connections (send to the least busy), or IP hash (same client always reaches the same instance)
• A load balancer needs health checks to stop routing to a backend instance that has crashed or is failing -- otherwise it keeps sending traffic to a dead target
• Gunicorn/uWSGI serving a Python app are typically run BEHIND a reverse proxy (nginx), not exposed to the internet directly -- the proxy handles TLS, slow clients, and static files so the Python process only handles application logic

Command

# nginx reverse proxy + load balancer, conceptual config
upstream app_servers {
    server 10.0.0.1:8000;
    server 10.0.0.2:8000;
}
server {
    listen 443 ssl;
    location / {
        proxy_pass http://app_servers;   # nginx picks an instance and forwards the request
    }
}

Key features

• Opening a TCP connection costs a round trip (the handshake); adding TLS costs another. A pool amortizes that cost across many requests to the same host by keeping connections open and reusable
• This applies beyond HTTP -- database drivers (psycopg2's pool, SQLAlchemy's engine pool) hold open connections for the same reason, since reconnecting per query is far slower than reusing one
• A connection-level timeout limits how long to wait for the TCP handshake to complete; a separate read/response timeout limits how long to wait for data once connected -- conflating the two hides which stage actually failed
• No timeout at all means code can hang indefinitely on a server that accepts a connection but never responds -- a resource leak and a hung request under load, not a crash that shows up in a stack trace
• socket.settimeout(seconds) applies to a raw socket's blocking operations (connect, recv); it raises socket.timeout (an alias of TimeoutError) once the limit passes

Command

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.settimeout(5)             # 5 seconds for connect() AND subsequent recv() calls
s.connect((host, port))     # raises socket.timeout if the handshake takes too long

Key features

• A forward proxy sits in front of clients: the client is configured to send traffic through it, commonly for content filtering, caching, or hiding the client's real IP from the destination server
• NAT lets multiple devices with private IP addresses (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) share a single public IP -- the router rewrites the source address/port on outbound packets and reverses it on the matching reply
• NAT is why most home devices do not have their own public, internet-routable IP address, and why an unsolicited inbound connection to one specific device behind NAT generally cannot reach it without extra configuration (port forwarding)
• A proxy operates on complete requests (it can inspect/modify an HTTP request, cache a response); NAT operates on raw packets (it rewrites IP/port headers) and knows nothing about HTTP or any application protocol
• IPv6's much larger address space removes NAT's original scarcity motivation, but NAT persists widely for IPv4 and for the network-boundary/isolation properties it happens to also provide

Command

import httpx

# routing a Python HTTP client's traffic through a forward proxy
with httpx.Client(proxy='http://proxy.internal:8080') as client:
    response = client.get('https://example.com')

Key features

• A WebSocket connection starts as a normal HTTP request with an Upgrade: websocket header; the server responds 101 Switching Protocols, and from then on the same TCP connection carries the WebSocket framing protocol instead of HTTP
• Once upgraded, a WebSocket is full-duplex: server and client can each send messages independently, at any time, without waiting for a request/response cycle
• SSE is plain HTTP -- no upgrade or new protocol at all. The client opens a request expecting Content-Type: text/event-stream, and the server keeps the response open, writing one event at a time as data: ...\n\n lines
• SSE only flows server-to-client; the client cannot send data back over the same stream -- it would issue a separate, normal HTTP request for that
• Browsers auto-reconnect a dropped SSE connection using EventSource, resuming with a Last-Event-ID header; a dropped WebSocket requires the application to detect the close and manually reconnect

Command

# WebSocket server handler (e.g. with the third-party 'websockets' package)
async def handler(ws):
    async for message in ws:      # receive, full-duplex
        await ws.send(f'echo: {message}')

# SSE: a plain streaming HTTP response (e.g. with a WSGI/ASGI framework)
def sse_view():
    def event_stream():
        yield 'data: {"progress": 10}\n\n'
        yield 'data: {"progress": 42}\n\n'
    return Response(event_stream(), content_type='text/event-stream')