--- title: "TLS 1.3 and 0-RTT at the Edge: The Real Handshake Cost" description: "TLS 1.3 and 0-RTT at the CDN edge: explore session resumption, handshake latency, and the real cost of faster connections." image: https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Sep-21-2026-07-30-27-5571-AM.jpeg --- [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [๐Ÿ“˜Learn โ–พ](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [CDN Fundamentals](https://blog.blazingcdn.com/cdn-fundamentals?hsLang=en-us) [By Content Type](https://blog.blazingcdn.com/by-content-type?hsLang=en-us) [Advanced Concepts](https://blog.blazingcdn.com/advanced-concepts?hsLang=en-us) [Glossary](https://blog.blazingcdn.com/glossary?hsLang=en-us) [โšก Web Performance](https://blog.blazingcdn.com/web-performance?hsLang=en-us) [๐ŸŽฌVideo & Streaming โ–พ](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [๐Ÿ”ด Live Streaming](https://blog.blazingcdn.com/live-streaming?hsLang=en-us) [๐Ÿ“บ VOD & OTT](https://blog.blazingcdn.com/vod-ott?hsLang=en-us) [๐Ÿ’ฐ Bandwidth & Costs](https://blog.blazingcdn.com/bandwidth-costs?hsLang=en-us) [๐Ÿญ Other Industries โ–พ](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [๐Ÿ“บ Media & Broadcasting](https://blog.blazingcdn.com/media-broadcasting?hsLang=en-us) [๐Ÿ’พ Software & SaaS](https://blog.blazingcdn.com/software-saas?hsLang=en-us) [๐Ÿ—๏ธ DevOps & Cloud Infra](https://blog.blazingcdn.com/devops-cloud-infra?hsLang=en-us) [๐Ÿ“š AdTech & Advertising](https://blog.blazingcdn.com/adtech-advertising?hsLang=en-us) [๐ŸŽฎ Gaming & Esports](https://blog.blazingcdn.com/gaming-esports?hsLang=en-us) [๐Ÿ“ฑ Mobile Apps & Developers](https://blog.blazingcdn.com/mobile-apps-developers?hsLang=en-us) [๐Ÿค– AI & Machine Learning](https://blog.blazingcdn.com/ai-machine-learning?hsLang=en-us) [๐Ÿ›๏ธ Enterprise & Corporate](https://blog.blazingcdn.com/enterprise-corporate?hsLang=en-us) [๐Ÿ“š E-Learning & EdTech](https://blog.blazingcdn.com/e-learning-edtech?hsLang=en-us) [๐ŸŸ๏ธ Sports & Live Events](https://blog.blazingcdn.com/sports-live-events?hsLang=en-us) [๐Ÿ’ฐ Pricing & Costs โ–พ](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [Provider Pricing](https://blog.blazingcdn.com/provider-pricing?hsLang=en-us) [Cost Optimization](https://blog.blazingcdn.com/cost-optimization?hsLang=en-us) [Decision Support](https://blog.blazingcdn.com/decision-support?hsLang=en-us) [โšกCompare โ–พ](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [Provider Comparisons](https://blog.blazingcdn.com/provider-comparisons?hsLang=en-us) [Strategy Comparisons](https://blog.blazingcdn.com/strategy-comparisons?hsLang=en-us) [Ratings & Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐Ÿ“Š Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐Ÿ”’ Security โ–พ](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [Attack Protection](https://blog.blazingcdn.com/attack-protection?hsLang=en-us) [Encryption & Access](https://blog.blazingcdn.com/encryption-access?hsLang=en-us) [Video & DRM Security](https://blog.blazingcdn.com/video-drm-security?hsLang=en-us) [๐Ÿ“ Case Studies](https://blog.blazingcdn.com/case-studies?hsLang=en-us) [๐Ÿ”Œ Integrations](https://blog.blazingcdn.com/integrations?hsLang=en-us) [๐Ÿ› ๏ธ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [Get Started](https://blazingcdn.com/sign-up-contact-form/) [Learn](https://blog.blazingcdn.com/en-us/tag/learn) [Security](https://blog.blazingcdn.com/en-us/tag/security) [Security - Encryption & Access](https://blog.blazingcdn.com/en-us/tag/security-encryption-access) # TLS 1.3 and 0-RTT at the Edge: The Real Handshake Cost Vadym Borovskyi Sep 21, 2026, 9:33:42โ€ฏAM ![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Sep-21-2026-07-30-27-5571-AM.jpeg) **TLS 1.3 removes exactly one round trip from a full handshake compared with TLS 1.2, and 0-RTT removes one more on resumed connections.** On a TLS 1.3 CDN edge with a 25 ms client RTT that is 25 ms off time-to-first-byte; on a 95 ms intercontinental path it is 95 ms, and up to 190 ms against TLS 1.2 when early data applies. The catch is accounting: the saving lands once per connection, not once per request, and 0-RTT only fires when the client already holds a valid pre-shared key. On public web traffic that is a minority of connections. ![TLS 1.3 CDN handshake and 0-RTT session resumption round-trip diagram at the edge](https://blog.blazingcdn.com/hs-fs/hubfs/Gemini%20INBlog%20Pictures/image-Sep-21-2026-07-30-45-6520-AM.jpeg?width=1280&height=720&name=image-Sep-21-2026-07-30-45-6520-AM.jpeg) ## **What a TLS 1.3 CDN handshake actually costs, in round trips** Count round trips to the first application byte, not milliseconds of CPU. Everything else in the handshake budget is noise by comparison. | Path | Transport setup | Crypto setup | RTT to first byte | | --- | --- | --- | --- | | TCP + TLS 1.2 full | 1 | 2 | 3 | | TCP + TLS 1.2 abbreviated (ticket) | 1 | 1 | 2 | | TCP + TLS 1.3 full | 1 | 1 | 2 | | TCP + TLS 1.3 PSK session resumption | 1 | 1 | 2 | | TCP + TLS 1.3 with 0-RTT early data | 1 | 0 | 1 | | QUIC / HTTP/3 full (RFC 9000, RFC 9001) | combined | 1 | 1 | | QUIC / HTTP/3 with 0-RTT | combined | 0 | 0 | Plain TLS 1.3 session resumption without early data buys you nothing in round trips over a full TLS 1.3 handshake โ€” the entire latency win of resumption is in 0-RTT, while the win of resumption itself is in bytes and CPU. Those bytes matter more than engineers expect. A full handshake ships the certificate chain: roughly 2โ€“4 KB for a two-certificate ECDSA chain, 4โ€“6 KB with RSA, plus 1โ€“2 KB if you staple an OCSP response. With an initial congestion window of 10 segments (about 14 KB), the chain competes directly with your first HTML bytes on the same flight, and on a lossy mobile path a single dropped certificate segment costs an RTO, not an RTT. ### **Why TLS 1.3 CDN savings do not add up across parallel connections** Handshakes to the same edge hostname happen in parallel, so the saving is not additive. A navigation that opens two connections to your asset host does not save 2 ร— RTT from TLS 1.3; it saves one RTT on the critical path, because the second handshake overlaps the first. Worked example, assumptions stated: 25 ms in-region RTT, one HTTP/2 connection to the page host, one to the asset host, 46 subresources. Moving from TLS 1.2 to TLS 1.3 removes 25 ms from the critical path. Enabling 0-RTT on the repeat visit removes another 25 ms. The remaining 45 requests ride the open connection and pay zero handshake cost. Total tls handshake latency saved per repeat navigation: 50 ms, or about 4% of a 1.2 s LCP. At 95 ms RTT the same change is worth 190 ms, which is 16%. That ratio is the whole decision. 0-RTT is a long-RTT, high-connection-churn optimization. It is close to irrelevant for a single long-lived HTTP/3 connection streaming 4-second HLS segments for an hour. ## **The replay problem: what 0-RTT does not guarantee** TLS 1.3, standardized as RFC 8446, cuts a full handshake from two round trips to one, and 0-RTT resumption removes the last one for returning clients. Early data carries no replay protection at the protocol level: an attacker who captures a 0-RTT flight can resend it, and the server has no way to distinguish the copy from the original without additional state. RFC 8446 section 8 defines the mitigations; it does not mandate strong ones. Two properties make this awkward specifically at the edge. First, anti-replay strike registers are node-local โ€” a single-use ticket database is cheap within one server and expensive to make globally consistent, so a replay directed at a different edge node than the original often lands. Second, ticket keys are typically shared fleet-wide so that resumption works after a client moves between nodes, which widens the blast radius of a key compromise. Early data also lacks forward secrecy: it is protected by the resumption secret derived from the previous session, so a ticket-key leak exposes recorded early data that a full handshake would have kept safe. The practical containment is boring and effective: accept early data only for idempotent methods with no request body, cap ticket lifetime at 10 minutes or less, validate the obfuscated ticket age against your own clock skew window, and forward the situation to the origin instead of hiding it. ## **Config pattern: early data at the TLS terminator** ``` ssl_protocols TLSv1.2 TLSv1.3; ssl_early_data on; ssl_session_tickets on; ssl_session_timeout 10m; ssl_session_ticket_key ticket_keys/current.key; ssl_session_ticket_key ticket_keys/previous.key; proxy_set_header Early-Data $ssl_early_data; log_format handshake '$ssl_protocol reused=$ssl_session_reused early=$ssl_early_data ttfb=$request_time'; ``` The two ticket key files implement rotation: the first entry encrypts new tickets, later entries only decrypt, so you rotate hourly without invalidating in-flight sessions. The Early-Data header is RFC 8470 โ€” the origin sees value 1 when the request arrived as early data and answers 425 Too Early for anything that touches state. Compliant clients then retry the same request after the handshake completes, which turns the replay question into an application-layer decision instead of a gamble at the edge. If your terminator cannot express per-method rules, split hostnames: early data on for the static asset host, off for the API host. Whichever edge you run, that split should be a configuration change rather than an architecture change; BlazingCDN handles TLS behavior as [**per-property edge configuration**](https://blazingcdn.com/features/), which is the granularity this pattern needs. ## **Trade-offs, failure modes, and the observability gap** 0-RTT enlarges the first client flight. A ClientHello carrying a ticket plus early data can exceed one packet, and under QUIC the server's 3x anti-amplification limit means a large early flight may still stall waiting for address validation โ€” the 0 RTT on paper becomes 1 RTT in practice for some clients. Anti-replay costs memory. A strike register sized for a 10-minute ticket lifetime at 50,000 handshakes per second per node holds tens of millions of entries; most implementations use a bounded Bloom filter and accept a false-positive rejection rate, which shows up as unexplained handshake retries rather than errors. The observability gap is the real problem. Standard access logs record status and duration but not handshake type, so teams cannot answer "what share of our connections resume?" โ€” and without that number, the 0-RTT decision is guesswork. Log the protocol version, the reuse flag, the early-data flag, and 425 counts before you tune anything. ## **Verify this on your own stack** - Log the session-reuse and early-data flags for one day, then compute resumed connections as a share of total. Below roughly 20%, 0-RTT will not move your aggregate p95. - Split p95 time-to-first-byte by handshake type. If full and resumed handshakes differ by less than your RTT p50, your measurement is dominated by something else. - Send a test request to a static asset host with an early-data-capable client and confirm the origin receives the Early-Data header value 1. - Alert on 425 responses. A rising rate means clients are sending early data to state-changing endpoints that should be on a separate hostname. ## **Who should enable 0-RTT, by workload** | Workload | New-connection share | Verdict | Reason | | --- | --- | --- | --- | | Static assets, images, fonts | High | Enable, GET and HEAD only | Idempotent by definition; replay is harmless | | Mobile APIs with short-lived connections | High | Enable with 425 handling | Radio churn and NAT rebinding kill keep-alive | | HLS or DASH segment delivery | Very low | Marginal | One handshake amortized over hundreds of segments | | Large file and game patch downloads | Low | Skip | One RTT against minutes of transfer is unmeasurable | | Authenticated, state-changing endpoints | Any | Do not enable | Replay risk exceeds the value of one round trip | 0-RTT earns its configuration effort only where new connections are frequent and client RTT is high; everywhere else, plain TLS 1.3 session resumption already captured the win. ## **FAQ: TLS 1.3, 0-RTT, and session resumption on a CDN** ### How much latency does TLS 1.3 save compared with TLS 1.2? TLS 1.3 saves exactly one network round trip on a full handshake: two round trips of crypto negotiation become one. In wall-clock terms that is your client-to-edge RTT, typically 10โ€“40 ms in-region and 80โ€“150 ms intercontinental. It also removes 2โ€“6 KB of certificate chain from the first flight on resumed sessions. ### Is 0-RTT safe to enable on a CDN? 0-RTT is safe when early data is restricted to idempotent requests with no body. The protocol provides no replay protection, and edge-local anti-replay state does not stop a replay aimed at a different node. Forward the Early-Data header per RFC 8470 and let the origin return 425 Too Early for anything that mutates state. ### What is the difference between TLS 1.3 session resumption and 0-RTT? Session resumption reuses a pre-shared key to skip certificate exchange, saving CPU and bytes but still costing one round trip. 0-RTT is an optional extension of resumption that lets the client send application data in its first flight, saving that remaining round trip. Resumption is a prerequisite for 0-RTT, not the same thing. ### Does HTTP/3 make 0-RTT unnecessary? No. QUIC per RFC 9000 already merges transport and crypto setup into one round trip, which matches TLS 1.3 over TCP at two. QUIC 0-RTT drops that to zero for resumed connections, with the same replay caveats plus the 3x anti-amplification limit, which can stall large early flights until address validation completes. ## **Measure your resumption rate before you tune anything** Spend twenty minutes this week adding four fields to your edge access log: TLS version, session-reuse flag, early-data flag, and time-to-first-byte. Run it for 24 hours, then compute two numbers โ€” the share of connections that resume, and the p95 TTFB delta between full and resumed handshakes. If resumption is under 20% of connections, your handshake budget is not the problem and 0-RTT will not fix it. If it is over 50% and your RTT p75 is above 80 ms, early data on your static hostname is one of the cheapest latency wins available. Post your two numbers to your platform channel and argue from data. Share: [f](https://www.facebook.com/sharer/sharer.php?u=https://blog.blazingcdn.com/en-us/tls-1-3-and-0-rtt-at-the-edge-the-real-handshake-cost) [in](https://www.linkedin.com/sharing/share-offsite/?url=https://blog.blazingcdn.com/en-us/tls-1-3-and-0-rtt-at-the-edge-the-real-handshake-cost) [๐•](https://twitter.com/intent/tweet?url=https://blog.blazingcdn.com/en-us/tls-1-3-and-0-rtt-at-the-edge-the-real-handshake-cost&text=) [โœ‰](mailto:?subject=%3Cspan%20id="hs_cos_wrapper_name"%20class="hs_cos_wrapper%20hs_cos_wrapper_meta_field%20hs_cos_wrapper_type_text"%20style=""%20data-hs-cos-general-type="meta_field"%20data-hs-cos-type="text"%20%3ETLS%201.3%20and%200-RTT%20at%20the%20Edge:%20The%20Real%20Handshake%20Cost%3C/span%3E&body=https://blog.blazingcdn.com/en-us/tls-1-3-and-0-rtt-at-the-edge-the-real-handshake-cost) ![BlazingCDN](https://blog.blazingcdn.com/hs-fs/hubfs/Logo/blog-logo-w.png?height=24&name=blog-logo-w.png) *Heavy traffic.* Light bill. The CDN for video and large traffic Their monthly bill vs ours - 20 TBFastly $2,087**$92.50** - 50 TBCDN77 $990**$215** - 200 TBCloudFront $11,965**$765** Published list prices, Aug 2026 [Calculate your cost](https://blazingcdn.com/cdn-cost-calculator/?utm_source=blog&utm_medium=sidebar&utm_campaign=blog_sidebar&utm_content=compare_calc) ## Related posts [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Oct-14-2026-07-30-23-9310-AM.jpeg)](https://blog.blazingcdn.com/en-us/lossy-vs-lossless-compression-images-video-and-audio?hsLang=en-us) Learn ### [Lossy vs Lossless Compression: Images, Video and Audio](https://blog.blazingcdn.com/en-us/lossy-vs-lossless-compression-images-video-and-audio?hsLang=en-us) Lossy vs lossless compression comes down to one trade: lossless compression rebuilds every original bit and typically ... Oct 14, 2026, 9:32:43โ€ฏAM [Read more](https://blog.blazingcdn.com/en-us/lossy-vs-lossless-compression-images-video-and-audio?hsLang=en-us) [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Oct-14-2026-07-00-56-2080-AM.jpeg)](https://blog.blazingcdn.com/en-us/using-cloudfront-with-s3-cost-analysis?hsLang=en-us) Pricing - Pricing & Costs ### [CloudFront vs S3 Direct: Real Cost Breakdown and When to Use Each](https://blog.blazingcdn.com/en-us/using-cloudfront-with-s3-cost-analysis?hsLang=en-us) The CloudFront vs S3 decision depends more on object size than on traffic volume. At a 500 KB average response, 100 TB ... Oct 14, 2026, 9:04:54โ€ฏAM [Read more](https://blog.blazingcdn.com/en-us/using-cloudfront-with-s3-cost-analysis?hsLang=en-us) [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Oct-13-2026-07-30-24-3649-AM.jpeg)](https://blog.blazingcdn.com/en-us/cbr-vs-vbr-choosing-a-bitrate-mode-for-streaming?hsLang=en-us) Learn ### [CBR vs VBR: Choosing a Bitrate Mode for Streaming](https://blog.blazingcdn.com/en-us/cbr-vs-vbr-choosing-a-bitrate-mode-for-streaming?hsLang=en-us) For most on-demand video, capped variable bitrate (VBR) wins the cbr vs vbr decision: it spends bits where the picture ... Oct 13, 2026, 9:32:48โ€ฏAM [Read more](https://blog.blazingcdn.com/en-us/cbr-vs-vbr-choosing-a-bitrate-mode-for-streaming?hsLang=en-us) [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [๐Ÿ“˜ Learn](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [๐Ÿ“Š Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐ŸŽฌ Video & Streaming](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [๐Ÿญ Industries](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [๐Ÿ’ฐ Pricing & Costs](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [โšก Compare](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [๐Ÿ”’ Security](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [๐Ÿ› ๏ธ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [โœ๏ธ Publish with us](https://blog.blazingcdn.com/publish-with-us?hsLang=en-us) in f ๐• โœ‰ Copyright ยฉ BlazingCDN |. All rights reserved. ```json { "@context" : "https://schema.org", "@id" : "https://blazingcdn.com/#organization", "@type" : "Organization", "description" : "High-volume CDN for video, live streaming, OTT/IPTV, software, games, SaaS and large-file delivery.", "logo" : { "@id" : "https://blazingcdn.com/#logo", "@type" : "ImageObject", "height" : 560, "url" : "https://blazingcdn.com/wp-content/uploads/2024/08/logo-560-560.png", "width" : 560 }, "name" : "BlazingCDN", "sameAs" : [ "https://www.linkedin.com/company/blazingcdn", "https://x.com/BlazingCdn", "https://www.reddit.com/r/BlazingCDN/", "https://www.wikidata.org/wiki/Q141711074" ], "url" : "https://blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/#website", "@type" : "WebSite", "inLanguage" : "en-US", "name" : "BlazingCDN Blog", "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "url" : "https://blog.blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/tls-1-3-and-0-rtt-at-the-edge-the-real-handshake-cost#article", "@type" : "BlogPosting", "author" : { "@id" : "https://blog.blazingcdn.com/en-us/author/blazingcdn#person", "@type" : "Person", "description" : "Vadym Borovskyi is Chief Product and Marketing Officer at BlazingCDN, where he has led product strategy and growth since 2021. He has more than 11 years of experience in IT product management and B2B marketing. On this blog he writes about CDN pricing and egress costs, video and software delivery, cache configuration, and how teams evaluate and switch CDN providers. He is based in Warsaw, Poland.", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/vadym-borovskyi.jpg", "jobTitle" : "Chief Product and Marketing Officer", "knowsAbout" : [ "Content Delivery Networks (CDN)", "CDN pricing", "Video streaming delivery", "Software and game distribution", "Cache optimization", "Product Management", "B2B Marketing", "Digital Marketing", "Pay Per Click Marketing (PPC)", "Google Ads", "Search Engine Marketing (SEM)", "Marketing Strategy", "Artificial Intelligence (AI)", "Cloud Management", "SaaS Development", "IT Consulting", "Computer Networking", "Project Management", "Startups" ], "name" : "Vadym Borovskyi", "sameAs" : [ "https://www.linkedin.com/in/axelt/" ], "url" : "https://blog.blazingcdn.com/en-us/author/blazingcdn", "worksFor" : { "@id" : "https://blazingcdn.com/#organization" } }, "dateModified" : "2026-09-21T07:33:42Z", "datePublished" : "2026-09-21T07:33:42Z", "description" : "TLS 1.3 and 0-RTT at the CDN edge: explore session resumption, handshake latency, and the real cost of faster connections.", "headline" : "TLS 1.3 and 0-RTT at the Edge: The Real Handshake Cost", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/Gemini-Blog/image-Sep-21-2026-07-30-27-5571-AM.jpeg", "inLanguage" : "en-us", "isPartOf" : { "@id" : "https://blog.blazingcdn.com/#website" }, "mainEntityOfPage" : { "@id" : "https://blog.blazingcdn.com/en-us/tls-1-3-and-0-rtt-at-the-edge-the-real-handshake-cost", "@type" : "WebPage" }, "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "wordCount" : 1772 } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/tls-1-3-and-0-rtt-at-the-edge-the-real-handshake-cost#breadcrumb", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us", "name" : "Blog", "position" : 1 }, { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us/tls-1-3-and-0-rtt-at-the-edge-the-real-handshake-cost", "name" : "TLS 1.3 and 0-RTT at the Edge: The Real Handshake Cost", "position" : 2 } ] } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/tls-1-3-and-0-rtt-at-the-edge-the-real-handshake-cost#faq", "@type" : "FAQPage", "mainEntity" : [ { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "TLS 1.3 saves exactly one network round trip on a full handshake: two round trips of crypto negotiation become one. In wall-clock terms that is your client-to-edge RTT, typically 10โ€“40 ms in-region and 80โ€“150 ms intercontinental. It also removes 2โ€“6 KB of certificate chain from the first flight on resumed sessions." }, "name" : "How much latency does TLS 1.3 save compared with TLS 1.2?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "0-RTT is safe when early data is restricted to idempotent requests with no body. The protocol provides no replay protection, and edge-local anti-replay state does not stop a replay aimed at a different node. Forward the Early-Data header per RFC 8470 and let the origin return 425 Too Early for anything that mutates state." }, "name" : "Is 0-RTT safe to enable on a CDN?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Session resumption reuses a pre-shared key to skip certificate exchange, saving CPU and bytes but still costing one round trip. 0-RTT is an optional extension of resumption that lets the client send application data in its first flight, saving that remaining round trip. Resumption is a prerequisite for 0-RTT, not the same thing." }, "name" : "What is the difference between TLS 1.3 session resumption and 0-RTT?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "No. QUIC per RFC 9000 already merges transport and crypto setup into one round trip, which matches TLS 1.3 over TCP at two. QUIC 0-RTT drops that to zero for resumed connections, with the same replay caveats plus the 3x anti-amplification limit, which can stall large early flights until address validation completes." }, "name" : "Does HTTP/3 make 0-RTT unnecessary?" } ] } ```