Version is introduced

HTTP protocol need not I say more, we all know, now I web development is generally using HTTP protocol for communication. So far, there have been several versions of HTTP, and HTTP 1.1 stands for HTTP version 1.1. Version 1.1 is also the current version used by most websites.

The HTTP 0.9

  • Release date: 1991
  • Description: At the beginning of the dream, only one request method is accepted, the version number is not specified in the communication, and the request header is not supported. Since this version does not support the POST method, the client cannot pass much information to the server.

The HTTP 1.0

  • Release date: May 1996
  • Summary: This is the first HTTP protocol version to specify a version number in communication. It also adds a number of new features over version 0.9. Non – continuous connection, each time to re-establish a connection to the server.

The HTTP 1.1

  • Release date: January 1997
  • Introduction: The default Connection is keep-alive, which works well with the proxy server. It also supports piped multiple requests simultaneously to reduce line load and increase transmission speed. It is also the most popular version.

The differences between HTTP/1.1 and HTTP/1.0 are as follows:

  • Cache handling
  • Bandwidth optimization and network connection usage
  • Management of error notifications
  • The sending of messages across the network
  • Maintenance of Internet addresses
  • Security and integrity

The HTTP 2.0

  • Release date: May 2015
  • HTTP/2 is the first update to the HTTP protocol since RFC 2616, an improved VERSION of HTTP 1.1, was released in 1999. It is based on SPDY. It was developed by the Hypertext Transfer Protocol Bis (HTTPBIS) Working group of the Internet Engineering Task Force (IETF). The organization submitted the HTTP/2 standard proposal to IESG for discussion in December 2014 and it was approved on 17 February 2015.

Message format

The request message

The request message is divided into four parts, namely, the request line, the request header, the line break and the request data. At the end of each part, there are carriage return characters (CR, ASCII: 0D) and line break characters (LF, ASCII: 0A).

The request line is divided into request method, request URL address, HTTP version number, and each field is separated by Spaces (ASCII: 20)

The request header can have multiple lines, each line distinguished by carriage return and newline characters

To make it easier to understand, we can use Wireshark to grab an HTTP request and associate it with the image above

The response message

The response message is basically the same as the request message, except that the first status line is different from the first request line of the request message.

The status line is also divided into three parts: HTTP version, status code, and status code description. Each part is separated by Spaces.

The response header, like the request header, can have multiple lines

In the same way, Wireshark is used to capture a response packet and map it to the preceding figure.

Persistent and non-persistent connections

As mentioned above, HTTP 1.1 connections have been changed from non-persistent to persistent (Connection: keep-alive). So what’s the difference between these two?

A non-continuous connection refers to a situation where multiple requests to the server for resources require separate TCP connections and disconnections each time.

Persistent connection refers to the fact that when requesting resources from the server, one TCP connection can be shared for the transfer of resources.

Although HTTP 1.1 uses persistent connections by default, it can also be configured to be non-persistent by setting the Connection field to close

To make it easier to understand, a diagram has been drawn that omits the elaborate steps of TCP establishing and disconnecting a connection.

Request method

GET and POST are the only two commonly used request methods, but if you follow the REST style of API design, you can use the following request methods.

  • OPTIONS: This method asks the server to return all HTTP request methods supported by the resource.
  • GET: obtains data of a specified resource address. Uploading data is not recommended.
  • HEAD: The server does not return the content of the Body resource when responding to a HEAD request. This allows us to retrieve the server’s response header without transferring the entire content.
  • POST: A POST request submits data to a specified resource, which is processed by the request server and contained in the request body.
  • PUT: The latest data for a specified resource can be sent to the server to replace the content of the specified resource.
  • DELETE: deletes the data of the specified resource.
  • TRACE: The request server displays the received request information. This method is used to test or diagnose HTTP requests.
  • .

The response code

1xx

Informational indicates that the received request is being processed. For details, see the RFC documentation

2xx

“Success” indicates that the request is successfully processed. For details, see the RFC document

3xx

Redirection (Redirection status code), which requires additional action to complete the request, see the RFC documentation for details

4xx

Client Error indicates that the server cannot process the request. For details, see the RFC document

5xx

Server Error: Indicates that the Server fails to process the request. For details, see the RFC document