Ilya Grigorik on the implementation of HTTP / 2
Well-known server and client optimization specialist, co-author of WebRTC, author of High Perfomance Browser Networking, Google's Ilya Grigorik, published the presentation “HTTP / 2 all the things!” , Which explains how to configure the server part for HTTP 2.0 in order to improve page loading speed and reduced latency compared to HTTP 1.1.
The Connection View mode in the browser shows the loading of the Yahoo.com title page elements in HTTP 1.1.
Ilya begins with the fact that for modern sites most of the delays are due to waiting for resources to load, and the bandwidth is not a limiting factor (in blue in the Connection View diagram). According to statistics, to download the average web page, the browser makes 78 requests to 12 different hosts (the total size of download files is 1232 KB).
For 1 million of the largest Internet sites, according to Alexa, on a 5-megabit channel, the average page load time is 2.413 seconds , with the CPU running only 0.735 seconds, and the rest is waiting for resources from the network (latency) to arrive.
')
HTTP 1.1 problems consist in a large number of requests, limited parallelism, not working in practice, pipelining of requests, the presence of concurrent TCP-flows, the overhead of service traffic.
Another problem is that webmasters go overboard with domain sharding. They add too many shards to bypass the browser restriction on 6 simultaneous connections with one server, and because of this they harm themselves. Traffic is repeatedly duplicated, congestion, retransmissions, etc. occur.
Problems with a large number of requests when developing applications for HTTP 1.1 are also solved in the wrong way: through concat (creating large monolithic code fragments, expensive cache invalidation, delayed execution of JSS / CSS) and inline (duplication of resources on each page, broken prioritization).
What to do?
Everything is very simple. The new HTTP 2.0 fixes many of the shortcomings of HTTP 1.1, Ilya Grigorik is sure. HTTP 2.0 does not require the establishment of multiple connections and reduces latency while maintaining the usual HTTP 1.1 semantics.
First, all the threads are mixed by splitting into frames (HEADERS, DATA, etc.), which are sent over a single TCP connection. Frames have priority and flow control. And server-push replaces inline. And, of course, effective header compression, to the point that the HEADER is “compressed” to 9 bytes (only changes are transmitted).
How specifically to use the benefits of HTTP 2.0 to optimize server applications? This is the most interesting part of the presentation of Ilya Grigorik.
Sharding specifically beats HTTP / 2 performance, breaks frame prioritization, flow control, and so on.
If necessary, you can implement sharding via
Flows are no longer a limitation, so it is possible to correctly allocate resources across modules, set a caching strategy for each of them.
The server can now issue several responses to one request. The client orders one thing, and the server can give him something else as well. Each resource is cached independently (it is not necessary to cache for each request, there is a smart push). By the way, using server-side push notifications, you can also cancel the entry in the client cache!
Smart push is generally a great thing. The server itself analyzes the traffic and builds dependencies, what resources the client requests, depending on the referrer. For example, index.html → {style.css, app.js} . In accordance with these laws, rules are created for further push notifications to new customers.
Ilya Grigorik stresses that in the case of HTTP / 2 servers must be properly configured. This wasn’t so critical in the days of HTTP / 1.1, but now it’s true. For example, in HTTP / 1.1, the browser itself first sent important requests (index.html, style, css), holding the secondary ones (hero.jpg, other.jpg, more.jpg, etc.), but now it does not. So, if you do not configure the server to process important requests in the first place, then performance will suffer.
Further, HTTP / 2 allows fine control of the stream. For example, you can first send the first few kilobytes of the image (so that the browser decodes the header and determines the size of the image), then the important scripts, and then the rest of the image.
Testing has shown that when using SPDY, latency and page loading speed are reduced by 30-40%.
For example, Twitter tested the delay in accessing the API in December 2013. The results in milliseconds are shown in the graph for the 50th, 75th, 95th, and 99th percentiles (median). Interestingly, SPDY brings more value when a client is connected via the worst communication channel (low latency locale).
Google has published its statistics to increase the speed of loading pages a year ago .
Native HTTP / 2 support will appear in the nearest stable version of Chrome 39 and in the nearest stable version of Firefox 34, so in just a few months most browsers on the Internet will support HTTP / 2 and be able to take advantage of the new protocol (since SPDY has become part of HTTP / 2, now his separate incarnation is removed from circulation).
Github maintains a list of known HTTP / 2 implementations in C #, NodeJS, C ++, Perl, etc. The nghttp2 library in C is also included there. In general, Ilya Grigorik urges everyone to optimize their servers for HTTP / 2 and check the correct operation of TLS .
The Connection View mode in the browser shows the loading of the Yahoo.com title page elements in HTTP 1.1.
Ilya begins with the fact that for modern sites most of the delays are due to waiting for resources to load, and the bandwidth is not a limiting factor (in blue in the Connection View diagram). According to statistics, to download the average web page, the browser makes 78 requests to 12 different hosts (the total size of download files is 1232 KB).
For 1 million of the largest Internet sites, according to Alexa, on a 5-megabit channel, the average page load time is 2.413 seconds , with the CPU running only 0.735 seconds, and the rest is waiting for resources from the network (latency) to arrive.
')
HTTP 1.1 problems consist in a large number of requests, limited parallelism, not working in practice, pipelining of requests, the presence of concurrent TCP-flows, the overhead of service traffic.
Another problem is that webmasters go overboard with domain sharding. They add too many shards to bypass the browser restriction on 6 simultaneous connections with one server, and because of this they harm themselves. Traffic is repeatedly duplicated, congestion, retransmissions, etc. occur.
Problems with a large number of requests when developing applications for HTTP 1.1 are also solved in the wrong way: through concat (creating large monolithic code fragments, expensive cache invalidation, delayed execution of JSS / CSS) and inline (duplication of resources on each page, broken prioritization).
What to do?
Everything is very simple. The new HTTP 2.0 fixes many of the shortcomings of HTTP 1.1, Ilya Grigorik is sure. HTTP 2.0 does not require the establishment of multiple connections and reduces latency while maintaining the usual HTTP 1.1 semantics.
First, all the threads are mixed by splitting into frames (HEADERS, DATA, etc.), which are sent over a single TCP connection. Frames have priority and flow control. And server-push replaces inline. And, of course, effective header compression, to the point that the HEADER is “compressed” to 9 bytes (only changes are transmitted).
How specifically to use the benefits of HTTP 2.0 to optimize server applications? This is the most interesting part of the presentation of Ilya Grigorik.
Eliminate domain sharding
Sharding specifically beats HTTP / 2 performance, breaks frame prioritization, flow control, and so on.
If necessary, you can implement sharding via
altName . If you use one IP and one certificate, then HTTP / 2 will be able to open a single connection for all shards.Get rid of unnecessary optimizations (concat, CSS sprites)
Flows are no longer a limitation, so it is possible to correctly allocate resources across modules, set a caching strategy for each of them.
Implement server-push instead of inline
The server can now issue several responses to one request. The client orders one thing, and the server can give him something else as well. Each resource is cached independently (it is not necessary to cache for each request, there is a smart push). By the way, using server-side push notifications, you can also cancel the entry in the client cache!
Smart push is generally a great thing. The server itself analyzes the traffic and builds dependencies, what resources the client requests, depending on the referrer. For example, index.html → {style.css, app.js} . In accordance with these laws, rules are created for further push notifications to new customers.
Ilya Grigorik stresses that in the case of HTTP / 2 servers must be properly configured. This wasn’t so critical in the days of HTTP / 1.1, but now it’s true. For example, in HTTP / 1.1, the browser itself first sent important requests (index.html, style, css), holding the secondary ones (hero.jpg, other.jpg, more.jpg, etc.), but now it does not. So, if you do not configure the server to process important requests in the first place, then performance will suffer.
Further, HTTP / 2 allows fine control of the stream. For example, you can first send the first few kilobytes of the image (so that the browser decodes the header and determines the size of the image), then the important scripts, and then the rest of the image.
Testing has shown that when using SPDY, latency and page loading speed are reduced by 30-40%.
For example, Twitter tested the delay in accessing the API in December 2013. The results in milliseconds are shown in the graph for the 50th, 75th, 95th, and 99th percentiles (median). Interestingly, SPDY brings more value when a client is connected via the worst communication channel (low latency locale).
Google has published its statistics to increase the speed of loading pages a year ago .
| Google News | Google sites | Google drive | Google maps | |
| Median | -43% | -27% | -23% | -24% |
| 5th percentile (fast connections) | -32% | -thirty% | -15% | -20% |
| 95th percentile (slow connections) | -44% | -33% | -36% | -28% |
Github maintains a list of known HTTP / 2 implementations in C #, NodeJS, C ++, Perl, etc. The nghttp2 library in C is also included there. In general, Ilya Grigorik urges everyone to optimize their servers for HTTP / 2 and check the correct operation of TLS .
Source: https://habr.com/ru/post/242255/
All Articles