What is HTTP?

Every website address begins with 'http://' (or 'https://'). This refers to the HTTP protocol, which your web browser uses to request a website. In the following, we will introduce the concept of HTTP, explain the dif­fer­ences between the versions, and indicate what other concepts are related to HTTP.

HTTP stands for 'Hy­per­text Transfer Protocol'. It was developed by Tim Berners-Lee at CERN (Switzer­land) alongside other concepts that laid the basis for the world wide web, such as HTML and URI. While HTML (Hypertext Markup Language) defines the structure and layout of a website, HTTP controls how the page is trans­ferred from the server to the client. The third concept URL (Uniform Resource Locator) defines how a resource (e.g. a website) must be addressed on the web.

So, what does the term 'hy­per­tex­t', used in the ab­bre­vi­ations HTTP and HTML, actually mean? It refers to a concept we are all familiar with: linking files. Hy­per­links are placed on websites and lead to other pages.

If you enter an internet address in your web browser and a website is displayed shortly there­after, your browser has com­mu­nic­ated with the web server via HTTP. Fig­ur­at­ively speaking, HTTP is the language your web browser uses to speak with the web server in order to inform it of a request.

Ori­gin­ally, HTTP was only used to request an HTML document from a web server. Today, the protocol has many different uses:

• Browsers use HTTP to request all types of media used on modern websites: text, images, videos, program code, etc.
• Ap­plic­a­tion programs use HTTP to request files and updates from remote servers.
• The REST-API is a HTTP-based solution for handling web services.
• Another HTTP-based tech­no­logy is WebDAV.
• HTTP is used in machine-to-machine com­mu­nic­a­tion as a protocol for com­mu­nic­at­ing between web services.
• Media players also use HTTP.
• Databases on the web can also be accessed (i.e. CRUD op­er­a­tions) using HTTP.

The history of HTTP began in 1989 when Tim Berners-Lee and his team at CERN developed the world wide web. The original version of HTTP was labelled version 0.9 and called the 'One-Line Protocol'. It could only request one HTML file from a server.

All the server did was send the cor­res­pond­ing file. Therefore, this protocol version could only handle HTML files.

In 1996, the Internet En­gin­eer­ing Task Force (IETF) doc­u­mented version HTTP/1 in the non-binding in­form­a­tion­al memo RFC 1945. A new header was in­tro­duced which could specify both the client request and the server response more precisely. One new header in­tro­duced was the 'content type' header which made it possible to transfer files other than HTML files. The following is a short summary of this HTTP version’s features:

• Con­nec­tion­less: The client es­tab­lishes a con­nec­tion to the server, sends a request, the server responds, and then the con­nec­tion is ter­min­ated. For the next request, the client will have to re-establish the con­nec­tion. This is in­con­veni­ent because a website usually consists of several files and each of them has to be retrieved using a separate request.
• Stateless: The two parties (i.e. the client and server) 'forget' about each other im­me­di­ately. The next time the client logs on to the server, the server will not remember that a client pre­vi­ously sent a request.
• Media-in­de­pend­ent: Any type of file can be sent via HTTP as long as both parties know how to handle the re­spect­ive file type.

In 1997, version HTTP/1.1 was published, as doc­u­mented in the in­form­a­tion­al memo RFC 2068. It became the first official standard and is still being used today. It offered some important in­nov­a­tions in com­par­is­on to HTTP/1:

• Keepalive: The client can keep a con­nec­tion from a request open (i.e. a per­sist­ent con­nec­tion) by sending a keepalive in the header of the request.
• HTTP pipelin­ing allows the client to send another request before it has received a response to the first one.
• In chats, the browser can update the browser window using the MIME type multipart/replace.
• Data can also be sent from the client to the server.
• The newly in­tro­duced TRACE method allows you to trace the path from the client to the web server.
• Cache: There are new mech­an­isms for caching content.
• Host: An HTTP request will work due to a given spe­cific­a­tion in the header (i.e. host) even if several different domains are hosted under a single IP address, as is the case with the majority of websites today (i.e. shared web hosting).

Over the years, websites have become larger and more complex. To load a modern website in your browser, the browser will need to request several megabytes of data and send up to several hundred HTTP requests. Since HTTP/1.1 requires requests over a con­nec­tion to be processed one after the other, the more complex the website is, the longer it will take to load the page.

In response, Google developed a new ex­per­i­ment­al protocol called SPDY (pro­nounced 'speedy'). This was met with great interest by the developer community and finally led to the release of the protocol version HTTP/2 in 2015. This new standard in­tro­duced the following non-com­pre­hens­ive list of in­nov­a­tions, all of which are intended to speed up the loading time of websites:

• Binary: The protocol is based on binary data instead of text files.
• Mul­ti­plex­ing: The client and server can send or process several HTTP requests at the same time.
• Com­pres­sion: The headers are com­pressed. Since headers are often almost identical in many HTTP requests, com­press­ing them elim­in­ates un­ne­ces­sary re­dund­ancy.
• Server push: If the server already knows what data the client will require, it can send it to a client cache by itself without having received a previous HTTP request.

HTTP/2 was able to establish itself quickly, par­tic­u­larly with websites with a lot of traffic which switched over shortly. According to W3Techs, currently (as of January 2020) around 42% of websites use HTTP/2.

A weak point of all the previous HTTP versions has been the un­der­ly­ing transport protocol TCP. This protocol requires the recipient to confirm each data packet before the next one can be sent. If a single data packet is lost, all the other packets have to wait for the lost one to be sent again. Experts refer to this as head-of-line blocking.

The new HTTP/3 will, therefore, no longer be based on TCP but rather on UDP which does not require any cor­rect­ive measures for this kind of situation. The QUIC protocol (Quick UDP Internet Con­nec­tions) was developed based on UDP as the found­a­tion for HTTP/3.

HTTP/3 has not yet been defin­it­ively adopted by the IETF. Nev­er­the­less, almost 3% of websites already use QUIC or HTTP/3 according to W3Techs.