In other words, it is a complete connection establishment process [C/S, TCP three-way handshake, packet sending, closing connection]

[Scenario description]

The client is started, and the server is started.

• The client initiates a connection
• The client sends a packet containing the four bytes of "Hutu"
• Client disconnection, server disconnection

[Process diagram]No picture, no truth!

 

[Socket status change diagram]No picture, no truth!

Establish a connection protocol (three-way handshake)

(1) the client sends a TCP packet with SYN flag to the server. This is packet 1 during the three-way handshake.Client status: syn_sent
(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.Server Status: syn_recv
(3) The customer must re-respond to an ACK packet in the service segment, which is packet segment 3.Client/Server Status: Established

Important concepts:Semi-connection queue

In the three-way handshake protocol, the server maintains an unconnected queue, which opens an entry for the SYN Packet of each client. This entry indicates that the server has received the SYN Packet and sent a confirmation message to the customer, waiting for the customer's confirmation package. The connection identified by these entries is in the syn_recv state on the server. When the server receives the customer's confirmation packet, it deletes the entry and the server enters the established state.

Important concepts:Backlog Parameters

Maximum capacity of unconnected queues

Important concepts:Number of SYN-ACK retransmissions

The server sends the SYN-ACK package. If the customer's confirmation package is not received, the server re-transmits the package for the first time, if the number of retransmission times exceeds the maximum number of retransmission times specified by the system, the system deletes the connection information from the semi-connection queue. Note that the waiting time for each retransmission is not necessarily the same.

Important concepts:Semi-join survival time

It refers to the maximum time for a semi-connection queue to survive, that is, the maximum time for the service from receiving a SYN packet to confirming that the message is invalid, the maximum waiting time of all retransmission request packets. The semi-join survival time is also called timeout time and syn_recv survival time.

 Connection termination protocol (four waves)

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 client 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 ).

 Meaning of various Logos

• SYN:Synchronization flag. The synchronize sequence numbers column is valid. This flag is valid only when three handshakes are used to establish a TCP connection. It indicates the serial number of the server check sequence of the TCP connection. The serial number is the serial number of the initial client of the TCP connection. Here, we can regard the TCP sequence number as a 32-bit counter ranging from 0 to 4,294,967,295. Each byte in the data exchange over TCP connections is serial number. The serial number column in the TCP header contains the serial number of the first byte in the TCP segment.
• Ack:Validation mark. The acknowledgement number column is valid. In most cases, this flag is set. The validation number (W + 1, figure-1) contained in the validation number column in the TCP header is the next expected sequence number, prompting that the remote system has successfully received all data.
• RST:Reset flag. The reset flag is valid. Used to reset the corresponding TCP connection.
• URG:Emergency sign. The URGent pointer sign is valid. Emergency flag placement,
• Psh:Push flag. When this flag is set, the receiving end does not process the data in the queue, but forwards the data to the application as soon as possible. This flag is always set to a bit when you connect to telnet, rlogin, or other interactive modes.
• Fin:End mark. The packet with this flag is used to end a TCP session, but the corresponding port is still open, ready to receive subsequent data.

 Meaning of various statuses

• Closed:There is nothing to say, indicating the initial state.
• Listen:This is also an easy-to-understand state, indicating that a socket on the server is in the listening state 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, 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 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:In fact, the true meanings of fin_wait_1 and fin_wait_2 indicate waiting for the fin message of the other party.
• The fin_wait_1 status is actually when the socket is in the established status, it wants to take the initiative to close the connection and send the FIN packet to the other party, then the socket enters the fin_wait_1 status. 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 already 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:It indicates that the other party's FIN packet is received, and the ACK packet is sent concurrently. After 2msl is sent, it can return to the available state of closed. 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 status is special and should be rare in actual situations. It is a rare exception status. 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 that it is 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 packet. After receiving the ACK message, you can enter the closed available status.

 Q &

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?

This is because, although both parties agree to close the connection, and the four packets of the handshake 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.

A story (hacker, how to defraud trust, is it so quiet to put the password

Let us first understand the basic simple process of TCP connection establishment. To build a small imitation environment, we assume there are three machines connected to the Internet. A is an attacker. B is an intermediary springboard machine (a trusted server ). C is the machine used by the victim (mostly the server). Here, machine C is locked as the target machine. Machine A sends a SYN packet to machine B and requests to establish a connection. Then machine B that has responded to the request will respond to machine A's SYN/ack indicating that it agrees to establish a connection, when machine A receives the SYN/ack response sent by machine B, it sends the response ack to establish
The network connection between machine A and machine B. In this way, the TCP communication channel between two machines is successfully established. The trusted server of Terminal B initiates a TCP connection to machine C, and machine a initiates SYN information to the server, so that machine C cannot respond to machine B. At the same time, machine A also sends a false SYN Packet responded by machine C to machine B and receives the SYN packet from machine B (trusted by machine C) start to send the SYN/ACK packet established by the response connection. At this time, machine C is busy responding to the SYN data sent previously and has no time to respond to machine B, the attacker of machine a predicts the serial number of machine B (the current TCP serial number is more difficult to predict) and sends a response ack to machine B by impersonating machine C to gain the trust of machine B, the counterfeit machine C establishes a TCP conversation connection with machine B. At this time, machine C is still responding to SYN data sent by machine.
Weakness of the TCP protocol stack: resource consumption of TCP connections, including packet information, condition status, and serial number. By deliberately failing to complete the three handshakes required for establishing a connection, the resources of the connection party are exhausted. The entire process of three handshakes required by the attacker to establish a connection is intentionally not completed, resulting in the depletion of resources of the C machine. The predictability of the serial number. The serial number of SYN/ack returned by the target host in response to the connection request is predictable.

 

Let's just say

Netstat, you can see the client/server status change process

Client	Server
	Closed
	Listen
Syn_sent	Syn_rcvd (short term)
Established	Established
Fin_wait_1	Close_wait
Fin_wait_2	Last_ack
Time_wait	Closed
Closed

 

 

 

TCP connection from socket programming: http://blog.sina.com.cn/s/blog_4b5039210100fgo0.html

TCP three handshakes and connection close process details: http://www.91linux.com/html/article/network/20101125/21223.html

TCP connection process (three-way handshake) Termination protocol (four-way handshake) http://blog.sina.com.cn/s/blog_624ca8080100ftk1.html