HTTP

What is hard to understand about a CDN is not “it can cache files.” It is that it moves user access points, cache layers, and origin protection out to the network edge. As a result, the first-packet time for the same URL may differ a lot across regions, the origin may be healthy while some users still see old content, and when image or video traffic rises, the first thing to saturate is often not the CPU but the cross-region bandwidth and origin fetch path.

WebSocket is often described as “HTTP that can talk both ways” or “HTTP better suited for real-time scenarios”. That gets the direction right, but if you stop there, implementation, packet capture, and troubleshooting will go off track. WebSocket is not adding a push feature to HTTP. It keeps the browser and existing Web infrastructure path intact, then turns request/response, which is naturally half-duplex, into a persistent full-duplex channel.

What it really solves is not “how to let the server send something occasionally”. It is “how to keep one connection alive between browser and server where both sides can speak at any time, while still reusing the current HTTP / TCP / TLS deployment reality as much as possible.” That is why the important parts are not the JavaScript API, but the upgrade handshake, connection lifetime, frame boundaries, heartbeats, and middlebox compatibility.

When the same site becomes slower on a weak network, the problem is not always that the server is slow to compute. Sometimes time is being eaten by packet loss, retransmission, and head-of-line blocking in the transport layer. With HTTP/2, that becomes more visible: the application layer is already multiplexed, but the underlying transport is still TCP, so if one packet is lost, all the streams on that connection still wait together.

The lock icon in the browser address bar is not just saying “this connection is encrypted”. HTTPS has to handle identity verification, key negotiation, transport protection, and handshake latency, and it has to do that at Internet scale.

HTTPS is often broken into separate topics like certificates, cipher suites, HTTP/3, and QUIC, and then only a pile of terms is left. Once the main line is pulled back together, the structure becomes clear: HTTPS is essentially HTTP over TLS. What matters is not that HTTP changed, but that HTTP now runs over a secure channel with authentication and key negotiation.

System DNS may be good enough most of the time, but mobile and large-scale businesses still keep pulling name resolution back into the application. They are not reinventing a slower wheel. They are taking the resolution control point back.

Once a business starts caring about carrier-path interference, local access steering, canary routing, cross-network consistency, and resolution observability, the system resolver’s “it can return an address” answer is no longer always enough. HTTPDNS appears because many applications do not really want one standard DNS query. They want an address decision they can control themselves.

HTTP is so common that it is easy to reduce it to “the client sends a request and the server returns a response.” But as soon as you work on caching, proxies, authentication, cross-origin access, long connections, packet capture, or performance debugging, the hard part turns out not to be the start line and headers. It is the fact that HTTP must serve browsers, origins, intermediaries, caches, and later Web applications all at once.

Many network behaviors look like “the client is talking directly to the server”, but there is often already a proxy in the middle. Browsers may go through a corporate proxy to reach the Internet. Mobile requests may hit a CDN before reaching the origin. Services may sit behind Nginx or an API gateway. When troubleshooting, the peer address, TLS certificate, source IP, and connection count you see may already be altered.