As we have said last time, there is no protocol, and communication between computers is even more dependent on the protocol. Today, we will focus on analyzing the TCP protocol.
TCP is a connection-oriented, reliable, and byte-stream-based transport layer communication protocol defined by RFC 793 of IETF. In the simplified computer network OSI model, it completes the functions specified by the layer-4 transmission layer. User data packet protocol (UDP) is another important transmission protocol in the same layer.
Let's first review the OSI Layer-7 model.
TCP works on the fourth layer of OSI-the transport layer, IP on the third layer-the network layer, ARP on the second layer-the data link layer; data on the second layer, we call it frame. The data on the third layer is called packet, and the data on the fourth layer is called segment. At the same time, we need to know that when data is sent from the application layer, header information is added to each layer for encapsulation and then sent to the data receiving end.
The TCP protocol involves too much knowledge and there is no way to balance it. I mainly want to talk about three handshakes and four waves. The TCP operation can be divided into three stages: establishing a connection, transmitting data, and closing a connection. Three handshakes and four waves correspond to establishing and closing the connection.
The operating system abstracts TCP connections into local endpoints represented by sockets and uses them as programming interfaces. During the lifetime of a TCP connection, the local endpoint must undergo a series of state changes. We often hear about socket-oriented programming.
If you want to know how the handshake works, Let's first look at the TCP packet structure.
The following requirements must be noted:
There is no IP address, source port and destination port in the TCP packet. The IP address is in packet at the network layer.
Sequence Number (sequence number) is used to identify the Data byte stream sent from the TCP sending end to the TCP receiving end. It indicates the sequence number of the First Data byte in this packet segment in the data stream; both parties need to know the initialization serial number of the other Party. This serial number must be used as the serial number for subsequent data communication, to ensure that the data received by the application layer is not in disorder due to network transmission issues (TCP uses this serial number to splice data ).
Acknowledgment number (validation number) 32-bit validation serial number contains the next serial number expected to be received by one end of the sending confirmation. Therefore, the validation serial number should be the byte number that was successfully received last time plus 1. However, the field that confirms the serial number is valid only when the ACK mark (described below) in the flag is 1. It is mainly used to solve the problem of no packet loss.
SYN, indicating the synchronization sequence number, used to establish a connection. SYN and ACK are used together. When a request is connected, SYN = 1, ACK = 0; when the connection is responded, SYN = 1, ACK = 1.
Packets with this flag are often used for port scanning. The scanner sends a syn-only data packet. If the recipient's host responds to a data packet, it indicates that the host has this port. However, this scan method only performs the first handshake of three TCP handshakes, therefore, the success of this scan means that the machine to be scanned is not safe. A secure host will force a connection to perform a TCP three-way handshake strictly.
Ack, TCP protocol, valid only when ACK = 1, also requires that the ACK of all sent packets after the connection is established must be 1.
Fin indicates that the sender has reached the end of the data. That is to say, the data transfer between the sender and the sender is complete, and no data can be transmitted. After the TCP packet of the FIN flag is sent, the connection will be disconnected. Packets with this flag are often used for port scanning.
The three-way handshake process is the process of establishing a TCP connection. In socket programming, this process is triggered by the client performing connect. The entire process is shown in.
The first handshake: the client sets the flag SYN to 1, generates a random value seq = x, and sends the packet to the server. The client enters the syn_sent status and waits for the server to confirm.
The second handshake: After the server receives the data packet, the flag SYN = 1 knows the client request to establish a connection. The server sets both the flag SYN and ACK to 1, ACK = x + 1, generate a random value seq = y and send the packet to the client to confirm the connection request. The server enters the syn_rcvd status.
The third handshake: after the client receives the confirmation, it checks whether the Ack is x + 1, and whether the Ack is 1. If yes, it sets the flag ack to 1, ACK = Y + 1, the server checks whether Ack is Y + 1 and Ack is 1. If yes, the connection is established successfully. The client and server enter the established status and complete three handshakes, then the client and server can start to transmit data.
Note: Do not confuse SYN and ACK with only the flag bit. seq is the serial number to prevent disorder. Ack is the confirmation number, which is mainly used to solve the problem of no packet loss.
To terminate a TCP connection, you need to send a total of four packets from the client and the server to confirm the disconnection. In socket programming, this process is triggered by the close of either client or server side.
Because the TCP connection is full-duplex, every direction must be closed independently. This principle is that after one party completes the data transmission task, send a fin to terminate the connection in this direction. If a fin is received, it means that no data flow is sent to the upstream side, that is, no data will be received, however, data can still be sent over the TCP connection until the other party sends fin. The first party closes the service and the other party closes the service.
Wave for the first time: HOST 1 (client or server), set sequence number and acknowledgment number, and send a FIN packet segment to host 2, HOST 1 enters the fin_wait_1 status. This indicates that host 1 has no data to send to host 2;
Second wave: Host 2 receives the FIN packet segment sent by HOST 1, returns an ACK packet segment to host 1, acknowledgment number is set to sequence number plus 1, and host 1 enters fin_wait_2; host 2 tells HOST 1 that I "agree" to your close request;
The third wave: Host 2 sends the FIN packet segment to host 1, requests to close the connection, and host 2 enters the last_ack status;
The fourth wave: HOST 1 receives the FIN packet segment sent by host 2, sends the ACK packet segment to host 2, and then HOST 1 enters the time_wait status; host 2 closes the connection after receiving the ACK packet segment of Host 1. At this time, HOST 1 still does not receive a reply after waiting for 2msl, it indicates that the server has been properly shut down, HOST 1 can also close the connection.
Why do I need three handshakes to establish a connection?
Because TCP must ensure reliable data transmission at both ends, at least three interactions are required. Three times is the minimum value for mutual confirmation that the other party can receive the data. The following is an example of your life.
TCP uses three-way handshake, which is a compromise design used to solve the "two armies problem. The so-called "two armies problem" is that the Red Army wants to tell the Blue Army to open a fire on the enemy tomorrow afternoon, then the Red Army will send a letter to let the blue army run on the first day, the Blue Army received a message and sent another messenger to the Red Army on the 2nd. Note that the Blue Army does not know whether the Red Army has received a reply from the Red Army. Therefore, the Red Army needs to receive a reply and send another messenger to inform the Blue Army to receive a reply. At this time, the Red Army does not know whether the Blue Army has received a reply. Therefore, the Blue Army receives a message from the messenger 3 and sends another messenger 4...
There is another second to understand the example. I can see this is really laughing at me. However, this example is not rigorous. It is good to have the right to be happy.
Three-way handshake:
"Hey, can you hear me ?"
"Can you hear me ?"
"I can hear you. Today, balabala ......"
Two handshakes:
"Hey, can you hear me ?"
"I can hear it"
"Hello, can you hear me ?"
"Grass, I can hear it !!!!"
"Can you hear me !! Hello !"
"……"
Four handshakes:
"Hey, can you hear me ?"
"Can you hear me ?"
"Can I hear you? Can you hear me ?"
"…… Don't want to talk to me"
Therefore, the number of handshakes must be exactly the same. 2 is not enough, and 4 is more.
Syn Attack
Syn Attack means that the attack client spoofs a large number of nonexistent IP addresses in a short period of time, continuously sends Syn packets to the server, the server replies to the confirmation packet, and waits for the customer's confirmation. Because the source address does not exist, the server needs to re-send until it times out. These forged Syn packets will occupy the unconnected queue for a long time, and normal SYN requests will be discarded, resulting in slow operation of the target system, serious cases may cause network congestion or even system paralysis. SYN attacks are typical DoS/DDoS attacks.
It is very convenient to detect SYN attacks. When you see a large number of semi-connection statuses on the server, especially when the source IP address is random, it can basically be determined that this is a SYN attack.
How to defend against SYN attacks?
SYN attacks cannot be completely blocked unless the TCP protocol is re-designed. What we do is to minimize the harm of SYN attacks. Common methods to defend against SYN attacks are as follows:
Shorten the time-out (syn timeout)
Increase the maximum number of semi-connections
Filter Gateway Protection
Syn cookies
Why do I need to hold the TCP connection three times?