Shulou(Shulou.com)06/02 Report--

This article mainly explains "HTTP persistent connection method", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let Xiaobian take you to learn "HTTP persistent connection method"!

We know that HTTP uses a "request-reply" mode. When using normal mode, i.e., non-Keep-Alive mode, each request/reply client and server must create a new connection and disconnect immediately after completion.(HTTP is a connectionless protocol); when Keep-Alive mode is used (also known as persistent connection, connection reuse), Keep-Alive keeps the client-to-server connection alive and avoids establishing or reestablishing the connection when subsequent requests to the server occur.

In HTTP 1.0, there is no official standard for how Keep-Alive works, so it is actually attached to the HTTP 1.0 protocol. If the client browser supports Keep-Alive, it adds a field Connection:Keep-Alive to the HTTP request header. When the server receives a request with Connection:Keep-Alive, it adds the same field to the response header to use Keep-Alive. In this way, the HTTP connection between the client and server is maintained and will not be broken (except for Keep-Alive specified time, unexpected power outages, etc.), and when the client sends another request, the established connection is used.

In HTTP version 1.1, all connections are maintained by default and closed only if "Connection:close" is added. Most browsers currently use the HTTP 1.1 protocol, which means that Keep-Alive connection requests are initiated by default, so whether a complete Keep-Alive connection can be completed depends on the server settings.

Since HTTP 1.0 does not have an official Keep-Alive specification and has largely been phased out, the following discussion is focused on Keep-Alive in the HTTP 1.1 standard.

Note:

HTTP Keep-Alive simply means to keep the current TCP connection and avoid reestablishing the connection.

For example, Keep-Alive:timeout=5,max=100 means that the TCP channel can last for 5 seconds, max=100 means that the long connection will be disconnected after receiving 100 requests at most.

HTTP is a stateless protocol, meaning that each request is independent, and Keep-Alive doesn't change that. Keep-Alive also does not guarantee that the connection between client and server is always active, even in HTTP 1.1. The only guarantee is that you get a notification when the connection is closed, so you shouldn't let your program rely on Keep-Alive's keep-alive feature, or there will be unintended consequences.

After using persistent connections, how do the client and server know that the transfer is over? Two parts: 1. Determine whether the transmitted data reaches the size indicated by Content-Length;2. The dynamically generated file has no Content-Length, it is chunked, and at this time, it should be judged according to chunked coding. Chunked coded data has an empty chunked block at the end, indicating the end of this data transmission. See here for details. What is chunked block transfer? Let's talk about it.

Transfer-Encoding is a header value used to indicate the transport format of HTTP messages. Although this value can theoretically be many, the current HTTP specification actually defines only one transport value-chunked.

If the Transfer-Encoding header of an HTTP message (request message or reply message) has the value chunked, then the message body consists of an unspecified number of blocks and ends with the last block of size 0.

Each non-empty block begins with the number of bytes of data contained in the block (in hexadecimal), followed by a CRLF (carriage return and line feed), followed by the data itself, and ends with the CRLF block. In some implementations, white spaces (0x20) are filled between block size and CRLF.

The final block is a single row, composed of block size (0), some optional white padding, and CRLF. The last block no longer contains any data, but an optional trailer can be sent, including header fields. The message ends with CRLF.

An example response is as follows:

HTTP/1.1 200 OKContent-Type: text/plainTransfer-Encoding: chunked25This is the data in the first chunk1Aand this is the second one0

Note:

Chunked and multipart have similar meanings, but in HTTP they are not a category. multipart is a Content-Type indicating the type of HTTP message content, and chunked is a transport format indicating how the header will be transmitted.

Chunked transfers cannot know the length of the content in advance, only by the last empty chunk, so there is no way to progress the download request. In browsers and download tools, occasionally we will see some files that cannot be downloaded in progress, that is, downloaded in chunked mode.

The advantage of chunked is that the server can generate content while sending it, without generating all the content in advance. HTTP/2 does not support Transfer-Encoding:chunked because HTTP/2 has its own streaming method (Source: MDN-Transfer-Encoding).

At this point, I believe that everyone has a deeper understanding of the "HTTP persistent connection method", so let's actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.