The TCP creation process and the link dismantling process are created automatically by the TCP/IP protocol stack relative to the socket developer. Therefore, the developer does not need to control this process. But it is quite helpful to understand the underlying operating mechanism of TCP. And for the network protocol engineers, such as written tests, is almost necessary to test the content. So here is a detailed explanation of the two processes.
TCP Packet Format
Sequence Number (32-bit): Used to identify the data stream sent from the TCP source to the TCP destination, which represents the ordinal number of the first data byte in the packet segment . If you consider a stream of bytes as a one-way flow between two applications, TCP counts each byte with a sequential number. The sequence number is an unsigned 32bit, and the sequence number reaches 2^32-1 and starts at 0. When a new connection is established, the SYN flag becomes 1, and the Sequence number field contains the initial order number of the connection selected by this host (Initial Sequence numbers).
Confirmation Number (32-bit): Contains the next sequence number expected to be received at the end of the send acknowledgement. Therefore, the confirmation sequence number should be the last time the data byte order was successfully received plus 1. Only the ACK flag is 1 o'clock to confirm that the ordinal field is valid. TCP provides full duplex service to the application layer, which means data can be transferred independently in two directions. Therefore, each end of the connection must maintain the transmit data sequence number in each direction.
TCP Header Length (4 bit): gives the number of 32bit words in the header, which actually indicates where the data starts. This value is required because the length of the optional field is variable. This field accounts for 4bit, so TCP has a maximum of 60 bytes of headers. However, there is no optional field, and the normal length is 20 bytes.
Reserved bit (6 bit): Reserved for future use, currently must be set to 0.
Control flags, 6 bits: There are 6 flag bits in the TCP header, and multiple of them can be set to 1 at the same time. In turn:
- ACK: 1 indicates that the confirmation number is valid, and 0 indicates that the message does not contain a confirmation message, ignoring the confirmation number field.
- PSH: 1 indicates that the data with the PUSH flag indicates that the receiver should hand over the segment to the application layer without waiting for the buffer to fill.
- RST: Used to reset a connection that was faulty due to a host crash or other cause. It can also be used to reject illegal message segments and deny connection requests. In general, if you receive a message with a RST of 1, some problems must have occurred.
- SYN: The synchronization sequence number, which represents a connection request for 1, is used to establish the connection and synchronize the sequence number.
- FIN: Used to release the connection, 1 means that the sender has no data to send, that is, to turn off this party traffic.
Window size (16 bits): The number of bytes of data, representing the number of bytes that the source can receive from the confirmation number, that is, the Source Party receive window size. The window size is a 16bit field, so the maximum window size is 65535 bytes.
Checksum (16-bit): This checksum is for the entire TCP message segment, including TCP headers and TCP data, calculated in 16-bit words. This is a mandatory field that must be computed and stored by the sending side and validated by the receiving side.
Emergency pointer (16-bit): The emergency hand is only valid if the URG flag is placed 1 o'clock. The emergency pointer is a positive offset, and the sum of the values in the Sequence Number field represents the ordinal of the last byte of the emergency data. The emergency mode of TCP is a way of sending an emergency data to the other end.
Option: The most common optional field is the longest message size, also known as MSS (Maximum Segment size). Each connector typically indicates this option in the first message segment of the communication (the segment that sets the SYN flag for establishing the connection), which indicates the maximum length of the message segment that can be received at the local end. The option length is not necessarily an integer multiple of 32-bit characters, so fill the bit so that the header length becomes the whole word count.
Data: The data portion of the TCP message segment is optional. When a connection is established and a connection is terminated, the message segments exchanged by both parties are only TCP headers. If a party has no data to send, it also uses the header without any data to confirm the received data. In many cases where the timeout is processed, a segment of the message without any data is also sent.
TCP Three-time handshakeThe so-called three-time handshake (three-way handshake) means that when a TCP connection is established, the client and server are required to send a total of 3 packets
. The purpose of the three-time handshake is to connect the server to the specified port, establish a TCP connection, and synchronize the serial number and confirmation number of both parties and Exchange TCP window size information . In socket programming, the client executes connect (). Will trigger a three-time handshake.
handshake for the first time: The client sends a TCP SYN flag where 1 of the packet indicates the port of the server to which the client intends to connect, as well as the initial sequence number x, which is saved in the header Number field of the Sequence.
Second handshake: The server sends back a confirmation packet (ACK) reply. That is, the SYN flag bit and the ACK flag bit are both 1, and the confirmation ordinal (acknowledgement number) is set to the customer's I S n plus 1 to. that is x+1.
handshake for the third time. The client sends a confirmation packet (ACK) again to the 0,ACK flag bit of 1. and sends the server an ACK to the ordinal field +1, which is sent to the other party in the OK field. and write +1 of the isn in the data segment.
SYN attack During a
three-time handshake, the TCP connection before the server sends Syn-ack is called a half-connection (Half-open Connect) before the ACK is received by the client . The server is now in Syn_ recv status. When an ACK is received, the server goes into the established state. SYN attack is to attack the client in a short period of time to forge a large number of non-existent IP address, to the server continuously send SYN packets, the server reply to confirm the package, and wait for the customer's confirmation, because the source address is not present, the server needs to be constantly , these bogus SYN packets will occupy the disconnected queue for a long time, the normal SYN request is discarded, the target system is running slowly, the serious person causes the network jam and even the system is paralyzed. A SYN attack is a typical DDoS attack. The detection of SYN attacks is very convenient, when you see a large number of semi-connected state on the server, especially the source IP address is random, basically can be concluded that this is a SYN attack. Under Linux, you can detect if SYN attacks are netstat-n-P TCP | grep syn_recv
In general, the newer TCP/IP protocol stack modifies this process to prevent SYN attacks and modify TCP protocol implementations. The main methods are SynAttackProtect protection mechanism, SYN-cookie technology, increasing the maximum half-connection and shortening the time-out. However, the SYN attack is not completely protected.
TCP four times Wave The removal of TCP connections requires sending four packets, so called four waves (Four-way handshake). Either the client or the server can initiate a wave gesture, and in socket programming, any party performs a close () operation to generate a wave. See Wireshark Grab bag, the measured capture results are not strictly according to the wave timing. I reckon the time interval is too short to cause.
1. Establish Connection Agreement (three handshake)(1) The client sends a TCP message with a SYN flag to the server. This is the message 1 in the three-time handshake process. (2) server-side response to the client, this is the 2nd message in the three handshake, the message with both an ACK flag and a SYN flag. So it represents the response to the client's SYN message, and it also flags the SYN to the client and asks the client if it is ready for data communication. (3) the customer must again respond to the service segment an ACK message, which is the message segment 3.
2. Connection termination protocol (four waves)because TCP connections are full-duplex, each direction must be closed separately. The principle is that when a party completes its data sending task, it can send a fin to terminate the connection in this direction. Receiving a fin only means there is no data flow in this direction, and a TCP connection can still send data after receiving a fin. The first party to close will perform an active shutdown, while the other side performs a passive shutdown. (1) The TCP client sends a fin to shut down the client-to-server data transfer (message segment 4). (2) The server receives this fin, it sends back an ACK, confirms that the serial number is the received sequence number plus 1 (message Segment 5). As with Syn, a fin will occupy a sequence number. (3) The server shuts down the client connection and sends a FIN to the client (message segment 6). (4) The customer segment sends back ACK message confirmation, and the confirmation serial number is set to receive the serial number plus 1 (message segment 7). CLOSED: This is nothing to say, it means the initial state.
LISTEN: This is also very easy to understand a state, that the server side of a socket is listening state, can accept the connection. SYN_RCVD: This status means that the SYN message is received, under normal circumstances, this state is the server side of the socket in the establishment of a TCP connection during the three handshake session process of an intermediate state, very short, basically with netstat you are very difficult to see this state, Unless you specifically write a client-side test program, deliberately not send the last ACK message during the three TCP handshake. Therefore, when the ACK message is received from the client, it goes into the established state. Syn_sent: This state is echoed with the syn_rcvd thinking back, when the client socket performs a connect connection, it sends the SYN message first, so it then enters the syn_sent state and waits for the server to send the 2nd message in the three-time handshake. The Syn_sent status indicates that the client has sent a SYN message. established: This is easy to understand, indicating that the connection has been established. fin_wait_1: This state should be well explained, in fact, the real meaning of fin_wait_1 and fin_wait_2 state is to wait for each other's FIN message. The difference between the two states is: The fin_wait_1 state is actually when the socket in the established state, it would like to actively close the connection, send a FIN message to the other side, when the socket is entered into the fin_wait_1 state. And when the other party responds to the ACK message, then into the fin_wait_2 state, of course, under the actual normal circumstances, regardless of the circumstances of each other, should immediately respond to the ACK message, so fin_wait_1 state is generally more difficult to see, and Fin_wait_ 2 states can also sometimes be seen with netstat. fin_wait_2: Above has explained in detail this state, actually fin_wait_2 the socket in the state, indicates the half connection, also namely has the party request close connection, but also tells the other side, I temporarily also some data need to transmit to you, later closes the connection again. Time_wait: Said to receive the other side of the fin message, and sent out an ACK message, just wait for 2MSL to return to the closed usable state. If the fin_wait_1 state, received the other side with the FIN flag and the ACK flag message, you can directly into the time_wait state, without having to go through the fin_wait_2 state. CLOSING: This kind of state is special, the actual situation should be very rare, belong to a relatively rare exception state. Normally, when you send a fin message, it is supposed to receive (or receive) the other's ACK message before receiving the other's fin message. But closing status indicates that you send fin message, and did not receive the other's ACK message, but also received the other side of the fin message. Under what circumstances will this happen? In fact, it is not difficult to come to a conclusion: that is, if the two sides close a socket at the same time, then there is a situation where both sides send the fin message, there will be a closing state, indicating that both sides are shutting down the socket connection. close_wait: The meaning of this state is actually expressed in waiting to be closed. How do you understand it? When the other side close a socket to send fin message to yourself, you will undoubtedly respond to an ACK message to each other, then enter into the close_wait state. Next, the real thing you really need to consider is whether you still have the data sent to the other person, if not, then you can close the socket, send fin messages to each other, that is, close the connection. So what you need to accomplish in the close_wait state is waiting for you to close the connection. Last_ack: This state is still relatively easy to understand, it is the passive close side after sending fin messages, and finally wait for each other's ACK message. When an ACK message is received, it is also possible to enter the closed available state.
1, why to establish a connection agreement is three handshake, and close the connection is four handshake it? this is because the socket in the listen state of the server is sent in a message after it receives a request for the connection of the SYN message, and it can put the ACK and SYN (ACK response, and SYN synchronous). However, when the connection is closed, when receiving the other's fin message notification, it simply means that no data is sent to you, but not all of your data are sent to the other side, so you may not immediately close the socket, that is, you may also need to send some data to the other side, Send the FIN message to the other side to show that you agree that you can now close the connection, so it is here that the ACK message and fin messages are sent separately in most cases.
2, why time_wait state also need to wait 2MSL to return to closed status? this is because: although both sides agree to close the connection, and the handshake of the 4 messages are also coordinated and sent, can be directly back to the closed state (like from the Syn_send state to establish state); but because we have to assume that the network is unreliable, You cannot guarantee that the last ACK message you send will be received by the other party, so the socket in the Last_ack state may be re-sending the fin message because the timeout does not receive an ACK message, so this time_wait state is used to resend the possible missing ACK message.
TCP Three-time handshake (connection established)/four waves (close connection)
