Lead Image © alphaspirit, 123RF.com

HTTP/1.1 versus HTTP/2 and HTTP/3

Turboboost

Article from ADMIN 63/2021

By Sandro Lucifora

HTTP/2 introduced multiplexing, resulting in superior bandwidth utilization over HTTP/1.1, and HTTP/3 solves the problem of transmission delays from packet loss by replacing TCP with QUIC.

The Hypertext Transfer Protocol (HTTP) no longer just serves as the basis for calling up web pages, it is also the basis for a wide range of applications. The best known version, which is still used on most servers, is HTTP/1.1 – even though HTTP/3 has already been defined. In this article, I look at the history of the protocol and the practical differences between versions 1.1, 2, and 3.

The foundation for today's Internet was laid by British scientist Tim Berners-Lee in 1989 while working at CERN in Geneva, Switzerland. The web was originally conceived and developed to meet the demand for an automated exchange of information between scientists at universities and institutes around the world. As a starting point, scientists relied on hypertext, which refers to text with a web-like, dynamic structure. It differs from the typical linear text found in books in that it is not written so that readers consume it from beginning to end in the published order. Especially in scientific works, authors work with references and footnotes that point and link to other text passages.

Technically, hypertext is written in what is known as a markup language, which in addition to design instructions invisible to the viewer also contains hyperlinks (i.e., cross-references to further text passages and other documents in the network). Hypertext Markup Language (HTML) has become established on the Internet.

Starting with hypertext, scientists created HTTP, now used millions of times a day. The goal was to exchange the hypertext in the HTML markup language with other computers, for which a generally valid protocol was required. Today's Internet can be summarized in four points:

The text format for displaying hypertext documents (HTML)
Software that displays HTML documents (the web browser)
A simple protocol for exchanging HTML documents (HTTP)
A server that grants access to the document (the HTTP daemon, HTTPD)

Single-Line Protocol HTTP/0.9

The original version of HTTP had no version number. To distinguish it from later versions, it was subsequently referred to as 0.9 . HTTP/0.9 is quite simple: Each request is a single line and starts with the only possible method, GET, followed by the path to the resource (not the URL because naming the protocol, and the server, and the port for connecting to the server are not required):

GET /it-administrator.html

The response to the GET command also was quite simple and contained only the content of the one file:

<HTML>
IT Administrator -- practical knowledge for system and network administration
</HTML>

This forerunner of today's protocols did not yet support HTTP headers, which means that only HTML files could be transmitted and no other document types – also, no status or error codes. Instead, in the event of a problem, the server sent back an HTML file that it generated with a description of the error that occurred.

First Standard: HTTP/1.1

In 1996, a consortium started working on the standardization of HTTP in version 1.1 and published the first standard in early 1997 (RFC 2616), which can still be read in today's extended version from June 1999 [1]. In the meantime, the Internet Engineering Task Force (IETF) had also taken over centralized work on the definition of HTTP. RFC 2616 cleared up ambiguities and introduced numerous improvements:

A connection can be reused to save time and reload resources.
Pipelining allows a second request to be sent, even before the server has fully transmitted the response for the first, which can reduce latency in communication.
Chunked transfer encoding is the transfer of data with additional information that allows the client to determine whether the information it receives is complete.
Additional cache control mechanisms were added.
For the sender and receiver to achieve the best compatibility, they perform a handshake, in which the server and client negotiate certain fundamentals to establish the best basis for communication.
The host header introduced here is groundbreaking and still indispensable today, for the first time allowing the server to store different domains under the same IP address.

The host header is absolutely crucial for today's Internet. Without this definition, set out in RFC 7230 section 5.4 [2], it would be impossible today to provide a large number of Internet sites on a single server. Each Internet site would need its own HTTP daemon and its own server. For a server to manage multiple domains under the same IP address, HTTP/1.1 makes it mandatory to send the desired host with the GET request, as well. For example, a GET request for http://www.it-administrator.de/pub/WWW/ would be:

GET /pub/WWW/ HTTP/1.1
Host: www.it-administrator.de

If this header is missing, the server must respond with the status 400 Bad Request by definition. To open the page https://www.it-administrator.de/trainings/ , the browser sends the header, as shown in Listing 1. The server first responds with a status 200, which signals to the client that its request is being processed without errors, and then adds further information (Listing 2) followed by the content of the requested page. When requesting an image, the host header looks slightly different (Listing 3), and the server responds as in Listing 4, followed by the image with the previously announced size of 32,768 bytes.

Listing 1

Opening a Page

GET /trainings HTTP/1.1
Host: www.it-administrator.de
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://www.it-administrator.de/trainings/

Listing 2

Adding Chunked Data

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 10 Jul 2020 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2020 11:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

Listing 3

Host Header

GET /img/intern/ita-header-2020-1.png HTTP/1.1
Host: www.it-administrator.de
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://www.it-administrator.de/trainings/

Listing 4

Server Response

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 32768
Content-Type: image/png
Date: Wed, 8 Jul 2020 10:55:34 GMT
Last-Modified: Tue, 19 Jul 2020 11:55:18 GMT
Server: Apache

In contrast to the text/html content type, the browser receives two additional pieces of information: Age tells the client how long the object has been in the proxy cache, and Cache-Control tells all the caching mechanisms whether and how long the object may be stored. Armed with this information, servers can ensure that files such as images, which usually do not change, are loaded from the local cache of the browser and not retrieved from the server.

Faster Transmission with HTTP/2

Thanks to the flexibility and extensibility of HTTP/1.1 and the fact that the IETF extended the protocol with two revisions – RFC 2616 was published in June 1999 and RFCs 7230-7235 in June 2014 – it took 16 years until the IETF presented the new standard HTTP/2.0 to the public as RFC 7540 [3] in May 2015.

The main purpose of HTTP/2.0 was to speed up the Internet and the transmission of data. Compared with the early days, web pages have become complex and are no longer pure representations of information, but interactive applications. The number of files required per page and their size have increased. As a result, significantly more HTTP requests are necessary. HTTP/1.1 connections must send requests in the correct order. Even if several parallel connections can theoretically be opened, it is still a not inconsiderable complexity of requests and responses.

1 2 3 4 Next »