Networking
& Web.

A computer network splits the work into layers. Each layer handles one job. When an app creates a request, the data travels down the stack. Each layer prepends its own header to the data. This mechanism is called encapsulation.

The transport layer adds port numbers. The network layer adds the IP address for routing. The link layer adds the next-hop MAC address. The receiver strips off the headers in reverse order to recover the original data.

The transport layer has two protocols. TCP is the reliable one. Before sending, both sides perform a three-way handshake to establish a connection.

TCP numbers every byte. The receiver acknowledges each segment. Any lost segment is retransmitted. Data arrives complete and in order. The cost is higher latency and more control overhead. Web, APIs, payments and file transfers all run on TCP, because they cannot tolerate data loss.

The second protocol is UDP. UDP sends data immediately. It sets up no connection, sends no acknowledgements, and never retransmits. UDP is fast and has very low latency. The cost is that data may be lost or arrive out of order.

Choose UDP when late data is useless. Video calls, real-time games and DNS all use UDP. A late video frame has no value, so dropping it beats waiting for a resend. HTTP/3 also moved to UDP for this reason.

HTTP is a request–response protocol. The client sends a request, the server returns a response. The difference between versions lies in how they handle many requests at once on one connection.

HTTP/1.1 processes requests sequentially on each connection. A later request must wait for the earlier response. One slow response blocks the queue behind it. This is called head-of-line blocking. Browsers mitigate this by opening up to 6 parallel connections per domain.

HTTP/2 uses multiplexing. Many streams run concurrently on one connection, with header compression. This removes head-of-line blocking at the HTTP layer. At the TCP layer the problem persists: TCP guarantees order for the whole connection, so one lost TCP packet stalls every stream.

HTTP/3 runs on QUIC, a protocol built on UDP. Each QUIC stream is independent. A lost packet on one stream does not affect the others. QUIC also folds encryption into connection setup, cutting handshake round-trips. HTTP/3 runs smoother on flaky mobile networks.

Classic HTTP lets the client ask first. When the server must push data on its own, there are three levels. Polling: the client asks again periodically, creating many empty requests. Long-polling: the server holds the request until new data appears. SSE: a one-way channel where the server pushes to the client, persistent, good for notifications and feeds.

WebSocket opens a two-way channel that stays open between client and server. It suits chat and real-time collaboration. Each client holds a persistent connection, so WebSocket is harder to load-balance and scale. The rule: use SSE for one-way needs, use WebSocket when two-way is mandatory.

HTTPS is HTTP running inside the TLS encryption tunnel. Before sending data, both sides perform a handshake to build the tunnel. The handshake does two things. The first is authenticating the server.

The server presents a certificate containing its public key. The certificate is signed by a Certificate Authority. The browser checks the CA signature to confirm the public key belongs to that exact server. An attacker cannot forge a certificate with a valid CA signature.

The handshake's second job is to agree on a secret session key. Both sides use public-key cryptography to derive this key together. All later data is encrypted with the session key.

The handshake costs round-trips. Each round-trip adds latency. When the server is far away, this cost is large. TLS 1.2 needs two round-trips. TLS 1.3 needs one, and supports 0-RTT when resuming an old session. Enabling TLS 1.3 and session resumption is a concrete performance decision.

There are two kinds of encryption. Symmetric encryption uses one shared key for both encryption and decryption. It is fast and lightweight.

Symmetric encryption has a core weakness. Both sides must hold the same key before they talk. Sending the key over the network lets an eavesdropper capture it. Once they have the key, they decrypt everything. This is the key distribution problem. Symmetric encryption alone is not enough to secure the Internet.

Asymmetric encryption uses a key pair: a public public key and a private private key. What the public key locks, only the matching private key unlocks. So no secret key needs to cross the network. Asymmetric encryption is hundreds to thousands of times slower than symmetric.

TLS combines both in a hybrid model. Asymmetric does one job: securely exchanging a symmetric session key. After that, all data is encrypted with symmetric. This model solves the key distribution problem. It also keeps the speed. Almost every modern security protocol is built on this division of roles.

HTTP has several verbs. Two properties decide how you use them. Safe means the verb does not change server state. It only reads. GET is a safe verb.

Idempotent means calling once or many times gives the same server result. GET, PUT and DELETE are idempotent. PUT replaces the whole resource, so resending the same body creates nothing new. DELETE on an already-deleted item still leaves it deleted. POST creates a new resource, so it is not idempotent. PATCH does a partial update and is usually not idempotent either.

Idempotency matters because networks are unreliable. A client often retries when it gets no response. With an idempotent verb, a retry is harmless. With POST, one retry can create two orders and charge twice.

The industry fix is an idempotency key. The client generates a unique key per operation and puts it in a header. The server stores the result keyed by that value. A request with a seen key gets the stored result instead of running again. Stripe and most payment gateways rely on this exact mechanism.

Status codes are grouped by their first digit. 2xx is success. 3xx is redirection. 4xx is a client error. 5xx is a server error. Knowing the classes covers most cases.

Two confusing pairs come up often. 401 means not authenticated; please log in. 403 means we know who you are and you lack permission. 301 is a permanent redirect; the browser caches it and search engines move the link. 302 is a temporary redirect.

When production returns server errors, three 5xx codes point to the failing layer. 502 Bad Gateway means the reverse proxy got a bad response from a service behind it. The upstream crashed or returned garbage.

503 Service Unavailable means the service is temporarily down, from overload or maintenance. 504 Gateway Timeout means the proxy waited too long for the upstream. Reading these three correctly narrows down the cause fast: 502 points to app errors, 503 to capacity, 504 to latency.

Headers carry many of the web's hidden mechanics. The most valuable part is caching, and there are two strategies. Cache-Control: max-age tells the browser and CDN to keep a copy for N seconds without asking again. This is the fastest path. The cost is serving stale data during those N seconds.

ETag is a content fingerprint. The client sends If-None-Match. If the content is unchanged, the server returns 304 Not Modified with an empty body. This is always accurate. The cost is one round-trip to ask.

Static assets use a cache-busting technique. Put a content hash in the file name and set a very long max-age with immutable. When the content changes, the file name changes, so the browser fetches the new version without asking.

CORS explains why a frontend on one domain calling an API on another gets blocked. The browser blocks it by default. The server must return the Access-Control-Allow-Origin header to allow it. This is a browser safeguard, not a backend bug.

URI is the umbrella term. It is any string that identifies a resource. URL and URN are two kinds of URI.

URL locates a resource by its address and access method: scheme, host and path. URN identifies by a persistent name, independent of location. A book's ISBN is a URN. In practice we meet URLs almost everywhere.

A URL has: the scheme (https), host and port, path, query after the question mark, and fragment after the hash. The path identifies a resource hierarchically. The query is for filtering, sorting and pagination.

One detail that gets asked: the fragment is never sent to the server. The browser keeps it on the client. This property underpins client-side routing in early single-page apps.

The web remembers nothing between requests. We need a way for the server to know who you are across calls. The first way is a session. After login, the server creates a state record and stores it on its side. It sends the client a session-id kept in a cookie.

On each later request, the client presents the session-id. The server looks up the identity. This is the stateful model. Deleting the record logs the user out instantly. The payload sent is very small.

The second way is a token. The server signs a JWT that already holds the user info and sends it to the client. On each request the client carries the token. The server just verifies the signature, with no store to query. This is the stateless model. It scales beautifully for microservices, since each service verifies on its own.

JWT has one weakness. A signed token stays valid until it expires, even after the user logs out. Early revocation is hard. The practical fix is a short TTL, plus a refresh token and a small denylist.

Both are intermediaries. They differ in whose side they sit on. A forward proxy sits in front of the client and acts on behalf of the client. Every client request goes through it before reaching the Internet. It is used to anonymize users, filter content and bypass blocks. The far server sees only the proxy.

A reverse proxy sits in front of the server and acts on behalf of the server. Every request from the Internet passes through it before reaching the backend. The client sees only the reverse proxy, not the real machines behind it.

The reverse proxy is a familiar figure in system design because it carries heavy work. It load-balances across backends. It terminates TLS in one place so backends skip encryption. It caches static content. It blocks attacks with rate limiting and a WAF.

The cost is one extra hop and a component that must be highly available. In return, every cross-cutting concern is gathered in one place. Nginx, Envoy and Cloudflare are all reverse proxies.

An API Gateway is an upgraded reverse proxy placed in front of a whole microservices system. Instead of letting each service redo the same work, the gateway centralizes it at one entry point.

The gateway handles authentication and authorization, rate limiting, routing to the right service, aggregating several calls into one, logging and metrics, and protocol translation. The services behind it stay lean and focus on business logic. The client only needs one address.

Centralizing brings two risks. First, the gateway easily becomes a single point of failure and a performance bottleneck. All traffic passes through it, so it must be highly available and scaled carefully.

Second, there is a temptation to push business logic into the gateway. That turns it into a giant, hard-to-maintain block. The healthy rule is to keep the gateway thin. It only handles cross-cutting concerns. Business logic stays inside the services.

When users are spread worldwide, sending them to the right endpoint is an architecture decision. It usually happens at the DNS layer, such as Route 53, before the request reaches a server.

There are several policies. Latency-based sends a user to the fastest region. Geolocation routes by geography, important for data residency compliance. Weighted splits a percentage of traffic. Failover switches to a backup region when the primary goes down.

Weighted routing is the tool for a canary deploy. Push 5% of users to the new version, watch for errors, then ramp up. It also runs A/B tests.

A classic question is designing a system for global users. A strong answer composes several pieces: latency-based routing sends users to the nearest region, a CDN serves static content at the network edge, a multi-region architecture tolerates failure, and weighted routing rolls out new versions safely.