Http/2 lightning
•Download as PPTX, PDF•
1 like•525 views
HTTP has a new specification (two actually) and has received a major overhaul of some of it's internals. While the protocol itself has not changed much, the transfer mechanism and other underlying systems have been completely re-worked. Adrian will expand on what has and has not changed, how to make the best use of it, and how to transition to the new standard if you need to.
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to Http/2 lightning
Similar to Http/2 lightning (20)
Recently uploaded
Recently uploaded (20)
Http/2 lightning
- 1. HTTP/2 The (not so) new Language of the Web
- 2. Binary Protocol Features ● Binary framing ● Streams ● Request & response multiplexing ● Stream prioritization ● Single connection per origin ● Flow control ● Server Push ● Header Compression
- 3. 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
- 4. Implementations Apache 2.4.17 F5 (upcoming release) 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
- 6. Binary Framing ● Similar to TCP packets ● Frames contain distinct data (headers, payload, etc) ● Frames are indexed ● Fixed length Length Flags Identifier Payload
- 7. Streams ● Bidirectional flow of bytes within a connection ● May carry one or more messages ● Single TCP connection can carry several streams ● Have identifiers ● Can be prioritized
- 9. Capable of Multiplexing ● Frames in different streams can be interleaved ● Solves Head-of-Line blocking by Ilya Grigorik
- 10. Header Compression ● Original SPDY 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
- 11. Header Compression by Ilya Grigorik
- 12. Server Push ● Server knows content needed ● Server sends a PUSH_PROMISE frame ● Client can decide to accept frame or reset it ● Currently still experimental
- 13. TLS Only ● Not mandated by the standard ● Chrome & Firefox stated they will not support without TLS ● Performance issues balanced in single connection scenario ● http://letsencrypt.org
- 14. Transition Plan ● Know your application as it is ● Which strategy is best for your customers ● Optimizations you might need to change ● Benchmark before & after every change ● Deploy
- 15. Transition Plan 1. Internal / Backend APIs 2. Public APIs 3. CDNs 4. Front end applications 5. Load balancers & other proxies
- 16. Transition Strategies ● Sit and wait ● Adopt HTTP/2 completely ● Hybrid approach
- 17. Resources ● http://http2.github.io ● High Performance 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
- 18. Thank You!
Editor's Notes
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.