In the last article, we learned how to use Wireshark and tcpdump to analyze TCP’s “three-way handshake, four-way wave.” These two brothers are the legendary hammer, holding the hammer, everything looks like a nail! In this article, I hit HTTP with a nail, ahem.

To gain a deeper understanding of network packet “flow”, I deployed a service on Docker (remote) that supports HTTP invocation. Request one of the interfaces HTTP from the client (locally) and get the response data. Packets are captured using Wireshark locally and tcpdump remotely, and all communication details are analyzed. Tragedy is tearing up the beautiful things for people to see, and I am tearing up the complicated things for people to see.

This article is a bit longer, so please be patient as you read it. I first through the tool to obtain HTTP communication packet, and then to extract the cocoon, deep into the binary world, decrypt all HTTP communication details. In the analysis process, from point to surface, the relevant knowledge is connected. By the end of this article, your understanding of HTTP will have moved up a notch!

For a better reading experience, I manually pasted the contents of this article:

HTTP Packet Interception

background

I currently have a geogeometric service that provides a set of interfaces for external use. One of the interfaces is Fence2Area. The user enters a fence (consisting of a list of points, represented by < longitude, latitude >), the coordinate system type of the point (Google Map uses WGS84, Tencent and Autonavi in China use SOSO, and Baidu uses another set of their own coordinate system), and the interface outputs the area of the fence.

I request the “Fence2Area” interface of the service, input the fence vertex (LNG) coordinates, coordtype, and output the area of the polygon.

An example of a normal request URL, which is familiar to everyone (I use docker_IP instead of the real IP) :

http://docker_ip:7080/data?cmd=Fence2Area&meta= {" caller ":" test ", "TraceId" : "test"} & request = {" fence ": [{" LNG" : 10.2, "lat" : 10 2}, {" LNG ": 10.2," lat ": 8.2}, {" LNG" : 8.2, "lat" : 8.2}, {" LNG ": 8.2," lat ": 10.2}]," coordtype ": 2}Copy the code

After the request is sent, the server processes it, and the client receives the following data:

{
    "data": {
        "area": 48764135597.842606
    },
    "errstr": ""
}
Copy the code

The area field indicates the area. Errstr indicates an error message.

caught

Before sending the request, you need to set the packet before capturing it. For local MAC, I use Wireshark; On remote Docker, I use tcpdump.

MAC local

Set up wireshark packet filters to monitor communication between localhost and remote Docker.

ip.addr eq docker_ip
Copy the code

Click to start capturing.

Remote docker

The service is provided externally through port 7080. Use the following command to capture network packets:

tcpdump -w /tmp/testHttp.cap port 7080 -s0
Copy the code

Request && analysis

With all my preparation done, I selected a sacred moment and accessed the following URL locally via my browser:

http://docker_ip:7080/data?cmd=Fence2Area&meta= {" caller ":" test ", "TraceId" : "test"} & request = {" fence ": [{" LNG" : 10.2, "lat" : 10 2}, {" LNG ": 10.2," lat ": 8.2}, {" LNG" : 8.2, "lat" : 8.2}, {" LNG ": 8.2," lat ": 10.2}]," coordtype ": 2}Copy the code

In this way, both the local Wireshark and the remote Tcpdump can capture HTTP network packets.

Closing the service process

Before making a formal request, let’s look at a few special cases.

First, the GCS server process is shut down and the RST message is directly returned.

As shown in the figure above, when I request, I access another port 5010 on the server side. This port has no service listening and has the same effect as shutting down the GCS server process. As you can see, the client sent a SYN packet, but it was dropped by the remote Docker RST. The server operating system could not find the process listening on this port.

Close the docker

When docker is disabled, the docker retries 10 times because the SYN segment does not receive a response.

He retried 5 times every 1 second and then tried again at the interval of “exponential retreat”, 2s, 4s, 8s, 16s, 32s. The end.

Restart the docker

Perform a normal access and then restart the Docker. The browser still uses the same port as last time. After accessing the server, it has been restarted, so the server has no message about this connection. Therefore, an RST message is returned.

Normal request

The service starts normally, sends the request normally, this request succeeds, that is of course, heh heh!

Seven packets are captured using the Wireshark. The first three packets are three-way handshake packets, the fourth packet is HTTP request packets, the fifth packet is TCP confirmation packets sent by the server, the sixth packet is RESPONSE packets sent by the server at the HTTP layer, and the seventh packet is MAC confirmation packets sent by the server to the sixth packet.

Let’s focus on the next few packages, the fourth package,

0x0000:  4500 0295 0000 4000 3606 623b ac17 ccdc
0x0010:  0a60 5cd4 db9b 1ba8 a59a 46ce 6d03 e87d
0x0020:  8018 1015 0ee7 0000 0101 080a 2e4c b2ef
0x0030:  0f20 3acf 4745 5420 2f64 6174 613f 636d
0x0040:  643d 4665 6e63 6532 4172 6561 266d 6574
0x0050:  613d 7b25 3232 6361 6c6c 6572 2532 323a
0x0060:  2532 3274 6573 7425 3232 2c25 3232 5472
0x0070:  6163 6549 6425 3232 3a25 3232 7465 7374
0x0080:  2532 327d 2672 6571 7565 7374 3d7b 2532
0x0090:  3266 656e 6365 2532 323a 5b7b 2532 326c
0x00a0:  6e67 2532 323a 3130 2e32 2c25 3232 6c61
0x00b0:  7425 3232 3a31 302e 327d 2c25 3230 7b25
0x00c0:  3232 6c6e 6725 3232 3a31 302e 322c 2532
0x00d0:  326c 6174 2532 323a 382e 327d 2c25 3230
0x00e0:  7b25 3232 6c6e 6725 3232 3a38 2e32 2c25
0x00f0:  3232 6c61 7425 3232 3a38 2e32 7d2c 2532
0x0100:  307b 2532 326c 6e67 2532 323a 382e 322c
0x0110:  2532 326c 6174 2532 323a 3130 2e32 7d5d
0x0120:  2c25 3232 636f 6f72 6474 7970 6525 3232
0x0130:  3a32 7d20 4854 5450 2f31 2e31 0d0a 486f
0x0140:  7374 3a20 3130 2e39 362e 3932 2e32 3132
0x0150:  3a37 3038 300d 0a55 7067 7261 6465 2d49
0x0160:  6e73 6563 7572 652d 5265 7175 6573 7473
0x0170:  3a20 310d 0a41 6363 6570 743a 2074 6578
0x0180:  742f 6874 6d6c 2c61 7070 6c69 6361 7469
0x0190:  6f6e 2f78 6874 6d6c 2b78 6d6c 2c61 7070
0x01a0:  6c69 6361 7469 6f6e 2f78 6d6c 3b71 3d30
0x01b0:  2e39 2c2a 2f2a 3b71 3d30 2e38 0d0a 5573
0x01c0:  6572 2d41 6765 6e74 3a20 4d6f 7a69 6c6c
0x01d0:  612f 352e 3020 284d 6163 696e 746f 7368
0x01e0:  3b20 496e 7465 6c20 4d61 6320 4f53 2058
0x01f0:  2031 305f 3133 5f36 2920 4170 706c 6557
0x0200:  6562 4b69 742f 3630 352e 312e 3135 2028
0x0210:  4b48 544d 4c2c 206c 696b 6520 4765 636b
0x0220:  6f29 2056 6572 7369 6f6e 2f31 322e 302e
0x0230:  3220 5361 6661 7269 2f36 3035 2e31 2e31
0x0240:  350d 0a41 6363 6570 742d 4c61 6e67 7561
0x0250:  6765 3a20 7a68 2d63 6e0d 0a41 6363 6570
0x0260:  742d 456e 636f 6469 6e67 3a20 677a 6970
0x0270:  2c20 6465 666c 6174 650d 0a43 6f6e 6e65
0x0280:  6374 696f 6e3a 206b 6565 702d 616c 6976
0x0290:  650d 0a0d 0a
Copy the code

Let’s analyze it word by word.

Byte value	Byte meaning
0x4	The IP version is ipv4
0x5	The header length is 5 * 4 bytes =20B
0x00	Service type, now basically set to 0
0x0295	The total length is 661 bytes, that is, the length of the entire package is 661 bytes
0x0000	Logo. A unique identifier for the same datagram. When IP datagrams are split, they are copied to every piece of data.
0x4000	3bit flag + 13bit offset. The 3-bit flag corresponds to R, DF, and MF. Currently, only the last two bits are valid. DF bit: 1 indicates no sharding, and 0 indicates sharding. MF: a value of 1 means “more slices” and a value of 0 means this is the last slice. 13bit bit shift: indicates the bit offset of the fragment relative to the first digit in the original data packet. (We need to multiply by 8)
0x36	TTL of the TTL. Indicates the maximum number of routers that IP packets are allowed to pass. Each time it passes through a router, the TTL decreases by 1. When it is 0, the router discards the datagram. The TTL field is an 8-bit field initially set by the sender. The recommended initial value is specified by the allocation number RFC. The TTL is often set to the maximum value 255 when sending an ICMP echo reply. TTL prevents datagrams from falling into routing loops. Here is 54.
0x06	Protocol type. Indicates the protocol used by the data carried by the IP packet so that the IP layer of the destination host can know which process to submit the data packet to. The PROTOCOL number of TCP is 6, and that of UDP is 17. The protocol number of ICMP is 1, and that of IGMP is 2. The data carried by the IP packet is authenticated using TCP.
0x623b	16bitIP header checksum.
0xac17 ccdc	32-bit Source IP address.
0x0a60 5cd4	32-bit Destination IP address.

The rest of the data is related to TCP. TCP is also a 20B fixed length + variable length part.

Byte value	Byte meaning
0xdb9b	16-bit source port. 56219
0x1ba8	16bit destination port 7080
0xa59a 46ce	32-bit serial number. 2778351310
0x6d03 e87d	32-bit confirmation number. 1828972669
0x8	4bit length of the header, expressed in 4 bytes. 8 x 4=32 bytes. Therefore, the optional length of TCP packets ranges from 32 to 20=12 bytes
0b000000	6bit reserved bits. This is set to 0.
0b011000	6bit Indicates the TCP flag bit. From left to right are emergency URG, ACK confirmation, PSH push, RST reset, SYN synchronization, and FIN termination. Both ACK and PSH are valid
0x1015	Sliding window size: Sliding window is the size of the TCP receive buffer, used for TCP congestion control. 4117
0x0ee7	16bit checksum.
0x0000	Emergency pointer. It is only meaningful if URG = 1, which indicates the number of bytes of urgent data in this paragraph. When URG = 1, the sender TCP inserts the emergency data at the top of the column data, while the data after the emergency data remains normal data.

For variable length, the protocol is as follows:

Byte value	Byte meaning
0x01	No operation
0x01	No operation
0x0402	Express support for SACK
0x080a 2e4c b2ef 0f20 3acf	The time stamp. Ts val=0x2e4c b2ef=776778479, ecr=0x0f20 3acf=253770447

All that’s left is the data. Let’s go line by line. Since HTTP is a stream of characters, let’s take a look at the ASCII character set and run the following command:

man ascii
Copy the code

To get ASCII code, let’s go straight to the hexadecimal result:

Address of the beginning of a line	Byte stream	character
0x0030	4745 5420 2f64 6174 613f 636d	GE T /d at a? cm
0x0040	643d 4665 6e63 6532 4172 6561 266d 6574	d= Fe nc e2 Ar ea &m et
0x0050	613d 7b25 3232 6361 6c6c 6572 2532 323a	a= {% 22 ca ll er %2 2:
0x0060	2532 3274 6573 7425 3232 2c25 3232 5472	%2 2t es t% 22 ,% 22 Tr
0x0070	6163 6549 6425 3232 3a25 3232 7465 7374	ac eI d% 22 :% 22 te st
0x0080	2532 327d 2672 6571 7565 7374 3d7b 2532	%2 2} &r eq ue st ={ %2
0x0090	3266 656e 6365 2532 323a 5b7b 2532 326c	2f en ce %2 2: [{ %2 2l
0x00a0	6e67 2532 323a 3130 2e32 2c25 3232 6c61	ng %2 2: 10 .2 ,% 22 la
0x00b0	7425 3232 3a31 302e 327d 2c25 3230 7b25	t% 22 :1 0. 2} ,% 20 {%
0x00c0	3232 6c6e 6725 3232 3a31 302e 322c 2532	22 ln g% 22 :1 0. 2, %2
0x00d0	326c 6174 2532 323a 382e 327d 2c25 3230	2l at %2 2: 8. 2} ,% 20
0x00e0	7b25 3232 6c6e 6725 3232 3a38 2e32 2c25	{% 22 ln g% 22 :8 .2 ,%
0x00f0	3232 6c61 7425 3232 3a38 2e32 7d2c 2532	22 la t% 22 :8 .2 }, %2
0x0100	307b 2532 326c 6e67 2532 323a 382e 322c	0{ %2 2l ng %2 2: 8. 2,
0x0110	2532 326c 6174 2532 323a 3130 2e32 7d5d	%2 2l at %2 2: 10 .2 } ]
0x0120	2c25 3232 636f 6f72 6474 7970 6525 3232	,% 22 co or dt yp e% 22
0x0130	3a32 7d20 4854 5450 2f31 2e31 0d0a 486f	:2 } HT TP /1 .1 crnl Ho
0x0140	7374 3a20 3130 2e39 362e 3932 2e32 3132	st : 10 .9 6. 92 .2 12
0x0150	3a37 3038 300d 0a55 7067 7261 6465 2d49	:7 08 0cr nlU pg ra de -I
0x0160	6e73 6563 7572 652d 5265 7175 6573 7473	ns ec ur e- Re qu es ts
0x0170	3a20 310d 0a41 6363 6570 743a 2074 6578	: 1cr nlA cc ep t: t ex
0x0180	742f 6874 6d6c 2c61 7070 6c69 6361 7469	t/ ht ml ,a pp li ca ti
0x0190	6f6e 2f78 6874 6d6c 2b78 6d6c 2c61 7070	on /x ht ml +x ml ,a pp
0x01a0	6c69 6361 7469 6f6e 2f78 6d6c 3b71 3d30	li ca ti on /x ml ; q =0
0x01b0	2e39 2c2a 2f2a 3b71 3d30 2e38 0d0a 5573	. 9, * / *; q =0 .8 crnl Us
0x01c0	6572 2d41 6765 6e74 3a20 4d6f 7a69 6c6c	er -A ge nt : Mo zi ll
0x01d0	612f 352e 3020 284d 6163 696e 746f 7368	a/ 5. 0 (M ac in to sh
0x01e0	3b20 496e 7465 6c20 4d61 6320 4f53 2058	; In te l Ma c OS X
0x01f0	2031 305f 3133 5f36 2920 4170 706c 6557	1 0_ 13 _6 ) Ap pl eW
0x0200	6562 4b69 742f 3630 352e 312e 3135 2028	eb Ki t/ 60 5. 1. 15 (
0x0210	4b48 544d 4c2c 206c 696b 6520 4765 636b	KH TM L, l i k e Ge ck
0x0220	6f29 2056 6572 7369 6f6e 2f31 322e 302e	o) V er si o n /1 2. 0.
0x0230	3220 5361 6661 7269 2f36 3035 2e31 2e31	2 Sa fa ri /6 05 .1 .1
0x0240	350d 0a41 6363 6570 742d 4c61 6e67 7561	5cr nlA cc ep t- La ng ua
0x0250	6765 3a20 7a68 2d63 6e0d 0a41 6363 6570	ge : zh -c ncr nlA cc ep
0x0260	742d 456e 636f 6469 6e67 3a20 677a 6970	t- En co di ng : gz ip
0x0270	2c20 6465 666c 6174 650d 0a43 6f6e 6e65	, de fl at ecr nlC on ne
0x0280	6374 696f 6e3a 206b 6565 702d 616c 6976	ct io n: k ee p- al iv
0x0290	650d 0a0d 0a	ecr nl cr nl

To put together the last column in the table above, it is:

GET /data? CMD = Fence2Area & meta = {% 22 caller % 22: % 22 test % 22, % 22 traceid % 22: % 22 test % 22} & request = {% 22 fence % 22: [{% 22 LNG % no. 2, % 22 lat % band LNG % % 20, 0.2}, {% 22 no. 2, then % % 22 lat. 2}, % 20 {then % 22 LNG % 2, % 22 lat % ". The 2}, % 20 {then % 22 LNG % 2, % 22 lat % no. 2}], % 22 coordtype % 22:2} HTTP/1.1 Host: 10.96.92.212:7080 upgrade-insecure -Requests: 1 Accept: text/html,application/xhtml+xml,application/xml; Q = 0.9 * / *; Q = 0.8 the user-agent: Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.2 Safari/605.1.15 Accept-language: zh-cn Accept-Encoding: gzip, deflate Connection: keep-aliveCopy the code

Where cr nl means enter, line feed.

When docker receives the data, it replies with an ACK package. The total length of the fourth packet is 661 bytes, excluding the IP header 20 bytes, the fixed part of the TCP header 20 bytes, and the optional length of the TCP header 12 bytes. Therefore, the total length of the TCP data part is 661-52=609 bytes. Also, the serial number is 2778351310.

For packet 5, the byte stream is as follows:

0x0000:  4500 0034 d28b 4000 4006 8810 0a60 5cd4
0x0010:  ac17 ccdc 1ba8 db9b 6d03 e87d a59a 492f
0x0020:  8010 00ec e04e 0000 0101 080a 0f20 3af7
0x0030:  2e4c b2ef
Copy the code

Byte value	Byte meaning
0x4	The IP version is ipv4
0x5	The header length is 5 * 4 bytes =20B
0x00	Service type, now basically set to 0
0x0034	The total length is 52 bytes, that is, the length of the entire package is 52 bytes
0xd28b	Logo. A unique identifier for the same datagram. When IP datagrams are split, they are copied to every piece of data.
0x4000	3bit flag + 13bit offset. The 3-bit flag corresponds to R, DF, and MF. Currently, only the last two bits are valid. DF bit: 1 indicates no sharding, and 0 indicates sharding. MF: a value of 1 means “more slices” and a value of 0 means this is the last slice. 13bit bit shift: indicates the bit offset of the fragment relative to the first digit in the original data packet. (We need to multiply by 8)
0x40	TTL of the TTL. Indicates the maximum number of routers that IP packets are allowed to pass. Each time it passes through a router, the TTL decreases by 1. When it is 0, the router discards the datagram. The TTL field is an 8-bit field initially set by the sender. The recommended initial value is specified by the allocation number RFC. The TTL is often set to the maximum value 255 when sending an ICMP echo reply. TTL prevents datagrams from falling into routing loops. Here is 54.
0x06	Protocol type. Indicates the protocol used by the data carried by the IP packet so that the IP layer of the destination host can know which process to submit the data packet to. The PROTOCOL number of TCP is 6, and that of UDP is 17. The protocol number of ICMP is 1, and that of IGMP is 2. The data carried by the IP packet is authenticated using TCP.
0x8810	16bitIP header checksum.
0x0a60 5cd4	32-bit Source IP address.
0xac17 ccdc	32-bit Destination IP address.

The rest of the data is related to TCP. TCP is also a 20B fixed length + variable length part.

Byte value	Byte meaning
0x1ba8	16-bit source port 7080
0xdb9b	16bit destination port. 56219
0x6d03 e87d	32-bit serial number. 1828972669
0xa59a 492f	32-bit confirmation number. 2778351919. The serial number of the third packet is 2778351310, plus the data length 609, which is exactly the same.
0x8	4bit length of the header, expressed in 4 bytes. 8 x 4=32 bytes. Therefore, the optional length of TCP packets ranges from 32 to 20=12 bytes
0b000000	6bit reserved bits. This is set to 0.
0b010000	6bit Indicates the TCP flag bit. From left to right are emergency URG, ACK confirmation, PSH push, RST reset, SYN synchronization, and FIN termination. Ack effective
0x00ec	Sliding window size: Sliding window is the size of the TCP receive buffer, used for TCP congestion control. 4117
0xe04e	16bit checksum.
0x0000	Emergency pointer. It is only meaningful if URG = 1, which indicates the number of bytes of urgent data in this paragraph. When URG = 1, the sender TCP inserts the emergency data at the top of the column data, while the data after the emergency data remains normal data.

For variable length, the protocol is as follows:

Byte value	Byte meaning
0x01	No operation
0x01	No operation
0x0402	Express support for SACK
0x080a 2e4c b2ef 0f20 3acf	The time stamp. Ts val=253770487, ecr=776778479

The data section is empty, and this package is only an acknowledgement package.

For the sixth packet, the byte stream is as follows:

0x0000:  4500 00f9 d28c 4000 4006 874a 0a60 5cd4
0x0010:  ac17 ccdc 1ba8 db9b 6d03 e87d a59a 492f
0x0020:  8018 00ec e113 0000 0101 080a 0f20 3af8
0x0030:  2e4c b2ef 4854 5450 2f31 2e31 2032 3030
0x0040:  204f 4b0d 0a41 6363 6573 732d 436f 6e74
0x0050:  726f 6c2d 416c 6c6f 772d 4f72 6967 696e
0x0060:  3a20 2a0d 0a44 6174 653a 2054 6875 2c20
0x0070:  3033 204a 616e 2032 3031 3920 3132 3a32
0x0080:  333a 3437 2047 4d54 0d0a 436f 6e74 656e
0x0090:  742d 4c65 6e67 7468 3a20 3438 0d0a 436f
0x00a0:  6e74 656e 742d 5479 7065 3a20 7465 7874
0x00b0:  2f70 6c61 696e 3b20 6368 6172 7365 743d
0x00c0:  7574 662d 380d 0a0d 0a7b 2264 6174 6122
0x00d0:  3a7b 2261 7265 6122 3a34 3837 3634 3133
0x00e0:  3535 3937 2e38 3432 3630 367d 2c22 6572
0x00f0:  7273 7472 223a 2222 7d
Copy the code

Byte value	Byte meaning
0x4	The IP version is ipv4
0x5	The header length is 5 * 4 bytes =20B
0x00	Service type, now basically set to 0
0x00f9	The total length is 249 bytes, that is, the length of the entire package is 249 bytes
0xd28c	Logo. A unique identifier for the same datagram. When IP datagrams are split, they are copied to every piece of data.
0x4000	3bit flag + 13bit offset. The 3-bit flag corresponds to R, DF, and MF. Currently, only the last two bits are valid. DF bit: 1 indicates no sharding, and 0 indicates sharding. MF: a value of 1 means “more slices” and a value of 0 means this is the last slice. 13bit bit shift: indicates the bit offset of the fragment relative to the first digit in the original data packet. (We need to multiply by 8)
0x40	TTL of the TTL. Indicates the maximum number of routers that IP packets are allowed to pass. Each time it passes through a router, the TTL decreases by 1. When it is 0, the router discards the datagram. The TTL field is an 8-bit field initially set by the sender. The recommended initial value is specified by the allocation number RFC. The TTL is often set to the maximum value 255 when sending an ICMP echo reply. TTL prevents datagrams from falling into routing loops. Here is 64.
0x06	Protocol type. Indicates the protocol used by the data carried by the IP packet so that the IP layer of the destination host can know which process to submit the data packet to. The PROTOCOL number of TCP is 6, and that of UDP is 17. The protocol number of ICMP is 1, and that of IGMP is 2. The data carried by the IP packet is authenticated using TCP.
0x874a	16bitIP header checksum.
0x0a60 5cd4	32-bit Source IP address.
0xac17 ccdc	32-bit Destination IP address.

The rest of the data is related to TCP. TCP is also a 20B fixed length + variable length part.

Byte value	Byte meaning
0x1ba8	16-bit source port 7080
0xdb9b	16bit destination port. 56219
0x6d03 e87d	32-bit serial number. 1828972669
0xa59a 492f	32-bit confirmation number. 2778351919
0x8	4bit length of the header, expressed in 4 bytes. 8 x 4=32 bytes. Therefore, the optional length of TCP packets ranges from 32 to 20=12 bytes
0b000000	6bit reserved bits. This is set to 0.
0b011000	6bit Indicates the TCP flag bit. From left to right are emergency URG, ACK confirmation, PSH push, RST reset, SYN synchronization, and FIN termination. Both ACK and PSH are valid
0x00ec	Sliding window size: Sliding window is the size of the TCP receive buffer, used for TCP congestion control. 236
0xe113	16bit checksum.
0x0000	Emergency pointer. It is only meaningful if URG = 1, which indicates the number of bytes of urgent data in this paragraph. When URG = 1, the sender TCP inserts the emergency data at the top of the column data, while the data after the emergency data remains normal data.

For variable length, the protocol is as follows:

Byte value	Byte meaning
0x01	No operation
0x01	No operation
0x0402	Express support for SACK
0x080a 0f20 3af8 2e4c b2ef	The time stamp. Ts val=0x2e4c b2ef=253770488, ecr=0x0f20 3acf=776778479

All that’s left is the data. Let’s go line by line.

The first address	Byte stream	character
0x0030	4854 5450 2f31 2e31 2032 3030	HTTP / 1.1 200
0x0040	204f 4b0d 0a41 6363 6573 732d 436f 6e74	OK \r\n Access-Cont
0x0050	726f 6c2d 416c 6c6f 772d 4f72 6967 696e	rol-Allow-Origin
0x0060	3a20 2a0d 0a44 6174 653a 2054 6875 2c20	: * \r\n Date: Thu,
0x0070	3033 204a 616e 2032 3031 3920 3132 3a32	03 Jan 2019 12:2
0x0080	333a 3437 2047 4d54 0d0a 436f 6e74 656e	3:47 GMT \r\n Conten
0x0090	742d 4c65 6e67 7468 3a20 3438 0d0a 436f	t-Length: 48\r\n Co
0x00a0	6e74 656e 742d 5479 7065 3a20 7465 7874	ntent-Type: text
0x00b0	2f70 6c61 696e 3b20 6368 6172 7365 743d	/plain; charset=
0x00c0	7574 662d 380d 0a0d 0a7b 2264 6174 6122	utf-8\r\n\r\n{“data”
0x00d0	3a7b 2261 7265 6122 3a34 3837 3634 3133	:{“area”:4876413
0x00e0	3535 3937 2e38 3432 3630 367d 2c22 6572	5597.842606}, “er
0x00f0	7273 7472 223a 2222 7d	rstr”:””}

To put together the last column in the table above, it is:

HTTP/1.1 200 OK Access-Control-Allow-Origin: * Date: Thu, 03 Jan 2019 12:23:47 GMT Content-Length: 48 Content-Type: text/plain; Charset = utf-8 {" data ": {" area", 48764135597.842606}, "errstr" : ""}Copy the code

Content-length: 48. The Length of the last line is 48 bytes.

Finally, in the seventh packet, the byte stream is as follows:

0x0000:  4500 0034 0000 4000 3606 649c ac17 ccdc
0x0010:  0a60 5cd4 db9b 1ba8 a59a 492f 6d03 e942
0x0020:  8010 100f 1eb9 0000 0101 080a 2e4c b314
0x0030:  0f20 3af8
Copy the code

Byte value	Byte meaning
0x4	The IP version is ipv4
0x5	The header length is 5 * 4 bytes =20B
0x00	Service type, now basically set to 0
0x0034	The total length is 52 bytes, that is, the length of the entire package is 52 bytes
0x0000	Logo. A unique identifier for the same datagram. When IP datagrams are split, they are copied to every piece of data.
0x4000	3bit flag + 13bit offset. The 3-bit flag corresponds to R, DF, and MF. Currently, only the last two bits are valid. DF bit: 1 indicates no sharding, and 0 indicates sharding. MF: a value of 1 means “more slices” and a value of 0 means this is the last slice. 13bit bit shift: indicates the bit offset of the fragment relative to the first digit in the original data packet. (We need to multiply by 8)
0x36	TTL of the TTL. Indicates the maximum number of routers that IP packets are allowed to pass. Each time it passes through a router, the TTL decreases by 1. When it is 0, the router discards the datagram. The TTL field is an 8-bit field initially set by the sender. The recommended initial value is specified by the allocation number RFC. The TTL is often set to the maximum value 255 when sending an ICMP echo reply. TTL prevents datagrams from falling into routing loops. Here is 54.
0x06	Protocol type. Indicates the protocol used by the data carried by the IP packet so that the IP layer of the destination host can know which process to submit the data packet to. The PROTOCOL number of TCP is 6, and that of UDP is 17. The protocol number of ICMP is 1, and that of IGMP is 2. The data carried by the IP packet is authenticated using TCP.
0x649c	16bitIP header checksum.
0xac17 ccdc	32-bit Source IP address.
0x0a60 5cd4	32-bit Destination IP address.

The rest of the data is related to TCP. TCP is also a 20B fixed length + variable length part.

Byte value	Byte meaning
0xdb9b	16-bit source port. 56219
0x1ba8	16bit destination port 7080
0xa59a 492f	32-bit serial number. 2778351919
0x6d03 e942	32-bit Confirmation number. 1828972866. The serial number of the sixth packet is 1828972669, plus the data length 197, which is exactly the same
0x8	4bit length of the header, expressed in 4 bytes. 8 x 4=32 bytes. Therefore, the optional length of TCP packets ranges from 32 to 20=12 bytes
0b000000	6bit reserved bits. This is set to 0
0b010000	6bit Indicates the TCP flag bit. From left to right are emergency URG, ACK confirmation, PSH push, RST reset, SYN synchronization, and FIN termination. Ack effective
0x100f	Sliding window size: Sliding window is the size of the TCP receive buffer, used for TCP congestion control. 4111
0x1eb9	16bit checksum.
0x0000	Emergency pointer. It is only meaningful if URG = 1, which indicates the number of bytes of urgent data in this paragraph. When URG = 1, the sender TCP inserts the emergency data at the top of the column data, while the data after the emergency data remains normal data.

For variable length, the protocol is as follows:

Byte value	Byte meaning
0x01	No operation
0x01	No operation
0x080a 2e4c b314 0f20 3af8	The time stamp. Ts val=0x2e4c b314=776778516, ecr=0x0f20 3af8=253770488

At this point, a complete HTTP request packet is resolved. How do you feel? Is it intimate?

HTTP Protocol Analysis

We have deconstructed the data related to HTTP protocol, and I will take you step by step to understand HTTP protocol by comparing the results of the above data disassembly.

Overall introduction

Hypertext Transfer Protocol (HTTP) is a Protocol used for communication over the Internet. To put it more figuratively: HTTP is the common language of the modern Internet. Its best known use is for communication between servers in browsers.

HTTP belongs to the application layer protocol, and the bottom layer relies on TCP for reliable information transmission.

HTTP Transmits packets in the form of streams through an open TCP connection in sequence. TCP receives a data stream from an upper-layer application and breaks the data stream into segments in sequence. It is delivered to the IP layer and transmitted through the network. Receivers on the other end, on the other hand, assemble the segments they receive in sequence and hand them over to the upper HTTP protocol for processing.

coding

Let’s review:

url	value
Original url	/data? CMD = Fence2Area & meta = {” caller “:” test “, “TraceId” : “test”} & request = {” fence “: [{” LNG” : 10.2, “lat” : 10.2}, {” LNG “: 10.2,” lat “: 8.2}, {” LNG” : 8.2, “lat” : 8.2}, {” LNG “: 8.2,” lat “: 10.2}],” coordtype “: 2}
Encoded url	/data? CMD = Fence2Area & meta = {% 22 caller % 22: % 22 test % 22, % 22 traceid % 22: % 22 test % 22} & request = {% 22 fence % 22: [{% 22 LNG % no. 2, % 22 lat % band LNG % % 20, 0.2}, {% 22 no. 2, then % % 22 lat. 2}, % 20 {then % 22 LNG % 2, % 22 lat % “. The 2}, % 20 {then % 22 LNG % 2, % 22 lat % no. 2}], % 22 coordtype % A vigorous}

In the previous packet unpacking process, we saw a lot more %22. In fact, 0x22 is the ASCII value of single quotation marks.

On the one hand, the resources described by URL can be transmitted through various other protocols, but some protocols will strip some specific characters in the transmission process. Urls, on the other hand, are still readable, so non-printable characters such as Spaces cannot be used in urls; Finally, the URL needs to be complete, and it needs to support characters in all languages.

In summary, URL designers integrate THE US-ASCII code and its escape sequence into urls for a number of reasons, and by escaping sequences, it is possible to encode arbitrary characters or data with a limited subset of the US-ASCII character set.

Escape method: The percent sign (%) is followed by two hexadecimal numbers representing the ASCII code. Such as:

So is it any wonder that the URL the browser sends to the server is encoded with non-” safe characters “?

In a URL, the URL needs to be encoded when the reserved character above is used for something other than the reserved purpose.

The MIME type

In the response data, we notice a header:

Content-Type: text/plain; charset=utf-8
Copy the code

There are thousands of different data types on the Internet, and HTTP labels each object with a Multipurpose Internet Media Extension (MIME), The content-type in the response data. MIME was originally used in the mail protocol, but was later ported to HTTP. When the browser retrieves an object from the server, it looks at the MIME type to know what to do with the object, whether to display an image or call a sound card to play a sound. MIME uses slashes to identify the main type of an object and specific subtypes within it. The following table shows some common types, where the body of the entity refers to the body part:

URI/URL/URN

Uniform Resource Identifiers (URIs) indicate server resources. Uniform Resource Locator (URL) and Uniform Resource Name (URN) are specific URI implementations. Uris are a general concept consisting of two main subsets of urls, which identify resources by location, and UrNs, which identify resources by name.

A URL defines the location of a resource and represents the actual address of the resource. When using a URL, if the location of the resource behind the URL changes, the visitor cannot find it. This is where the URN comes in. It gives the resource a name that can be used to query it wherever it moves. Perfect!

The usual format for a URL is:

Protocol scheme + server ADDRESS + Specific resource pathCopy the code

Protocol schemes, such as HTTP and FTP, tell Web clients how to access resources); Server address, for example, www.oreilly.com. A specific resource path, such as index.html.

HTTP method

HTTP supports several different request methods, each of which requires different actions on the server. Here are some common methods:

The HEAD method only gets the header, not the data part. The header is used to obtain information such as the content-type and content-length of the resource. In this way, the client can obtain some information about the resource that is about to be requested.

POST is used to send data to the server, usually to submit a form. PUT Stores data to resources on the server.

Status code

Each HTTP response packet carries a three-digit status code and an explanatory “reason phrase” to notify the client of the status of the request and help the client quickly understand the transaction result. The most common ones are:

200 OK 
404 Not Found
500 Internal Server Error
Copy the code

When we usually use the browser, a lot of error codes are actually handled by the browser, we do not know. But 404 Not Found comes to us through thick and thin. Why? It is because of his deep love for us!

The client can use the status code to determine the next action (such as redirection).

The first digit of a three-digit number indicates a classification:

Message format

HTTP packets are actually made up of lines of strings, with the end of each line delimited by \r\n, which can be easily read by humans. By the way, not all protocols are so friendly to humans. Like the Thrift protocol, which just throws a bunch of bytes at you and tells you 0x0001 means calling a method, and so on, you can only “decode” one hexadecimal chunk at a time. It is impossible to encode characters like HTTP, which humans can read directly.

Take a simple example of the format of request and response messages:

In fact, the request message can also have a body part. A request packet consists of request line, header, blank line, and request data. The only thing to note is that even if the body part of the request message is empty, the carriage return newline character after the request header must be present.

The format of the response message is similar to that of the request message:

The fields in the start line of the request message, the response message, and the response header are textual and structured. The request body, on the other hand, can contain any binary data (images, videos, software, etc.) or, of course, text.

Some headers are generic, while others are unique to request or response messages.

The first	attribute	value	meaning
Date	general	Thu, 03 Jan 2019 12:23:47 GMT	The time when the packet is constructed
Accept	The request message	text/html,application/xhtml+xml,application/xm	The type of data that the client can receive
Content-Type	general	Content-Type: text/plain; charset=utf-8	The data type of the body part in the packet. Note that this field is also required if the request packet also contains data

By the way, Telnet directly to the HTTP port of the server. The Telnet command establishes a TCP channel through which you can then send HTTP request data directly to retrieve the response data.

HTTP protocol advanced

The agent

The HTTP proxy server is both a Web server and a Web client.

Using a proxy, you can “touch” all the HTTP traffic that flows through, and the proxy can monitor and modify it. It is common to filter “adult” content for children; Network engineers use proxy servers to improve security by limiting which application-layer protocol data can pass through and filtering data such as viruses. The proxy can store cached files and return them directly to visitors without requesting the original server resources; When accessing public content on slow networks, you can pretend to be a server to provide services, thus improving access speed. This is called a reverse proxy; Can be used as a content router, such as for paying users, to direct requests to the cache server, improve access speed; The language of the page can be converted to match that of the client, which is called a content transcoder; The anonymous proxy deletes identity information, such as user-Agent and Cookie fields, from HTTP packets.

In reality, requests are sent to proxy servers in one of the following ways:

Each time a message passes through an intermediate point (proxy or gateway), a unique string representing the node is inserted at the end of the header VIA field, including the protocol version implemented and the host address. Notice the VIA field in the figure.

Request and response packets usually travel the same path, but in opposite directions. Therefore, the order of the intermediate nodes represented by the VIA field on the response message is reversed.

The cache

When there are many requests to access the same page, the server will transmit the same data multiple times. These data are transmitted repeatedly in the network, consuming a large amount of bandwidth. If you cache this data, you can improve response times and save network bandwidth.

Most caches test the freshness of a copy only if the client initiates a request and the copy is old. The most common request header is if-modified-since. If nothing has changed after xx time, the server responds with 304 Not Modified. Otherwise, the server responds normally and returns the original file data, a process known as a revalidation hit.

Reverify that a hit or miss may occur. On a miss, the server replies with 200 OK and returns complete data; On a hit, the server returns 304 Not Modified; Alternatively, if the cache is deleted, the cache server will also delete a copy of its cache based on the response status code.

By the way, if you want to use caching in a project, it’s important to pay attention to the cache hit ratio. If the hit rate is low, you may reconsider the need to set up a cache.

The cache server returns a response based on the header of the cached server response, with some minor tweaks to the header fields. Such as inserting freshness information (Age, Expires headers, etc.), and often including a VIA header indicating that the cache is provided by a cache proxy. Note that you do not modify the Date field at this point, which represents the Date on which the response was originally built by the original server.

HTTP maintains sufficient consistency between cached data and data across servers through document expiration mechanisms and server revalidation mechanisms.

Document expiration is indicated by the following header field:

When the expiration time implied by the above two fields is up, you need to verify the freshness of the document with the server again. If the cache is still the same as the original document on the server, the cache only needs to update the relevant fields in the header. Such as the Expires field mentioned in the table above.

In order to save network traffic, the cache server can send a conditional GET request to the original server via the relevant header, so that the original document will only be returned if the cache actually expires, otherwise only the relevant header will be returned. Conditional GET requests use the following fields:

cookie

A cookie is a label that the server “sticks” to the client, a fragment of state maintained by the client, and sent back only to the appropriate site.

There are two types of cookies: session cookies and persistent cookies. Session cookies are deleted after exiting the browser. Persistent cookies, on the other hand, are kept on the hard disk and persist after the computer restarts.

The server prefixes set-cookie or set-cookie2 to the client’s response field with a list of names = values, which can contain multiple fields. The next time the browser visits the same site, it carries these fields with it through cookies. The content retained in the cookie is the identification code that the server labels the client to facilitate tracking by the service. The browser stores cookies in a specific file in a specific format.

The browser only sends the cookie to the site that generated the cookie. The value of the set-cookie field contains the domain field, telling the browser that it can send the cookie to the relevant matching site. The PATH field does a similar thing. For example, browser I receives the following cookie:

Set-cookie: user="mary"; domain="stefno.com"
Copy the code

When the browser visits any site that ends in Stefno.com, it sends:

Cookie: user="mary"
Copy the code

Entity and encoding

The data transmitted in the body part of the response message is binary in nature. We can also see from the above packet data, which are expressed in hexadecimal numbers. The key is how to interpret this content. If the content-Type definition is text/plain, then the body Content is the text, and we interpret it as text encoding; If the content-Type definition is image/ PNG, then the body part is an image, and we interpret the data in the image format.

Content-length Indicates the Length of the data in the main body of a packet. If the Content is compressed, it indicates the compressed size. In addition, content-Length can segment multiple packets correctly in the case of long connections. Therefore, if chunking is not used, the response data must have a Content-Length field. In chunking, the data is broken up into many small pieces, each with a size description. Therefore, any message (request or response) with a body part should have the correct Content-Length header.

Earlier versions of HTTP delimited the end of a message by closing a connection. The problem with this is obvious: the client can’t tell whether the server ended properly or crashed. In this case, it is not advisable for the client to close to indicate the end of the body part of the request message, because after closing, the server will not be able to get a response. Of course, the client can use a semi-closed way, only to close the direction of data sent, but many servers are ignorant of other, will treat the semi-closed as a client to disconnect the server.

The HTTP packet may be unintentionally modified by a proxy or other communication entity during transmission. To let the recipient know about this, the server performs an MD5 on the body part and places the value in the Content-MD5 field. However, if the intermediate proxy modifies both the packet body and md5, it is difficult to detect. Therefore, the agent cannot modify the Content-MD5 header. In this way, after receiving the data, the client decodes it, calculates MD5, and compares it with the Content-MD5 header. This is to prevent the agent from unintentionally modifying the packet.

HTTP encodes the content before sending it. It is a reversible transformation of the packet body. For example, packets are compressed in GZIP format to reduce transmission time. Common encoding types are as follows:

Of course, in order to prevent the server from returning data that it cannot decode, the client will include its own supported Encoding in the accept-encoding header. Any encoding is accepted by default if not transmitted.

The encoding mentioned above is content encoding, which only encodes the original data in the main message of the response message, but changes the format of the content. There is another kind of encoding: transport encoding. It’s not about content, it’s about changing the way message data travels over the network. Transport encoding is a new feature introduced in HTTP 1.1.

Typically, when the server needs to transmit data, it calculates the Length of the data and encodes it into Content-Length. Sometimes, however, the content is dynamically generated and the server wants to start transferring the data before it is generated, so there is no way to know the size of the data. In this case, the transfer code is used to mark the end of the data.

The HTTP protocol describes and controls the transmission encoding through the following two headers:

field	meaning	Typical values
Transfer-Encoding	The sender informs the receiver of what transmission encoding we have done	Chuncked is chunked
TE	The requester tells the server which transport encoding can be used	Chuncked accepts block coding and is willing to accept a drag on the end of a message

The block-coded message looks like this:

Each partition contains a length value (hexadecimal, number of bytes) and the data for that partition.


is used to distinguish length values and data. The length value does not contain any


sequences in the partition. The last partition ends with a length value of 0. Note that the packet header contains a Trailer: Content-MD5, so there is a drag immediately after the end of the last packet. Content-length, Trailer, transfer-Encoding can also be used as drags.

Content encoding and transport encoding can be used together.

Internationalization support

In order for HTTP to support internationalized content, the client tells the server what language it understands and what alphabet encoding algorithm is installed on the browser. This is done with the Accept-charset and Accept-language headers.

Such as:

Accept-Language: fr, en; Q = 0.8 Accept - Charset: iso - 8859-1, utf-8Copy the code

Note: The client supports French (FR, priority 1.0 by default) and English (EN, priority 0.8), and supports ISO-8859-1 and UTF-8 character sets. The server will put charset in the content-Type prefix.

In essence, the body part of the HTTP packet stores a string of binary codes. We first convert the binary codes into character codes (for example, ASCII is a character with a byte, while UTF-8 is a character with an variable number of bytes, ranging from 1 to 6 bytes), and then use the character codes to find the corresponding elements in the character set.

The more common character set is US-ASCII: the ancestor of all character sets, the standard was published as early as 1968. ASCII code values range from 0 to 127, and only 7 bits are needed to cover code space. The ASCII character set used in the header and URL of HTTP packets. Take a look at the ACSII code set in the packet analysis section above.

Us-ascii encodes each character into a fixed 7-bit binary value. Utf-8 has no fixed encoding scheme. The high value of the first byte is used to indicate the number of bytes used to encode the character (if the number of bytes used is 5, the first five bits of the first byte are all 1 and the sixth bit is 0), and the subsequent bytes required contain a code value of 6 bits, with the first two bits identified by 10.

For example, the Unicode encoding for the Chinese character “Yan” is 4E25(100111000100101), which has 15 bits and falls on the third line in the table above, so the encoding for “Yan” requires three bytes. Fill 100111000100101 into the C bit in the table above. Therefore, the strict UTF-8 code is 11100100 10111000 10100101, which translates to hexadecimal E4B8A5. For example, when I search for “strict” in the Google search box, Google sends out the following request:

https://www.google.com.hk/search?q=%E4%B8%A5&oq=%E4%B8%A5&aqs=chrome.. 69 i57j0l5. 3802 j0j4 & sourceid = chrome&ie = utf-8 & gws_rd = crCopy the code

Q =%E4%B8%A5 This is the search term.

Redirection and load balancing

Web content is often distributed in many places, which prevents “single points of failure” — if an earthquake strikes somewhere and the computer room is destroyed, there are other computer rooms that can provide services. Generally there will be the so-called “double live”, “live more”, the so-called cunning rabbit three caves.

In this way, the user’s request is redirected to where it should go according to the principle of load balancing.

HTTP redirection

When the server receives the client request, it returns a message with status code 302 redirection telling the client that they should try somewhere else. Web sites use redirection as a simple load-balancing strategy. The redirection server finds the least loaded machine available, and since the server knows the address of the client, it can, in theory, make optimal redirection choices.

Of course, the disadvantages are obvious, as the client sends the request twice, thus increasing the time.

DNS redirect

DNS associates several IP addresses to a domain and uses an algorithm to determine which IP address to return. It can be a simple rotation; It can also be a more advanced algorithm, such as returning the IP address of the lightest load server, known as the load balancing algorithm; If geographical location is considered, the address of the nearest location is returned to the client, which is called the adjacency routing algorithm. Another method is to bypass the failed address, called a fault masking algorithm.

The DNS server always returns all IP addresses, but the DNS client usually only uses the first IP address, which is cached and used forever. Therefore, DNS rotation usually does not balance the load on a single client. However, because the DNS server always returns a rotated list of IP addresses for different requests, the load is spread over multiple clients.

HTTP connection

The HTTP connection is a key channel for HTTP packet transmission.

Parallel connection

When multiple objects appear on a page at the same time, if the browser opens multiple connections in parallel and obtains these objects at the same time, the TCP handshake delay of multiple connections can be overlapped and the speed will be faster.

For a page with three images, the browser sends four HTTP requests to fetch the page. One for the top-level HTML page and three for the image. If the serial approach is used, the connection delays are superimposed.

With parallel connections:

However, parallel connections do not necessarily improve the speed. If a page has hundreds of embedded objects, it will have to start hundreds of connections, which is also very challenging to the performance of the server. As a result, browsers usually limit the total number of concurrent connections to a small value, usually 4, and servers are free to close clients’ excessive connections.

On the other hand, if the client network bandwidth is low, each connection will compete for the limited bandwidth, and each connection will get a low speed, that is, each object will load at a low speed. In this way, the speed gain from parallel connections will be small or non-existent.

A persistent connection

HTTP keep alive – mechanism

We know that HTTP requests are request-reply. Each request-reply creates a new connection and then disconnects. HTTP is stateless and there is no relationship between connections.

HTTP is an application layer protocol and TCP is a transport layer protocol. The HTTP base still uses TCP to transmit data. TCP provides a layer of reliable bit transport over HTTP. HTTP typically does not exchange much data, and the TCP three-way handshake for each connection takes up a significant portion of the time, sometimes as much as 50%. If you can reuse the connection, you can reduce the latency associated with the TCP three-way handshake.

Keep-alive is enabled by default in HTTP 1.1, as can be seen from the packet captured above. In this way, the TCP connection is kept open after the data transfer is complete, and the multiplexing of the connection with the domain name continues to transmit data over this channel. After the server responds to a request, it can keep the keep-alive timeout period for the connection. If no request is made within this period, the connection is closed. Otherwise, restart the countdown keep-alive timeout time.

HTTP has the keep-alive mechanism, which enables multiple HTTP transactions to be transmitted over a TCP connection to improve communication efficiency. The underlying TCP also has a keep-alive mechanism to detect the activity of the TCP connection. The KEEPalive of the TCP layer can be set on either side, at one end, at both ends, or at neither end. The keep-alive property of the connection is activated when the protocol stack calls the tcp_set_keepalive function.

When a TCP connection is established on both ends of the network and the idle time (no data flow is sent between the two sides) exceeds tcp_keepalive_time, the server kernel tries to send a detection packet to the client to determine the TCP connection status (the client may crash, the application may be forcibly shut down, the host may be unreachable, and so on). If no ack packet is received, tcp_keepalive_intvl attempts to send the probe packet again until the ack packet is received. If no ACK packet is received, tcp_keepalive_probes tries several times. The interval time here is 15s, 30s, 45s, 60s, 75s respectively. If no ACK packet is received after repeated tcp_keepalive_probes attempts, the TCP connection is discarded. The default idle time of TCP connection is 2 hours. Generally, 30 minutes is sufficient.

Pipe connection

On the basis of keep-alive, we can go one step further. Before the response arrives, we put multiple requests into the request queue in sequence. After receiving the request, the server must correspond to the response of the request in sequence. However, because the network environment is very complex, even if the requests are sent sequentially, they do not necessarily reach the server sequentially. And even if the server processes it sequentially, it does not necessarily return it sequentially to the client, so it is best to include some parameters in the response that identify the request.

To be on the safe side, the connection pipelining is only suitable for “power”, such as the request, generally we think: GET/HEAD/PUT/DELETE/TRACE/OPTIONS and other methods are idempotent.

summary

That’s all of the HTTP communication details, enough to use in your daily development. More details that are not covered can be studied as needed.

After reading the article, do you have a better understanding of HTTP? Welcome to discuss with us.

The resources

【 long HTTP connection 】 www.cnblogs.com/cswuyg/p/36…

The HTTP/TCP keep alive 】 segmentfault.com/a/119000001…

【 HTTP/TCP keep alive】laravel-china.org/articles/80…

【 TCP keep alive 】 blog.51cto.com/zxtong/1788…

HTTP authority guidelines book.douban.com/subject/107 】…

The HTTP status code 】 【 www.cnblogs.com/starof/p/50…

The HTTP protocol 】 【 www.cnblogs.com/ranyonsue/p…

[HTTP status classification] www.runoob.com/http/http-s…

Url encoding 】 【 www.ruanyifeng.com/blog/2010/0…

The HTTP/TCP keep alive 】 www.nowamagic.net/academy/det…