On the binary system of HTTP transmission

From the first contact with the HTTP protocol, I do not know what is going on, forming a false view that the HTTP protocol is a pure ASCII character protocol, that is, in the HTTP stream is not see the binary stream of the 0x00 value. In fact, the answer is that the content in the HTTP protocol can be a pure binary stream.
http://my.chinaunix.net/space.php?uid=22568683&do=blog&id=84701

The process of HTTP transmission of ASCII text content is believed to be easy to understand because HTTP request headers and response headers are transmitted in ASCII text. The details of the HTTP transport binary stream are not as complicated as I imagined, but when I learned POP3 and SMTP (both of which were mail transfer protocols), I knew that they could only transmit ASCII text, and if you wanted to add attachments to the message, such as a picture (picture file is binary file) that must first to the picture file transcoding, the Mail protocol can not transfer the binary data flow can be transmitted by the Mail protocol of the ASCII data stream, which uses the most conversion is BASE64 encoding conversion. In fact, BASE64 code conversion is also suitable for HTTP protocol, only you in the HTTP response header after the conversion of the transfer-encoding set to Base64, of course, if the customer service browser does not support base64 coding that conversion is futile, Fortunately, however, almost all browsers now support BASE64 (you can use the browser to view the attachment in the mail is evidence).

But then come back, since HTTP can directly support binary data stream transmission, then why do we go around the bend, walk Long Way.

If you have the same question about HTTP being able to transmit the binary directly, then the following content will be very much to your liking.

We illustrate the problem with the transmission of a picture:

Http://gimg.baidu.com/img/gs.gif this is BaiduThe link address of a very small picture on the home page is the right side
Image
The tools we use are:

Firefox Browser

Firebug a very good Webdebugger, Firefox plugin

Ethereal Network grasping Bag tool

If you are not familiar with the above three tools, I suggest you go to Google first. And then read on.

Below is our Firefox address bar in the input http://gimg.baidu.com/img/gs.gif back, Firefox silently for us to do things. For details about HTTP traffic please refer to my previous Articles

http://blog.chinaunix.net/u3/104217/showart.php?id=2075210

Http://p.99081.com/unix/http_protocol_summary.html

Get/gs.gif http/1.1

Host:gimg.baidu.com

user-agent:mozilla/5.0 (Windows; U Windows NT 5.1; ZH-CN; rv:1.9.1.3) gecko/20090824 firefox/3.5.3

accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

accept-language:zh-cn,zh;q=0.5

Accept-encoding:gzip,deflate

accept-charset:gb2312,utf-8;q=0.7,*;q=0.7

keep-alive:300

Connection:keep-alive

When Firefox makes the request, the server receives and analyzes the request, and after analysis, it concludes that the file (or page) requested by the client-side browser is/img/gs.gif (the first ramp represents the server root directory), So the server (Baidu's HTTP server for Apache) from the server host's hard disk (or directly from the buffer area of memory) read the picture (note oh, read the binary stream directly), and stitching it to the HTTP response header, Then copy the data (I mean the HTTP response header plus the binary data of the picture) to the TCP send buffer (that is, call the Send function).

The following ascended to the customer service side received the data flow from the server side:

Let's just analyze the response head first.

http/1.1 OK

Date:tue, Oct 2009 13:43:15 GMT

Server:apache

Last-modified:fri, Aug 2006 04:20:15 GMT

Accept-ranges:bytes

content-length:91

cache-control:max-age=315360000

Expires:fri, Oct 2019 13:43:15 GMT

Connection:close

Content-type:image/gif

Note the last field content-type:image/gif This indicates that an image object is being transmitted, which is in GIF format. Besides, we have a note of content-length:91. This indicates that the data transmitted (that is, the gs.gif picture) is 91 bytes in size, and we also find that the response header does not transfer-encoding this field, which means that the transmitted data is not encoded in any form and transmits the contents of the source file.

Please take a look at the Blue bottom section of the image above, the last line in the blue end, there are two consecutive 0d 0a 0d 0a, which indicates that the HTTP response header has ended and the next content is the transferred file. Well, then of course it's about to analyze what the transfer file is. Take a look at the picture below

The blue bottom portion of the figure is the transmitted data stream (that is, the transmitted file), these are what things, I also do not understand, (estimate only do picture compression algorithm people can understand), but it doesn't matter, we can first save the picture in the local, and then use a hexadecimal viewing software to open the picture, you can know the mystery.

The following is a screenshot of the picture opened with UltraEdit

Please compare the above two pictures is not a lot of the same place Ah, in fact, the above two images, the first one in the blue bottom part is the second one of the data. You should understand that, in fact, the HTTP transmission is the image file binary encoding, Apache does not have the binary file for any form of encoding conversion. We can also calculate the size of this picture: 16 * 5 + 11 = 91 (i.e. 0x5a–0x00 = 0x5a), exactly the same as the content-length in the HTTP response header.

If there is no ultraedit such as hexadecimal editor, I wrote a simple program for viewing, the following is the source code:

Check_hex.c

#include <stdio.h> #include <stdlib.h> #include <string.h> #define Hex_buffer 1024 int main (int argc, char *argv[]) { if (argc!= 2) { printf ("Usage:%s hex_file_path\n", argv[0]); Exit (1); } FILE *FP = NULL; fp = fopen (argv[1], "RB"); if (fp = NULL) { printf ("Open%s error.) Please check the path of File,and make sure your have permission to read it.\n ", argv[1]); Exit (1); } unsigned char hex_buf[hex_buffer]; memset (hex_buf, 0, Hex_buffer); int read_count = 0; Read_count = fread (hex_buf, sizeof (unsigned char), Hex_buffer, FP); if (ferror (FP)!= 0) { printf ("Read%s error.\n", argv[1]); Exit (1); } if (feof (FP) = 1) { printf ("Too large of%s, please enlarge macro hex_buffer.\n", argv[1]); Exit (1); } Fclose (FP); int i = 0; int j = 0; printf ("\naddr\t0 1, 2 3 4 5 6 7 8 9 a b c d e f\n"); for (; i < Read_count; i++, J + +) { if ((j% 16) = = 0) { printf ("\n0x%-4x\t", j); } printf

Transferred from http://www.51testing.com/?uid-390472-action-viewspace-itemid-233993