Environmental preparation
Originally I wanted to find a website for packet capture analysis, but there were HTTP too many website requests in the formal environment, too much interference, and not very friendly to analysis, so I made it simpler demoand HTTP returned a string to the request.
surroundings:
1.响应http请求的服务demo
2.客户端ip：192.168.2.135
3.服务端：45.76.105.92
4.抓包工具：Wireshark
To demodeploy to the server, start a successful visit as follows:
Open the packet capture tool Wireshark to capture the packet, the results of the packet capture are as follows:
From the above figure, we have seen a successful packet capture to a HTTP request and response, but we have seen a lot of TCPrequests. Next, let’s analyze TCP what these requests do?
Packet capture analysis
A) Three handshake
At the beginning, two requests were sent to the server locally. Why are there two requests here? I will talk about it later. Let's first look at the port request corresponding to HTTP, as follows:
192.168.2.135:60738---->45.76.105.92:8081
Looking at the screenshot above, we know that this is TCP the first handshake of the protocol. Those who are familiar with the TCP protocol must know that TCP there are three handshake to establish a connection, and four waves of hands to disconnect.
Let’s look at the first request:
60738 -> 8081 [SYN] Seq=0 Win=64240 Len=0 Mss=1460 Ws=256 SACK_PERM=1
Let's parse the packet request information:
-
60783->8081Port number: source port--->target port -
[SYN]: Synchronous handshake signal -
Seq: Message number -
Win: TCP window size -
Len: Message length -
Mss: Maximum segment length -
Ws: Window zoom adjustment factor -
SACK_PERM: SACK option, here is equal to 1 means to enable SACK.
For the above concepts, here is a brief explanation, and then introduce TCPHeader the data structure diagram we looked at before , to TCP have an intuitive understanding of the head data structure
1. Win: TCP window size refers TCPto the maximum number of bytes that can be transmitted. This can be dynamically adjusted, that is, TCPa sliding window. The rate of sending data can be controlled by dynamically adjusting the window size. The above figure occupies 2one byte, that is, 16bits, then the maximum number that can be supported is 2^16=65536, so by default, TCPthe maximum number of windows that the header tag can support is 65536bytes, that is 64KB.
2. Len: The message length refers to the data message segment, because the entire TCP报文 = Header + packSize, so this message length refers to the total length of the data packet to be transmitted, which is HTTPthe size of the message in this analysis .
3. Mss: Maximum message segment length : This is to specify the maximum length of the message that can be transmitted. In order to achieve the best transmission efficiency, the TCP agreement usually negotiates the MSS value of both parties when establishing a connection . This value TCP is when the agreement is implemented It is often replaced by a MTU value (need to subtract IPthe size of the packet header 20Bytesand the header of the TCPdata segment 20Bytes) so the general MSS value 1460is also consistent with the value in our packet capture diagram.
4. Ws: Window zoom adjustment factor : In the previous TCP window size, we mentioned that by default, the TCP maximum window size can only support 64KBbuffered data. In today's high-speed Internet era, this size must not meet the conditions, so, In order to support more buffered data, TCP the expansion options specified in RFC 1323 , among which the window zoom adjustment factor is one of them, how does this work? First of all, this parameter is [SYN] negotiated during the synchronization phase. Let's analyze the packet capture data above. We see that the result of the first request for negotiation is WS=256, and then the ACK expansion factor takes effect in the second stage , and the window size is adjusted. The effective packet capture is as follows:
60738 ->8081 [ACK] Seq=1 ACK=1 Win=66560 Len=0
We found that this window has become 66560larger than the default window. We check the message details:
We found that the actual requested window is 260, the WSexpansion factor is 256, and the final calculated window size is 66560, so we know that the function of this expansion factor is to multiply the original window size by the expansion factor to get the final window size, which is 260*256=66560.
5. SACK_PERM: SACK option , we know that TCP the transmission mechanism have confirmed the package, by default, after termination by accepting a package, sending ACK confirmation, however, only supports default order confirmation, that is, send A, B, C packages, If I received A, Cpackage, Bdid not receive, then for Cthis package I will not confirm, the need to wait for Bthe package after receipt of confirmation, then TCPthere is a timeout retransmission mechanism, a bag for a long time if not confirmed, it will When it is lost, it is retransmitted, which will cause a lot of redundant packets to be retransmitted and waste transmission space. In order to solve this problem, SACKa selective confirmation mechanism is proposed. When enabled SACK , the receiving end will confirm all received packets, so that the sending end will only re-fax the lost packets.
After briefly introducing the basic concepts above, let's sort out the HTTP request process based on packet capture . According HTTP to the local port of the request 60378, the sorting process is as follows:
------------------------请求连接--------------------------
1) 60738 -> 8081 [SYN] Seq=0 Win=64240 Len=0 Mss=1460 Ws=256 SACK_PERM=1
2) 8081 -> 60738 [SYN,ACK] Seq=0 ACK =1 Win=29200 Len=0 MSS=1420 SACK_PERM=1 WS=128
3) 60738 -> 8081 [ACK] Seq=1 ACK=1 Win=66560 Len=0
4) Get /test HTTP/1.1
5) 8081 -> 60738 [ACK] Seq=1 ACK=396 Win=30336 Len=0
6) HTTP/1.1 200 (text/html)
7) 60738 -> 8081 [ACK] Seq=396 ACK=120 Win=66560 Len=0
------------------断开连接-----------------------------
8) 60738 -> 8081 [FIN ACK] Seq=396 Ack=120 Win=66560 Len=0
9) 8081 -> 60738 [FIN ACK] Seq=120 Ack=397 Win=30336 Len=0
10) 60738 -> 8081 [ACK] Seq=397 Ack=121 Win=66560 Len=0
The above carding process we can know, 序号1- 序号3a significant three-way handshake, and then 序号4carried out a HTTP request, and then 序号5is HTTP once received confirmation request, 序号6in response to HTTP the request, 序号7a response to a request to confirm.
B) Wave four times
The above number 8, 9, 10 is to close the browser after I caught the pack, since it is close your browser, we know for sure is that TCP connection is disconnected. Some students here should have found the problem. We 4waved this time when we disconnected. There are only three records in the packet you grabbed. Did you write it wrong? What I want to tell you is that I made no mistakes. This is a real packet capture. As for why it is three times, let's analyze it:
Under normal circumstances, the connection is disconnected 4and the wave is the 4second wave. The process of the second wave is as follows:
We analyze this picture, the wave process is like this:
1. 客户端发起一个断开请求，进入 FIN-WAIT 状态
2. 服务端确认断开请求
3. 服务端立即发送一个断开请求，进入 CLOSE-WAIT 状态
4. 客户端确认服务端断开请求，进入 TIME-WAIT 状态
We found that the above 流程2and 流程3are initiated by the server, then there is no possible merger of these two requests, one sent to the client? The answer is yes . It 4.2 is mentioned in the section of RFC 2581 that the ackconfirmation can be delayed, and it is only required to ensure 500msthat the confirmation packet arrives within it. Under such a standard, TCPconfirmation is possible to merge delayed confirmation, so based on this, we infer the following package:
9) 8081 -> 60738 [FIN ACK] Seq=120 Ack=397 Win=30336 Len=0
Incorporates the ackconfirmation to the client and the FINdisconnection signal packet sent by the server . We clicked on the package details as follows: here is reflected in the red box, this 9号包is Frame500 a ACK correct confirmation, we can know according to the initial screenshot, this package is 8号包
8) 60738 -> 8081 [FIN ACK] Seq=396 Ack=120 Win=66560 Len=0
And it 9号包 itself is the FIN signal packet sent , so we can think that the content of 9号包the ACK sum FINis merged , so the usual 4wave of the hand becomes the 3second wave after the merger .
The above is a HTTP complete request, the whole process is shown as follows:
C) Keep-Alive
-
Some students here will definitely ask, since this is a complete HTTP request, is there a three-way handshake for every request?
The answer is: the current agreement is not used
In the HTTP0.9 version and HTTP1.0 version, each request and response requires a three-way handshake, but it HTTP1.0 starts to try to connect continuously, which is the Keep-Alive parameter, but the official has not officially supported it. In the HTTP1.1protocol, the official default is to support the Keep-Alive parameter, and the default is continuous connection. Keep-Alive There are two main functions:
1.检查死节点
2.防止连接由于不活跃而断开
-
Check for dead nodes
The main purpose is to allow rapid connection failures to be discovered and reconnection is possible. For example A , B a connection has been established with both ends, and the Bnode hangs due to an abnormal reason, and the A node does not know it. There are two situations at this time:
1. Assuming that the B node has not recovered, the B node will not reply ACK, and the Anode will keep retrying. Only after a certain number of retries can it be known that the B node is a dead node.
2. The Bnode Arestarts successfully before sending the data. At this time, the Anode sends the data, Bbut the node will not accept it, but will send a RST signal (when socket receiving data on a closed one, it will send a RSTdata packet and request the opposite end to close Abnormal connection and the opposite end does not need to reply ACK), and then A know that the B node needs to reconnect.
In the above two situations, it is only when the data is sent that the other party has an abnormality. The Keep-Alive heartbeat will be sent every once in a while, so you can quickly know the status of the server node.
-
Prevent disconnection due to inactivity
We know that the establishment and maintenance of network connections consume resources. The connections that can be established on a server are limited. Therefore, in order to save resources, inactive connections will be released in firewalls or operating systems, and Keep-Alive sent at regular intervals. A heartbeat packet tells the firewall or operating system that my connection is active and don't kill me.
Later, I grabbed the Keep-Alive package again, and the screenshot is as follows:
In the above figure, the last two packets are sent Keep-Alive packets, and then the server ACK confirms, we see that the keep-alive packets are actually sent with one byte packet, this is keep-alive the realization.
Having said Keep-Alivethat, let's go back to the original question, why is HTTP there a handshake between two ports for one request? Actually, this has nothing to do with the protocol itself. The first screenshot of the captured packet was accessed using Google browser, and the last captured image was accessed using Firefox browser. After careful comparison, we found that Firefox only has one port three times. shake hands. So this situation is the implementation of the browser itself. Why does Google Chrome implement this? The guess is: ensure the availability of HTTP access as much as possible. When a port is unavailable, you can immediately switch to another port to complete HTTP. Requests and responses . (Personal guess, if you have an authoritative answer, you can communicate in the comment area)
to sum up
-
HTTPThe request is based on theTCPconnection, andTCPthe three-way handshake will be performed when the first connection is made . -
HTTPThrough theKeep-Alivepersistent connection, a heartbeat packet is sent regularly to tell the server that it is still active. -
HTTPThe disconnection of the connection will also causeTCPfour waves of hands, but if the server determines that the conditions are met, theACKsumFINsignals will be merged and then converted into three waves of hands.