HTTP is the cornerstone of the internet, the most important and widely used protocol in browsers, and the communication language between browsers and servers.

HTTP/0.9

HTTP/0.9 was proposed in 1991, primarily for academic communication, to transmit HTML hypertext content between networks, hence it is called the Hypertext Transfer Protocol.

HTTP/0.9 Request Process

• The request line can fully express the client’s needs, so there are no HTTP request headers or body.
• The server also does not return header information, as it does not need to tell the client much information, just to return the data.
• All files are in HTML format, so the returned file content is transmitted as an ASCII character stream.

HTTP/1.0

With the rapid development of the World Wide Web, browsers now handle not only HTML files but also different types of files such as JavaScript, CSS, images, audio, and video. Therefore, to support the download of multiple file types, HTTP/0.9 is no longer suitable for current needs, leading to the birth of HTTP/1.0.

Downloading Multiple File Types

The HTTP/0.9 protocol only has a request line and a response line, which cannot notify the server about file or browser file information. HTTP/1.0 introduced request and response headers in Key-Value format to address the issue of multiple file formats.

HTTP/1.0 Request Process

• The server informs the browser of the type of data being returned, allowing for targeted processing based on the different return data types.
• The server informs the browser of the compression method, facilitating the server to compress the data before transmission.
• The browser informs the server of the language version of the page to provide internationalization support.
• The browser needs to know the file’s encoding type to accurately read the file.

Request Headers

// Expecting the server to return an HTML type file
accept: text/html 
// Expecting the server to use one of the compression methods: gzip, deflate, or br
accept-encoding: gzip, deflate, br 
// Expecting the returned file encoding to be UTF-8 
accept-Charset: utf-8 
// Expecting the preferred language of the page to be Chinese
accept-language: zh-CN,zh 

After receiving the request header information sent by the browser, the server prepares the response data based on the information in the request header.

Response Headers

// The server uses the br compression method.
content-encoding: br
// The server returns an HTML file with UTF-8 encoding.
content-type: text/html; charset=UTF-8

The browser will use the br method to decompress the file, then process the original file according to the UTF-8 encoding format, and finally parse the file as HTML.

Other Features

• The response header introduces status codes to notify the browser whether the request was successful or failed through the response line.
• It provides a caching mechanism to cache already downloaded data, thereby reducing the load on the server.
• The request header also includes a user-agent field to facilitate the collection of basic client information.

HTTP/1.1

1. Improved Persistent Connections To reduce the unnecessary overhead of establishing or breaking multiple TCP connections, HTTP/1.1 introduced a method for persistent connections, allowing multiple HTTP requests to be transmitted over a single TCP connection. As long as the browser or server does not explicitly close the connection, the TCP connection will remain open. Persistent connections are enabled by default, allowing up to 6 simultaneous TCP persistent connections for the same domain. If you do not want to use persistent connections, add Connection: close in the HTTP request header.

HTTP/1.0 Connection

HTTP/1.1 Connection

2. Immature HTTP Pipelining allows multiple HTTP requests to be submitted to the server in batches, but the server still needs to respond to the browser’s requests in the order they were received. Although persistent connections can reduce the number of TCP establishments and disconnections, it requires waiting for the previous request to return before making the next request, which is the well-known Head-of-Line Blocking issue.

3. Support for Virtual Hosting A server can only support one domain name, and one domain name can only bind to one IP address. Therefore, it is necessary to implement multiple virtual hosts on a single physical host, each with its own separate domain name, all sharing the same IP address. The HTTP/1.1 request header includes a Host field to indicate the current domain address, allowing the server to handle different requests based on different Host values.

4. Perfect Support for Dynamically Generated Content HTTP/1.1 introduces the Chunked Transfer mechanism to address the size of received data or to determine whether the file transfer is complete. The server splits the data into several chunks of arbitrary size, with each chunk sent along with the length of the previous chunk, and finally uses a zero-length chunk as a marker to indicate the completion of data transmission.