Connection establishment and connection release for TCP

I. Connection establishment of TCP ( three-time handshake )

Assume that host A is running a TCP client program, and B is running a TCP server program. The TCP process at both ends is the close (off) state. a actively opens the connection, while B passively opens the connection.

The TCP server process for B first creates the transport control block TCP, ready to accept connection requests from the client process. The server process is then in listen (listening) state, waiting for the client's connection request. If so. That is made accordingly.

A TCP client process is also the first to create a transport control block TCP, then send a connection request packet to B, then the synchronization bit in the header syn=1, and select an initial sequence number seq=x. TCP Specifies that the SYN message segment cannot carry data, but consumes an ordinal number. At this point, the TCP client process enters the syn-sent (synchronous sent) state.

b When the connection request message is received, a confirmation is sent to a if the connection is also established. In the confirmation message, both the SYN and ACK bits should be set to 1, the confirmation number is ack=x+1, and an initial sequence number seq=y is selected for itself. This message segment also cannot carry data, but it also consumes a sequence number. At this point the TCP server process enters the SYN-RCVD (synchronously received) state.

After the TCP client process receives B's acknowledgement, it also needs to confirm to B. Confirm the ACK of the Message section, confirm the number ack=y+1, and your own serial number seq=x+1. The TCP standard specifies that the ACK segment can carry data. However, if you do not take the data without consuming the serial number, in this case, the sequence number of the next data segment is still seq=x+1. At this point, the TCP connection is established and a enters the established (established connection) state.

When B receives the confirmation of a, it also enters the established state.

a further acknowledgment is due to the fact that the "Failed connection request segment" was suddenly transmitted to B, resulting in an error.

(1) The normal condition of the failed connection request message segment

A connection request was made, but no acknowledgement was received due to the loss of the connection request message. The A then re-passes the connection request. Later received confirmation that the connection was established. After the data transfer is complete, the connection is released. A total of two connection request message segments were sent, the first of which was lost, and the second reached B. There is no "failed connection request message segment".

(2) The exception condition of the failed connection request message segment

The first connection request message segment sent is not lost, but is stuck in some network nodes for a long time, so that it is delayed until a certain time after the connection is released to arrive at B. Originally this is a message segment that has already expired. However, when B receives the connection request message segment at this time, it is mistaken for a and a new connection request is issued. A confirmation message section is sent to a, agreeing to establish a connection. Assuming a three-time handshake is not used, only b confirms that the new connection is established.

Because a does not make a connection request now, it does not respond to the acknowledgment of B, nor does it send data to B. But B thought the new transport connection had been established and was waiting for a to send the data. Many of the resources of B will be wasted.

The use of three-time handshake can prevent the occurrence of the above phenomenon.

two. Connection release for TCP ( Wave four times )

After the data transfer is complete, both sides of the communication can release the connection. Now both A and B are in the established state. A's application process first sends a connection release segment to its TCP and stops sending the data, actively shutting down the TCP connection.

A connect the fin=1 to release the header of the packet, its sequence number seq=u, wait for the confirmation of B.

B Issue confirmation, confirmation number ack=u+1, and this message segment own serial number SEQ=V. The TCP server process notifies the high-level application process.

The connection from A to B is released, and the TCP connection is in a semi-closed state. b If you send the data, a is still received. That is, the connection from B to a is not closed, and this state may persist for some time.

If B has no data to send to a, its application process notifies TCP to release the connection.

A confirmation must be issued after receiving the connection release message segment. In the confirmation message section ack=1, the confirmation number ack=w+1, own serial number seq=u+1. The TCP connection must go through time of 2MSL before it is really released.

where a must wait for 2MSL of time for the reason:

(1) To ensure that the last ACK segment sent by a can reach B;

(2) Prevent "Invalid connection request message segment" From appearing in this connection. A after sending the last ACK segment, then after 2MSK, you can make the connection for the duration of the time generated by all the message segments from the network disappears. This makes it possible for the next new connection not to have this old connection request message segment.

This article is from the "Zwy" blog, make sure to keep this source http://10548195.blog.51cto.com/10538195/1773660

Connection establishment and connection release for TCP