Downloaded 30 times
Uploaded byAdrian Cardenas
Http/2
This document discusses HTTP/2, including a brief history of HTTP 1.x, the development of SPDY which became the basis for HTTP/2, the key features of HTTP/2 like binary framing, streams, header compression and server push, considerations for transitioning from HTTP 1.x to HTTP/2, and strategies for optimizing performance with HTTP/2. It recommends benchmarking optimizations and transitioning first internal APIs, then public APIs and CDNs, followed by front-end applications and proxies.
More Related Content
![[BDD 2025 - Full-Stack Development] Agentic AI Architecture: Redefining Syste...](https://cdn.slidesharecdn.com/ss_thumbnails/fs-agenticaiarchitectureredefiningsystemcommunication-251124030838-e6c70cc2-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Full-Stack Development] The Modern Stack: Building Web & AI Appli...](https://cdn.slidesharecdn.com/ss_thumbnails/fs-themodernstackbuildingwebaiapplicationswithserverless-251124030844-388cf04f-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Artificial Intelligence] Building AI Systems That Users (and Comp...](https://cdn.slidesharecdn.com/ss_thumbnails/ai-buildingaisystemsthatusersandcompanieslove-251124030845-038f7732-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Mobile Development] Crafting Immersive UI with E2E and AGSL Shade...](https://cdn.slidesharecdn.com/ss_thumbnails/md-craftingimmersiveuiwithe2eandagslshaderveronicaputrianggraini-251124030840-0c677f44-thumbnail.jpg?width=640&height=640&fit=bounds)
Http/2
- 1. HTTP/2 The (not so)new Language of the Web
- 2. Software Engineer All aroundnerd Systems Administrator for 7 years @aramonc in all the places About Me
- 3. Slight History ofHTTP 1.x ● World Wide Web first proposed by Tim Berners-Lee & team in 1989 ● First documented in 1991 in HTTP 0.9 ○ Request only GET ○ Response only HTML ● Officially documented in RFC 1945 as HTTP 1.0 in 1996 ○ HTTP 1.1 was already in draft ○ Documented common use cases from existing web browsers ○ Not a standard ● HTTP 1.1 became official standard in 1997 ○ Defined in RFC 2068 ○ Additions & Disambiguations added in 1999 as RFC 2616 ○ Supported by most browsers and tools since early drafts ○ Re-written into multiple proposed RFCs between 2007 & 2014
- 4. Then Came SPDY ●Binary protocol worked on by Mike Belshe & Roberto Peon at Google ● Implemented on Chrome & GFE servers between 2009 & 2014 ● Introduced to Mark Nottingham of the IETF HTTPBIS working group in 2012 ● Became the basis of HTTP/2
- 5. Binary Protocol Features ●Binary framing ● Streams ● Request & response multiplexing ● Stream prioritization ● Single connection per origin ● Flow control ● Server Push ● Header Compression
- 6. The Final HTTP/ 2 RFC(s) ● Hypertext Transfer Protocol version 2 - RFC7540 ○ Describes the new internals of the protocol ○ Designed for low latency ● HPACK - Header Compression for HTTP/2 - RFC7541 ● Published in May 2015
- 7. Implementations Apache 2.4.17 F5 (upcomingrelease) Jetty ~7.6.13 IIS Server 2016 Nginx 1.9.5 Akamai ~2015 cURL 7.38.0 WireShark 1.11 IE 11 (Windows 10 only) Edge 2 Chrome 41 Firefox 36
- 8.
- 9. Binary Framing ● Similarto TCP packets ● Frames contain distinct data (headers, payload, etc) ● Frames are indexed ● Fixed length Length Flags Identifier Payload
- 10. Streams ● Bidirectional flowof bytes within a connection ● May carry one or more messages ● Single TCP connection can carry several streams ● Have identifiers ● Can be prioritized
- 11.
- 12. Capable of Multiplexing ●Frames in different streams can be interleaved ● Solves Head-of-Line blocking by Ilya Grigorik
- 13. Header Compression ● OriginalSPDY compression was vulnerable ● HPACK used in HTTP/2 ● HPACK uses 2 compression techniques ○ Huffman compression ○ Client & Server must keep indexed list of previously seen headers
- 14. Header Compression by IlyaGrigorik
- 15. Server Push ● Serverknows content needed ● Server sends a PUSH_PROMISE frame ● Client can decide to accept frame or reset it ● Currently still experimental
- 16. TLS Only ● Notmandated by the standard ● Chrome & Firefox stated they will not support without TLS ● Performance issues balanced in single connection scenario ● http://letsencrypt.org
- 17. Connection Upgrade ● ALPNduring TLS hand-shake ○ Recommended ● Connection & Upgrade headers
- 18. DoS Vectors ● Singleconnection reduces many vectors ● TCP is still point of failure ● HPACK & required buffering can be memory intensive ● HPACK can be used to increase payload ● Header frames cannot be interrupted
- 19. What does thisMean for you? ● Increased performance ○ Conservative measure of 5% to 15% ● Decreased resource use ● New tools for debugging & monitoring ● Happier customers ● Time to switch
- 20. It’s for Everyone ●Reduces battery use in mobile devices ● Reduces CPU use in the server level ● Overall fewer costs
- 21. Transition Plan ● Knowyour application as it is ● Which strategy is best for your customers ● Optimizations you might need to change ● Benchmark before & after every change ● Deploy
- 22. Transition Plan 1. Internal/ Backend APIs 2. Public APIs 3. CDNs 4. Front end applications 5. Load balancers & other proxies
- 23. Transition Strategies ● Sitand wait ● Adopt HTTP/2 completely ● Hybrid approach
- 24. Optimize, Fine Tune ●Applications currently compensate for shortcomings in HTTP 1.1 ● Most optimizations still ok ○ Maybe different ● Re-optimize assets to take advantage of new features ● No changes to use of CDNs
- 25. Detrimental Optimizations ● Domainsharding ● Inline assets ● Image sprites ● Concatenated resources
- 26. Hybrid Approach ● Forfront-end servers ● HTTP/2 capable proxy ● Proxy terminates TLS ● Forwards requests to servers with appropriate optimizations ● More costly approach
- 27. Benchmarks, Benchmarks, Benchmarks ●Load Impact comparison tool ○ http://http2.loadimpact.com/entry/ ● Plugin for JMeter ● h2load ● Test all optimizations
- 28. Resources ● http://http2.github.io ● HighPerformance Browser Networking - http://bit.ly/1PWhBQ3 ● Google HTTP/2 podcasts - http://bit.ly/1QgUrUP ● http://caniuse.com/#feat=http2 ● HTTP/2 is here, let’s optimize - http://bit.ly/20KJq5I
- 29.
Editor's Notes
- #4 When we refer to the Internet today, we’re actually talking about what Tim Berners-Lee referred to as the World Wide Web in 1989. It was not a formal thing with standards or specifications, it was just an idea for requesting and transferring ASCII documents over the newly created internet. Before this there was only email, FTP, and USENET boards. All of which were interactive by their nature. You had to request that someone send you a document. The World Wide Web project eventually also defined its own protocol in HTTP & was documented as HTTP 0.9 in 1991. At this time it was a very simple HTML document addressing & retrieval system. This would not be officially documented until 1996 as a sort of after the fact standard. The RFC document common practices in the wild amongst companies like Netscape and Microsoft. This was later revised and then revised again and again between 2007 & 2014 because the revisions and additions were written by several people using slightly different language. All of which combined to make the HTTP 1.1 standard somewhat ambiguous and difficult to implement leading to slightly different behaviours amongst implementers according to Mark Nottingham, chairman of the IETF HTTPBis working group.
- #5 At the same time as Roy Fielding & Mark Nottingham were working on revising HTTP 1.1, Mike Belshe & Roberto Peon had come up with SPDY at Google. SPDY was meant to be a binary, low latency replacement for HTTP that maintained the HTTP semantics. Belshe & Peon worked on the Chrome and GFE teams at Google independently and started to implement this new protocol around 2009 as a proof of concept. There had been a similar attempt at a binary protocol with HTTPNG, but that never took off. According to an interview with Mark Nottingham, he met with Mike Belshe in 2012 & was so impressed with the concept & performance numbers that Google was seeing with SPDY that he scheduled a presentation at the next session of the HTTPBIS working group. They then decided to created a new version of the standard using SPDY as a starting point.
- #6 The binary protocol differs from HTTP 1.1 in that information is transmitted in a fixed length binary package which we’ll go into later as opposed to plain text documents. I will not cover all of the features as most don’t directly affect developers, but you should be aware of all of tem.
- #7 The new standard was worked on between 2013 and 2015. The original specification for SPDY had a few things that did not mesh well with all of the members of working group, such as a requirement for resolution over TLS only and that it didn’t take much into account non web uses of HTTP. The SPDY specification also used zlib for header compression and this was found to have a vulnerability a little over halfway through the process. The working group ended up with 2 RFCs, one to describe the new binary protocol and one to describe a new header compression mechanism. These were officially published & accepted by the IETF as proposed standards in May of 2015. By then there were already several implementations amongst client & server softwares of earlier drafts.
- #8 The HTTP/2 documentation repo maintains a list of implementations which is by no means exhaustive. For example there are very few tools mentioned in the list, but a quick search reveals plugins for JMeter and other benchmarking tools. Also Cloudflare has released blog posts indicating that they’re also working on an implementation for their global netowrk. This is a sample of the implementations from that list plus the approximate version of when the software started to support HTTP/2. For some of these finding the version that started supporting HTTP2 was not simple.
- #9 The majority of all browser vendors have implemented HTTP/2 fully as of the latest release with the exception of some deprecated mobile browsers such as Android Browser. For a detailed list of current browser implementations you can go to caniuse.com & search for HTTP/2 and then click the Show All toggle.
- #10 You may be wondering what makes binary framing so special if TCP is already transmitted as binary packets. Binary framing borrows the same concept of a TCP packet in that it divides the content being transmitted into distinct units that contain metadata about the content in fixed length binary fields. Each frame contains an identifier that tells the receiver the request/response it belongs to and the type of payload it’s carrying. This is what really enables the majority of the features in the binary protocol. The content can be things like headers, request or response body chunks, other meta data. There are about 7 or 8 different content types. Now this also makes it easier for the receiver to parse the content. The receiver knows the length of the content and it knows what kind of content it’s looking at. With HTTP 1.1 the receiver gets an entire plain text message and the application has to guess at where things like headers end & the content begins, what whitespace is significant and what isn’t, etc. With a binary protocol, that’s all gone and the receiver can can parse the content of each frame much faster.
- #11 So now that we have binary frames with identifiers we can also define streams to carry and associate all of the frames related to a single request / response messages. You can send settings frames to have a common contract between the client & server on how to deal with the stream. You can send a prioritization frame to let the receiver know which stream is more important or define dependencies.
- #18 Application Layer Protocol Negotiation Transport Layer Security