Falsehoods programmers believe about TCP
Programmers are revisiting what guarantees TCP actually provides, pushing back against simplistic notions like “TCP packets” mapping cleanly to application messages or the protocol being fully reliable in all failure modes. Several comments unpack how TCP is really a byte-stream built on segments and IP packets, why “exactly-once” delivery is impossible in the face of dropped acknowledgements, and how higher-level protocols must add idempotency and retries. Many also criticize the popular “falsehoods programmers believe” list format used in the original post as imprecise or koan-like, arguing that without concrete explanations it risks confusing more than it teaches.
Ambiguity of “TCP packets” (Items 5 & 6)
- Many are confused by “There is a such thing as a TCP packet” and “There is no such thing as a TCP packet” being simultaneously labeled false.
- Several interpret this as a context issue:
- At the protocol level, TCP clearly has “segments” carried in IP packets / Ethernet frames.
- At the application level, TCP is a byte stream;
send/recvcalls do not map 1:1 to packets, and middleboxes can split/merge segments.
- Some see these lines as playful “koans” about leaky abstractions; others find them logically self‑contradictory and poorly explained.
TCP Abstractions, OSI, and Pedantry
- Multiple comments stress that networking concepts (packet, stream, reliability) are highly context‑dependent and that abstractions are leaky.
- There is debate over using “packet” generically vs. strictly distinguishing frames/packets/segments.
- The OSI model is criticized as misleading or “net negative” for understanding real‑world stacks, though some defend its limited pedagogical value.
Reliability, Two Generals, and “Exactly Once”
- Early items (1–4) are linked to the Two Generals’ Problem: if an ACK is lost, the sender can’t know if data was received.
- Commenters emphasize TCP offers “mostly reliable” delivery, not absolute guarantees; timeouts, drops, and broken paths are expected.
- Long sub‑thread on “exactly‑once delivery”:
- One side: you can only have at‑most‑once or at‑least‑once; exactly‑once delivery is impossible over unreliable channels.
- Other side: you can build an abstraction of exactly‑once processing over at‑least‑once using ids/idempotency; disagreement centers on what “delivery” means.
- This is flagged as subtle and often misunderstood in distributed systems.
Real‑world TCP behavior and performance
- Cable‑unplug examples: Linux often keeps connections alive briefly; Windows may reset them on link‑down. Trade‑off between robustness and fast failure.
- Suggestions to work around slow start and congestion: either many parallel TCP connections or tuning buffers and congestion control (e.g., BBR).
- Concern that many systems and rate limiters misunderstand TCP dynamics, leading to bufferbloat or broken behavior.
Critique of the “Falsehoods” List Format
- Many criticize this particular list as vague, contradictory, and “low‑level pedantry” without explanations.
- Others argue such lists are meant to provoke thought, serve as test‑case sources, or be humorous; but several wish for concrete examples and clarifications.