Shulou(Shulou.com)05/31 Report--

In view of how the client and server of HTTP Keep-Alive mode determine the completion of the transmission, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

What is a long connection?

We know that the HTTP protocol uses the "request-reply" mode. When using the normal mode, that is, the non-KeepAlive mode, each request / reply client and server will create a new connection and disconnect immediately after completion (the HTTP protocol is connectionless). When using Keep-Alive mode (also known as persistent connection, connection reuse), the Keep-Alive function keeps the connection from the client to the server valid, and the Keep-Alive function avoids establishing or re-establishing the connection when a subsequent request to the server occurs.

How does the server know that it has fully accepted the data sent by the client?

Content-Length is an entity message header that indicates the size of the message body sent to the receiver, that is, the number of octets represented by decimal numbers.

How does the client know that it has fully accepted the data sent by the server?

In a HTTP 1.0 short connection, the client sends a small request, and the server responds with the desired information (such as a html file or a gif image). The server usually closes the connection after sending back the requested data. In this way, when the client reads the data, it will return EOF (- 1) and know that the data has been fully received.

Message header field Conent-Length

Message header field Transfer-Encoding

Transfer-Encoding

When the client requests a static page or a picture from the server, the server can clearly know the size of the content and then tell the client how much data to receive through the header field of the Content-length message. However, if it is a dynamic page, etc., it is impossible for the server to know the size of the content in advance, so you can use Transfer-Encoding:chunk mode to transfer data. That is, if you want to generate data and send it to the client at the same time, the server needs to use "Transfer-Encoding: chunked" instead of Content-Length.

Chunk coding occurs when data is divided into chunks. The Chunked code will be concatenated using several Chunk, ending with a chunk marked with a length of 0. Each Chunk is divided into two parts: the header and the body. The high-quality content specifies the total number of characters (hexadecimal numbers) and quantity units (usually not written) in the text. The body part is the actual content of the specified length, separated by carriage return line feed (CRLF). The content in the last Chunk of length 0 is called footer, which is some additional Header information (which can usually be ignored directly).

Transfer-Encoding is a header value used to indicate the transmission format of HTTP messages. Although there can be many values in theory, only one transport value, chunked, is actually defined in the current HTTP specification.

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

Each non-empty block starts with the number of bytes (in hexadecimal) that the block contains data, followed by a CRLF (carriage return and line feeds), then the data itself, and finally the block CRLF. In some implementations, there is a 0x20 between the block size and the CRLF.

The last block is a single line, made up of block size (0), some optional blanks, and CRLF. The last block no longer contains any data, but you can send an optional trailer, including the header field. 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:

The two nouns chunked and multipart are similar in meaning, but in the HTTP agreement, these two concepts are not in the same category. Multipart is a Content-Type that identifies the type of HTTP message content, while chunked is a transport format that indicates how the header will be transmitted.

The chunked transmission cannot know the length of the content in advance and can only be judged by the last empty chunk block, so there is no way to achieve progress for download requests. In browsers and download tools, we occasionally see some files that do not see the progress of downloading, that is, downloading in chunked mode.

The advantage of chunked is that the server side can send content while generating content, without having to generate all the content in advance. HTTP/2 does not support instagram user search Transfer-Encoding: chunked because HTTP/2 has its own streaming transport (Source:MDN-Transfer-Encoding).

Transfer-coding and Content-Length

In fact, the above two methods can be summarized as how to determine the size and number of http messages. RFC 2616 summarizes the length of the message as follows: the transfer-length (transmission length) of a message refers to the length of the message-body (message body) in the message. When transfer-coding (transport coding) is applied, the length (transfer-length) of the message-body (message body) in each message is determined by the following situations (priority from high to low):

Any message that does not contain a message body, such as a response message such as 1XXX, 204,304, and any header (HEAD, header) request, is always terminated by a blank line (CLRF).

If the Transfer-Encoding header field appears and the value is not "identity", the transfer-length is defined by the "chunked" transport code, unless the message is terminated because the connection is closed.

If the Content-Length header field appears, its value represents entity-length (entity length) and transfer-length (transfer length). If the two lengths are different in size (i.e. If the Transfer-Encoding header field is set), the Content-Length header field cannot be sent. And if you receive both the Transfer-Encoding field and the Content-Length header field, you must ignore the Content-Length field.

If the message uses the media type "multipart/byteranges" and transfer-length is not otherwise specified, then this self-delimiting media type defines transfer-length. The type cannot be used unless the sender knows that the receiver can resolve the type.

The length of the message is determined by the server closing the connection. (note: closing the connection cannot be used to determine the end of the request message because the server can no longer send response messages to the client. )

To be compatible with HTTP/1.0 applications, the request message body of HTTP/1.1 must contain a legitimate Content-Length header field unless you know that the server is HTTP/1.1 compliant. A request contains a message body and the Content-Length field is not given. If the length of the message cannot be determined, the server should respond with 400 (bad request), or the server insists that it wants to receive a legitimate Content-Length field and responds with 411 (length required).

All HTTP/1.1 recipient applications must accept the "chunked" transfer-coding, so this mechanism is allowed to transmit messages when the length of the message is not known in advance. The message should not contain both the Content-Length header field and the non-identity transfer-coding. If a message contains both non-identity transfer-coding and Content-Length, Content-Length must be ignored.

This is the answer to the question about how the client and server of HTTP Keep-Alive mode determine the completion of the transmission. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.