Status chart of TCP Connection
Three handshakes of TCP connection establishment and four handshakes of closing connection
Paste a Telnet command to establish a connection. If the connection is disconnected, use the packet captured by Wireshark.
1. Establish a connection protocol (three-way handshake)
(1) the client sends a TCP packet with a SYN sign to the server. This is packet 1 during the three-way handshake.
(2) The server responds to the client. This is the first packet in the three-way handshake. This packet carries both the ACK mark and SYN sign. Therefore, it indicates the response to the client SYN Packet. It also marks the SYN message to the client and asks whether the client is ready for data communication.
(3) The customer must re-respond to an ACK packet in the service segment, which is packet segment 3.
2. Connection termination protocol (four handshakes)
Because the TCP connection is full-duplex, each direction must be closed separately. This principle is that when one party completes its data sending task, it can send a fin to terminate the connection in this direction. Receiving a fin only means that there is no data flow between the two parties. a tcp connection can still send data after receiving a fin. First, the party that closes the service will take the initiative to close the service, and the other party will passively close the service.
(1) The tcp client sends a fin to disable data transmission from the customer to the server (packet segment 4 ).
(2) When the server receives the fin, it sends back an ACK and confirms that the serial number is 1 (packet segment 5 ). Like SYN, a fin occupies a sequence number.
(3) The server closes the client connection and sends a fin to the client (packet segment 6 ).
(4) The customer segment sends back the ACK message for confirmation, and sets the confirmation sequence number to receive the serial number plus 1 (packet segment 7 ).
Closed: this is nothing to say, indicating the initial state.
Listen: this is also an easy-to-understand status, indicating that a socket on the server is in the listening status and can accept connections.
Syn_rcvd: this status indicates that the SYN packet is received. Normally, this status is an intermediate status of the server socket during the three-way handshake session when a TCP connection is established. It is very short, basically, you can hardly see this status with netstat unless you write a client test program and deliberately disable the last ACK packet from the three TCP handshakes. Therefore, when an ACK packet is received from the client, it enters the established status.
Syn_sent: this status echo syn_rcvd. When the client socket executes the connect connection, it first sends the SYN packet, and then it enters the syn_sent status, and wait for the server to send 2nd messages in the three-way handshake. Syn_sent status indicates that the client has sent Syn packets.
Established: This is easy to understand, indicating that the connection has been established.
Fin_wait_1: The fin_wait_1 and fin_wait_2 statuses both indicate waiting for the FIN packets of the other party. The difference between the two States is that the fin_wait_1 state is actually when the socket is in the established State, it wants to actively close the connection and send a FIN packet to the other party, the socket enters the fin_wait_1 state. When the other Party responds to the ACK packet, it enters the fin_wait_2 status. Of course, under normal circumstances, the other party should immediately respond to the ACK packet, regardless of the situation, therefore, the fin_wait_1 status is generally difficult to see, while the fin_wait_2 status is often seen using netstat.
Fin_wait_2: The above has explained in detail this status. In fact, the socket in the fin_wait_2 status indicates a semi-connection, that is, either party requires a close connection, but also tells the other party, I have some data to send to you, and close the connection later.
Time_wait: indicates that the FIN packet of the other party is received, and the ACK packet is sent concurrently, so that 2msl can return to the closed available status. If fin_wait_1 receives a message with both the fin mark and ACK mark, it can directly enter the time_wait status without passing through the fin_wait_2 status.
Closing: this is a special exception that is rare in actual situations. Normally, when you send a FIN packet, you should first (or simultaneously) receive the ACK packet from the other party and then receive the FIN packet from the other party. However, the closing status indicates that after you send the FIN packet, you have not received the ACK packet from the other party, but have also received the FIN packet from the other party. Under what circumstances will this happen? In fact, it is not difficult to come to the conclusion that if both parties close a socket at the same time, both parties may send FIN packets at the same time, that is, the closing status may occur, both parties are closing the socket connection.
Close_wait: the meaning of this state is actually waiting to be closed. How can this problem be solved? When the other party closes a socket and sends a FIN packet to itself, your system will undoubtedly respond to an ACK packet to the other party, and then enters the close_wait status. Next, in fact, what you really need to consider is to check if you still have data to send to the other party. If not, you can close the socket and send the FIN packet to the other party, that is, close the connection. So what you need to do in close_wait is to wait for you to close the connection.
Last_ack: this status is easy to understand. It passively closes a side and waits for the other side's ACK packet after sending the fin message. After receiving the ACK message, you can enter the closed available status.
Supplement:
A. by default (without changing the socket option), when you call close (or closesocket, the close is not repeated), if there is data in the sending buffer, TCP continues to send data.
B. If fin is sent, it means that the end cannot send data continuously (the application layer cannot call send again), but it can also receive data.
C. How does the application layer know that the peer is disabled? Generally, in the simplest blocking model, if 0 is returned when you call Recv, it indicates that the peer is disabled. At this time, the usual practice is to call close, so the TCP layer sends fin and continues to complete four handshakes. If you do not call close, the peer end will be in the fin_wait_2 state, and the local end will be in the close_wait state. You can try writing code here.
D. In many cases, the TCP connection is automatically disconnected by the TCP layer. For example, if you press Ctrl + C to terminate your program, the TCP connection will still be closed normally. You can try writing code.
1. Why is the three-way handshake while the four-way handshake when the connection is closed?
This is because the socket in the listen status of the server can respond to ack and SYN after receiving the SYN Packet connection request) it is sent in a message. However, when the connection is closed, when the other party receives the fin Message notification, it only indicates that the other party has no data to send to you; but not all your data may have been sent to the other party, therefore, you may not close the socket immediately, that is, you may need to send some data to the other party, and then send the fin message to the other party to indicate that you agree to close the connection now, therefore, the ACK messages and fin messages are sent separately in most cases.
2. Why does the time_wait status still need to be 2 MSL before it can be returned to the closed status?
What is 2msl? MSL is maximum segment lifetime, that is, the maximum message survival time. In reference to "TCP/IP details", "it (MSL) it is the longest time in the network before any packet segment is discarded." Then, 2msl is twice the time. When the TCP connection completes the exchange of four packet segments, the party that closes the switch will continue to wait for a certain period of time (2-4 minutes ), even if the applications at both ends end. For example, after the Telnet client is closed, use netstat to view the result:
C: \> netstat-Na | find "172.29.21.25"
TCP 172.29.132.60: 2795 172.29.21.25: 23 time_wait
Why is this 2msl required,
First, although both parties agree to close the connection, and the four handshake packets are also coordinated and sent, it can be directly returned to the closed state (just like from syn_send to establish State), but because we must assume that the network is unreliable, you cannot guarantee that the last ACK message you sent will be received by the other party. Therefore, the socket in the last_ack status of the other party may fail to receive the ACK message due to timeout, but resend the fin message, therefore, the time_wait status is used to resend potentially lost ACK packets.
Second, messages may be confused, meaning that connections in other cases may be treated as the current connection. Directly reference the TCP/IP guide: the second is to provide a "buffering period" between the end of this connection and any subsequent ones. if not for this period, it is possible that packets from different connections cocould be mixed, creating confusion.
When one end of a connection is in the time_wait status, the connection will no longer be used. In fact, what makes sense for us is that this port will no longer be used. When a port is in the time_wait status (in fact, this connection should be used), this means that the TCP connection is not closed (completely disconnected). If you bind this port, it will fail. For the server, if the server suddenly crashes, it cannot be restarted within 2msl, because bind will fail. One way to solve this problem is to set the so_reuseaddr option of the socket. This option means you can reuse an address.
When a TCP connection is established, the server will continue to use the original port to listen and use this port to communicate with the client. By default, the client uses a random port to communicate with the listening port of the server. Sometimes, for the sake of server security, we need to verify the client, that is, to limit a client with a specific IP address port. The client can use bind to use specific ports. On the server side, when the so_reuseaddr option is set, it can be started in 2msl and listen is successful. However, when BIND is used on the client and so_reuseaddr is set, if BIND is started in 2msl, the connection fails on Windows platform even though BIND is successful. This problem does not exist in Linux. (My lab platform: WINXP, ubuntu7.10)
To solve this problem on Windows, you can set the so_linger option. The so_linger option determines the TCP behavior when close is called. So_linger involves the linger struct. If l_onoff In the struct is set to a non-0 value and l_linger is set to 0, the TCP connection will be disconnected immediately when close is called, and TCP will not send unsent data in the sending buffer, instead, an RST packet is sent to the peer immediately. At this time, the TCP connection (when it is closed) will not enter the time_wait status. As you can see, this solution solves the problem but is not safe. Setting the so_linger status is equivalent to setting the so_dontlinger status.
When a TCP connection experiences some physical exceptions, such as network disconnection, the TCP implementation on Linux still considers the connection to be valid, while Windows returns an error message after a certain period of time. This seems to be solved by setting the so_keepalive option, but I don't know if this option is valid for all platforms.
3. Why cannot I use two handshakes for connection?
We know that three handshakes are required to complete two important functions: Both parties must prepare for data sending (both parties know that each other is ready), and both parties must allow negotiation on the initial serial number, the serial number is sent and confirmed during the handshake.
Now, only two handshakes are needed to change the three-way handshake. A deadlock may occur. For example, considering the communication between computer S and C, assuming C sends a connection request group to S, s receives the group and sends a confirmation Response Group. According to the two handshakes, s considers that the connection has been successfully established and can start sending data groups. However, if C's Response Group in S is lost during transmission, it will not know if S is ready or what serial number S has created, c even doubts whether s has received its own connection request group. In this case, C considers that the connection has not been established successfully, and ignores any data groups sent by S, only waiting for the connection to confirm the response group. When the Group sent by S times out, the same group is repeatedly sent. In this way, a deadlock occurs.
4. Why is ISN random?
DoS Attacks
I believe you have heard of DoS attacks, DDoS attacks, and drdos attacks! DOS is short for denial of service and DDoS is short for Distributed Denial of Service and Distributed Denial of Service. drdos is short for Distributed reflection Denial of Service, this is the meaning of Distributed Denial-of-Service.
However, the most severe attack method in these three cases is DDoS. Although the drdos attack is a new attack method, it is only a deformation of DDoS attacks, the only difference is that there is no need to occupy a large number of "bots ". All these three methods use the TCP three-way handshake vulnerability for attacks, so their defense methods are similar.
DoS attacks were the first to appear. In other words, their attack methods are simply one-on-one. They provide better performance and faster speed than their machines. However, today's technology is developing rapidly. Generally, website hosts have more than a dozen hosts, and the processing capability, memory size, and network speed of each host are all developing rapidly, some network bandwidth even exceeds 1 Gigabit. In this way, our one-to-one, one-on-one, one-on-one attack will have no effect, and our machines will die if they do not work well. For example, if your machine can send 10 attack packets per second, and the machine you attack (the performance and network bandwidth are top-notch) it can accept and process 100 attack packets per second. In this case, your attack will be useless and very likely to crash. You know, if you send such an 1vs1 attack, your machine's CPU usage is more than 90%. If your machine's configuration is not high enough, you will die.
However, technology is developing and hacking technology is also developing. The so-called high level, high magic battle. After countless attacks, hackers finally found a new DoS attack method, which is a DDoS attack. The principle is to put it bluntly. Many machines are used to launch DoS attacks against the target machine, but not many hackers are involved. This attack is only operated by one hacker. The hacker does not own many machines. He uses his machines to occupy many "bots" on the network and controls these "bots" to launch DDoS attacks. How else is distributed. In the example above, your machine can send 10 attack packets per second, and the attacked machine can accept 100 packets per second, so that your attack will certainly not work, if you use 10 or more machines to attack the target machine, hey! I won't talk about the results.
Drdos distributed denial of service (DoS) attacks are a form of DDoS attacks. The difference between drdos and DDoS is that drdos does not need to occupy a large number of "bots" before the attack ". Its attack principles are similar to those of Smurf attacks, but drdos can be carried out on the wide area network, while Smurf attacks are carried out on the LAN. Its function is based on the broadcast address and Response Request. When a computer sends some special packets to another computer, such as ping requests, it will receive a response. If a request packet is sent to the broadcast address of the network, in fact, it will reach all the computers on the network, and then it will get a response from all the computers. These responses are processed by the computer to be received. Each Processing Task occupies one system resource. If the system receives a response from all the computers on the network at the same time, the recipient's system may not be enough, just as it was under DDoS attacks. However, no one is stupid enough to attack themselves, but the improvement of this method by hackers is very powerful. A hacker sends a request packet to a broadcast address. After receiving the request, all computers do not send the response to the hacker, but to the attacked host. This is because the hacker impersonates the host to be attacked. The software used by hackers to send request packets can forge the source address. The host receiving the forged data packet will send a response based on the source address, which is of course the address of the attacked host. At the same time, hackers will reduce the time interval between sending request packets, so that a large number of request packets can be sent in a short time, so that the attacked host can receive a flood response from the spoofed computer, it is like a system crash caused by a DDoS attack. Hackers use all computers in the network to attack victims, instead of occupying these spoofed hosts in advance. This is a Smurf attack. Drdos attacks are based on this principle. Hackers also use a special packet sending tool to first send SYN connection request packets that have forged the source address to spoofed computers. According to the three-way handshake rule of TCP, these computers send SYN + ACK or RST packets to the source IP address to respond to this request. Like Smurf attacks, the source IP address of the Request Packet sent by the hacker is the address of the attacked host, so that the spoofed host will send the response to the attacked host, as a result, the attacked host is busy processing these responses.
Explanation:
SYN :( synchronize sequence numbers) is used to establish a connection. In a connection request, SYN = 1, ACK = 0, and SYN = 1, ACK = 1 when the connection is responding. That is, SYN and ACK are used to differentiate connection request and connection accepted.
RST :( reset the connection) is used to reset the wrong connection caused by some reason, and to reject illegal data and requests. If an rst bit is received, some errors usually occur.
Ack :( acknowledgment field significant) indicates that the acknowledgment number is valid when it is set to 1. If it is set to 0, the data segment does not contain the confirmation information, and the confirmation number is ignored.
Let's prepare to establish a connection, and the server is in the normal answer status.
Step 1: the client sends a request with SYN bit, indicating that the connection is required to the server. If the request packet serial number is 10, ACK = 0, and then wait for the response from the server.
Step 2: After the server receives such a request packet, check whether the specified port is being received. If not, the server sends the RST = 1 response and rejects the connection. If a request packet is received, the server sends a confirmation response. SYN is an internal code of the server. For example, if it is 100, the ACK bit is the request serial number of the client plus 1, in this example, the sent data is SYN = 100, ACK = 11, and the data is returned to us. It indicates that the server connection is ready and we are waiting for confirmation. After receiving the response, we will analyze the information and prepare to send a confirmation connection signal to the server.
Step 3: Send the confirmation message to the server. The SYN bit of the confirmation message is the ACK bit sent by the server, and the ACK bit is the SYN bit sent by the server plus 1. That is, SYN = 11, ACK = 101.
In this way, our connection is established.
How exactly does DDoS attack? Currently, the most popular and best attack method is syn-flood attack, which is also called SYN Flood attack. Syn-flood does not complete the third step of TCP three-way handshake, that is, it does not send the Connection Confirmation information to the server. In this way, the server cannot complete the third handshake, but the server will not give up immediately. The server will keep retrying and wait for a certain amount of time before giving up the Unfinished Connection. This time is called syn timeout, this time is about 30 seconds-2 minutes. If a user encounters a connection problem and a thread on the server waits for one minute, it is not a big deal. However, if someone uses special software to simulate this situation, the consequences can be imagined. If a server processes a large amount of semi-connection information and consumes a lot of system resources and network bandwidth, in this way, the server will not be free to process normal requests of common users (because the normal Request Rate of the customer is very small ). In this way, the server cannot work. This attack is called syn-flood attack.
So far, it is still difficult to defend against DDoS attacks. First, this attack is characterized by the exploitation of TCP/IP protocol vulnerabilities. Unless you do not need TCP/IP, you can fully defend against DDoS attacks. However, this does not mean we have no way to block DDoS attacks. We can try our best to reduce DDoS attacks. The following are some defense methods:
1. Ensure that the system file of the server is the latest version, and update the system patch in time.
2. disable unnecessary services.
3. Limit the number of SYN semi-connections opened at the same time.
4. shorten the time out time of SYN semi-join.
5. Set the firewall correctly
6. Prohibit Access to non-open services on the host
7. Restrict access from specific IP addresses
8. Enable the anti-DDoS attribute of the firewall
9. strictly restrict external access to open servers
10. Run the port ing program to scan ports. Check the privileged port and non-privileged port carefully.
11. Check the logs of network devices and host/server systems carefully. As long as a vulnerability or time change occurs in the log, the machine may be attacked.
12. Restrict sharing of network files outside the firewall. This will give hackers the opportunity to intercept system files. The host information is exposed to hackers, which undoubtedly gives the other party the opportunity to intrude.
Three-way handshake of TCP/IP and four-way handshake DoS Attacks
