Networking

Think of it as

The roadmap draws the path once — browser, DNS, CDN or load balancer, nginx, gunicorn, Django, then PostgreSQL, Redis and object storage — and being able to walk it in both directions is most of what "knows networking" means for a backend engineer. Every hop on that path is an address and a port, and every hop can fail in its own way. Start with resolution, because it happens before anything else and is invisible in most application logs: DNS maps the name to an address, the answer is cached for its TTL at several layers (the resolver, the OS, sometimes the process), and a name that resolves on your laptop can fail inside a container that has a different resolver. "DNS failure" is a distinct failure class from "connection refused" for exactly this reason. Then the connection. TCP performs a handshake before any data moves, which is why a connect timeout is a separate number from a read timeout, and why connection reuse — keep-alive, connection pooling — is worth so much: you pay the handshake once instead of per request. TCP guarantees ordering and retransmits lost segments, so your application sees a byte stream rather than packets; UDP hands you individual datagrams that may be lost, duplicated or reordered, which suits DNS queries and metrics samples and does not suit anything you must not lose. A socket is the endpoint. A *listening* socket is bound to an address and port — `0.0.0.0:8000` means every interface, `127.0.0.1:8000` means loopback only, and that single choice is the difference between a service reachable from the internet and one reachable only from the same host. Bind gunicorn to loopback or, better, to a Unix domain socket, and let nginx be the only process listening publicly. Unix sockets are worth knowing as a distinct kind: they are files on disk, they skip the TCP stack entirely, and access is controlled by ordinary file permissions rather than by a firewall rule. Ports below 1024 need root to bind, which is why nginx starts as root and drops privileges while gunicorn never needs to. And the accepted-connection socket is not the listening socket: the four-tuple of source address, source port, destination address, destination port is what makes thousands of simultaneous connections to port 443 unambiguous.

Think of it as

Think of HTTPS as two independent things stacked: a transport that is encrypted and authenticated, and a protocol that is not. The transport does three jobs — it encrypts so the bytes are unreadable in transit, it verifies the server's certificate so you know which server you reached, and it detects tampering. It does not know what a status code is. Getting the boundary right matters because of where TLS ends. Terminating at the edge is normal and desirable: certificates live in one place, renewals happen in one place, and the CPU cost of the handshake is paid by a machine built for it. The consequence is that by the time a request reaches gunicorn it is ordinary HTTP, and Django cannot tell from the connection whether the user typed `https://`. Left alone, `request.is_secure()` returns `False` for every request, so secure-cookie logic and CSRF checks see a site that appears to be plain HTTP even though every user is on TLS. The fix is `SECURE_PROXY_SSL_HEADER`, and its documentation is unusually blunt about the condition: only set it "if you control your proxy or have some other guarantee that it sets/strips this header appropriately", and specifically the proxy must strip a client-supplied `X-Forwarded-Proto` "even when it contains a comma-separated list of protocols". The reason is direct — if a client can send that header and reach Django, the client decides whether their own request counts as secure. Underneath that sit the redirect and the pin. `SECURE_SSL_REDIRECT` turns a plain HTTP request into a redirect to HTTPS, which covers the user who typed the bare domain, and HSTS (`SECURE_HSTS_SECONDS`) tells the browser to refuse plain HTTP for this host for a period, which closes the gap the very first redirect leaves open. HSTS is worth respecting: it is cached by the browser and a long `max-age` set on a host you cannot serve over HTTPS is not something you can quickly undo. Finally, keep the two forms of "secure" separate in your head. TLS protects the channel; it says nothing about who is calling or what they may do. An API served over HTTPS with no authentication is fully encrypted and completely open.

Think of it as

The proxy in front of Django is doing work you would otherwise pay for in worker time, and the list is worth knowing because each item is a class of outage it prevents. It terminates TLS, so handshake CPU never touches your fleet. It serves static and media files from disk or object storage, so a worker is never occupied streaming a 40 MB PDF. It *buffers* — reading the whole request body from a slow client before opening anything upstream, and buffering the response back out — which is the property that protects synchronous workers: with a sync worker, a client on a 3G connection would otherwise hold a worker for the whole upload. It enforces limits your application should not have to: body size, request rate, and its own timeouts. The load balancer adds distribution and health. Requests go to the instances currently passing a check, which is what makes a rolling deploy possible; an instance that fails readiness is simply not sent traffic. The important operational rule is that timeouts must be *ordered* along the path, and this is where most 502/504 confusion comes from. The load balancer's idle timeout, nginx's `proxy_read_timeout`, gunicorn's `--timeout`, and your own outbound call timeouts form a chain, and each hop should allow slightly more than the hop beneath it. When gunicorn's timeout is longer than nginx's, nginx gives up first and returns 504 while the worker keeps going, so you burn capacity on a response nobody will read. When it is much shorter, the worker is killed mid-request and nginx reports 502 without the traceback that would have explained it. Connection pooling is the same idea applied downwards: opening a TCP connection costs a handshake, and TLS costs several, so long-lived connections are reused everywhere sensible — nginx keeps upstream keepalives, `requests.Session` reuses connections via urllib3, and Django keeps a database connection per worker for `CONN_MAX_AGE` seconds. The trap is that pools are per process, so "pool size 10" with 24 workers is up to 240 connections, and that arithmetic is what exhausts a database. Two smaller things complete the picture. A forward proxy is what an outbound call goes through in a locked-down network, configured by `HTTP_PROXY`/`HTTPS_PROXY` environment variables that most Python HTTP clients read automatically — worth knowing before you spend an afternoon on a timeout that is really an unset variable. And NAT explains why source IPs are not identities: many clients share one public address, so per-IP rate limits punish whole offices, and `X-Forwarded-For` is a list you must read from the right-hand side.

Think of it as

Start with the question that actually decides between them: does the client need to send? A chat room, a collaborative editor and a multiplayer board all have clients that speak, so they need WebSockets. A progress bar, a live dashboard, a notification bell and a "your export is ready" toast only ever listen, and for those SSE is less machinery for the same result. The difference in cost is not the protocol, it is everything around it. SSE is an ordinary GET whose response never ends, so it passes through proxies, corporate middleboxes and HTTP caches as normal traffic, and the browser reconnects on its own — MDN: "By default, if the connection between the client and server closes, the connection is restarted." It also carries resumption for free: the server can emit an `id` with each event, and the browser sends the last one back in `Last-Event-ID` when it reconnects, so you can replay what was missed. A WebSocket starts as an HTTP request with an `Upgrade` header and then stops being HTTP, which means proxies must be configured for it explicitly, and reconnection, backoff and message replay are all yours to write. In a Django deployment the shared constraint matters more than the difference: both hold a connection open for as long as the feature lasts, and a held connection occupies a worker. Under WSGI that is fatal — a synchronous worker serves one request at a time, so ten thousand listeners would mean ten thousand workers. Both therefore need ASGI, and an async server that can hold many idle connections cheaply on one process. WebSockets in Django additionally need the consumer machinery that Channels provides, plus a channel layer if a message must reach a connection held by a *different* worker, which it usually must. There is a third option worth naming, because it is often the right one: polling. A request every thirty seconds for a status that changes twice an hour costs almost nothing, needs no ASGI, no reconnection logic and no proxy configuration, and it is what most "real-time" features should start as. Move to SSE when the latency genuinely matters, and to WebSockets when the client has something to say.