The introduction

HTTP is short for Hyper Text Transfer Protocol, which is used to Transfer hypertext from the World Wide Web server to the local browser. HTTP is based on TCP/IP protocol communication protocol to transfer data (HTML files, image files, query results, etc.). It does not involve packet transmission and mainly defines the communication format between the client and the server. Port 80 is used by default.

First, Http characteristics

1. Simple and fast: when customers request services to the server, they only need to send the request method and path. The commonly used request methods are GET, HEAD, PUT, DELETE, and POST. Each method specifies a different type of contact between the client and the server. Because HTTP protocol is simple, the HTTP server program size is small, so the communication speed is very fast.

2. Flexibility: HTTP allows the transfer of any type of data object.

3. Connectionless: Connectionless means that only one request can be processed per connection. The server disconnects from the customer after processing the request and receiving the reply from the customer. In this way, transmission time can be saved.

4. Stateless: **HTTP is stateless, and the HTTP protocol itself does not store the communication status between the request and response. There is no dependency between any two requests. Intuitively speaking, each request is independent and has no direct connection to the previous request or the subsequent request. The protocol itself does not retain information about all previous request or response messages. The HTTP protocol is designed to be so simple in order to process a large number of transactions more quickly and ensure protocol scalability.

2. Http packets

An Http packet consists of a request packet and a response packet. A request packet consists of a request line, a header, a blank line and a request body. The response message consists of status line, response header, blank line and response body. Let’s take a closer look at the various parts of the request message and their functions.

1. The request line, which describes the request type, the resource to access, and the HTTP version to use.

POST/chapter17 / user. HTTP / 1.1 HTMLCopy the code

In the preceding code, POST indicates the request method, /chapter17/user.html indicates the URI, and HTTP/1.1 indicates the protocol and the protocol version. The popular version is Http1.1

2. The request header consists of a keyword/value pair. Each line consists of two pairs.

The request header notifies the server that there is information about the client request. It contains a lot of useful information about the client environment and the request body. For example, Host indicates the Host name and virtual Host. Connection,HTTP/1.1 added to use keepalive, a Connection can send more than one request; User-agent, request originator, compatibility, and customization requirements.

3. The last request header is followed by an important blank line indicating that the request header has ended, followed by the request body.

4. Request body, which can carry data of multiple request parameters

name=tom&password=1234&realName=tomson
Copy the code

The above code, carrying the name, password, realName three request parameters.

HTTP request method

  • GET requests the specified page information and returns the entity body.
  • A HEAD is similar to a GET request, except that there is no concrete content in the response returned to retrieve the header
  • POST Submits data to a specified resource for processing requests (such as submitting a form or uploading a file). The data is contained in the request body.
  • PUT Transmits data from the client to the server instead of the content of the specified document.
  • DELETE requests the server to DELETE the specified page.

GET and POST

  • GET is harmless when the browser falls back, while POST resubmits the request
  • GET requests are actively cached by browsers, whereas POST is not, unless set manually
  • GET request parameters are retained in browser history, while parameters in POST are not
  • A GET request has a length limit on the parameters it passes in the URL, whereas a POST request has no limit
  • The GET parameter is passed through the URL, and the POST is placed in the Request body

The status code consists of three digits. The first number defines the categories of the response. There are five categories:

  • 1XX: Indicating message – indicating that the request has been received and processing continues
  • 2xx: Success: The request is successfully received, understood, or accepted
  • 3xx: Redirect – Further action must be taken to complete the request
  • 4XX: Client error – The request has a syntax error or the request cannot be implemented
  • 5xx: Server side error — the server failed to fulfill a valid request

For example, we usually have two kinds of error status code:

403 Forbidden // Access to the requested page is Forbidden 404 Not Found // The requested resource does Not exist, for example, an incorrect URL has been enteredCopy the code

Persistent connection

1. Why persistent connections

In the original version of the HTTP protocol, TCP connections were disconnected for every HTTP communication. In the case of communications in those days, it was all very small text transfers, so even this was not a problem. However, with the popularity of HTTP, it has become more common for documents to contain large numbers of images. For example, when viewing an HTML page with multiple images in a browser, it sends a request to access the resources of the HTML page and also asks for other resources contained in the HTML page. Therefore, each request causes unnecessary TCP connection establishment and disconnection, increasing the traffic overhead.

2. Persistent connection characteristics

To solve the above TCP connection problem, HTTP/1.1 and some HTTP/1.0 came up with HTTP Persistent Connections. Also known as HTTP keep-alive or HTTP Connection reuse). The characteristic of a persistent connection is that the TCP connection remains as long as neither end explicitly disconnects.

The benefits of persistent connections are that they reduce the overhead caused by the repeated establishment and disconnection of TCP connections and reduce the load on the server side. In addition, the time spent reducing overhead allows HTTP requests and responses to end earlier, which increases the speed of Web page display. In HTTP/1.1, all connections were persistent by default, but they were not standardized in HTTP/1.0. Although some servers implement persistent connections through non-standard means, the server side does not necessarily support persistent connections. Of course, in addition to the server, the client also needs to support persistent connections.

7. Pipeline

Persistent connections make it possible to send most requests as pipelining. After sending the previous request, wait and receive the response before sending the next request. With the advent of pipelining, the next request can be sent directly without waiting for a response. This makes it possible to send multiple requests simultaneously in parallel without having to wait for one response after another. In layman’s terms, the request is packaged once and passed through, and the response packaged once and passed back. The premise of pipelining is under persistent connection.

When requesting an HTML Web page with 10 images, using persistent connections can end the request faster than connecting one by one. Pipelining is faster than persistent connections. The more requests there are, the more significant the time difference becomes. The client needs to request these ten resources. Before, in the same TCP connection, sends A request first, and then wait for the server to respond, received after the B requests, and so on, and pipeline mechanism is to allow the browser the ten requests at the same time, but the server is in accordance with the order, to respond to A request, after the completion of the response to B request again. Thus, in the case of persistent connections, the passing of messages on a connection is similar to

Request 1-> Response 1-> Request 2-> Response 2-> Request 3-> Response 3

Piped sending becomes something like this:

Request 1-> Request 2-> Request 3-> Response 1-> Response 2-> Response 3

reference

Illustrated HTTP. [Japan] Ueno