entry~2 min de lecturaActualizado 2026-06-30#orientation#fundamentals
Esta nota todavía no está traducida, así que se muestra la fuente en inglés.

Must Know

A handful of ideas that hold the rest of this atlas up.

The ideas

  • Long-lived connections are a different problem than many short requests. Atlas II's HTTP server answers a request and moves on; here, a connection stays open for the life of a session and needs to see every other open connection. Broadcast, presence, and rooms don't exist in a stateless-request world.
  • Suffer the framing problem before a standard hands you the solution. TCP is a byte stream with no message boundaries. Designing your own binary protocol first — and hitting its versioning and heartbeat problems yourself — is what makes RFC 6455's answers land as answers, not just syntax to copy.
  • A real standard is unforgiving on purpose. WebSocket's masking requirement, its three payload-length encodings, its close handshake — these aren't arbitrary. Implementing RFC 6455 by hand is where "I designed a protocol" turns into "I can read a spec and match it exactly."
  • Concurrency here means connections seeing each other, not just many things happening at once. The hard part isn't parallelism — it's a shared, mutable registry of live connections under real concurrent access, from the C10K problem's era to now.
  • The same protocol, two runtimes, is the point. The C client and the TypeScript client aren't a chore of building things twice — they're the experiment. What a high-level runtime gives you for free (framing, backpressure, parsing) is exactly what you had to write by hand in C.
  • Atlas I and II are prerequisites, not references you skim mid-project. If a socket, an epoll loop, or a thread pool feels unfamiliar here, that's a sign to go back, not push through.

Where they live

See also: Start Here · Full Index