HTTP/2 (or “H2” as the cool kids call it) has been ratified for months, and browsers already support or have committed to supporting the protocol. Everything we hear tells us that the new version of HTTP will provide significant performance benefits while requiring little to no change to our applications—all the problems with HTTP/1.x have seemingly been addressed; we no longer need the “hacks” that enabled us to circumvent them; and the Internet is about to be a happy place at last.
But maybe we should put the pom-poms down for a minute. Deploying HTTP/2 may not be as easy as it seems since the protocol brings with it new complications and issues. Likewise, the new features the spec introduces may not work as seamlessly as we hope. Hooman Beheshti examines HTTP/2’s core features and how they relate to real-world conditions, discussing the positives, negatives, new caveats, and practical considerations for deploying HTTP/2.
Topics include:
The single-connection model and the impact of degraded network conditions on HTTP/2 versus HTTP/1
How server push interacts (or doesn’t) with modern browser caches
What HTTP/2’s flow control mechanism means for server-to-client communication
New considerations for deploying HPACK compression
Difficulties in troubleshooting HTTP/2 communications, new tools, and new ways to use old tools
HTTP/2 for Developers: How It Changes Developer's Life?
by Svetlin Nakov (SoftUni) - http://www.nakov.com
jProfessionals Conference - Sofia, 22-Nov-2015
Key new features in HTTP/2
- Multiplexing: multiple streams over a single connection
- Header compression: reuse headers from previous requests
- Sever push: multiple parallel responses for a single request
- Prioritization and flow control: resources have priorities
A technical description of http2, including background of HTTP what's been problematic with it and how http2 and its features improves the web.
See the "http2 explained" document with the complete transcript and more: http://daniel.haxx.se/http2/
(Updated version to slides shown on April 13th, 2016)
HTTP/2 (or “H2” as the cool kids call it) has been ratified for months, and browsers already support or have committed to supporting the protocol. Everything we hear tells us that the new version of HTTP will provide significant performance benefits while requiring little to no change to our applications—all the problems with HTTP/1.x have seemingly been addressed; we no longer need the “hacks” that enabled us to circumvent them; and the Internet is about to be a happy place at last.
But maybe we should put the pom-poms down for a minute. Deploying HTTP/2 may not be as easy as it seems since the protocol brings with it new complications and issues. Likewise, the new features the spec introduces may not work as seamlessly as we hope. Hooman Beheshti examines HTTP/2’s core features and how they relate to real-world conditions, discussing the positives, negatives, new caveats, and practical considerations for deploying HTTP/2.
Topics include:
The single-connection model and the impact of degraded network conditions on HTTP/2 versus HTTP/1
How server push interacts (or doesn’t) with modern browser caches
What HTTP/2’s flow control mechanism means for server-to-client communication
New considerations for deploying HPACK compression
Difficulties in troubleshooting HTTP/2 communications, new tools, and new ways to use old tools
HTTP/2 for Developers: How It Changes Developer's Life?
by Svetlin Nakov (SoftUni) - http://www.nakov.com
jProfessionals Conference - Sofia, 22-Nov-2015
Key new features in HTTP/2
- Multiplexing: multiple streams over a single connection
- Header compression: reuse headers from previous requests
- Sever push: multiple parallel responses for a single request
- Prioritization and flow control: resources have priorities
A technical description of http2, including background of HTTP what's been problematic with it and how http2 and its features improves the web.
See the "http2 explained" document with the complete transcript and more: http://daniel.haxx.se/http2/
(Updated version to slides shown on April 13th, 2016)
Learn about HTTP/2 and its relationship to HTTP 1.1 and SPDY. Understand core features and how they benefit security and browser efficiency. More that a "what's new" this talk will leave you with an understanding of why choices in HTTP/2 were made. You'll leave knowing what HTTP/2 is and why it is better for clients and servers.
HTTP 1.1, which is the backbone of pretty much everything we’ve been using on the Internet, has been around for over 15 years. Recently the HTTP 2.0 specification has been completed and gradually application servers will start supporting it. It does make one wonder though: why change if something has been working for so long. In this talk we’ll examine the shortcomings of HTTP 1.1 and how 2.0 intends to address those. We’ll see what we need to know and how it’s going to affect our existing applications, and future ones.
HTTP/2 and QUICK protocols. Optimizing the Web stack for HTTP/2 erapeychevi
The new HTTP/2 protocol which is going to replace HTTP 1.1 was finished on February. Together with it, QUIC is being developed rapidly. Discover why are they so important for the Web and how will they influence the way we optimize the Web stack for the HTTP/2 era.
Matt Summers, NCC Group - Web technology has changed a lot in the last 25 years but the underlying transport mechanism has stayed the same. The web we have today was not designed for the plethora of new device types and communication methods but things are changing and you probably don’t even know it. You probably don’t even notice the problem because it is so ingrained. In this presentation we are going to delve into the problems with the web and how we use it today. We will also take an in depth look at the proposed solutions for the next generation web and the implications that come with it.
HTTP/3 over QUIC. All is new but still the same!Daniel Stenberg
HTTP/3 is the designated name for the coming next version of the protocol that is currently under development within the QUIC working group in the IETF. HTTP/3 is designed to improve in areas where HTTP/2 still has some shortcomings, primarily by changing the transport layer. HTTP/3 is the first major protocol to step away from TCP and instead it uses QUIC.
Daniel Stenberg does a presentation about HTTP/3 and QUIC. Why the new protocols are deemed necessary, how they work, how they change how things are sent over the network and what some of the coming deployment challenges will be.
HTTP is one of the most widely used protocols in the world.
The version of HTTP 1.1, used to this day, was developed and described 18 years ago - 1999.
With the increasing complexity of web applications, the capabilities of HTTP 1.1 are already insufficient to provide increased demands on performance and responsiveness.
So in order to meet new requirements, HTTP must evolve. HTTP 2.0 is designed to make web applications faster, simple and reliable.
In this report I will tell about
- drawbacks of HTTP 1.1 and why we need a new version of HTTP.
- which advantages HTTP/2 offers in comparison with the previous version?
- how the new protocol affected the new version of SERVLET 4.0 and how we can use it.
RFC 7540 was ratified over 2 years ago and, today, all major browsers, servers, and CDNs support the next generation of HTTP. Just over a year ago, at Velocity (https://www.slideshare.net/Fastly/http2-what-no-one-is-telling-you), we discussed the protocol, looked at some real world implications of its deployment and use, and what realistic expectations we should have from its use.
Now that adoption is ramped up and the protocol is being regularly used on the Internet, it's a good time to revisit the protocol and its deployment. Has it evolved? Have we learned anything? Are all the features providing the benefits we were expecting? What's next?
In this session, we'll review protocol basics and try to answer some of these questions based on real-world use of it. We'll dig into the core features like interaction with TCP, server push, priorities and dependencies, and HPACK. We'll look at these features through the lens of experience and see if good practice patterns have emerged. We'll also review available tools and discuss what protocol enhancements are in the near and not-so-near horizon.
Bart Salaets – is Solutions Architect in F5 Networks specifically focusing on service providers in the EMEA region. Prior to this, he has held IP consulting and technical leadership positions in Juniper Networks, Redback Networks and Alcatel-Lucent, giving him more than 15 years of experience in both fixed and mobile broadband IP network design. Bart Salaets was born and still lives in Belgium and holds a Masters degree in Electrical Engineering from the Catholic University of Leuven, Belgium and an MBA from Flanders Business School in Antwerp, Belgium.
Topic of Presentation: Optimising TCP in today’s changing network environment
Language: English
Abstract: The need to juggle performance across wired, wireless and wi-fi networks is a challenge as each of these paths has very different characteristics when it comes to TCP. Tuning the TCP stack to be optimized for the varying degrees of packet loss, latency and congestion on the different connection types is a challenge. This session will cover tuning several aspects of your network and the underlying TCP stack to deliver an optimized application experience for all users. Topics will include:
Choosing the correct Congestion Control algorithm
Optimizing TCP with techniques like TCP buffering and adjusting TCP window sizes
Rate-based pacing to help multiple request/responses over a single connection
Learn about HTTP/2 and its relationship to HTTP 1.1 and SPDY. Understand core features and how they benefit security and browser efficiency. More that a "what's new" this talk will leave you with an understanding of why choices in HTTP/2 were made. You'll leave knowing what HTTP/2 is and why it is better for clients and servers.
HTTP 1.1, which is the backbone of pretty much everything we’ve been using on the Internet, has been around for over 15 years. Recently the HTTP 2.0 specification has been completed and gradually application servers will start supporting it. It does make one wonder though: why change if something has been working for so long. In this talk we’ll examine the shortcomings of HTTP 1.1 and how 2.0 intends to address those. We’ll see what we need to know and how it’s going to affect our existing applications, and future ones.
HTTP/2 and QUICK protocols. Optimizing the Web stack for HTTP/2 erapeychevi
The new HTTP/2 protocol which is going to replace HTTP 1.1 was finished on February. Together with it, QUIC is being developed rapidly. Discover why are they so important for the Web and how will they influence the way we optimize the Web stack for the HTTP/2 era.
Matt Summers, NCC Group - Web technology has changed a lot in the last 25 years but the underlying transport mechanism has stayed the same. The web we have today was not designed for the plethora of new device types and communication methods but things are changing and you probably don’t even know it. You probably don’t even notice the problem because it is so ingrained. In this presentation we are going to delve into the problems with the web and how we use it today. We will also take an in depth look at the proposed solutions for the next generation web and the implications that come with it.
HTTP/3 over QUIC. All is new but still the same!Daniel Stenberg
HTTP/3 is the designated name for the coming next version of the protocol that is currently under development within the QUIC working group in the IETF. HTTP/3 is designed to improve in areas where HTTP/2 still has some shortcomings, primarily by changing the transport layer. HTTP/3 is the first major protocol to step away from TCP and instead it uses QUIC.
Daniel Stenberg does a presentation about HTTP/3 and QUIC. Why the new protocols are deemed necessary, how they work, how they change how things are sent over the network and what some of the coming deployment challenges will be.
HTTP is one of the most widely used protocols in the world.
The version of HTTP 1.1, used to this day, was developed and described 18 years ago - 1999.
With the increasing complexity of web applications, the capabilities of HTTP 1.1 are already insufficient to provide increased demands on performance and responsiveness.
So in order to meet new requirements, HTTP must evolve. HTTP 2.0 is designed to make web applications faster, simple and reliable.
In this report I will tell about
- drawbacks of HTTP 1.1 and why we need a new version of HTTP.
- which advantages HTTP/2 offers in comparison with the previous version?
- how the new protocol affected the new version of SERVLET 4.0 and how we can use it.
RFC 7540 was ratified over 2 years ago and, today, all major browsers, servers, and CDNs support the next generation of HTTP. Just over a year ago, at Velocity (https://www.slideshare.net/Fastly/http2-what-no-one-is-telling-you), we discussed the protocol, looked at some real world implications of its deployment and use, and what realistic expectations we should have from its use.
Now that adoption is ramped up and the protocol is being regularly used on the Internet, it's a good time to revisit the protocol and its deployment. Has it evolved? Have we learned anything? Are all the features providing the benefits we were expecting? What's next?
In this session, we'll review protocol basics and try to answer some of these questions based on real-world use of it. We'll dig into the core features like interaction with TCP, server push, priorities and dependencies, and HPACK. We'll look at these features through the lens of experience and see if good practice patterns have emerged. We'll also review available tools and discuss what protocol enhancements are in the near and not-so-near horizon.
Bart Salaets – is Solutions Architect in F5 Networks specifically focusing on service providers in the EMEA region. Prior to this, he has held IP consulting and technical leadership positions in Juniper Networks, Redback Networks and Alcatel-Lucent, giving him more than 15 years of experience in both fixed and mobile broadband IP network design. Bart Salaets was born and still lives in Belgium and holds a Masters degree in Electrical Engineering from the Catholic University of Leuven, Belgium and an MBA from Flanders Business School in Antwerp, Belgium.
Topic of Presentation: Optimising TCP in today’s changing network environment
Language: English
Abstract: The need to juggle performance across wired, wireless and wi-fi networks is a challenge as each of these paths has very different characteristics when it comes to TCP. Tuning the TCP stack to be optimized for the varying degrees of packet loss, latency and congestion on the different connection types is a challenge. This session will cover tuning several aspects of your network and the underlying TCP stack to deliver an optimized application experience for all users. Topics will include:
Choosing the correct Congestion Control algorithm
Optimizing TCP with techniques like TCP buffering and adjusting TCP window sizes
Rate-based pacing to help multiple request/responses over a single connection
Cleaning Up the Dirt of the Nineties - How New Protocols are Modernizing the WebSteffen Gebert
About HTTP/2, QUIC, and Multipath TCP.
Download of PDF file recommended (Slideshare screws backgrounds up)
Talk at the TYPO3camp Vienna
Vienna, Austria, 06.-08.05.2016
Jetty 9 – The Next Generation Servlet ContainerCodemotion
Jetty has always been known to be a technology leader in several areas—from Jetty Continuations (later standardized as Servlet 3 asynchronous servlets) to WebSocket to SPDY—delivering exceptional production performance.
Jetty 9 is not only a great production server but provides features such as the Jetty Maven plug-in and embedded Jetty that help you in application development and integration testing. This session covers Jetty 9’s scalability, stability, performance, and features such as the new HTTP client and how to configure Jetty for optimal production performance.
The web has dramatically evolved over the last 20+ years, yet HTTP - the workhorse of the Web - has not. Web developers have worked around HTTP's limitations, but:
--> Performance still falls short of full bandwidth utilization
--> Web design and maintenance are more complex
--> Resource consumption increases for client and server
--> Cacheability of resources suffers
HTTP/2 attempts to solve many of the shortcomings and inflexibilities of HTTP/1.1
Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1yKnuxS.
Omer Shapira introduces HTTP/2 (and SPDY), exploring the impact the protocol has on application design, and telling the story of LinkedIn adopting SPDY on its network infrastructure. Filmed at qconsf.com.
Omer Shapira is an engineering manager at LinkedIn. He and his team are building scalable, low-latency traffic infrastructure to keep LinkedIn site fast.
Web Performance in the Age of HTTP/2 - FEDay Conference, Guangzhou, China 19/...Holger Bartel
Web performance optimisation has been gaining ground and is slowly getting more of its deserved recognition. Now that we’ve learned to recognise this integral part of user experience and are approaching HTTP/2 as our new protocol of choice, some of our existing web performance best practices will turn into the new anti-patterns.
Talk slides from FEDay Conference in Guangzhou, China on 19/03/2016.
HTTP/3 is designed to improve in areas where HTTP/2 still has some shortcomings, primarily by changing the transport layer. HTTP/3 is the first major protocol to step away from TCP and instead it uses QUIC.
HTTP/3 is the designated name for the coming next version of the protocol that is currently under development within the QUIC working group in the IETF.
HTTP/3 is designed to improve in areas where HTTP/2 still has some shortcomings, primarily by changing the transport layer. HTTP/3 is the first major protocol to step away from TCP and instead it uses QUIC.
Daniel Stenberg does a presentation about HTTP/3 and QUIC. Why the new protocols are deemed necessary, how they work, how they change how things are sent over the network and what some of the coming deployment challenges will be.
HTTP, WebSocket, SPDY: evoluzione dei protocolli web by Simone BordetCodemotion
Questa session vi guiderà attraverso la storia e il futuro dei protocolli web, da HTTP, a WebSocket e infine a SPDY (l’ultimo nato dei protocolli web). Verranno analizzati pro e contro di ogni protocollo, il loro supporto nei browsers e nei server, concludendo con HTTP 2.0, e discutendo di come i web server dovranno cambiare per stare al passo con questi nuovi protocolli.
an overview from the HTTP2 protocol including comparison with previous version, a deeper look over the protocol enhancements, compatibility matrix with the internet ecosystem and set of online demos that can show the performance optimization.
In Jan 2012, Zynga was kind enough to invite me to speak at their SF office. These are the slides I presented; its much of the same SPDY content, although starting to focus more on mobile.
SPDY, TCP, and the Single Connection ThrottleMike Belshe
This presentation was made for the Transport Area discussion on 04/01/11 in Prague. Although SPDY is an application layer protocol, this talk focuses on how HTTP impacts the transport layer and what SPDY can do to improve it.
12. What else was there in 1998
http://web.archive.org/web/19980425182703/http://geocities.com/
13. What else was there in 1998
4/25/1998
no external scripts or css files
20 images, ~65KB entire page
http://web.archive.org/web/19980425182703/http://geocities.com/
15. HTTP/1.1
Compression
Headers
Poor connection management
Only one request can be done at a time (Half duplex)
Particularly important on high latency links (mobile)
short lived connections
security - optional
18. Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
* http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
19. Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
15%-30% of responses not compressed for no good reason!*
for SSL even worse
* http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
20. Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
15%-30% of responses not compressed for no good reason!*
for SSL even worse
no request compression
* http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
21. Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
15%-30% of responses not compressed for no good reason!*
for SSL even worse
no request compression
no header compression
* http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
31. “Lost” Capacity on each RTT
User Data: User Data:
average bandwidth average RTT
BW Mbps RTT ms
Global 1.9 Broadband 30
US 5.1 Coast-to-Coast 100
Mobile - US 1.1 3G device-GW 80-200
Mobile - EU ~2
Source: State of the Internet, Q4 2010
http://www.akamai.com/stateoftheinternet/
US Broadband: 63.7KB
US Mobile: 27.5KB
Average obj size 8.1KB
Source: HTTP Archive, 6/1/2011 data for Top 1,000
http://httparchive.org
34. Requirements
Avoid requiring the website author to change content
Allow for incremental changes
Performing "better" with content changes is okay
Performing "worse" without content changes is unacceptable
Perform always better, never worse than HTTP
Drop-in replacement from webapp's point of view
Changing the web server/application server is inevitable and therefore
acceptable
35. What is SPDY?
Goal: Reduce Web Page Load time.
Multiplexing
Better utilize client connections
Compression
HTTP headers are excessive
Uplink bandwidth is limited
Prioritization
Today the browser holds back
Priorities enable multiplexing
Encrypted & Authenticated
Eavesdropping at the Cafe must be stopped
Server Push
Websites do some of this today with data URLs
38. Deployment Status
Google
Enabled for all Google SSL traffic
On by default since Chrome 6
CDNs/Service providers:
Cotendo
39. Deployment Status
Google
Enabled for all Google SSL traffic
On by default since Chrome 6
CDNs/Service providers:
Cotendo
Server implementations:
Strangeloop
SPDY Proxy available
Others: C++, Python, Ruby, Go
40. Deployment Status
Google
Enabled for all Google SSL traffic
On by default since Chrome 6
CDNs/Service providers:
Cotendo
Server implementations:
Strangeloop
SPDY Proxy available
Others: C++, Python, Ruby, Go
Client implementation
Chrome
Android coming...
51. Not Too Shabby WebSockets
docs.google.com has a "hanging get" for every doc open
how to scale beyond 6 connections per domain?
docs[1-N].google.com
gets expensive, complicated, and is horribly inefficient
SPDY is easy, works great, efficient
Header compression mitigates the inefficiency of a hanging GET
54. Can't We Address Latency & Security Separately?
If eavesdropping in the cafe is still possible in 2020 with trivial tools, we have
failed our users.
Security is not just for banks!
Social/Mail/Content is a major target
example: Comodo attack
Firesheep tools make sniffing easy
Major content providers want privacy
Facebook opt-in
Twitter opt-in
Google working toward 100%
56. High Performance Web Sites
1.Make fewer HTTP requests
2.Use CDN
3.Add expires header
4.Gzip Components
5.Put stylesheets at the top
6.Put scripts at the bottom
7.Avoid CSS expressions
8.Make JS and CSS external
9.Reduce DNS lookups
10.Minify JS
11.Avoid redirects
12.Remove duplicate scripts
13.Configure Etags
14.Make Ajax cacheable
15.Sharding domains
57. High Performance Web Sites
1.Make fewer HTTP requests
2.Use CDN
3.Add expires header
4.Gzip Components
Du
5.Put stylesheets at the top
6.Put scripts at the bottom e
7.Avoid CSS expressions To
8.Make JS and CSS external HT
9.Reduce DNS lookups TP
10.Minify JS
Li
11.Avoid redirects m
12.Remove duplicate scripts ita
13.Configure Etags tio
14.Make Ajax cacheable ns
15.Sharding domains !
65. Rethink your optimizations
As rules change, your need to re-evaluate your best practices
13 years is a long time! start at the beginning...
But also presents many new opportunities
Delivery priorities
Smart Push
Simple web code
Automate!
66. Image Compression
Number of Requests Transfer Size in KB
Other
HTML Other HTML
7.0
6.5 99 32
Scripts
Scripts 119
13.0
Stylesheets
Stylesheets
25
3.5
Images
Images
55.0
415
Source: http://httparchive.org/trends.php?s=Top1000
67. In mobile even stronger!
Number of Requests Transfer Size in KB
Other HTML
2 Other
4 HTML
6
42
Scripts
7
Scripts
Stilesheets 80
2
Images
Images 228
31 Stilesheets
20
Source: http://mobile.httparchive.org/trends.php?s=Top1000
68. Lossy compression is the way to go!
Billy Hoffman / Zoompf
AP Photo/John Bazemore
69. Lossy-Compression is
Not for Everything
http://www.flickr.com/photos/tracy_olson/61056391/
82. SPDY actually delivers!
but we are still in the early phases
83. SPDY actually delivers!
but we are still in the early phases
participate and be part of the solution
84. SPDY actually delivers!
but we are still in the early phases
participate and be part of the solution
85. SPDY actually delivers!
but we are still in the early phases
participate and be part of the solution
Rules CAN be broken. Changes are possible!
86. SPDY actually delivers!
but we are still in the early phases
participate and be part of the solution
Rules CAN be broken. Changes are possible!
HTTP is built into the internet architecture, it can’t be changed.
87. SPDY actually delivers!
but we are still in the early phases
participate and be part of the solution
Rules CAN be broken. Changes are possible!
HTTP is built into the internet architecture, it can’t be changed.
What’s next?
88. SPDY actually delivers!
but we are still in the early phases
participate and be part of the solution
Rules CAN be broken. Changes are possible!
HTTP is built into the internet architecture, it can’t be changed.
What’s next?
89. SPDY actually delivers!
but we are still in the early phases
participate and be part of the solution
Rules CAN be broken. Changes are possible!
HTTP is built into the internet architecture, it can’t be changed.
What’s next?
Opens the door to implement new class of optimizations
90. SPDY actually delivers!
but we are still in the early phases
participate and be part of the solution
Rules CAN be broken. Changes are possible!
HTTP is built into the internet architecture, it can’t be changed.
What’s next?
Opens the door to implement new class of optimizations
91. SPDY actually delivers!
but we are still in the early phases
participate and be part of the solution
Rules CAN be broken. Changes are possible!
HTTP is built into the internet architecture, it can’t be changed.
What’s next?
Opens the door to implement new class of optimizations
Get engaged NOW!
92. Measurement - Proving us Right
No 3rd party tools (yet)!
Chrome developer tools
not good for large scale data...
w3c Web Performance tools - Navigation Timing
Supported on IE9, and Chrome 11+
http://w3c-test.org/webperf/specs/NavigationTiming/
Site metrics:
Google Analytics