BlogsCloudflareProtocol Deprecation and Evolution

Protocol Deprecation and Evolution

Protocol Deprecation and Evolution

29
posts
2012–2022

Cloudflare has a history of adopting and supporting emerging internet protocols to democratize performance and security. This includes early adoption of SPDY, HTTP/2, and TLS 1.3. As newer, standardized protocols like HTTP/2 have gained widespread adoption, Cloudflare has strategically deprecated older protocols like SPDY to streamline its infrastructure, reduce engineering overhead, and focus on maintaining modern standards. This process involves analyzing adoption trends, assessing the impact. This post details the publication of new RFCs for HTTP semantics, caching, HTTP/1.1, HTTP/2, and HTTP/3, and analyzes traffic trends showing the increasing adoption of HTTP/3 across browsers and the slower adoption by search engine bots.

2022

HTTP RFCs have evolved: A Cloudflare view of HTTP usage trends

6/6/2022

This post details the publication of new RFCs for HTTP semantics, caching, HTTP/1.1, HTTP/2, and HTTP/3. It also presents an analysis of Cloudflare's HTTP traffic over the past year, showing trends in HTTP version usage across browsers (Chrome, Edge, Firefox, Safari), search engine bots (GoogleBot, BingBot), and social media bots. The analysis highlights the increasing adoption of HTTP/3, particularly by Chrome, and the slower adoption by search engine bots.

2018

A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)

8/11/2018

This post announces the publication of RFC 8446, standardizing TLS 1.3. It details the security and performance improvements of TLS 1.3 over TLS 1.2, including the removal of legacy features, improved key exchange mechanisms (fixing RSA key exchange and promoting forward secrecy with ephemeral Diffie-Hellman), and a reduced handshake latency (one round-trip for new connections). It also discusses the historical context of TLS evolution and the challenges faced in designing secure cryptographic protocols.

Deprecating SPDY

1/18/2018

This post announces the deprecation of SPDY protocol support on Cloudflare's edge by February 21st, 2018. It details the history 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 current state where SPDY usage has dropped to 3.83% of TLS connections. The post highlights the engineering cost of maintaining custom NGINX patches for SPDY support and the minimal impact of deprecation on users, primarily older iOS/macOS apps. It also notes that traffic using SPDY will gracefully fall back to HTTP/1.1. The decision to deprecate SPDY is framed as a necessary step in moving forward with newer, standardized technologies.

2016

So you want to expose Go on the Internet

12/26/2016

This post details how to harden Go servers for internet exposure by tuning `crypto/tls` and `net/http`. It covers `crypto/tls` configuration for cipher suites, curve preferences, and certificate management with Let's Encrypt. It also discusses `net/http` timeouts (`ReadTimeout`, `WriteTimeout`, `IdleTimeout`), HTTP/2 behavior, TCP Keep-Alives, and best practices for `ServeMux` and logging. The core contribution is providing practical guidance and code examples for making Go services production-ready for the internet.

HPACK: the silent killer (feature) of HTTP/2

11/28/2016

This post details the implementation of full HPACK header compression in nginx, including the upstreaming of Huffman encoding. It explains the HPACK algorithm's mechanisms (static dictionary, dynamic dictionary, Huffman encoding) and its resilience to attacks like CRIME. The post quantifies the performance gains, showing an average of 76% compression for ingress headers and 69% for egress headers, leading to substantial savings in total ingress traffic (53%) and a 1.4% saving in total egress HTTP/2 traffic. It also contrasts HPACK with previous compression methods used in TLS and SPDY.

Opportunistic Encryption: Bringing HTTP/2 to the unencrypted web

9/21/2016

Introduced Opportunistic Encryption, enabling HTTP/2 connections for non-HTTPS sites by leveraging HTTP Alternative Services. This allows browsers to connect over TLS on port 443 using HTTP/2 or SPDY, providing encrypted connections and performance benefits without requiring a full HTTPS migration. This addresses mixed content issues and offers a security improvement over unencrypted HTTP.

Evenly Distributed Future

8/22/2016

This post discusses Cloudflare's role in making advanced internet technologies like HTTP/2, IPv6, HTML5, and TLS 1.3 available to all websites, regardless of size. It highlights how Cloudflare's platform allows customers to experiment with and adopt these new technologies, thereby distributing the 'future' of the internet more evenly. The post also touches on the challenges of keeping up with evolving technologies and security threats, and how Cloudflare's infrastructure helps bridge the gap between vulnerability disclosure and patching.

Accelerating Node.js applications with HTTP/2 Server Push

8/16/2016

This post introduces `netjet`, a Node.js middleware that parses HTML to automatically add `Link` headers for HTTP/2 Server Push. It details the implementation using PostHTML, discusses the trade-off of increased latency with an adjustable LRU cache, and provides examples for Express and raw Node.js HTTP servers. It also covers how to enable Server Push in Ghost and how to verify its usage in Chrome Developer Tools.

HTTP/2 Server Push with multiple assets per Link header

6/30/2016

This post details an enhancement to Cloudflare's HTTP/2 Server Push implementation. Previously, only one asset could be pushed per `Link` header. This update allows for multiple assets to be specified in a single `Link` header, addressing limitations in CMS and web development platforms. A new header, `Cf-H2-Pushed`, has been introduced to provide visibility into which assets were pushed by Cloudflare, aiding in debugging.

Optimizing TLS over TCP to reduce latency

6/10/2016

This post introduces an NGINX patch that enables dynamic TLS record sizing. 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 NGINX SSL module. This allows TLS records to dynamically adjust their size based on the underlying TCP connection's state, starting small and growing larger as the connection stabilizes, and resetting to a small size during idle periods. This aims to reduce latency by minimizing delays caused by TLS record fragmentation across TCP segments, especially during TCP slow start or packet loss.

Using HTTP/2 Server Push with PHP

5/13/2016

This post details the implementation of HTTP/2 Server Push using PHP by adding `Link` headers with `rel=preload` to HTTP responses. It demonstrates how to use the PHP `header` function to achieve this, showing the effect on page load times and network waterfalls through browser developer tools and `chrome://net-internals/`. The post highlights the benefits of Server Push for preloading critical resources like images, reducing overall page load time.

Open sourcing our NGINX HTTP/2 + SPDY code

5/13/2016

This post details the open-sourcing of Cloudflare's modifications to NGINX, enabling it to support both HTTP/2 and SPDY simultaneously. The 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 for the `listen` directive. It utilizes ALPN and NPN for protocol negotiation, preferring HTTP/2 over SPDY/3.1 when both are offered. The post also provides instructions for configuring NGINX and testing protocol advertisement using OpenSSL.

Announcing Support for HTTP/2 Server Push

4/28/2016

This post announces the rollout of HTTP/2 Server Push for all Cloudflare customers, completing the set of HTTP/2 features. It details how Server Push works using PUSH_PROMISE and RST_STREAM, and how it can be enabled via Link headers with the 'rel=preload' directive. The post also explains how to disable Server Push using the 'nopush' directive and discusses its performance implications, best use cases (uncacheable content, all assets on a page, likely next page), and how to profile its benefits using browser developer tools. It highlights the potential for significant performance gains, especially on slower connections, and mentions future plans for automated Server Push optimization.

What happened next: the deprecation of ANY

4/13/2016

This post details Cloudflare's decision and implementation strategy for deprecating the DNS ANY meta-query type. It explains the rationale behind the decision, including the lack of legitimate use, abundance of malicious use, and its role in DNS amplification DDoS attacks. The post discusses the community conversation around the deprecation, the technical challenges of answering ANY queries (especially with DNSSEC), and the chosen approach of returning a 'harmless' HINFO record to recursive resolvers to minimize amplification factors while signaling non-support for the ANY query type. It also references the relevant IETF draft 'Refuse ANY'.

It takes two to ChaCha (Poly)

4/4/2016

This post details Cloudflare's adoption and ongoing support of ChaCha20-Poly1305 cipher suites for TLS. It explains the history of ChaCha20-Poly1305, its standardization process, and its importance for web performance and security, particularly on mobile devices. The post highlights Cloudflare's updated open-sourced patch for OpenSSL, which implements both draft and RFC versions of the cipher suites to ensure compatibility with existing and upcoming browsers. It also provides a technical overview of AEADs, ChaCha20-Poly1305, and the key differences between the draft and RFC versions, including changes in IV generation and Poly1305 application to TLS records.

CloudFlare’s Impact On The HTTP/2 “Universe”

2/3/2016

This post details the impact of Cloudflare's HTTP/2 rollout on overall HTTP/2 adoption. It presents data showing a significant increase in HTTP/2 capable browsers visiting Cloudflare.com and a doubling of HTTP/2 traffic ratio on www.cloudflare.com. It also highlights that Cloudflare's release more than quadrupled the number of websites with 'True Support' for HTTP/2, and improved HTTP/2's market position close to that of SPDY. The post also reminds customers that HTTP/2 is enabled by default for Free and Pro plans and can be enabled for Business and Enterprise plans.

2015

HTTP/2 Demo: Under the Hood

12/11/2015

This post details the technical implementation of an HTTP/2 demonstration page. It explains how iframes were used to load content over both HTTP/1.1 (using Amazon CloudFront) and HTTP/2 (using Cloudflare's network) simultaneously for comparison. It describes the use of JavaScript to request 200 image tiles generated by ImageMagick, tracking load times and reporting metrics via `Window.postMessage` due to cross-domain security. It also covers the caching policy implemented to force edge caching and prevent browser caching, and discusses the SPDY fallback mechanism for browsers that do not support HTTP/2.

HTTP/2 For Web Developers

12/10/2015

This post details how HTTP/2 changes web optimization best practices for developers. It explains that instead of minimizing HTTP requests (as in HTTP/1.1), developers should focus on optimizing caching behavior by shipping small, granular resources. Key HTTP/2 features like multiplexing, header compression, stream prioritization, and server push are discussed. Specific HTTP/1.1 practices that are no longer recommended for HTTP/2 include concatenating files, inlining assets, and sharding domains. The post also reiterates that some HTTP/1.1 best practices remain relevant, such as reducing DNS lookups, using CDNs, leveraging browser caching, minimizing request/response sizes, and eliminating unnecessary redirects.

Tools for debugging, testing and using HTTP/2

12/4/2015

This post details 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-http, curl with --http2, nghttp2 tools like nghttp and h2load, h2c, h2i), OpenSSL's s_client for protocol negotiation, and conformance testing tools (h2spec, h2scan). It highlights the release of HTTP/2 for all Cloudflare customers and the importance of using up-to-date browsers and tools for development and testing.

HTTP/2 is here! Goodbye SPDY? Not quite yet

12/3/2015

This post details Cloudflare's introduction of HTTP/2 support for all customers using SSL/TLS connections, while continuing to support SPDY. It explains the technical benefits of HTTP/2 and SPDY, such as multiplexing, stream dependencies, and header compression, and provides real-world performance data showing significant page load time improvements with HTTP/2. The post also addresses the decision to support both protocols simultaneously by analyzing usage data, highlighting the impact of deprecating SPDY prematurely on a significant portion of the user base. It details how to enable HTTP/2 for different customer plans and provides methods for checking server protocol negotiation using OpenSSL.

Test all the things: IPv6, HTTP/2, SHA-2

9/2/2015

This post announces the launch of a test server at https://http2.cloudflare.com/ to test compatibility with IPv4/IPv6, HTTP/2, and SHA-2 certificates. It details the server's IP addresses, the SHA-256 certificate, and how to identify HTTP/2 usage in Chrome. The server is intended for testing purposes only and is not part of the main Cloudflare network. It highlights the deprecation of SHA-1 and the use of ECDHE for forward secrecy.

Do the ChaCha: better mobile performance with cryptography

2/23/2015

Cloudflare has added support for ChaCha20-Poly1305 cipher suites, which are optimized for mobile devices and offer improved performance and battery life compared to AES-GCM on hardware without AES acceleration. This move diversifies TLS cipher suites, providing a secure fallback option and enhancing overall security. The implementation leverages an open-source assembly code version of ChaCha/Poly for server-side optimization.

2014

The little extra that comes with Universal SSL

10/6/2014

This post announces the rollout of SPDY 3.1 for all Cloudflare users, enabled by the Universal SSL feature. It highlights how SPDY, which requires SSL, improves performance by allowing browsers to query for multiple objects in one request and send them as they are ready. This expands the availability of SPDY to all sites on Cloudflare, not just large ones.

The Web is World-Wide, or who still needs RC4?

5/19/2014

This post analyzes the continued need for RC4 cipher support in TLS connections, despite its known vulnerabilities. It details the breakdown of RC4 usage by client type (older phones, browsers, software updates, proxies) and geographic region. It also explains the RC4 algorithm and its historical context, and highlights the issue of transparent SSL proxies in institutions using outdated cipher suites. The post concludes with recommendations for users to check their SSL configuration and update software.

Staying up to date with the latest protocols: SPDY/3.1

2/17/2014

This post details Cloudflare's rollout of SPDY/3.1 for all customers, highlighting its importance in keeping up with protocol evolution as older versions are deprecated. It explains the technical changes in SPDY/3 and SPDY/3.1, specifically flow control for individual streams, and discusses ongoing experimentation with QUIC, a UDP-based protocol.

2013

Using CloudFlare to mix domain sharding and SPDY

12/26/2013

This post analyzes the performance implications of domain sharding in conjunction with the SPDY protocol. It demonstrates that while domain sharding was beneficial for HTTP/1.1 by increasing connection limits, it can negatively impact SPDY performance by forcing multiple SSL negotiations and connections. The post advocates for using a single certificate covering multiple subdomains to allow SPDY to multiplex requests over a single connection, thus achieving the best of both worlds for performance across different browser capabilities.

2012

SPDY Now One-Click Simple for Any Website

8/3/2012

This post announces the general availability of SPDY support for 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 Cloudflare's commitment to advancing web speed.

What makes SPDY speedy?

6/25/2012

This post explains the technical underpinnings of SPDY, a protocol designed to make web browsing faster by sitting between HTTP and TCP. It details how SPDY achieves speed improvements by allowing a single connection for multiple asynchronous, overlapping HTTP requests, thereby minimizing connection setup time, TCP slow start penalties, and blocking issues inherent in traditional HTTP over TCP. The post also announces Cloudflare's upcoming beta availability of SPDY.

Introducing SPDY

6/15/2012

Introduced SPDY beta to Cloudflare customers, enabling connection multiplexing, out-of-order object retrieval, and HTTP header compression for faster page loads. Cloudflare acts as a gateway, allowing origin servers to not support SPDY directly. Integrated with Rocket Loader to further enhance multiplexing benefits, even for third-party scripts.