HTTP/2

The working group charter mentions several goals and issues of concern:{{cite web|url=https://datatracker.ietf.org/wg/httpbis/charter/|title=HTTP (httpbis) |publisher=Internet Engineering Task Force Datatracker |url-status=live |archive-url= https://web.archive.org/web/20240106112614/https://datatracker.ietf.org/wg/httpbis/charter/ |archive-date= Jan 6, 2024 }}

• Create a negotiation mechanism that allows clients and servers to elect to use HTTP/1.1, 2.0, or potentially other non-HTTP protocols.
• Maintain high-level compatibility with HTTP/1.1 (for example with methods, status codes, URIs, and most header fields).
• Decrease latency to improve page load speed in web browsers by considering:
• data compression of HTTP headers
• HTTP/2 Server Push
• prioritization of requests
• multiplexing multiple requests over a single TCP connection (fixing the HTTP-transaction-level head-of-line blocking problem in HTTP 1.x)
• Support common existing use cases of HTTP, such as desktop web browsers, mobile web browsers, web APIs, web servers at various scales, proxy servers, reverse proxy servers, firewalls, and content delivery networks.

The proposed changes do not require any changes to how existing web applications work, but new applications can take advantage of new features for increased speed. HTTP/2 leaves all of HTTP/1.1's high-level semantics, such as methods, status codes, header fields, and URIs, the same. What is new is how the data is framed and transported between the client and the server.{{cite book|chapter=Chapter 12: HTTP 2.0|chapter-url=https://hpbn.co/http2/|title=High Performance Browser Networking|author=Ilya Grigorik|publisher=O'Reilly Media, Inc.|quote=HTTP/2 does not modify the application semantics of HTTP in any way}}

Websites that are efficient minimize the number of requests required to render an entire page by minifying (reducing the amount of code and packing smaller pieces of code into bundles, without reducing its ability to function) resources such as images and scripts. However, minification is not necessarily convenient nor efficient and may still require separate HTTP connections to get the page and the minified resources. HTTP/2 allows the server to "push" content, that is, to respond with data for more queries than the client requested. This allows the server to supply data it knows a web browser will need to render a web page, without waiting for the browser to examine the first response, and without the overhead of an additional request cycle.{{cite web|last=Pratt|first=Michael|title=Apiux|url=http://apiux.com/2013/07/23/http2-0-initial-draft-released|access-date=March 19, 2014|website=apiux.com}}

Additional performance improvements in the first draft of HTTP/2 (which was a copy of SPDY) come from multiplexing of requests and responses to avoid some of the head-of-line blocking problem in HTTP 1 (even when HTTP pipelining is used), header compression, and prioritization of requests.{{cite news|url=https://www.infoq.com/news/2012/11/http20-first-draft|title=HTTP 2.0 First Draft Published|author=Dio Synodinos |date=November 2012|publisher= C4Media Inc. |website=InfoQ.com}} However, as HTTP/2 runs on top of a single TCP connection there is still potential for head-of-line blocking to occur if TCP packets are lost or delayed in transmission.{{cite web|url=https://community.akamai.com/customers/s/article/How-does-HTTP-2-solve-the-Head-of-Line-blocking-HOL-issue?language=en_US|author=Javier Garza|date=October 2017|title=How does HTTP/2 solve the Head of Line blocking (HOL) issue}}

HTTP/2 no longer supports HTTP/1.1's chunked transfer encoding mechanism, as it provides its own, more efficient, mechanisms for data streaming.{{cite journal|url=https://tools.ietf.org/html/rfc7540|title=Hypertext Transfer Protocol Version 2 (HTTP/2)|first1=Mike|last1=Belshe|first2=Martin|last2=Thomson|website=tools.ietf.org|language=en|access-date=2017-11-17|first3=Roberto|last3=Peon|editor-first1=M. |editor-last1=Thomson |date=May 2015|doi=10.17487/RFC7540 |quote=HTTP/2 uses DATA frames to carry message payloads. The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] MUST NOT be used in HTTP/2|doi-access=free}}

SPDY (pronounced like "speedy") was a previous HTTP-replacement protocol developed by a research project spearheaded by Google.{{cite web|url=https://www.extremetech.com/computing/124153-sm-vs-spdy-microsoft-and-google-battle-over-the-future-of-http-2-0 |title=S&M vs. SPDY: Microsoft and Google battle over the future of HTTP 2.0|publisher=ExtremeTech|author=Sebastian Anthony|date=March 28, 2012}} Primarily focused on reducing latency, SPDY uses the same TCP pipe but different protocols to accomplish this reduction. The basic changes made to HTTP/1.1 to create SPDY included "true request pipelining without FIFO restrictions, message framing mechanism to simplify client and server development, mandatory compression (including headers), priority scheduling, and even bi-directional communication".{{cite web|last=Grigorik|first=Ilya|title=Life beyond HTTP 1.1: Google's SPDY|url=https://www.igvita.com/2011/04/07/life-beyond-http-11-googles-spdy/}}

The HTTP Working Group considered Google's SPDY protocol, Microsoft's HTTP Speed+Mobility proposal (SPDY based), and Network-Friendly HTTP Upgrade.{{cite news|url=https://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00 |title=Proposal for a Network-Friendly HTTP Upgrade|date=March 29, 2012|author1=Willy Tarreau|author2=Amos Jeffries|author3=Adrien de Croy|author4=Poul-Henning Kamp|work=Network Working Group|publisher=Internet Engineering Task Force}} In July 2012, Facebook provided feedback on each of the proposals and recommended HTTP/2 be based on SPDY.{{cite web|url=https://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0251.html |title=HTTP2 Expression of Interest|author=Doug Beaver|date=July 15, 2012|type=mailing list|publisher=W3C}} The initial draft of HTTP/2 was published in November 2012 and was based on a straight copy of SPDY.{{cite web |author=Dio Synodinos |date=2012-11-30 |title=HTTP/2 First Draft Published |publisher=InfoQ |url=https://www.infoq.com/news/2012/11/http20-first-draft }}

The biggest difference between HTTP/1.1 and SPDY was that each user action in SPDY is given a "stream ID", meaning there is a single TCP channel connecting the user to the server. SPDY split requests into either control or data, using a "simple to parse binary protocol with two types of frames".{{Cite book|title=HTTP/2 : a new excerpt from high performance browser networking|last=Ilya|first=Grigorik|publisher=O'Reilly Media|year=2015|isbn=9781491932483|edition= May 2015, First|location=Sebastopol, Calif.|pages=211–224|oclc=1039459460}} SPDY showed evident improvement over HTTP, with a new page load speedup ranging from 11% to 47%.{{cite web|title=SPDY: An experimental protocol for a faster web|url=https://www.chromium.org/spdy/spdy-whitepaper|work=The Chromium Projects}}

The development of HTTP/2 used SPDY as a jumping-off point. Among the many detailed differences between the protocols, the most notable is that HTTP/2 uses a fixed Huffman code-based header compression algorithm, instead of SPDY's dynamic stream-based compression. This helps to reduce the potential for compression oracle attacks on the protocol, such as the CRIME attack.

On February 9, 2015, Google announced plans to remove support for SPDY in Chrome in favor of support for HTTP/2.{{cite web|title=Hello HTTP/2, Goodbye SPDY|url=https://blog.chromium.org/2015/02/hello-http2-goodbye-spdy.html |work=Chromium Blog|quote=Update: To better align with Chrome's release cycle, SPDY and NPN support will be removed with the release of Chrome 51. |date=2015-02-09|author1=Chris Bentzel|author2=Bence Béky}} This took effect starting with Chrome 51.{{cite web |url=https://developers.google.com/web/updates/2016/04/chrome-51-deprecations?hl=en#remove-support-for-spdy31 |title=API Deprecations and Removals in Chrome 51 |quote=TL;DR: Support for HTTP/2 is widespread enough that SPDY/3.1 support can be dropped.}}{{cite web|last1=Shadrin|first1=Nick|title=Supporting HTTP/2 for Google Chrome Users {{!}} NGINX|url=https://www.nginx.com/blog/supporting-http2-google-chrome-users/|website=NGINX|access-date=July 10, 2017|date=June 7, 2016}}

HTTP/2 is defined both for HTTP URIs (i.e. without TLS encryption, a configuration which is abbreviated in {{strong|h2c}}) and for HTTPS URIs (over TLS using ALPN extension{{cite web|url=https://tools.ietf.org/html/rfc7301|title=RFC 7301 - Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension|publisher=IETF|date=July 2014|doi=10.17487/RFC7301 |last1=Friedl |first1=S. |last2=Popov |first2=A. |last3=Langley |first3=A. |last4=Stephan |first4=E. |doi-access=free }} where TLS 1.2 or newer is required, a configuration which is abbreviated in {{strong|h2}}).

Although the standard itself does not require usage of encryption,{{cite web|url=https://http2.github.io/faq/#does-http2-require-encryption|title=HTTP/2 Frequently Asked Questions|access-date=September 8, 2014|work= IETF HTTP Working Group}} all major client implementations (Firefox,{{cite web|url=https://wiki.mozilla.org/Networking/http2|title=Networking/http2|publisher=MozillaWiki|access-date=September 7, 2014}} Chrome, Safari, Opera, IE, Edge) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory.{{cite web|url=https://www.mnot.net/blog/2015/06/15/http2_implementation_status|title=HTTP/2 Implementation Status|website=mnot’s blog}}

The FreeBSD and Varnish developer Poul-Henning Kamp asserts that the standard was prepared on an unrealistically short schedule, ruling out any basis for the new HTTP/2 other than the SPDY protocol and resulting in other missed opportunities for improvement. Kamp criticizes the protocol itself for being inconsistent and having needless, overwhelming complexity. He also states that the protocol violates the protocol layering principle, for example by duplicating flow control that belongs in the transport layer (TCP). He also suggested that the new protocol should have removed HTTP Cookies, introducing a breaking change.

Initially, some members{{who|date=July 2016}} of the Working Group tried to introduce an encryption requirement in the protocol. This faced criticism.

Critics stated that encryption has non-negligible computing costs and that many HTTP applications actually have no need for encryption and their providers have no desire to spend additional resources on it. Encryption proponents have stated that this encryption overhead is negligible in practice.{{cite web|url=https://istlsfastyet.com/|title=Is TLS Fast Yet?|first = Ilya|last = Grigorik|access-date = 30 December 2015}} Poul-Henning Kamp has criticized the IETF for hastily standardizing Google's SPDY prototype as HTTP/2 due to political considerations.{{cite magazine |url=https://queue.acm.org/detail.cfm?id=2716278 |title=HTTP/2.0 – The IETF is Phoning It In (Bad protocol, bad politics) |date=January 6, 2015 |magazine=ACM Queue |volume=13 |number=2 |pages=10-12 |issn=1542-7730 |first=Poul-Henning |last=Kamp |author-link=Poul-Henning Kamp |doi=10.1145/2732266.2716278 |doi-access=free }}{{cite journal|doi=10.1145/2717515|doi-access=free|title=Http/2.0|journal=Communications of the ACM|volume=58|issue=3|page=40|year=2015|last=Kamp|first=Poul-Henning|s2cid=20337779}}{{cite mailing list|mailing-list=ietf-http-wg@w3.org |url=https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0043.html|title=Re: Last Call: (Hypertext Transfer Protocol version 2) to Proposed Standard|date=January 7, 2015|access-date=January 12, 2015|first=Poul-Henning |last=Kamp |author-link=Poul-Henning Kamp}} The criticism of the agenda of mandatory encryption within the existing certificate framework is not new, nor is it unique to members of the open-source community{{snd}} a Cisco employee stated in 2013 that the present certificate model is not compatible with small devices like routers, because the present model requires not only annual enrollment and remission of non-trivial fees for each certificate, but must be continually repeated on an annual basis.{{cite mailing list|mailing-list=ietf-http-wg@w3.org|url=https://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/0909.html|title=Mandatory encryption *is* theater|date=August 25, 2013|access-date=January 26, 2015|first=Eliot|last=Lear}} In the end the Working Group did not reach consensus over the mandatory encryption, although most client implementations require it, which makes encryption a de facto requirement.

The HTTP/2 protocol also faced criticism for not supporting opportunistic encryption, a measure against passive monitoring similar to the STARTTLS mechanism that has long been available in other Internet protocols like SMTP. Critics have stated that the HTTP/2 proposal goes in violation of IETF's own {{IETF RFC|7258}} "Pervasive Monitoring Is an Attack", which also has a status of Best Current Practice 188.{{cite mailing list|mailing-list=ietf-http-wg@w3.org|url=https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0106.html|title=Re: Last Call: (Hypertext Transfer Protocol version 2) to Proposed Standard|date=January 9, 2015|access-date=January 12, 2015|first=Constantine A.|last=Murenin}} RFC7258/BCP188 mandates that passive monitoring be considered as an attack, and protocols designed by IETF should take steps to protect against passive monitoring (for example, through the use of opportunistic encryption). A number of specifications for opportunistic encryption of HTTP/2 have been provided,{{cite web|url=//tools.ietf.org/html/draft-hoffman-httpbis-minimal-unauth-enc-01|title=Minimal Unauthenticated Encryption (MUE) for HTTP-2: draft-hoffman-httpbis-minimal-unauth-enc-01|publisher=Internet Engineering Task Force|author=Paul Hoffman}}{{cite web|url=//tools.ietf.org/html/draft-nottingham-http2-encryption-03|title=Opportunistic Encryption for HTTP URIs: draft-nottingham-http2-encryption-03|publisher=Internet Engineering Task Force|author1=Mark Nottingham|author2=Martin Thomson}}{{cite news|url=https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-01|title=Opportunistic Security for HTTP: draft-ietf-httpbis-http2-encryption-01|publisher=Internet Engineering Task Force|author1=Mark Nottingham|author2=Martin Thomson|newspaper=Ietf Datatracker }} of which draft-nottingham-http2-encryption was adopted as an official work item of the working group, leading to the publication of {{IETF RFC|8164}} in May 2017.

Although the design of HTTP/2 effectively addresses the HTTP-transaction-level head-of-line blocking problem by allowing multiple concurrent HTTP transactions, all those transactions are multiplexed over a single TCP connection, meaning that any packet-level head-of-line blocking of the TCP stream simultaneously blocks all transactions being accessed via that connection. This head-of-line blocking in HTTP/2 is now widely regarded as a design flaw, and much of the effort behind QUIC and HTTP/3 has been devoted to reduce head-of-line blocking issues.{{cite web|url=http://www.circleid.com/posts/20190304_a_quick_look_at_quic/|title=A Quick Look at QUIC|website=www.circleid.com|language=en|access-date=2019-08-02|first=Geoff |last=Huston|date=2019-03-04}}{{cite web|url=https://engineering.salesforce.com/the-full-picture-on-http-2-and-hol-blocking-7f964b34d205|title=The Full Picture on HTTP/2 and HOL Blocking|last=Gal|first=Shauli|date=2017-06-22|website=Medium|language=en|access-date=2019-08-03}}

{{Main|Comparison of web server software}}

The following web servers support HTTP/2:

• Apache httpd 2.4.12 supports HTTP/2 via the module mod_h2,{{cite web|url=https://icing.github.io/mod_h2/ |title=http/2 module for apache httpd|access-date=July 28, 2015}} although appropriate patches must be applied to the source code of the server in order for it to support that module. As of Apache 2.4.17 all patches are included in the main Apache source tree, although the module itself was renamed mod_http2.{{cite web|url=https://archive.apache.org/dist/httpd/CHANGES_2.4.17|title=Apache 2.4.17 release changelog|access-date=August 22, 2017}} Old versions of SPDY were supported via the module mod_spdy,{{cite web|url=https://googledevelopers.blogspot.de/2014/06/modspdy-is-now-apache-project.html|title=mod_spdy is now an Apache project|author= Matthew Steele|date=June 19, 2014|work=Google Developers Blog}} however the development of the mod_spdy module has stopped.{{cite web|url=https://svn.apache.org/viewvc/httpd/mod_spdy/?view=log|title=Log of /httpd/mod_spdy|access-date=February 3, 2017 |website=svn.apache.org}}
• Apache Tomcat 8.5 (requires a configuration change){{cite web|url=https://tomcat.apache.org/migration-9.html#HTTP/2_support_added|title=Apache Tomcat Migration|access-date=July 29, 2016}}
• Apache Traffic Server{{cite web|url=https://trafficserver.apache.org/downloads|website=trafficserver.apache.org|title=Apache Traffic Server Downloads|date=September 21, 2015}}
• Caddy{{Cite web|last=Server|first=Caddy Web|title=Caddy 2 - The Ultimate Server with Automatic HTTPS|url=https://caddyserver.com/|access-date=2020-08-08|website=caddyserver.com|date=March 23, 2016}}
• Charles Proxy since version Charles 4.{{Cite web|date=2016-08-02|title=Charles 4 has HTTP/2|url=https://publicobject.com/2016/08/02/charles-4-has-http2/|access-date=2020-10-12|website=Public Object|language=en}}
• Citrix NetScaler 11.x{{cite web|url=https://blogs.citrix.com/2015/08/06/3-simple-steps-to-bring-http2-performance-to-legacy-web-applications/|title=3 Simple Steps to Bring HTTP/2 Performance to Legacy Web Applications|date=September 22, 2015}}
• Sucuri{{cite web|title=Sucuri += HTTP/2 — Announcing HTTP/2 Support|url=https://blog.sucuri.net/2015/11/sucuri-announcing-http2-support.html|website=Sucuri|date=November 27, 2015 |access-date=December 5, 2015}}
• F5 BIG-IP Local Traffic Manager 11.6{{cite web|url=https://devcentral.f5.com/articles/goodbye-spdy-hello-http2|title=Goodbye SPDY, Hello HTTP/2|access-date=September 18, 2015|author1=Robert Haynes|publisher=F5 Networks}}
• Barracuda Networks WAF (Web Application Firewall){{cite web|url=https://blog.barracuda.com/2016/07/05/new-features-capabilities-added-to-barracuda-web-application-firewall|title=New features, capabilities added to Barracuda Web Application Firewall|author=Risov Chakrabortty|date=July 5, 2016 |publisher=Barracuda Networks}}
• h2o (built from the ground up for HTTP/2 support){{cite web|url=https://h2o.examp1e.net/|title=H2O - the optimized HTTP/2 server|website=h2o.examp1e.net}}
• HAProxy 1.8{{cite web|url=https://www.haproxy.com/blog/whats-new-haproxy-1-8/|website=haproxy.com|access-date=February 9, 2018|title=What's New in HAProxy 1.8|date=November 2017 }}
• Jetty 9.3{{cite web|url=https://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/VERSION.txt|title=Jetty change log|access-date=May 28, 2015|publisher=Eclipse Foundation.|date=May 28, 2015}}
• lighttpd 1.4.56{{citation|url=https://redmine.lighttpd.net/issues/2813|title=Feature #2813: Support for HTTP/2 protocol|work=Lighttpd}}
• LiteSpeed Web Server 5.0{{cite web|url=https://blog.litespeedtech.com/2015/04/17/lsws-5-0-is-out-support-for-http2-esi-litemage-cache/|title=LSWS 5.0 Is Out – Support for HTTP/2, ESI, LiteMage Cache|date=April 17, 2015}}
• Microsoft IIS (in Windows 10,{{cite web|url=https://blogs.msdn.com/b/ie/archive/2014/10/08/http-2-the-long-awaited-sequel.aspx|title=HTTP/2: The Long-Awaited Sequel|date=October 8, 2014|author1=Rob Trace|author2=David Walp|work=MSDN IEBlog|publisher=Microsoft Corporation}} Windows Server 2016, and Windows Server 2019)
• Netty 4.1{{cite web|url=https://netty.io/news/2016/05/26/4-1-0-Final.html|title=Netty.news: Netty 4.1.0.Final released|website=netty.io|access-date=June 1, 2016}}
• nghttpd (exclusively implements HTTP/2)
• nginx 1.9.5{{cite web|url=https://nginx.org/en/CHANGES|title=nginx changelog|website=www.nginx.com|date=2015-09-22}} released on September 22, 2015, using module ngx_http_v2_module and HTTP/2 Server Push since version 1.13.9 on February 20, 2018.{{cite web|url=https://nginx.org/en/CHANGES-1.14 |title=Changes with nginx 1.14.2 |date=December 4, 2018 |website=nginx.org |access-date=2019-09-27}}
• Node.js 8.13.0{{cite web|url=https://nodejs.org/en/blog/release/v8.13.0/|title=Node v8.13.0 (LTS)|last=Foundation|first=Node js|website=Node.js|date=November 20, 2018 |language=en|access-date=2019-06-05}} (A separate module is available for Node.js 5.0{{cite web|url=https://github.com/molnarg/node-http2|title=Node http2|website=www.github.com|date=July 26, 2016}} and Node 8.4 introduced experimental built-in support for HTTP/2.{{cite web|url=https://nodejs.org/en/blog/release/v8.4.0/|title=Node v8.4.0 (Current)|website=nodejs.org|date=August 15, 2017}})
• [https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel Kestrel web server] for ASP.NET Core supports HTTP/2 since .NET Core 2.2.0-preview 1.{{Cite news|url=https://devblogs.microsoft.com/aspnet/asp-net-core-2-2-0-preview1-http-2-in-kestrel/|title=ASP.NET Core 2.2.0-preview1: HTTP/2 in Kestrel|access-date=2021-04-06|language=en-US}}
• OpenLiteSpeed 1.3.11 and 1.4.8{{cite web|url=https://open.litespeedtech.com/mediawiki/index.php/Release_Log/1.x#V1.4.5|title=OpenLiteSpeed 1.4.5 change log|access-date=February 26, 2015|publisher=LiteSpeed Technologies, Inc.|date=February 26, 2015}}
• [https://github.com/facebook/proxygen Proxygen]
• Pulse Secure Virtual Traffic Manager 10.2{{cite web|url=https://www.pulsesecure.net/vtm/|title=Pulse Virtual Traffic Manager|date=August 22, 2017}}
• Radware Alteon NG{{cite web|url=https://www.radware.com/newsevents/pressreleases/radware-alteon-provides-fastest-website-acceleration/|title=Radware Combines an Integrated HTTP/2 Gateway with its Leading Fastview Technology to Provide Web Server Platforms Increased Acceleration|date=July 20, 2015}}
• ShimmerCat{{cite web|url=https://www.shimmercat.com/|title=www.shimmercat.com|date=March 23, 2016|access-date=March 23, 2016|archive-date=March 31, 2022|archive-url=https://web.archive.org/web/20220331025648/https://www.shimmercat.com/|url-status=dead}}
• Vert.x 3.3
• Warp (Haskell web server, used by default in Yesod)
• Wildfly 9
• [https://www.envoyproxy.io Envoy proxy]

• Akamai was the first major CDN to support HTTP/2 and HTTP/2 Server Push.
• Microsoft Azure supports HTTP/2.
• PageCDN supports HTTP/2 out of the box and provides user-interface to setup HTTP/2 Server Push in CDN dashboard.{{cite web|title=Why PageCDN, and what problem does it solve?|url=https://pagecdn.com/about/why|website=PageCDN|access-date=January 11, 2020}}
• CDN77 supports HTTP/2 using nginx (August 20, 2015).
• Cloudflare supports HTTP/2 using nginx with SPDY as a fallback for browsers without support, whilst maintaining all security and performance services.{{cite web|title=HTTP/2 is here! Goodbye SPDY? Not quite yet|url=https://blog.cloudflare.com/introducing-http2/|website=CloudFlare|access-date=December 5, 2015}} Cloudflare was the first major CDN to support HTTP/2 Server Push.{{cite web|last1=Krasnov|first1=Vlad|title=Announcing Support for HTTP/2 Server Push|url=https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/|website=CloudFlare|access-date=May 18, 2016|date=April 28, 2016}}
• AWS CloudFront supports HTTP/2{{cite web|url=https://aws.amazon.com/about-aws/whats-new/2016/09/amazon-cloudfront-now-supports-http2/|title=Amazon CloudFront now supports HTTP/2|website=Amazon Web Services, Inc.|access-date=2016-09-08}} since September 7, 2016.
• Fastly supports HTTP/2 including Server Push.{{cite web|url=https://www.fastly.com/blog/announcing-limited-availability-http2|title=Announcing Limited Availability for HTTP/2|date=June 30, 2016 |access-date=August 22, 2017}}
• Imperva Incapsula CDN supports HTTP/2.{{cite web|url=https://www.imperva.com/blog/http2-is-here-what-you-need-to-know/|title=HTTP/2 is here: What You Need to Know|access-date=November 1, 2015}} The implementation includes support for WAF and DDoS mitigation features as well.
• KeyCDN supports HTTP/2 using nginx (October 6, 2015). [https://tools.keycdn.com/http2-test/ HTTP/2 Test] is a test page to verify if your server supports HTTP/2.
• BrandSSL supports HTTP/2.
• Voxility supports HTTP/2 using nginx since July, 2016. The implementation comes in support for Cloud DDoS mitigation services.{{cite web|url=https://www.information-age.com/http2-more-risk-cyber-attacks-123461771/|title=HTTP/2 more at risk to cyber attacks?|date=2016-08-03|website=Information Age|language=en|access-date=2019-02-04}}
• StackPath supports HTTP/2.

• Other implementations are collected on the [https://github.com/http2/http2-spec/wiki/Implementations GitHub HTTP/2 wiki].

• gRPC
• HTTP pipelining
• HTTP request and response messages
• HTTP/3
• QUIC
• SPDY
• WebSocket
• Web Server
• Web Browser
• {{Section link|Comparison of web browsers|Protocol support}}

{{Reflist}}

• {{Official website}}
• {{github|http2|HTTP/2}}
• {{IETF RFC|7540}} – Hypertext Transfer Protocol version 2 (HTTP/2)
• {{IETF RFC|7541}} – HPACK: Header Compression for HTTP/2
• [https://http2-explained.haxx.se/ HTTP/2 explained] (Daniel Stenberg)
• [//tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00 SPDY Protocol] (draft-mbelshe-httpbis-spdy-00)
• [//tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-01 HTTP Speed+Mobility] (draft-Montenegro-httpbis-speed-mobility-01)
• [//tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00 Proposal for a Network-Friendly HTTP Upgrade] (draft-tarreau-httpbis-network-friendly-00)

{{Web interfaces}}

{{Web browsers|fsp}}

{{DEFAULTSORT:HTTP 2}}

Category:Hypertext Transfer Protocol

Category:Application layer protocols

Category:Internet properties established in 2015