HTTP Protocol Development History __unix

HTTP protocol is the foundation of the Internet Protocol, but also the necessary knowledge of web development, the latest version of HTTP/2 is to let it become a technical hotspot.

This paper introduces the historical evolution and design idea of HTTP protocol.

First, http/0.9

HTTP is an application layer protocol based on the TCP/IP protocol. It does not involve packet (packet) transmissions, which mainly specify the communication format between the client and the server, using port 80 by default.

The earliest version was released in 1991, the 0.9 edition. This version is extremely simple, with only one command get.

Get/index.html

The above command indicates that after the TCP connection (connection) is established, the client requests the Web page index.html the server (request).

The protocol stipulates that the server can only respond to HTML-formatted strings and cannot respond to other formats.

 
When the server is sent, the TCP connection is turned off. Second, http/1.0 2.1 Introduction

May 1996, the http/1.0 release, the content greatly increased.

First, any form of content can be sent. This allows the Internet not only to transfer text, but also to transfer images, video, binary files. This has laid the foundation for the great development of the Internet.

Second, in addition to the Get command, also introduced the post command and Head command, enriching the browser and the server interactive means.

Again, the format of HTTP requests and responses has changed. In addition to the data section, each communication must include header information (an HTTP header) to describe some metadata.

Other new features include status code, multiple character set support, multi-part type, permissions (authorization), caching (cache), content encoding (contents encoding), and more. 2.2 Request Format

The following is an example of a version 1.0 HTTP request.

get/http/1.0
user-agent:mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*
 
As you can see, this format is very different from the 0.9 version.

The first line is the request command, and the Protocol version (http/1.0) must be added at the rear. The back is a lot of wardrobe information, describing the client situation. 2.3 Response Format

The server responds as follows.

http/1.0 OK 
content-type:text/plain
content-length:137582
Expires:thu, Dec 1997 16:00:00 GMT
Last-modified:wed, 5 August 1996 15:55:28 GMT
server:apache 0.84

 
The format of the response is "header information + a blank line (\ r \ n) + data". Where the first line is the protocol version + Status code (status code) + status description. 2.4 content-type Field

With regard to the encoding of characters, version 1.0 stipulates that the header information must be an ASCII code, and the following data can be any format. Therefore, when the server responds, it must tell the client what the data format is, which is the role of the Content-type field.

The following are the values of some common content-type fields. Text/plain text/html text/css image/jpeg image/png image/svg+xml audio/mp4 video/mp4 application/javascript Application /pdf Application/zip Application/atom+xml

These data types are always referred to as MIME types, and each value includes a first-level type and a level two type, separated by a slash.

In addition to predefined types, vendors can customize the type.

Application/vnd.debian.binary-package
 
The above type indicates that a binary packet of the Debian system is being sent.

The MIME type can also use semicolons at the end to add parameters.

content-type:text/html; Charset=utf-8
 
The above type indicates that the page is sent, and the encoding is UTF-8.

When client requests, you can use the Accept field to declare which data formats you can accept.

Accept: */*
 
In the code above, the client declares that it can accept data in any format.

MIME type is used not only in HTTP protocol, but also in other places, such as HTML Web pages.

<meta http-equiv= "Content-type" content= "text/html; Charset=utf-8 "/>
<!--equal to-->
<meta charset=" Utf-8 "/> 
 
2.5 content-encoding Field 
Because the data you send can be in any format, you can compress the data and then send it. The Content-encoding field describes the compression method for the data.

Content-encoding:gzip
content-encoding:compress
content-encoding:deflate
 
When the client requests, use the Accept-encoding field to indicate which compression methods they can accept.

Accept-encoding:gzip, deflate
 
2.6 Disadvantages 
The main disadvantage of the http/1.0 version is that each TCP connection can send only one request. When the data is sent, the connection is closed, and if additional resources are requested, a new connection must be created.

The new cost of TCP connections is high because the client and server are required to shake hands three times and start at a slower rate (slow start). Therefore, the HTTP 1.0 version of the performance is relatively poor. As the Web page loads more external resources, the problem becomes more pronounced.

To solve this problem, some browsers use a nonstandard connection field when they request it.

Connection:keep-alive
 
This field requires the server not to turn off the TCP connection so that other requests are reused. The server also responds to this field.

Connection:keep-alive
 
A reusable TCP connection is established until the client or server actively shuts down the connection. However, this is not a standard field and the behavior of different implementations may be inconsistent and therefore not a fundamental solution. Third, http/1.1

The http/1.1 version was released in January 1997, only half a year later than the 1.0 version. It further refined the HTTP protocol, which has been used 20 years later, until now is still the most popular version. 3.1 Persistent Connections

The biggest change in version 1.1 is the introduction of a persistent connection (persistent connection), which means that TCP connections are not closed by default and can be reused with multiple requests, without declaring connection:keep-alive.

The client and the server find each other inactive for some time,