Falsehoods programmers believe about TCP

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/recv calls 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.