HTTP connection Establishment Method

HTTP supports establishing connections in 2: non-persistent connections and persistent connections (http1.1 uses persistent connections by default ).

1) non-persistent connection

Let's take a look at the steps for transferring a web page from the server to the customer in the case of non-persistent connections. Assume that the bay surface consists of a basic HTML file and 10 JPEG images, and all these objects are stored on the same server host. Assume that the URL of the basic HTML file is gpcuster.cnblogs.com/index.html.

Follow these steps:

1. The HTTP client initializes a TCP connection to the HTTP server in gpcuster.cnblogs.com. The HTTP server uses the default port 80 to listen for connection establishment requests from HTTP clients.

2. the HTTP client sends an HTTP request message through the local socket associated with the TCP connection. This message contains the path name/somepath/index.html.

3. the HTTP server receives the request message through the local socket associated with the TCP connection, and then retrieves the object/somepath/index.html from the memory or hard disk of the server host, sends a response message containing the object through the same socket.

4. the HTTP server informs TCP to close the TCP connection (however, TCP will terminate the connection only after the customer receives the Response Message ).

5. The HTTP client receives the response message through the same socket. The TCP connection is subsequently terminated. The message indicates that the encapsulated object is an HTML file. After the customer extracts the file and analyzes it, it finds that 10 JPEG objects are referenced.

6. Repeat steps 1-4 for each referenced JPEG object.

The above steps are called using a non-persistent connection because each time the server sends an object, the corresponding TCP connection is closed, that is, each connection does not last until other objects can be transferred. Each TCP connection is used to transmit only one request message and one response message. In the preceding example, each time a user requests a Web page, 11 TCP connections are generated.

 

2) persistent connection

Non-persistent connections have some disadvantages.

First, the customer must establish and maintain a new connection for each object to be requested. For each such connection, TCP must allocate a TCP buffer on the client and server, and maintain the TCP variable. This severely increases the burden on Web servers that may provide services for requests from hundreds of different customers at the same time.

Second, as mentioned above, each object has two RTT response extensions-one RTT is used to establish a TCP connection, and the other RTT is used to request and receive objects.

Finally, each object is slowed down by TCP because each TCP connection starts from the slow start phase. However, the use of parallel TCP connections can partially reduce the RTT latency and slow startup latency.

In the case of persistent connections, after the server sends a response, the TCP connection continues to open.

Subsequent requests and responses to the same client/server can be sent through this connection.

The entire web page (in the preceding example, a page containing a basic htmll file and 10 images) can be sent through a single persistent TCP connection: even multiple web pages stored on the same server can be sent through a single persistent TCP connection.

Generally, the HTTP server shuts down a connection after a specific period of time, which can be configured during this period.

Persistent connections are divided into two versions: Without pipelining and with pipelining.

 

If it is a version without a pipeline, the customer sends a new request only after receiving the response from the previous request.

In this case, each object referenced by the web page (10 images in the previous example) experiences a RTT delay, which is used to request and receive the object. Compared with the latency of two RTTs for non-persistent connections, persistent connections without pipelines have been improved, but persistent connections with pipelines can further reduce the response latency. Another disadvantage without the assembly line version is that the server sends an object and waits for the next request, but the new request cannot arrive immediately. During this time, the server resources are idle.

The default HTTP/1.1 mode uses persistent connections with pipelines.

In this case, each time an HTTP client encounters a reference, it immediately sends a request. Therefore, an HTTP client can send a request next to each referenced object. After receiving these requests, the server can send each object one by one. If all requests and responses are sent next to each other, all referenced objects will experience only one RTT delay (instead of the same as the version without pipelines, each referenced object has a RTT delay ). In addition, requests such as server null in persistent connections with pipelines are less time-consuming. Compared with non-persistent connections, persistent connections (whether with or without a pipeline) reduce the response latency of one RTT, and slow startup latency is also relatively small. The reason is that since each object uses the same TCP connection, after the server sends the first object, it does not have to send subsequent objects at the initial slow rate. On the contrary, the server can start sending the next object at the rate at which the first object is sent.