Blog.csdn.net/ZWE7616175/…
TCP header:
1. Source port number: indicates the port number of the sending port. The field length is 16 bits.
2. Destination port number: indicates the receiving port number. The field length is 16 bits.
3. Serial number: indicates the location where data is sent. The field length is 32 bits. Each time data is sent, the size of the data bytes is incremented.
Note: The serial number does not start at 0 or 1, but rather a random number generated by the computer as its initial value when the connection is established and sent to the receiving host via a SYN packet. The number of bytes forwarded is then added to the initial value to indicate the location of the data.
4. Acknowledge reply number: serial number of the data to be received next time. The field length is 32 bytes. After receiving this acknowledgement, the sender can assume that all data prior to this sequence number has been received normally.
The advantages of serial numbers are as follows: (1) Ensure that packets arrive in sequence. (2) Ensure reliability. (3) Ensure efficiency. (4) Accurately report which packets have been received and which need to be retransmitted.
Header length: The length of this field is 4 bits, in units of 4 bytes (32 bits). The TCP header length, excluding options, is 20 bytes, 20/4= 5,5 binary sequence: 0101, header length is also called data offset, so this field can be set to 5. The maximum length of the option field is 40 bytes. Therefore, the maximum length of the TCP header is 20+40=60 bytes, and this field can be set to 60/4=15. Reserved: This field is 4 bits long and is intended for later expansion. The value is generally set to 0. Even if the received packet is not 0 in this field, the packet is not discarded. Control bit: The field length is 6, and each bit is URG, ACK, PSH, RST, SYN, and FIN from left to right. If the value is 1, it indicates a specific meaning. Parameter Meaning Indicates whether the URG emergency pointer is valid. The value is 1, indicating that one of the packets needs to be processed first. The ACK confirmation number is valid. It is usually set to 1. PSH prompts the receiving application to immediately read the data away from the TCP buffer. RST The peer party requests to re-establish the connection and reset. SYN requests a connection and initializes the sequence number in its sequence number field. Set the connection to 1. FIN wishes to disconnect the connection. 8. Window size: the size of the receive buffer. TCP does not allow you to send data larger than the size shown here. 9. Checksum: the sending end is filled with CRC check. If the receiving check fails, the data is considered to have a problem. The difference between UDP and UDP is that UDP verifies the data itself, while TCP verifies not only the TCP header but also the TCP data part. 10. Emergency pointer: Valid only when URG is 1. This field 1 indicates the pointer to emergency data in the paragraph of this article. 11. Option: Improves TCP transmission performance. It needs to be controlled based on the length of the header, which can be 40 bytes at most.
We will focus on the use of serial numbers, confirmation numbers and flag bits in the three-way handshake and four-way wave.
1. The serial number seq. 4 bytes, used to mark the order of the data segments, the TCP connection to send all these data bytes in a serial number, the serial number of the first byte is composed of local random generation, to the bytes in the serial number, and each message segment is assigned a serial number, serial number seq is the period of the first byte of data message number.
No. 2. Confirm ack of 4 bytes, look forward to receiving the other side of the next message segment of the first data byte sequence number, serial number indicates the data message segment to carry the serial number of the first byte, and the confirmation number is expected to accept to the next byte number, therefore retaining wall section of the serial number of the last byte message + 1 is the confirmation number.
3. The ACK field is valid only when ACK=1. ACK=0, the confirmation number is invalid.
4. Synchronize Sequence numbers of SYN connections. When SYN=1, ACK=0 indicates that this is a connection request packet segment. If the connection is accepted, SYN=1, ACK=1 is used in the response packet segment. Therefore, SYN=1 indicates that this is a connection request or a connection received packet. The SYN bit is set to 1 only after TCP establishes a connection, and 0 after the handshake is complete.
5. Terminate the FIN to release one
TCP three-way handshake and four-way wave
Three handshakes
Step1: the first handshake
When a connection is established, the client sends a SYN packet to the server, which contains the initial sequence number of the client seq= X, and enters the SYN_SENT state for confirmation by the server. SYN=1, ACK=0, indicating that this is a TCP connection request packet. Serial number seq=x, indicating that the serial number of the first data byte is X).
Step2: The second handshake after the server receives the request, it must confirm the client’s packet. It also sends a SYN packet, that is, a SYN+ACK packet, and the server enters the SYN_RECV state. (In the acknowledgement packet, SYN=1 and ACK=1 indicate that this is a TCP connection response packet, and contain the initial sequence number of the server seq = Y and the initial sequence number of the server to the client ACK= SEq (client)+1=x+1).
Step3: Third handshake After receiving a SYN+ACK packet from the server, the client sends a sequence number (SEq = X +1) to the server, and the acknowledgement number is ACK (client)= Y +1. After the packet is sent, the client and the server enter ESTAB_LISHED state (TCP connection is successful), and the three-way handshake is complete.
Unconnected queue In the three-way handshake protocol, the server maintains an unconnected queue that opens an entry for each client’s SYN packet (SYN =j). This entry indicates that the server has received the SYN packet and sends an acknowledgement to the customer. While waiting for the acknowledgement packet, the server deletes the entry and enters ESTAB_LISHED state.
1. Why do you need to shake hands three times? Or four or five times? We have to analyze a special case, assuming that the client requests a connection, sent to the server the SYN packet waiting for a server to confirm, the server after receiving the confirmation, if it is two shake hands, assuming the server to the client to send data when the second handshake, data from the server, the server that connection has been established, but in the process of sending data loss of data, The client considers that the connection is not established and retransmits data. If the server continues to lose data each time the client SYN is sent, the server will generate multiple invalid connections, occupying resources, and the server may hang. This phenomenon is known as the SYN flood attack. Summary: The third handshake is to prevent: if the client does not receive the acknowledgement message from the server, it will drop the connection and restart a connection request. But the problem is: the server does not know that the client did not receive it, so it will receive two connections, wasting the connection cost. If this happens every time, multiple connection overhead is wasted.
Step1: for the first wave, the client sends a FIN to close the client-to-server data transfer and waits for the server’s confirmation. Where the stop flag bit FIN=1 and serial number SEq = U.
Step2: The server receives the FIN for the second wave and sends an ACK to confirm that the ACK is the received sequence number plus one.
Step3: close the connection between the server and the client with a third wave and send a FIN to the client.
Step4: wave for the fourth time after receiving the FIN, the client sends an ACK packet to confirm the receipt, and sets seq to the receiving sequence number plus one. The party that closes first performs an active shutdown and the other party performs a passive shutdown.
After the client sends a FIN packet, the server enters the termination wait state. After receiving the connection release packet from the client, the server immediately sends a confirmation message to the client. Then the server enters the CLOSE_WAIT state. In this case, the client cannot send messages to the server, but the server can send messages to the client. At this point, if the server has no datagrams to send to the client, its application notifies TCP to release the connection, then sends the client connection to release the datagrams and waits for confirmation. After sending the confirmation, the client enters the TIME_WAIT state, but the TCP connection has not been released, and then enters the CLOSE state after waiting 2MSL set by the timer.
2. Why do we need 2MSL time? MSL indicates the Maximum Segment Lifetime. MSL indicates the Maximum Segment Lifetime. As described in TCP/IP Detail, MSL is the maximum time that any packet segment stays in the network before being discarded. In RFC 793, MSL is defined as 2 minutes. In practical application, MSL is commonly used as 30 seconds, 1 minute, 2 minutes, etc.
TCP TIME_WAIT requires a timeout of 2MSL. When one end of TCP initiates an active shutdown and sends an ACK packet for the fourth wave, it enters this state. To prevent the peer party from receiving the last ACK packet, the peer party resends the FIN packet for the third handshake after the timeout. After receiving the resent FIN packet, the peer party can send another ACK packet. In TIME_WAIT state, the ports on both ends cannot be used until the end of 2MSL. When the connection is in the 2MSL wait phase, any late segments are discarded.
3. Why four waves, not three, or five, or six? Both parties must agree to close the connection. Therefore, the client sends a FIN to the server to close the connection. Upon receiving the FIN, the server sends an ACK for confirmation. The server then sends another FIN, and the client sends an ACK confirmation and enters the TIME_WAIT state. Wait for 2MSL and then automatically close.
Conclusion: (1) To ensure that the last ACK packet segment sent by the client can reach the server. That is, the last confirmation packet may be lost, and the server retransmits the packet due to timeout. Then the server sends a FIN request to close the connection, and the client sends an ACK. A return packet contains two packet life cycles.
If there is no waiting time and the connection is immediately released after the confirmation message is sent, the server cannot retransmit and therefore cannot receive the acknowledgement. Therefore, the server cannot enter the CLOSE state according to the steps, that is, it cannot CLOSE until it receives the acknowledgement. (2) Prevent invalid connection request packets from appearing in the connection. After 2MSL, within this continuous duration, all the generated message segments can disappear from the network. — — — — — — — — — — — — — — — — — — — — – the author: ZWE7616175 source: CSDN, blog.csdn.net/ZWE7616175/… Copyright notice: This article is the blogger’s original article, reprint please attach the blog link!