TechPrufer
Get started
Cloudflare
Cloudflare logoCloudflare · Feature trail

QUIC and HTTP/3 Protocol Development

17 posts · Jun 2012 – Nov 2025

What this trail covers

Cloudflare's QUIC and HTTP/3 support has evolved to be generally available on the edge network, enabling faster, more reliable, and more secure connections. This builds upon industry collaboration through the IETF and partnerships with browser vendors like Google Chrome and Mozilla Firefox. The implementation leverages QUIC as the transport layer, which encapsulates UDP datagrams and combines TCP and TLS handshakes for faster connection establishment and improved performance by eliminating head-of-line blocking. This post details structural enhancements to NGINX to improve HTTP/2 performance, specifically addressing data queuing and prioritization. Key changes include HTTP/2 frame write queue reclamation, allowing unwritten frames to be re-queued for subsequent prioritization rounds, and HTTP/2 frame write event re-ordering, which consolidates frame processing and prioritization into a single event to increase 'Potential' (a metric for how effectively prioritization strategies can be applied). These changes aim to improve overall throughput and the effectiveness of prioritization algorithms.

All Cloudflare trails
  1. Async QUIC and HTTP:3 made easy- tokio-quiche is now open-sourceThis post announces the open-sourcing of tokio-quiche, an asynchronous QUIC library that integrates the quiche QUIC implementation with the Tokio Rust async runtime. It details the library's architecture, which uses an actor model to manage the QUIC and HTTP/3 state machine, and its role in powering Cloudflare's internal systems like Proxy B for iCloud Private Relay and Oxy proxies. The post highlights how tokio-quiche simplifies the integration of sans-io libraries like quiche by handling UDP socket management and async IO, and provides an `ApplicationOverQuic` trait for abstracting application protocols like HTTP/3. It also mentions the development of `H3Driver` for HTTP/3 specific logic and the `InboundPacketRouter` and `IoWorker` actors for data movement.
  2. Defending QUIC from acknowledgement-based DDoS attacksThis post details the patching of two QUIC vulnerabilities in the quiche library: CVE-2025-4821 (lack of ACK range validation) and CVE-2025-4820 (Optimistic ACK attack). The fix for CVE-2025-4821 involves enforcing ACK range validation based on the largest packets sent by the server and closing the connection on violation. The fix for CVE-2025-4820 introduces a dynamic CWND-aware skip frequency that scales with a connection's send rate to prevent artificial inflation of the congestion window.
  3. QUIC action: patching a broadcast address amplification vulnerabilityThis post details the discovery and mitigation of a broadcast amplification vulnerability in Cloudflare's QUIC implementation. The vulnerability arose from the interaction of QUIC's handshake mechanism with Linux's handling of broadcast addresses bound to the loopback interface. The researchers found that sending a QUIC Initial packet to a broadcast IP address could trigger an amplification attack exceeding RFC 9000's 3x limit. Cloudflare patched this by adjusting its internal routing rules to prevent broadcast traffic targeting anycast prefixes from being processed in a way that leads to amplification.
  4. Open sourcing h3i: a command line tool and library for low-level HTTP/3 testing and debuggingThis post introduces h3i, an open-source command-line tool and Rust library for low-level HTTP/3 testing and debugging over QUIC. It addresses the need for more accessible and maintainable testing tools beyond existing libraries like Requests and aioquic, which can have safety guards that hinder testing of malformed or non-RFC compliant traffic. h3i allows for granular control over HTTP/3 frames, including the control stream and SETTINGS frames, enabling deeper testing of protocol robustness and security. It is part of Cloudflare's quiche project and aims to empower engineers to test their own software and services against protocol specifications.
  5. Introducing HTTP/3 PrioritizationThis post introduces Cloudflare's implementation of HTTP/3 Extensible Priorities (RFC 9218), which enhances webpage loading performance by up to 37%. It details the technical aspects of the new standard, including the urgency (0-7) and incremental (boolean) parameters, and how they are exchanged via HTTP headers or PRIORITY_UPDATE frames. The post also explains Cloudflare's server-side scheduling logic, which prioritizes requests based on urgency and incremental values, and provides examples of how this improves metrics like Largest Contentful Paint (LCP). Server-side overrides via Cloudflare Workers are also highlighted.
  7. Examining HTTP/3 usage one year onThis post analyzes HTTP/3 usage trends across Cloudflare's network one year after the formal definition of HTTP/3 (RFC 9114). It details the growth of HTTP/3 in browser-retrieved content, its continued low adoption by search engine indexing and social media bots, and its doubling in API traffic. The post also discusses the transition from draft ALPN IDs (e.g., 'h3-29') to the final 'h3' identifier, and presents detailed breakdowns of HTTP/3 usage by browser (Chrome, Safari, Edge, Firefox) and traffic type (overall, API, mitigated). It highlights the increasing adoption of HTTP/3 by Safari and the persistent use of HTTP/1.1 and HTTP/2 by malicious traffic.
  8. The state of HTTP in 2022This post details the publication of HTTP/3 and QUIC v1 as standards in 2022, highlighting Cloudflare's increasing adoption and confidence in HTTP/3. It discusses the deprecation of HTTP/2 server push due to its performance challenges and the emergence of HTTP Early Hints (RFC 8297) as a safer alternative, with Cloudflare experimenting with and integrating it into Cloudflare Pages. The post also covers the MASQUE working group's efforts to enable UDP tunnels and IP tunneling for privacy-enhancing technologies like iCloud Private Relay and Privacy Gateway, and mentions the finalization of Digest Fields and HTTP Message Signatures specifications for protocol security.
  9. HTTP/3 inspection on Cloudflare GatewayThis post announces the upcoming support for HTTP/3 inspection within Cloudflare Gateway. It details the challenges administrators face with inspecting HTTP/3 traffic due to its reliance on QUIC over UDP, which is architecturally distinct from TCP-based protocols and poorly supported by legacy secure web gateways. The solution allows for UDP traffic proxying and TLS decryption, enabling security features like AV-scanning, DLP, and HTTP filtering on HTTP/3 traffic.
  10. HTTP RFCs have evolved: A Cloudflare view of HTTP usage trendsThis post analyzes Cloudflare's network traffic data over the past year (May 2021 - May 2022) to understand HTTP version usage trends. It details the adoption rates of HTTP/1.1, HTTP/2, and HTTP/3 across different browser families (Chrome, Edge, Firefox, Safari), search engine bots (GoogleBot, BingBot), and social media bots. Key findings include the steady growth of HTTP/3 traffic, its dominance in Chrome, and the slower adoption by search engine bots. The post also discusses the impact of browser releases and customer configurations on HTTP version adoption.
  11. Unlocking QUIC’s proxying potential with MASQUEThis post introduces MASQUE (Multiplexing And Secure Communication over QUIC Express) as a mechanism to enable UDP tunneling over QUIC. It details how QUIC's DATAGRAM frame, an unreliable message primitive, can be used to encapsulate UDP payloads. The post explains the MASQUE working group's specifications for using QUIC datagrams with HTTP/3 and a new extended CONNECT request for initiating UDP sockets to target servers. It also analyzes the anatomy of encapsulation, including overheads and MTU considerations, and discusses nested tunneling architectures for improved privacy.
  12. Cloudflare and the IETFThis post details Cloudflare's active involvement and contributions to the IETF for the advancement of internet protocols, specifically focusing on QUIC and HTTP/3. It highlights how Cloudflare Research develops, advocates for, and implements open standards to improve performance, security, privacy, and availability. The post provides examples of incremental innovations like DNS-over-HTTPS (DoH), TLS Encrypted Client Hello (ECH), Oblivious DNS-over-HTTPS (ODoH), and MASQUE for metadata privacy. It also discusses architectural advancements with QUIC and HTTP/3, emphasizing their benefits over TCP and the socket API, and their role in mitigating network ossification. The post underscores the importance of exercising QUIC's extensibility features for long-term protocol health and the emergence of new use cases like DNS-over-QUIC and MASQUE.
  13. Early Hints: How Cloudflare Can Improve Website Load Times by 30%This post introduces Cloudflare's support for Early Hints (RFC 8297), a new web standard that leverages HTTP status code 103 to send preliminary resource hints to browsers during server 'think time'. This allows browsers to proactively fetch assets, improving page load performance by over 30% in initial tests. Cloudflare acts as an intermediary, emitting these hints on behalf of origins that may not support the feature directly, and automatically generating hints based on observed traffic patterns. This contrasts with HTTP/2 Server Push by providing hints rather than dictating resource loading, and can be combined with `rel=preload` and `rel=preconnect` for enhanced performance.
  14. QUIC Version 1 is live on CloudflareThis post announces the general availability of QUIC version 1 (RFC 9000) on Cloudflare, following its standardization by the IETF. It details how Cloudflare servers listen for QUIC traffic on UDP port 443, the handshake process involving version identifiers and ALPN, and the use of HTTP Alternative Services (Alt-Svc) to inform clients about HTTP/3 availability. The post highlights the role of Cloudflare's open-source quiche implementation in Rust, its integration into various projects, and the availability of tools like quiche-client for testing and debugging.
  15. Good-bye ESNI, hello ECH!This post introduces Encrypted Client Hello (ECH) as a successor to Encrypted SNI (ESNI). ECH aims to provide full handshake encryption for TLS, protecting sensitive parameters like Server Name Indication (SNI) and Application-Layer Protocol Negotiation (ALPN) from network observers. It builds upon the lessons learned from ESNI and the limitations of TLS 1.3's handshake encryption, addressing the key distribution problem for handshake encryption. The post details the motivation for ECH, the privacy leaks it addresses, and the technical challenges involved in achieving full handshake encryption.
  16. A Last Call for QUIC, a giant leap for the InternetThis post announces the IETF Last Call for the QUIC and HTTP/3 protocol documents (draft 32), marking a significant milestone towards standardization. It highlights Cloudflare's ongoing deployment of HTTP/3 since September 2019 and the maturity of the specification, with draft 29 being a stable basis for interoperability. The post also points to extensive resources for learning about QUIC and HTTP/3, including a series on Cloudflare TV and a collection of links at cloudflare-quic.com. It discusses future opportunities for evolving QUIC, such as multipath, different congestion control approaches, and the DATAGRAM frame, and mentions the formation of the MASQUE and WebTransport Working Groups.
  17. Speeding up HTTPS and HTTP/3 negotiation with... DNSThis post details the rollout of support for the SVCB/HTTPS DNS record type across Cloudflare's edge network. This enables Cloudflare's DNS servers to dynamically advertise HTTP/3 and HTTP/2 support for zones where these features are enabled. The post explains the benefits of SVCB/HTTPS records for accelerating HTTPS and HTTP/3 negotiation by providing protocol and endpoint information directly via DNS, thus avoiding initial plaintext HTTP requests and improving connection establishment latency and security. It also discusses the 'alias form' of SVCB/HTTPS records as a potential replacement for CNAME records at the apex of domains.
  18. CUBIC and HyStart++ Support in quicheThis post details the integration of CUBIC and HyStart++ congestion control algorithms into Cloudflare's quiche QUIC implementation. It explains the concepts of QUIC congestion control, loss recovery, and contrasts Reno, CUBIC, and HyStart++. Lab test results are presented, demonstrating that QUIC CUBIC with HyStart++ performs comparably to TCP CUBIC while significantly reducing packet loss, especially in lossy network conditions.
  19. Comparing HTTP/3 vs. HTTP/2 PerformanceThis post details the performance comparison between HTTP/3 and HTTP/2, highlighting HTTP/3's advantages in handling packet loss (mitigating Head-of-line blocking) and faster session startup (0-RTT support). It presents benchmark data showing HTTP/3's improved Time To First Byte (TTFB) and real-world performance from various geographical locations. The post also discusses the impact of different congestion control algorithms (CUBIC for HTTP/3, BBR v1 for HTTP/2) on performance and outlines future work to achieve more accurate comparisons and further performance enhancements.
  20. A cost-effective and extensible testbed for transport protocol developmentThis post details the design and configuration of a cost-effective and extensible testbed for developing and testing transport protocols like QUIC. It outlines the goals of the lab (multiple protocol development, debugging, performance comparison, bottleneck finding), the hardware and software components (Raspberry Pis, x86 boxes, FreeBSD/Linux traffic shapers, quiche client/server), and the automation and visualization techniques used (CSV output, Clickhouse database, Google Sheets charts). It also describes a separate testbed incorporating smartphones for mobile network simulation and analysis.
  21. Accelerating UDP packet transmission for QUICThis post details techniques to accelerate UDP packet transmission for QUIC, focusing on improving throughput. It introduces and benchmarks the use of `sendmmsg()` to batch multiple UDP packets per system call, significantly reducing context switches compared to `sendmsg()`. It also explores Generic Segmentation Offload (GSO) via the `UDP_SEGMENT` socket option, which allows the kernel to segment a single 'super buffer' into smaller packets, further improving throughput and reducing kernel traversal overhead. The post also discusses the challenges and ongoing research into packet pacing for QUIC, particularly how it interacts with batching techniques.
  22. Adopting a new approach to HTTP prioritizationThis post details the adoption of the 'Extensible Prioritization Scheme for HTTP' by the IETF HTTP Working Group, co-authored by Cloudflare's Tommy Pauly. This new scheme replaces HTTP/2's dependency-based relative prioritization with an absolute weighting signaled in an HTTP header, allowing for backporting to HTTP/2 or use over HTTP/1.1. It aims to improve scheduling and performance by making request priorities independent of each other, addressing challenges posed by out-of-order delivery in HTTP/3. The post also recaps the evolution of HTTP prioritization from HTTP/1.1 to HTTP/2 and the challenges faced with HTTP/3's non-deterministic ordering.
  23. Even faster connection establishment with QUIC 0-RTT resumptionThis post introduces and details the implementation of 0-RTT connection resumption for QUIC and TLS 1.3 on Cloudflare's platform. It explains the technical benefits of reduced latency, the security risks associated with replay attacks on non-idempotent requests, and the mitigation strategies employed, including the `Early-Data: 1` header and the 425 Too Early response. It also announces the availability of a dashboard toggle for enabling this feature and its support in the NGINX HTTP/3 patch.
  24. Experiment with HTTP/3 using NGINX and quicheThis post details the integration of Cloudflare's quiche library with NGINX, providing a patch and build instructions to enable HTTP/3 support in NGINX. It includes a minimal NGINX configuration example for accepting HTTP/3 connections and highlights the experimental nature of the implementation.
  25. HTTP/3: the past, the present, and the futureThis post announces the general availability of QUIC and HTTP/3 support on Cloudflare's edge network. It details the evolution from preliminary support to a production-ready feature, highlighting industry collaboration with Google Chrome and Mozilla Firefox through the IETF. The post explains the technical rationale behind HTTP/3, contrasting it with HTTP/1.0, HTTP/1.1, and HTTP/2, emphasizing the benefits of QUIC's stream multiplexing over UDP to overcome TCP's head-of-line blocking. It also covers the combined handshake of QUIC and TLS 1.3 for faster connection establishment and the user-facing implications of this rollout.
  26. On the recent HTTP/2 DoS attacksThis post details Cloudflare's immediate response and mitigation of several HTTP/2 Denial of Service (DoS) vulnerabilities (CVE-2019-9511 through CVE-2019-9518). Cloudflare's Protocols team developed and deployed patches to detect and block attack attempts, ensuring customer protection. The company's NGINX-based infrastructure was updated to address these specific vulnerabilities, with ongoing monitoring.
  27. NGINX structural enhancements for HTTP/2 performanceThis post details structural enhancements to NGINX to improve HTTP/2 performance, specifically addressing data queuing and prioritization. Key changes include HTTP/2 frame write queue reclamation, allowing unwritten frames to be re-queued for subsequent prioritization rounds, and HTTP/2 frame write event re-ordering, which consolidates frame processing and prioritization into a single event to increase 'Potential' (a metric for how effectively prioritization strategies can be applied). These changes aim to improve overall throughput and the effectiveness of prioritization algorithms.
  28. HTTP/3: From root to tipThis post traces the historical evolution of HTTP from its early versions (0.9, 1.1) through HTTP/2 and the development of QUIC, culminating in the standardization of HTTP/3. It details the naming conventions and the process within the IETF for standardizing protocols, emphasizing the 'rough consensus and running code' principle. The post highlights the relationship between Google's gQUIC and the IETF's QUIC standard, and presents a detailed timeline visualization of protocol development.
  29. Enjoy a slice of QUIC, and Rust!This post introduces quiche, Cloudflare's open-source QUIC implementation in Rust. It details the design principles, API for integration with C/C++ and Rust applications, and the use of BoringSSL for TLS 1.3 handshakes and the ring library for packet protection and header protection. It also mentions the ability to integrate quiche with NGINX and cURL.
  30. Get a head start with QUICThis post details the initial beta deployment of QUIC on Cloudflare's network, focusing on enabling users to test the IETF QUIC draft standard using a command-line client (ngtcp2). It explains the client and server handshake process, highlighting the overlap of transport and TLS negotiation for reduced round trips. The post also discusses QUIC's mechanisms for mitigating amplification and DDoS attacks, including the use of large connection IDs and padding frames.
  31. The QUICeningThis post introduces QUIC as a solution to the problems of mobile roaming and packet loss, explaining its core technologies: UDP as a replacement for TCP, end-to-end encryption, forward-error correction (FEC), solving HTTP/2 head-of-line blocking, and a merged connection/encryption handshake for faster connection establishment. It also links to a technical blog for testing QUIC and the Cloudflare dashboard for early access.
  32. Encrypt it or lose it: how encrypted SNI worksThis post introduces and explains the technical implementation of Encrypted SNI (ESNI) as an extension to TLS 1.3. It details how ESNI leverages DNS for public key distribution and Diffie-Hellman key exchange to encrypt the SNI extension in the ClientHello message. It also discusses the cryptographic machinery involved, including ephemeral Diffie-Hellman shares, cipher suites, and digests, and explains the importance of key rotation for forward secrecy. The post also touches upon the interplay between ESNI, encrypted DNS (DoT/DoH), and DNSSEC for comprehensive privacy.
  33. The Road to QUICThis post introduces QUIC, detailing its built-in security (combining TCP and TLS handshakes for single round-trip establishment), its solution to HTTP/2's head-of-line blocking by delivering streams independently, and the challenges of NAT rebinding and connection migration. It highlights the use of connection IDs to track connections and the need for Layer 4 load balancing solutions like Katran. It also introduces QPACK as the header compression mechanism for QUIC, addressing the challenges of out-of-order stream delivery.
  34. Deprecating SPDYThis post announces the deprecation of SPDY protocol support on Cloudflare's edge by February 21st, 2018. It details the historical context of SPDY as a precursor to HTTP/2, Cloudflare's decision to support both protocols for a transition period due to low HTTP/2 adoption, and the engineering costs associated with maintaining custom NGINX patches. The post highlights the current low usage of SPDY (3.83% of TLS connections) compared to HTTP/2 (66.88%) and the minimal impact on users, as most remaining SPDY clients are older iOS/macOS apps that will fall back to HTTP/1.1. The deprecation allows Cloudflare to simplify its NGINX stack, reduce maintenance overhead, and avoid the cost of developing custom security patches for SPDY.
  35. Introducing Zero Round Trip Time Resumption (0-RTT)This post introduces Zero Round Trip Time Resumption (0-RTT) for TLS 1.3, a feature that reduces the number of round trips required for setting up a secure HTTPS connection for resumed connections from 3 RTT to 2 RTT. This optimization is particularly beneficial for mobile networks and frequently visited sites. The post details the latency costs of DNS lookups, TCP handshakes, and TLS handshakes, and explains how TLS 1.3 and 0-RTT improve these timings. It also notes that 0-RTT is not enabled by default and is experimental, with a demo provided to illustrate its performance benefits. The post also mentions that 0-RTT is disabled transparently when a query string is used to prevent replay attacks.
  36. HPACK: the silent killer (feature) of HTTP/2This post details the implementation and benefits of HPACK header compression within HTTP/2. It explains the HPACK algorithm's three compression methods (static dictionary, dynamic dictionary, Huffman encoding) and how they mitigate the CRIME attack. The post provides examples of HPACK's effectiveness on request and response headers, showing significant reductions in header size and overall traffic. It also highlights Cloudflare's full HPACK implementation in nginx and upstreaming of Huffman encoding.
  37. Opportunistic Encryption: Bringing HTTP/2 to the unencrypted webThis post introduces Opportunistic Encryption, a feature that allows HTTP/2 connections over TLS for non-HTTPS sites. It leverages HTTP Alternative Services to advertise support for HTTP/2 or SPDY on port 443. This provides encrypted connections from the browser to the server, offering performance benefits of HTTP/2 and some security advantages over unencrypted HTTP, particularly for sites with mixed content issues that prevent full HTTPS migration. It is enabled by default for Free and Pro plans.
  38. Optimizing TLS over TCP to reduce latencyThis post introduces a modification to NGINX to support dynamic TLS record sizes. The patch adds parameters `ssl_dyn_rec_size_lo`, `ssl_dyn_rec_size_hi`, `ssl_dyn_rec_threshold`, and `ssl_dyn_rec_timeout` to the `ssl` module. The dynamic sizing aims to reduce latency by adjusting TLS record sizes based on TCP connection behavior, starting small and growing as the connection stabilizes, and resetting to a small size during idle periods. The patch is open-sourced.
  39. Using HTTP/2 Server Push with PHPThis post demonstrates how to implement HTTP/2 Server Push using PHP by adding `Link` headers with `rel=preload` and `as=image` directives via the `header()` function. It provides a code example and illustrates the performance benefits through network waterfalls and `chrome://net-internals` logs, showing a reduction in page load time from 651ms to 251ms.
  40. Open sourcing our NGINX HTTP/2 + SPDY codeThis post announces the open-sourcing of Cloudflare's NGINX modifications that enable simultaneous support for HTTP/2 and SPDY. The provided patch allows NGINX to be built with both `--with-http_v2_module` and `--with-http_spdy_module`, and to accept both `spdy` and `http2` keywords in the `listen` directive. It details the configuration required for dual protocol support and demonstrates testing using the OpenSSL client to verify advertised protocols.
  41. CloudFlare’s Impact On The HTTP/2 “Universe”This post details the impact of Cloudflare's HTTP/2 rollout on browser adoption and overall HTTP/2 traffic ratios. It presents data showing a significant increase in HTTP/2 capable browser market share and a corresponding decrease in SPDY traffic on Cloudflare.com after the HTTP/2 launch. It also quantifies Cloudflare's contribution to the growth of HTTP/2 enabled websites, stating that Cloudflare powered over 58,000 domains with 'True Support' for HTTP/2 in December 2015, more than quadrupling the number of such sites. The post also provides instructions for enabling HTTP/2 for different customer plans.
  42. Tools for debugging, testing and using HTTP/2This post introduces and details various tools and techniques for debugging, testing, and using HTTP/2. It covers browser extensions (HTTP/2 and SPDY Indicator, Claire), online testing tools, command-line utilities (`is-http2-cli`, `curl` with `--http2`, `nghttp`, `h2c`, `openssl s_client`, `h2i`), load testing tools (`h2load`), and conformance testing tools (`h2spec`, `h2scan`). It also briefly mentions the underlying protocol evolution and its impact on web performance.
  43. HTTP/2 is here! Goodbye SPDY? Not quite yetThis post announces the introduction of HTTP/2 support for all Cloudflare customers using SSL/TLS connections, while continuing to support SPDY. It details how HTTP/2 and SPDY offer performance benefits through multiplexing, header compression, and reduced connection overhead. The post provides real-world performance data showing significant page load time improvements with HTTP/2 and SPDY compared to HTTP/1.x. It also explains the protocol negotiation process (ALPN/NPN) and how to check server protocol support using OpenSSL. The decision to support both protocols simultaneously is justified by the significant existing SPDY usage and the still-developing HTTP/2 adoption rate.
  44. Test all the things: IPv6, HTTP/2, SHA-2This post announces the launch of a test server ([https://http2.cloudflare.com](https://http2.cloudflare.com)) to test compatibility with IPv6, HTTP/2, and SHA-2 certificates. It details the server's IPv4/IPv6 addresses, the use of SHA-256 for the SSL certificate with ECDHE for forward secrecy, and how to identify HTTP/2 connections in Chrome. The server is intended for testing purposes only and is not part of the main Cloudflare network.
  45. Staying up to date with the latest protocols: SPDY/3.1This post announces the rollout of SPDY/3.1 for all customers, highlighting its multiplexing capabilities and flow control extensions. It also details early experiments with QUIC, a UDP-based transport protocol, and provides instructions for users to experiment with it using Chromium and Wireshark.
  46. SPDY Now One-Click Simple for Any WebsiteThis post announces the general availability of SPDY for all eligible Cloudflare customers. SPDY is now a one-click option for paying customers with SSL enabled, including those using Cloudflare's Flexible SSL. The post highlights the performance benefits of SPDY and its requirement for TLS/SSL, indicating future plans to extend support to non-HTTPS connections if the protocol allows.
  47. What makes SPDY speedy?This post introduces SPDY, a new protocol designed to make web browsing faster without replacing HTTP. SPDY sits between HTTP and TCP, allowing a single connection to be used for multiple requests and responses returned in the order they are available. This minimizes connection setup cost and slow start, and eliminates blocking issues inherent in HTTP over TCP. SPDY also includes compression of previously uncompressed parts of HTTP. Cloudflare will be rolling out SPDY to customers in beta.
  48. Introducing SPDYThis post introduces the beta rollout of SPDY to Cloudflare customers. It explains how SPDY improves web performance through connection multiplexing, out-of-order object delivery, and header compression. It also details the limitations of SPDY, such as browser support and the requirement for SSL certificates, and how Cloudflare's gateway architecture and Rocket Loader mitigate these limitations. The post acknowledges NGINX's SPDY implementation as foundational to Cloudflare's rollout.