d7DetectabilityOperational debt — how invisible misuse is to your safety net
Closest to 'only careful code review or runtime testing' (d7). The detection_hints indicate tools like webpagetest, lighthouse, and chrome-devtools are needed, and automated detection is explicitly marked 'no'. The code_pattern notes high TTFB without distinguishing which phase is slow — this requires manual profiling and interpretation, not automated flagging.
e5EffortRemediation debt — work required to fix once spotted
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix describes understanding a multi-phase cycle and remediating common_mistakes such as enabling Keep-Alive, HTTP/2, DNS TTL tuning, and TLS session resumption — each is a separate configuration or infrastructure change. Together they span multiple systems (DNS, TLS config, server config), making this more than a one-line fix but not a full architectural rewrite.
b5BurdenStructural debt — long-term weight of choosing wrong
Closest to 'persistent productivity tax' (b5). The term applies to all web and API contexts, meaning every developer working on performance, latency, or infrastructure must understand these hidden phases. Misunderstanding imposes ongoing drag across multiple workstreams (CDN decisions, TLS config, DNS management, HTTP version upgrades) but does not single-handedly define the system's shape.
t7TrapCognitive debt — how counter-intuitive correct behaviour is
Closest to 'serious trap' (t7). The misconception field explicitly states developers believe 'HTTP requests are instant' — the obvious mental model ignores DNS, TCP, and TLS round trips entirely. This contradicts how developers reason about server-side latency (e.g., conflating TTFB with PHP processing time), a meaningful contradiction with a common analogous concept, warranting t7.
About DEBT scoring →
scored by claude-sonnet-4-6 · 2026-05-08 · reviewed by human
The complete lifecycle of an HTTP request — DNS resolution, TCP connection, TLS handshake, request transmission, server processing, and response delivery.
Explanation
Full cycle: (1) DNS resolution — browser checks cache, then recursive resolver, then authoritative nameserver; (2) TCP connection — SYN/SYN-ACK/ACK three-way handshake; (3) TLS handshake — certificate exchange, key agreement (adds 1-2 RTTs); (4) HTTP request sent — method, headers, body; (5) Server processing — nginx receives, forwards to PHP-FPM via FastCGI, PHP executes, returns response; (6) Response delivery — status, headers, body; (7) Connection reuse via Keep-Alive for subsequent requests. Total time: 50-500ms for a typical dynamic PHP page.
Common Misconception
✗ HTTP requests are instant — each request involves multiple network round trips (DNS + TCP + TLS) before a single byte of application code runs; these are the hidden latency costs optimised by CDN edge nodes.
Why It Matters
Understanding the full request cycle explains why a CDN reduces latency (eliminates DNS + TCP + TLS round trips to distant origin), why preconnect hints help, and where time is actually spent on each page load.
Common Mistakes
No HTTP Keep-Alive — establishes a new TCP connection per request.
No DNS TTL tuning — low TTL causes DNS resolution on every request.
Not using HTTP/2 — multiplexes multiple requests on a single connection.
TLS session resumption disabled — requires full TLS handshake on every connection.
Code Examples
✗ Vulnerable
// Every request pays full connection cost:
// User request → DNS (50ms) → TCP SYN (30ms) → TLS (60ms)
// → request (10ms) → PHP (100ms) → response (20ms)
// Total: 270ms before user sees content
// Connection: close header — no reuse:
header('Connection: close');
✓ Fixed
// Optimised request cycle:
// DNS: preconnect + long TTL (300s)
<link rel="preconnect" href="https://api.example.com">
// nginx: HTTP/2 + TLS session tickets + Keep-Alive:
listen 443 ssl http2;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
keepalive_timeout 65;
// CDN edge: user connects to nearby PoP
// → edge serves cached or proxies to origin once
// User sees: 30ms (cached) or 100ms (dynamic)
💬 Status codes are a genuine component of the HTTP response half of the request/response cycle, so contains fits as a part-of relation. Direction is correct (whole → part).
💬 HTTP/2 push is a server-initiated resource delivery mechanism that operates within the broader HTTP request/response cycle context. 'often_seen_in' is an appropriately weak verb capturing this contextual co-occurrence without overclaiming a hard dependency or build-upon relationship.
🧱FUNDAMENTALS— new to this? Start with the ground floor.
HTTPgeneralHTTP (Hypertext Transfer Protocol) is the set of rules that web browsers and servers use to send and receive web pages, images, and data over the internet.
HTTP is the foundation of all web communication. Whether you're building APIs, debugging slow pages, or securing user data, you're working with HTTP concepts daily.
💡 When debugging web issues, always check the Network tab in browser DevTools to see the actual HTTP requests and responses being exchanged.
ResponsegeneralA response is the data a server sends back after receiving a request, containing the information or result the client asked for.
Every web interaction depends on responses. Understanding their structure helps you debug why pages fail, build APIs correctly, and control exactly what users receive.
💡 Always set headers before any echo or HTML output—headers must come first.
