Networking & Protocols
Integrated handshake and 1-RTT
Crux QUIC fuses the transport and TLS layers into one exchange — the client sends TLS ClientHello in the first packet and application data flows after just one round trip.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at middle altitude — in the skyTCP finishes its handshake. Then TLS starts its own. These are separate protocols with separate round trips. Every new connection pays that double toll. QUIC refuses to accept that — it runs both handshakes in the same packet exchange.
The merged handshake
QUIC eliminates the separate transport handshake layer. Instead of TCP SYN/SYN-ACK (1 RTT) followed by TLS ClientHello/ServerHello (another RTT), QUIC carries the TLS handshake inside CRYPTO frames that travel in QUIC packets.
The sequence:
- Client sends an Initial packet containing a CRYPTO frame with the TLS ClientHello.
- Server responds with its own Initial packet containing a CRYPTO frame with ServerHello + EncryptedExtensions + Certificate + CertificateVerify — all in one packet burst.
- Client sends a Handshake packet with a CRYPTO frame containing Finished.
- Both sides transition to 1-RTT state. The client can send stream data immediately after step 1 completes.
Result: 1 RTT from client start to receiving server’s response, vs TCP+TLS’s 2 RTT.
QUIC handshake packet sequence
Client→ServerInitial [CRYPTO: ClientHello] + Padding
Client←ServerInitial [CRYPTO: ServerHello + EE + Cert + CertVerify]
Client←ServerHandshake [CRYPTO: Finished]
Client→ServerHandshake [CRYPTO: Finished] + 1-RTT [STREAM data]
Total: 1 RTT before client can send stream data. TCP+TLS = 2 RTT.
Four encryption levels
QUIC defines four distinct encryption levels, each with its own key:
- Initial — derived deterministically from the destination Connection ID. Both sides can compute these keys before exchanging any material, so the Initial packet is encryptable immediately.
- 0-RTT — derived from a session ticket cached from a previous connection. Allows the client to send application data in the ClientHello without waiting for the server’s response.
- Handshake — derived from the shared secrets after the ClientHello-ServerHello exchange. Used for Finished messages.
- 1-RTT — the final post-handshake keys. All subsequent stream data uses these.
Three packet-number spaces
The four encryption levels map to three packet-number spaces:
- Initial/Handshake — each has its own packet-number sequence (0, 1, 2, …).
- Application Data — 0-RTT and 1-RTT share one space.
Separation is critical: loss detection is independent per space. A lost Initial packet triggers PTO in the Initial space only — it does not shrink the congestion window for 1-RTT data.
Quiz
Completed
Why does QUIC have separate packet-number spaces for Initial/Handshake vs. 1-RTT?
Heads-up Wraparound is a non-issue with 62-bit packet numbers. Separation is about loss detection.
Heads-up Both can arrive out of order; separate packet-number spaces are about encryption keys and loss logic.
Heads-up UDP does not reorder; out-of-order delivery is an artifact of the network path, not UDP vs. TCP.
Trace it
1/4 Trace a QUIC connection from client initiation to the first stream data.
1
Step 1 of 4
Client sends Initial packet with ClientHello in CRYPTO frame. What encryption key does it use?
The keys derived from the QUIC Initial Secrets, which are deterministic from the destination connection ID. Both sides can derive these keys without exchanging material, so the Initial packet is encryptable by both sides immediately.
2
Locked
Server receives Initial packet. What does it respond with?
Server sends Initial packet containing CRYPTO frames with ServerHello + EncryptedExtensions + Certificate + CertificateVerify, encrypted with the Handshake keys (derived from the shared secrets now that it has the ClientHello).
3
Locked
Client receives server Initial. What state is the client in?
The client now has the server's keying material and can derive the 1-RTT keys. The handshake is complete from the client's perspective; it can send stream data in 1-RTT packets.
4
Locked
Client sends first stream data in a 1-RTT packet. What is the RTT elapsed since the Initial?
Exactly 1 RTT from client Initial to server Initial receipt, no additional wait. Compare TCP+TLS which is 1 RTT (TCP 3-way handshake) + 1 RTT (TLS) = 2 RTT.
✓ Traced.
Order the steps
Completed
Order the packet types in a QUIC handshake from initial to completion:
- 1 Client sends Initial packet with ClientHello
- 2 Server sends Initial packet with ServerHello + EncryptedExtensions + Certificate + CertificateVerify
- 3 Server sends Handshake packet with Finished
- 4 Client sends Handshake packet with Finished
- 5 Both sides transition to 1-RTT state and can send Short Header packets with stream data
Why this works
QUIC’s Initial packet uses deterministic keys derived from the Connection ID — an apparently paradoxical choice. Why encrypt if both sides can compute the key? The goal is not secrecy at this stage but integrity: encrypting the Initial prevents passive observers from trivially tampering with the ClientHello. The Handshake and 1-RTT keys, derived from DH key exchange material, provide actual confidentiality.
- QUIC new connection
- 1 RTT before first stream byte
- TCP + TLS 1.3 new connection
- 2 RTT before first stream byte
- QUIC 0-RTT resumption
- 0 RTT (data in ClientHello)
- Saving on 100 ms link
- 100 ms per new connection
- Saving on 150 ms link (Asia-US)
- 150 ms per new connection
- 01Why does QUIC's 1-RTT handshake save latency compared to TCP+TLS, and what do the numbers look like on intercontinental links?
- 02What are the four QUIC encryption levels and what is each used for?
- 03Why are packet-number spaces separated per encryption level?
Recap
QUIC’s handshake merges what TCP and TLS kept separate: a CRYPTO frame inside a QUIC Initial packet carries the TLS ClientHello so both transport and TLS complete in one round trip instead of two. The server responds with its full Certificate chain in the same burst, and the client can send stream data immediately after. Four encryption levels (Initial, 0-RTT, Handshake, 1-RTT) map to three packet-number spaces so that loss detection in each phase does not interfere with the others. On a 100 ms link this saves 100 ms per new connection — 150 ms on cross-Pacific paths. 0-RTT resumption goes further: a cached session ticket lets the client attach application data to the ClientHello itself, reaching zero round trips at the cost of replay vulnerability for non-idempotent requests.
Connected lessons
deepens into
appears again in162
- The journey of a request: seven stops from socket to responsejunior
- Accept and parse: from kernel queue to a typed requestmiddle
- Routing and middleware: choosing what runs, and in what ordermiddle
- Handler and response: from business logic to bytes on the wiremiddle
- Streaming and backpressure: when the client reads slower than you writesenior
- Timeouts and tail latency: budgets, deadlines, and the fan-out trapsenior
- Middleware and DI: the two patterns that shape every backendjunior
- Writing middleware: signatures, next(), and the three framework modelsmiddle
- Inversion of control: how dependencies reach a classmiddle
- DI scopes and lifecycles: singleton, request, transientmiddle
- DI as a testing seam: fakes, mocks, and the boundary that matterssenior
- DI containers in production: resolution graphs, circular deps, and when not tosenior
- Blocking vs non-blocking I/O: two ways to waitjunior
- The event loop: one thread, ordered phasesmiddle
- What blocks the loop: CPU work and sync callsmiddle
- Offloading CPU work: worker threads and the libuv poolmiddle
- Backpressure and bounded concurrencysenior
- Throughput under load: tail latency and saturationsenior
- Why pool: the cost of creating a connectionjunior
- Pool sizing: why bigger is not fastermiddle
- Acquisition and timeouts: the wait queue is the real latency dialmiddle
- Retry strategies: backoff, jitter, and thundering herdmiddle
- Observability, production failures, and global-scale designsenior
- Tasks, microtasks, and scheduler.yield()middle
- Timer accuracy, throttling, and idle workmiddle
- Node.js event loop: phases, nextTick, and loop lagsenior
- Rendering strategies: SSG, SSR, ISR, streaming, and hydrationjunior
- SSG, SSR, ISR, streaming, and RSC — how each worksmiddle
- Hydration cost: selective, progressive, islands, resumabilitymiddle
- Core Web Vitals: what LCP, INP, and CLS measurejunior
- LCP: four phases, one dominant costmiddle
- INP: input delay, processing, presentationmiddle
- Lab vs field: why the two disagree and how to use eachmiddle
- Metric tradeoffs, RUM attribution, and the CI+field loopsenior
- The full picture: URL to LCP to INP as a relay racejunior
- Eight layers traced: from the service worker to the second navigationmiddle
- Five canonical breaks: where production reliably diessenior
- The three-track method: reading traces and building a monitored systemsenior
- What an index is and how it speeds up queriesjunior
- The leading-column rule and composite index designmiddle
- Partial, expression, and covering indexesmiddle
- Index types: GIN, GiST, BRIN, Hash, Bloom, and HOT updatesmiddle
- Index-only scans, the Visibility Map, and INCLUDEsenior
- Production failure modes and the index audit playbooksenior
- Index design exercise: full-text search strategysenior
- EXPLAIN and execution plans: what the planner decides and whyjunior
- Scan types: Seq, Index, Bitmap, Index-Onlymiddle
- Join algorithms and the row-estimate cascademiddle
- pg_statistic, ANALYZE, and production observabilitymiddle
- Extended statistics: fixing correlated-column estimate failuressenior
- Plan cache, cost-constant tuning, and planner internalssenior
- Production failure modes and plan stabilitysenior
- Connection pools: amortising the cost of a Postgres backendjunior
- PgBouncer session, transaction, and statement modesmiddle
- Pool sizing: the (cores × 2) + spindles formula and the two-layer stackmiddle
- Pool exhaustion and idle-in-transaction: the 3 AM failure modemiddle
- Migrating to transaction mode: rollout playbook and PgBouncer 1.21 prepared statementsmiddle
- The Postgres process model and why raising max_connections degrades throughputsenior
- Pooler landscape 2026, serverless connection storms, and the full failure-mode taxonomysenior
- ADD COLUMN: instant in PG 11+ vs rewrite in older Postgresjunior
- The lock-queue failure mode: why instant DDL can freeze the databasemiddle
- Safe DDL patterns: NOT VALID, CONCURRENTLY, and unsafe-op fixesmiddle
- Migration failure taxonomy and production disciplinesenior
- Shard-key selection: hash, range, list, and directory strategiesmiddle
- Co-location and Citus: the invariant that makes sharding usablemiddle
- The hot-shard failure mode: detection, isolation, and durable policymiddle
- Online resharding, 2PC, and the operational cost of shardingsenior
- The seven acts: from CREATE TABLE to Citusjunior
- Acts 1–3 in depth: schema, indexes, and planner statisticsmiddle
- Acts 4–6 in depth: MVCC bloat, connection pooling, and safe migrationsmiddle
- Act 7 in depth: sharding, co-location, and the seven-tier tradeoff cascademiddle
- Observability, anti-patterns, and production triagesenior
- What the three signals are: logs, metrics, and tracesjunior
- Metrics and cardinality: the cost model of a time-series databasemiddle
- Logs and volume: the cost model of structured loggingmiddle
- Traces and sampling: the cost model of distributed tracingmiddle
- Join keys and exemplars: making the three signals composemiddle
- Observability 2.0: wide events and the cost shiftsenior
- Failure modes and engineering practice: cardinality budgets, PII, and samplingsenior
- Why structured logs exist: the diary vs the spreadsheetjunior
- The production log schema: fields every line must carrymiddle
- Log levels and alert routingmiddle
- Sampling strategies and log costmiddle
- PII redaction and log injectionsenior
- Trace context propagation in logssenior
- OTel Logs Data Model and audit logs as a subsystemsenior
- OTel signals, Semantic Conventions, and the OTLP wire formatmiddle
- Auto-instrumentation and manual spans: the 80/20 of OTelmiddle
- The OTel Collector: receivers, processors, exporters, and deployment patternsmiddle
- Sampling strategies: head, tail, and parent-basedmiddle
- Vendor neutrality, eBPF instrumentation, the Operator, and browser/serverless OTelsenior
- Operating the OTel Collector: reliability, version skew, failure modes, and governancesenior
- RED and USE: two checklists, one triage disciplinejunior
- Instrumenting RED in Prometheus: counters, histograms, and cardinality disciplinemiddle
- USE on Linux: CPU, memory, disk, network, and PSImiddle
- Golden signals, dashboard layout, and service mesh auto-REDmiddle
- Cardinality as a cost driver: labels, PII, exemplars, and samplingmiddle
- Native histograms, SLO tie-in, and production failure patternsmiddle
- Choosing SLIs and SLO targets: ratios, not feelingsmiddle
- Multi-window multi-burn-rate alerting: why AND beats ORmiddle
- Error budget policy, latency SLOs, and composite journeysmiddle
- Iceberg SLIs, composite SLO math, and SLA vs SLOsenior
- Flame graphs: reading the picture that shows where time goesjunior
- Sampling vs instrumentation profiling: why 99 Hz wins in productionmiddle
- Profile types: CPU, memory, off-CPU, mutex — which one to reach formiddle
- Continuous profiling: always-on flame graphs with eBPF and trace-id correlationmiddle
- How flame graphs are built from samples, and the production workflows that use themmiddle
- Linux perf, eBPF internals, PGO, and the limits of samplingsenior
- Profiling in production: security, war stories, OTel profiles, and the infrastructure designsenior
- The debugging funnel: SLO → RED → trace → profilejunior
- OTel architecture: one SDK, four signals, one wire formatmiddle
- Cost discipline: keeping observability under 5% of infra spendmiddle
- Scale, security, and the ROI of observable systemssenior
- Why profile first: measure where time actually goesjunior
- Amdahl''''s law and self-time: the ceiling on every speedup you can shipmiddle
- The measurement loop: microbench, macrobench, prod profile, observer effectmiddle
- Reading flame graphs: shapes, per-language profilers, and the 60-second scanmiddle
- Statistical baselines: why one run is not a measurementmiddle
- Profiler history and microbenchmark pitfalls: Knuth to GWPsenior
- Hardware counters, cold-start profiles, and profile securitysenior
- Continuous profiling at scale: costs, CI gates, trace correlation, and anti-patternssenior
- What makes a hot path: symptom vs causejunior
- Five shapes of hotspot: CPU, alloc, cache, lock, syscallmiddle
- Reading parent and child chains: where to apply the fixmiddle
- JIT deopt, the fix-and-verify loop, and PR-time profilingmiddle
- Hardware counters and Intel TMA: sub-category diagnosissenior
- False sharing and native-bridge hot pathssenior
- Hot paths in production: security, tail latency, and tooling lineagesenior
- Memory hierarchy: why the same O(N) loop can be 17x slowerjunior
- Row-major vs column-major: access order and the 9x gapjunior
- Branch prediction and branchless codemiddle
- Hardware prefetcher, TLB, and memory-level parallelismsenior
- GC basics: what the runtime taxes you forjunior
- GC algorithms: generational, concurrent, and per-runtimemiddle
- GC tradeoffs: pause, throughput, heap — and object poolingmiddle
- GC tuning: pacing, heap shape, and allocation observabilitymiddle
- GC internals: tri-color invariant, write barriers, and per-runtime deep-divessenior
- GC in production: observability, security, edge cases, and fleet governancesenior
- N+1: one logical operation, many round-tripsjunior
- Fix families: JOIN, IN, preload, and DataLoadermiddle
- Detecting N+1: query logs, APM traces, and CI gatesmiddle
- DataLoader: batching across resolver treesmiddle
- Cross-protocol N+1: HTTP fan-out and Redis MGETmiddle
- N+1 at scale: pool exhaustion, plan changes, and denormalisationsenior
- Batching: amortize fixed cost per operationjunior
- The batching window: size and wait timemiddle
- Batching in Kafka and Postgresmiddle
- io_uring and observability of batchingmiddle
- From Nagle to io_uring: evolution of batchingmiddle
- Backpressure, failure isolation, and batch security in productionsenior
- What a bundle actually costs: download, parse, compile, executejunior
- Core Web Vitals: LCP, INP, and CLSmiddle
- Code splitting: route-level, component-level, vendor splittingmiddle
- Tree shaking and compression: removing what you don''''t usemiddle
- Third-party scripts: the silent budget killermiddle
- CI enforcement and RUM: making budgets stickmiddle
- V8 JIT pipeline, HTTP priorities, and bundle securitysenior
- The performance loop: discipline, not a projectjunior
- Classify and fix: matching bottleneck families to remediesmiddle
- Observability stack and CI gates: catching regressions before they shipmiddle
- Incident to enforcement: SLO burn to verified fix in 35 minutesmiddle
- Culture, economics, and org-scale performancesenior