« Previous 1 2 3 4 Next »
HTTP/1.1 versus HTTP/2 and HTTP/3
Turboboost
Google and Microsoft
As early as the beginning of the 2010s, Google presented an alternative method for exchanging data between client and server with the SPDY protocol, which defined an increase in responsiveness and solved the limitation of the amount of data to be transferred. In addition to SPDY, Microsoft's development of HTTP Speed+Mobility also served as the basis for today's HTTP/2 protocol.
One major change from HTTP/1.1 is that it is a binary protocol, compared with the previous text-based protocol. Therefore, HTTP/2 can no longer be read or created manually. It also compresses the header. Because the header is similar for most requests, the new protocol combines them, preventing unnecessary duplicate transmission of data. Furthermore, HTTP/2 allows the server to send data in advance to the client cache before the client requests it. For example, assume an index.html
file loads the style.css
and script.js
files within the data structure. If the browser connects to the server, the server first delivers the content of the HTML file. The browser analyzes the content and finds the two instructions in the code to reload the style.css
and script.js
files.
Only now can the browser request the files. With HTTP/2, it is possible for web developers to set rules so that the server takes the initiative and delivers the two files (style.css
and script.js
) directly with index.html
, without waiting for the client to request them first. Therefore, the files are already in the browser cache when index.html
is parsed, eliminating the wait time that requesting the files would otherwise entail. This mechanism is known as server push
.
Server Push with Apache and Nginx
Because a server cannot know which files depend on what others, it is up to the web developers or administrators to set up these relationships manually. On Apache 2, the instruction can be stored in httpd.conf
or .htaccess
. For example, to push a CSS file whenever the browser requests an HTML file, the instruction for the httpd.conf
or .htaccess
file is:
<FilesMatch "\.html$"> Header set Link "</css/styles.css>; rel=preload; as=style" <FilesMatch>
To add multiple files, you can use add Link
instead of set Link
:
<FilesMatch "\.html$"> Header add Link "</css/styles.css>; rel=preload; as=style" Header add Link "</js/scripts.js>; rel=preload; as=script" </FilesMatch>
Here, you could also imitate pushing files from foreign sites by adding crossorigin
to the tag:
<FilesMatch "\.html$"> Header set Link "<https://www.googletagservices.com/tag/js/gpt.js>; rel=preload;as=script; crossorigin" </FilesMatch>
If you cannot or do not want to change the Apache files, you could still imitate pushing files with the header
function of PHP or other server-side scripting languages:
header("Link: </css/styles.css>; rel=preload; as=style");
To push multiple resources, you separate each push directive with a comma:
header("Link: </css/styles.css>; rel=preload;as=style, </js/scripts.js>;rel=preload;as=script, </img/logo.png>;rel=preload; as=image");
You can also combine this directive with other rules included with the Link
tag. For example, simultaneously issuing a push directive with a preconnect
hint,
header("Link: </css/styles.css>; rel=preload; as=style,<https://fonts.gstatic.com>;rel=preconnect");
tells the server to push the style.css
file to the client and simultaneously to establish a connection to fonts.gstatic.com
. Because Nginx does not process .htaccess
files or the like, the instruction can also be implemented, as described earlier, with PHP or directly in the server configuration by extending the location
paragraph to include the http2_push
command (Listing 5).
Listing 5
location Paragraph
location / { root /usr/share/nginx/html; index index.html index.htm; http2_push /style.css; http2_push /logo.png; }
Many Small Files vs. One Big File
Over the years, HTTP/1.1 has shown that HTTP pipelining places a heavy load on a server's resources. From a purely technical point of view, this means that the browser puts the requests for the required files into a pipeline, and the server processes them one by one (Figure 1). For web developers, this previously meant that their goal had to be to reload as few individual files as possible. Therefore, combining individual CSS or JavaScript files, for example, has proven to be very helpful. Loading a single 80KB CSS file is faster than loading eight 10KB files, because each request for a new file again takes time to establish the TCP connection.
Not all files can be combined and downloaded as a single file, especially for images, so HTTP/2 has become a multiplex protocol. One of the two core changes is that a client only opens one stream to the server over which all files can be transferred, without opening a new stream for each new request. The existing TCP connections are thus more durable, which in turn means they can achieve full data transfer speeds more often.
The second change is that this adaptation allows the server to send files in parallel rather than serially. Instead of one file at a time, the server now delivers many files at once (Figure 2). Conversely, the previously mentioned rule with the eight CSS files now no longer applies. On the contrary, applying this rule slows down the website unnecessarily, because the maximum transfer time for all files is the same as the transfer time for the largest file. For example, if transferring an 80KB file takes 347ms, transferring eight 10KB files takes only about 48ms, because the server delivers them at the same time. With HTTP/2, browsers typically use only one TCP connection to each host, instead of the up to six connections with HTTP/1.1.
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)