I. Key words
1. Packet header:
Ack 1.1:
Acknowledgement number: After receiving the packet from the client, the server sends an ACK packet to the client. The acknowledgement number of the reply packet is equal to the sequence number of the received packet +1: SEQ +1.
After receiving the packet from the client, the server sends an ACK packet to the client. The ACK number of the reply packet is equal to the sequence number (SEQ) of the received packet +1.
For example, if the sequence number of the packet received by the server is ISN+2048, the confirmation number of the packet returned by the server to the client is ISN+2048+1, which tells the client that all the data before the ISN+2048+1 is received.
A. After sending a packet, the client can send the next packet without waiting for the ACK reply from the server.
B. When sending an ACK reply, ensure that all data before the ACK ack number is received. For example, if the ACK with the ISN+2048 is received, but the ISN+1024 is not received, the ACK with the ISN+2048+1 cannot be received.
C. The server does not immediately send ack packets to the client after receiving data. The delay is 200ms. (the system has a timer to check whether ack packets need to be sent every 200ms.) This is because the order of TCP packets arriving is not guaranteed. For example, the ACK for the ISN+2048+1 ISN+1024+1 ISN+1024+1 ISN+1024+1 ISN+1024+1 ISN+1024+1 is not needed. An ACK that replies to ISN+2048+1 tells the client that all the data before ISN+2048+1 has been received. This also reduces network traffic. If the server does not receive any ACK response from the ISN+1024 because of packet loss, the client will resend data from the last ACK response, including the ISN+2048 received by the server. In addition, if the server happens to have data to send to the client, the ACK message will be included in the TCP packet that sends the data.
1.2 seq:
Serial number, == To ensure that multiple pieces of data are sent in the correct order ==. The initial sequence number is initialized to a random value, that is, ISN. The sequence number of a packet is the offset of the first byte of the data carried by the packet. Each handshake takes up a sequence number, so each handshake after that, the sequence number +1
2. The sign bit
-
ACK: 1 indicates that the acknowledgement number is valid. The packet segment carrying the ACK flag is also called the acknowledgement packet segment (used for handshake).
-
SYN: Initializes the sequence number of a connection. A value of 1 indicates that a connection is established. The segment carrying the SYN flag is the synchronization segment. The SYN flag bit is set to 1 only when TCP establishes a connection (that is, during a three-way handshake). When a client requests to establish a connection (for the first handshake), the packet carries the SYN flag and the initial sequence number (ISN). The SYN flag reminds the server of the start sequence number of the client. The server also initializes its start sequence number and replies to the client with a packet (second handshake) containing the start sequence number of the server, the SYN flag bit, and the ACK flag bit. The SYN flag bit is used to remind the client of the start sequence number of the server
-
FIN — a value of 1 indicates that the local end is closing the connection.
-
URG: 1 indicates that the emergency pointer is valid.
-
PSH: 1 indicates that the receiving application should immediately read data from the TCP receive buffer to make room for subsequent received data
-
RST: 1 notifies the peer party to close the connection or re-establish the connection. Once the reset packet segment is sent, all the queued data on the sender is discarded. In addition, the TCP connection is closed after the RST packet is sent. Therefore, the receiver does not need to send an ACK packet after receiving the RST packet.
Two. Three handshakes
Second handshake: (SYN=1, ACK=1, SEq = Y, ACK= x+1): The server detects SYN=1 (a connection request) after receiving the packet from the client. The Server sends back an ACK. That is, the SYN flag bit and ACK flag bit are both 1. The Server confirms the ISN sequence number Y, places it in the SEQ field, and sets the ACK sequence number to the ISN of the Client plus 1, that is, X +1. After sending the packets, the Server enters the SYN_RCVD state.
Third handshake :(ACK=1, seq=x+1, ACK= y+1) the Client sends an ACK packet with the ACK bit set to 1, and sends the ISN field +1 in the ACK field. After the TCP handshake is complete, the Client and Server establish a connection.
After receiving the reply from the server, the client finds ACK=1 and ACK= x+1, and then knows that the server has received the packet with serial number X. SYN=1, the server accepts the connection, so the server sequence number y is saved. The client then replies a packet to the server containing the ACK flag bit (ACK=1), ACK= Y +1 Server sequence number +1), and SEq = X +1. The packet that is sent during the first handshake occupies a sequence number. Note that the ACK packet that does not carry data does not occupy the sequence number. So seQ is x+1 when the data is sent officially for the first time. When the server finds ACK=1 and ACK= Y +1 after receiving the packet, the client knows that it has received the packet with the serial number Y. In this way, the client establishes a connection with the server through TCP.
Three. Four waves
The quadruple wave is actually the process of the Client and Server closing the TCP connection and sending four packets.
First wave :(FIN=1, seq=u)
If the Client wants to close the connection, it sends a packet with the FIN flag position 1 and the sequence number u (ISN+ length of the sent content +1), indicating that the connection needs to be closed. The Client enters the FIN_WAIT_1 state.
Note that after sending FIN packets, the client cannot send data, but can receive data normally. In addition, a FIN packet segment occupies a sequence number even if it does not carry data.
Second wave :(ACK=1, seq=v, ACK= u+1)
After receiving the FIN packet from the Client, the Server replies the Client with an ACKNOWLEDGEMENT packet containing the ACK flag bit (ACK=1), the packet whose SERIAL number is V (the ISN+ from the Server), and the received packet whose serial number is ACK is U +1. In this case, the Server receives the request to close the connection. But you’re not ready to close the connection. The Server enters the CLOSE_WAIT state, and the Client enters the FIN_WAIT_2 state.
The server is in the closed waiting state, but does not immediately send FIN packets to the client. This state lasts for a period of time because the server may not finish sending data.
Third wave :(FIN=1, ACK=1, seq=w, ACK= u+1)
When the Server has sent the rest of the data, it sends its own FIN packet with the sequence number U +1. The Server enters the LAST_ACK state and waits for the last ACK from the Client.
After sending the last data (for example, 50 bytes), the server sends a connection release packet to the client. The packet contains the FIN and ACK flag bits (FIN=1,ACK=1),ACK number (same as the second wave), and serial number (SEQ = (the server ISN+ what it is sending) +50.
Fourth wave :(ACK=1, seq=u+1, ACK= w+1)
After receiving the shutdown request from the Server, the Client sends the last ACK confirmation packet (ACK=1) with ACK id = W +1 and SEQUENCE number (SEq = U +1). The Client enters the TIME_WAIT state and waits for ACK packets that require retransmission. After receiving this acknowledgement packet, the Server closes the connection and enters the CLOSED state. After sending an acknowledgement packet, the Client does not immediately release the TCP connection. Instead, the Client waits for 2MSL(twice the lifetime of the longest packet segment). If the Client does not receive an ACK from the Server, it confirms that the Server is in the CLOSED state and closes the Server to enter the CLOSED state. The Server releases the TCP connection as soon as it receives the confirmation packet from the Client. Therefore, the Server terminates the TCP connection earlier than the Client.
Four. Often meet test questions
1. Why are TCP connections made three times? Can’t you do it twice?
In the book Computer Network, it is mentioned that the purpose of the three-way handshake is “to prevent the invalid connection request message segment from suddenly being transmitted to the server and causing errors”. This situation is as follows:
The first connection request packet sent by client A is not lost, but is delayed on A network node for some unknown reason. As A result, the packet arrives at server B some time after the connection is released. Originally, this is an invalid packet segment. However, after receiving the invalid packet, USER B mistakenly thinks it is A new connection request sent by user A. Therefore, user B sends another confirmation packet to user A, indicating that user B agrees to establish A connection. If the three-way handshake is not adopted, as long as end B sends A confirmation packet, it considers that A new connection has been established. However, end A does not send A request for establishing A connection, so it does not send data to end B. End B waits until it receives data, wasting A lot of resources. If the three-way handshake is adopted, this situation will not occur. After receiving an outdated and invalid packet segment, end B sends an acknowledgement to end A. In this case, end A does not request to establish A connection, so it does not send an acknowledgement to end B. In this case, end B also knows that the connection is not established.
2. Why are TCP connections made three times but closed four times?
This is because TCP can only be disconnected when neither the client nor the server has data to send. When the client sends FIN packets, the client can only ensure that no data is sent. It is unknown whether the server sends data to the client. While the service side only after receipt of the client a FIN message to reply a confirmation message to the client first told me the client service side FIN of your message has been received, but I still have some data server didn’t send out, such as the data is sent over the server to send the client FIN packet (so cannot one-time to send confirmation message and FIN a message to the client, This is the extra one).
3. Why does the client wait 2MSL to release the TCP connection after sending the fourth wave acknowledgement packet?
Packet loss is also considered here. If the fourth wave packet is lost, the server will resend the third wave packet without receiving the ack packet. In this way, the longest time for the packet to go back is 2MSL, so it takes such a long time to confirm that the server has received the packet.
4. What if the client suddenly fails after the connection is established?
TCP has a keepalive timer, so if the client fails, the server can’t wait forever, wasting resources. The server resets this timer every time it receives a request from the client, usually for two hours. If it does not receive any data from the client within two hours, the server sends a probe segment, which is then sent every 75 seconds. If there is no response after 10 probe packets are sent, the server assumes that the client is faulty and closes the connection.
5. Interview questions
1. The SYN attack
1) What is SYN Flood attack?
In the three-way handshake, after the server sends a SYN-ACK, the TCP connection before it receives an ACK from the client is called half-open connect. The server is in the SYN_RCVD state. The server changes to ESTABLISHED only after receiving the ACK.
In a SYN attack, the attacking client forges a large number of non-existent IP addresses in a short period of time and sends SYN packets repeatedly to the server. The server replies with an acknowledgement packet and waits for the client’s confirmation. Because the source address does not exist, the server needs to continuously resend until timeout. These forged SYN packets occupy the unconnected queue for a long time, and normal SYN requests are discarded, resulting in slow running of the target system, or even network congestion and system breakdown in serious cases.
SYN attack is a typical DoS/DDoS attack
2) How to detect SYN attacks?
SYN attacks are very easy to detect. When you see a lot of semi-connected states on the server, especially if the source IP address is random, you can basically tell that this is a SYN attack. On Linux/Unix, you can use the netstats command to detect SYN attacks.
3) How to defend against SYN attacks?
SYN attacks cannot be completely blocked unless TCP is redesigned. We minimize the damage caused by SYN attacks. Common SYN attack defense methods are as follows:
Shorten SYN Timeout
Increase the maximum number of connections
Filtering gateway Protection
The SYN cookies technology
4) Does it take 4 waves to close a TCP connection?
Not necessarily. Four waves to close the TCP connection is the safest thing to do. But there are times when we don’t like TIME_WAIT (for example, when MSL values are too high and the server has too many TCP connections in TIME_WAIT state, reducing the number of entries can close the connection more quickly, freeing up more resources for new connections). To prevent the SOCKET from entering the TIME_WAIT state after close(), set the SO_LINGER flag of the SOCKET variable. In this case, an RST is sent to forcibly terminate the TCP connection (instead of the normal TCP quad handshake termination). But this is not a very good idea, and TIME_WAIT is often advantageous to us.
5) Is the Server vulnerable to SYN attacks?
Resources on the Server are allocated during the second handshake, while resources on the Client are allocated during the third handshake. Therefore, the Server is vulnerable to SYN flood attacks. In this attack, the Client forges a large number of non-existent IP addresses in a short period of time and sends SYN packets to the Server. Because the source IP address does not exist, the Server repeatedly resends SYN packets until they time out. These forged SYN packets occupy unconnected queues for a long time. As a result, normal SYN requests are discarded because the queues are full, causing network congestion or even system breakdown.
6) Network Layer 7 protocol
- The application layer
Examples: TELNET, HTTP, FTP, NFS, SMTP, etc.
- The presentation layer
Examples: encryption, ASCII, etc.
- The session layer
Examples: RPC, SQL, etc.
- The transport layer
Example: TCP, UDP, SPX.
- The network layer
Example: IP, IPX, etc.
- Data link layer
Examples: ATM, FDDI, etc.
- The physical layer
Examples: Rj45, 802.3, etc.
2.TCP KeepAlive
TCP connection, in fact, is a pure software level concept, there is no “connection” in the physical level of this concept. The TCP communication parties establish an interactive connection, but data interaction does not always exist. Some connections are released after data interaction, while others are not. In a long period of time when there is no data interaction, both parties may have various accidents such as power failure, crash, and abnormal restart. When these accidents occur, the TCP connection is not released in time. On the software level, the other party does not know the situation of the peer end and maintains the connection all the time. The accumulation of a long time will lead to a lot of half-open connections, resulting in the consumption and waste of terminal system resources. To solve this problem, the KeepAlive mechanism of TCP can be used in the transport layer to achieve it. Most major operating systems support this feature in the kernel.
The basic principle of TCP KeepAlive is to send a probe packet to the peer end at intervals. If the peer end receives an ACK reply, the connection is considered alive. After the number of retries exceeds a certain limit, the peer end dismisses the TCP connection
Reference:
Mp.weixin.qq.com/s/3KPCJcyrM… Blog.csdn.net/weixin_3968… Juejin. Cn/post / 684490…