Set up the observation
This workbook examines decisions and observations. It contains no latency measurements or captured traffic; addresses and exchanges are teaching examples.
A browser does not obtain a web page with one indivisible action. It interprets a URL, finds a destination, establishes a suitable connection, checks the server’s identity, requests a representation and interprets the response. Some steps can be reused from an earlier visit. Others depend on the selected HTTP version.
The useful mental model is a chain of separate questions. Which name? Which address? Which transport? Which identity? Which resource? A successful answer at one stage is evidence about that stage, not proof that every later stage will succeed.
Name & address
DNS associates domain names with records. An A record holds an IPv4 address; AAAA holds an IPv6 address; CNAME aliases one name to another. A recursive resolver normally answers a client using cached data or by consulting other DNS servers as needed.
A successful lookup does not show that an address is reachable, that a service is listening, or that a certificate is valid. One name may resolve to several addresses. Different networks can receive different answers, and a browser may attempt IPv6 and IPv4 according to its connection strategy.
A cache lifetime expressed in seconds. It controls how long a record may remain reusable in a DNS cache; it is not a guarantee that every device will notice a change at the exact same instant.
When investigating a change, distinguish the authoritative record from an answer already held by a recursive or local cache. “The DNS is correct” is too broad unless it identifies which answer was observed, where and when.
Transport choice
TCP provides an ordered byte stream with retransmission and congestion control. Applications receive bytes, not the original network packet boundaries. A connection can be established successfully and still later become slow or fail. Opening a port and transferring a large response exercise different parts of the path.
HTTP/1.1 and HTTP/2 commonly run over TCP; HTTPS adds TLS. HTTP/3 instead runs over QUIC, which is carried over UDP and integrates TLS 1.3 for security. Calling HTTP/3 “unreliable UDP” misses the transport implemented by QUIC: it provides reliable streams and congestion control above UDP.
Independent QUIC streams avoid the same cross-stream transport head-of-line blocking associated with a single TCP connection. They still share network capacity and congestion state, so packet loss and congestion do not stop mattering. Protocol names are not performance guarantees.
Server verification
TLS protects data in transit and, in ordinary HTTPS, authenticates the server through a certificate chain and a name check. The client needs to establish that the certificate is valid for the requested hostname, valid in time and trusted under its verification rules. An encrypted connection to the wrong party is not the intended result.
A certificate problem can come from the wrong hostname, expiry, a missing intermediate certificate, an untrusted issuer or an incorrect device clock. Those are different causes. Disabling verification conceals the symptom while removing a central protection.
TLS does not certify that a page’s editorial claims are true, or that the operator will handle submitted data responsibly. It authenticates the connection endpoint under the certificate trust model. Content trust and transport security are related but distinct questions.
Request & response
HTTP defines request methods, response statuses, headers and representation semantics. A browser can receive a perfectly valid HTTP response that reports failure. Conversely, a connection failure can occur before any HTTP status is available. “It returned an error” should distinguish these two situations.
| Part | Question it answers |
|---|---|
| Status | How did the server handle this request? |
| Content-Type | What media type describes the representation? |
| Cache-Control | Under what conditions may a cache store or reuse it? |
| Body | What representation, if any, was transferred? |
200 alone does not establish that the expected document arrived. A misrouted request may receive an unrelated HTML page with a successful status. Check the intended content as well as the status. A redirect is also a response; following it introduces another destination and another opportunity for failure.
Reading again
A cache can reuse a fresh response without asking the origin again. Once a stored response becomes stale, it may need validation or replacement, depending on its directives and the request. Validation asks whether the stored representation is still usable; it does not necessarily download the whole document.
no-cache does not mean “never store”. It requires successful validation before reuse. no-store tells caches not to store the applicable request or response. These directives solve different problems. Neither is a substitute for access control or a reason to put confidential data in a public document.
Validators such as ETag support conditional requests. A 304 response can allow reuse of the stored representation without transferring its body again. A reader may therefore see current content even when the network log does not show another complete document download.
Failure analysis
Begin with one reproducible observation: the exact hostname, the time, the network and the visible failure. Keep secrets out of notes. Compare the same request on the same device before introducing multiple simultaneous changes. Otherwise, a successful result may leave the cause as unclear as the original failure.
- Resolution. Was an address obtained? Which address family was used?
- Connection. Was the transport established, or did it time out or refuse?
- Identity. Did certificate and hostname verification succeed?
- Response. Was there an HTTP status and the expected media type?
- Representation. Was the intended content complete and usable?
A small page loading successfully is evidence for that request. It does not establish large-transfer throughput, uninterrupted long-lived connections or every other application path. Write conclusions at the same scale as the observation. That habit produces fewer dramatic theories and more useful next steps.
Failure worksheet
| Observation | Inspect next | Not established yet |
|---|---|---|
| Name resolution failed | Requested name, resolver response and local network. | That the web server is powered off. |
| Address available, connection absent | Selected address, transport and port reachability. | That the certificate is incorrect. |
| TLS verification failed | Name, clock, validity interval and chain. | That disabling verification is the repair. |
| HTTP 200, wrong document | Path, Host, redirects and request handler. | That the intended resource works. |
| Small response works, large one stops | Loss, limits, timeouts and characteristics of the larger request. | A single exact cause from this symptom alone. |