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

This article to share with you is about HTTP transmission encoding is what, Xiaobian think quite practical, so share to everyone to learn, I hope you can read this article after some harvest, not much to say, follow Xiaobian to see it.

What is Transmission Coding?

The transport encoding is marked in the HTTP header using the Transfer-Encoding header, which indicates the transport encoding currently in use.

Transfer-Encoding changes the format and transmission method of the message. It does not reduce the size of the content transmission, and may even make the transmission larger. It seems to be an environmentally unfriendly approach, but it is actually to solve some special problems.

In short, transport coding must be used with persistent connections, designed to block data and mark the end of transmission in a persistent connection, as explained in detail later.

In earlier designs, just as content encoding used Accept-Encoding to mark the compression encoding type received by the client, transport encoding was also used in conjunction with TE, the request header, to specify the supported transport encoding. However, in the latest HTTP/1.1 specification, only one type of transport encoding is defined: chunked, so there is no need to rely on the TE header.

These details will be discussed later. Since transport coding and persistent connections are closely related, let's first understand what persistent connections are.

Persistent Connection

Persistent connection is a long connection, English is called Persistent Connection, in fact, according to the literal meaning of the good.

In the early HTTP protocol, the order of transmitting data was roughly divided into the steps of initiating a request, establishing a connection, transmitting data, and closing the connection, while a persistent connection was to remove the step of closing the connection so that the client and server could continue to transmit content through the connection.

In fact, this is also to improve transmission efficiency, we know that HTTP protocol is based on TCP protocol, naturally has the same characteristics as TCP three-way handshake, slow start, etc., so that each connection is actually a precious resource. To maximize HTTP performance, it is important to use persistent connections. For this reason, in the HTTP protocol, a related mechanism has been introduced.

In the early HTTP/1.0 protocol, there was no persistent connection, and the concept of persistent connection was introduced later, when it was marked by the header Connection:Keep-Alive, which was used to inform the client or the opposite end of the server not to disconnect the TCP connection after sending data, and then need to be used again.

In HTTP/1.1, the importance of persistent connections was found, which specified that all connections must be persistent unless explicitly specified in the header of the message, via the Connection:close header, that the connection would be closed after the end of the transmission.

In fact, in HTTP/1.1, the header of Connect no longer has the value of Keep-Alive. Due to historical reasons, many clients and servers still retain this header.

Long connections pose another problem, how to determine if the current data transmission is complete.

Determine transmission completion

In the early days when persistent connections were not supported, it was actually possible to rely on disconnection to determine that the current transfer had ended, as most browsers did, but this was not the norm. The Content-Length header should be used to specify the length of the entity content currently being transmitted.

For example, while maintaining a persistent connection, Content-Length is relied upon to determine that the data has been sent.

Content-Length here serves as a basis for determining that the response entity has been sent. In this case, we require Content-Length to be consistent with the length of the content entity. If it is inconsistent, various problems will occur.

As shown in the figure above, if Content-Length is less than the length of the content entity, it will be truncated; otherwise, it cannot determine that the current response has ended, and the request will continue to be suspended, resulting in Padding status.

Ideally, when we respond to a request, we need to know the size of its content entity. However, in practice, sometimes the length of the content entity is not so easy to obtain. e.g., content entities from network files or dynamically generated. At this time, if you still want to get the length of the content entity in advance, you can only open a Buffer large enough, and wait for the content to be cached before calculating.

But this is not a good solution, all cached in Buffer, the first will consume more memory, the second will be more time-consuming, let the client wait too long.

In this case, a new mechanism is needed, which does not depend on the value of Content-Length to determine whether the current content entity is transmitted completely. In this case, the header Transfer-Encoding is needed to determine.

Transfer-Encoding:chunked

As mentioned earlier, Transfer-Encoding in the latest HTTP/1.1 protocol, only the chunked parameter, indicating that the current block encoding transmission.

Since there is only one optional parameter, we only need to specify it as Transfer-Encoding:chunked, and then we can wrap the content entity one block for transmission.

Rules for block transmission:

1. Each block contains a hexadecimal data length value and real data.

2. The data length value occupies one row and is separated from the real data by CRLF(\r\n).

3. Data length value, do not calculate CRLF at the end of real data, only calculate the data length of the current transmission block.

4. Finally, the end of transmission of the current content entity is marked by a block with a data length value of 0.

In this example, Transfer-Encoding: chunked is first marked in the response header, followed by the first block "0123456780" of length b (hexadecimal 11), followed by "Hello CxmyDev" and "123" respectively, and finally a block of length 0 marks the end of the current response.

Chunked trailer

When we use chunked for block coding transmission, after the transmission is over, there is still an opportunity to add a piece of data at the end of the block message, which is called trailer.

The suspended data can be the data that the server needs to deliver at the end, and the client can actually ignore and discard the suspended content, which requires both parties to negotiate the content of the transmission.

The trailer may include an attached header field, and all HTTP headers except Transfer-Encoding, Trailer, and Content-Length headers may be sent as trailers.

Usually we will use the trailer to pass some values that cannot be determined at the beginning of the response message, for example: Content-MD5 header is a common header appended to the trailer. As with length, it is difficult to calculate MD5 values for content entities that need to be block-coded for transmission at the beginning of the response.

Note that Trailder is added to the header to specify that a Content-MD5 trailer header will be passed at the end. If there are multiple trailers, commas can be used to separate them.

Combination of content coding and transmission coding

Content coding and transmission coding are generally used together. We compress the content entity using content encoding, and then send it out in blocks using transport encoding. The client receives the segmented data, reintegrates the data, and restores it to the original data.

Transmission coding summary

We should know something about the transmission code. Here is a brief summary:

1. The transport encoding is marked with the Transfer-Encoding header, which in the latest HTTP/1.1 protocol has only one value, chunked, indicating block encoding.

2. Transmission coding is mainly to solve the problem of determining the end of content entity transmission after data block transmission in persistent connection.

3. Block format: data length (hexadecimal)+ block data.

4. If there is additional data, you can use Trailer to drag the extra data after the end.

5. Transmission encoding is usually used in conjunction with content encoding.

In addition, the transmission code should be all HTTP/1.1 standard implementations, should have support, if you receive an unintelligible transmission encoded message, you should directly return 501 Unimplemented status code to reply.

The above is what HTTP's transmission encoding is, Xiaobian believes that some knowledge points may be what we see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.