TCP/IP Model
debt(d9/e5/b5/t7)
Closest to 'silent in production until users hit it' (d9). The detection_hints confirm 'automated: no' — there is no tool that catches misunderstandings of the TCP/IP model. Symptoms like excess latency from missing keep-alive or TCP handshake overhead only surface under real traffic conditions, often misattributed to other causes.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix points to TCP connection reuse via keep-alive, but fixing misuse patterns (e.g., new TCP per HTTP request, not accounting for TLS overhead, or wrongly choosing TCP vs UDP) requires touching connection configuration, HTTP client setup, and potentially architectural decisions about HTTP/3 vs HTTP/1.1 — spanning multiple files or components.
Closest to 'persistent productivity tax' (b5). The applies_to covers both web and cli contexts broadly. Misunderstanding the model creates a recurring cognitive tax: developers who don't understand the stack will repeatedly make suboptimal decisions about connection pooling, latency, protocol choice (HTTP/3 vs HTTP/1.1), and debugging — affecting multiple work streams over time.
Closest to 'serious trap (contradicts how a similar concept works elsewhere)' (t7). The misconception field explicitly states the trap: developers learn the OSI 7-layer model (commonly taught in education) and assume it maps directly to how the internet works, but the practical TCP/IP 4-layer model is what's actually implemented. This is compounded by common_mistakes like assuming HTTP requires TCP (HTTP/3 uses QUIC/UDP), which directly contradicts expectations from the 'reliable HTTP over TCP' mental model.
Also Known As
TL;DR
Explanation
The TCP/IP model layers from bottom to top: Link (Ethernet, WiFi — physical transmission), Internet (IP — addressing and routing between networks), Transport (TCP/UDP — end-to-end delivery), Application (HTTP, DNS, SMTP — what applications speak). Each layer adds a header encapsulating the layer above. Understanding TCP/IP explains why HTTP needs TCP (reliable), why UDP suits video (fast, loss-tolerant), and why IP routing works across heterogeneous networks.
Diagram
flowchart TD
subgraph Application
HTTP2[HTTP] & DNS2[DNS] & SMTP2[SMTP]
end
subgraph Transport
TCP2[TCP] & UDP2[UDP]
end
subgraph Internet
IP2[IP Routing]
end
subgraph Link
ETH2[Ethernet / WiFi]
end
Application -->|Data| Transport -->|Segments| Internet -->|Packets| Link -->|Frames| WIRE[Physical Medium]
style Application fill:#1f6feb,color:#fff
style Transport fill:#238636,color:#fff
style Internet fill:#d29922,color:#fff
style Link fill:#6e40c9,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Confusing TCP (reliable, ordered, connection-oriented) with UDP (unreliable, unordered, connectionless).
- Not understanding that IP addresses are Layer 3 (Internet) and MAC addresses are Layer 2 (Link) — they serve different scopes.
- Assuming HTTP requires TCP — HTTP/3 uses QUIC over UDP for improved performance.
- Not accounting for TCP connection overhead — each new TCP connection requires a 3-way handshake adding round-trip latency.
Code Examples
# Ignoring TCP connection cost — new connection per request:
# PHP script making 100 HTTP calls with new connections each time:
for ($i = 0; $i < 100; $i++) {
$ch = curl_init($url);
curl_exec($ch);
curl_close($ch); // Connection closed — 100 TCP handshakes
}# Reuse connections with persistent handles:
$mh = curl_multi_init();
$handles = [];
for ($i = 0; $i < 100; $i++) {
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_2_0); // HTTP/2 multiplexing
$handles[] = $ch;
curl_multi_add_handle($mh, $ch);
}
// HTTP/2 multiplexes all 100 requests over one TCP connection