Three-time handshake: establishing a TCP connection
Connection Establishment Process:
The TCP server process of B first creates the Transport control block TCB (which stores some important information in each connection, such as the TCP connection table, the pointer to the sending and receiving caches, the pointer to the retransmission queue, the current send and receive sequence numbers, and so on), 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 to be made accordingly.
The TCP client process for a is also the first to create the Transport control module TCB, and then sends a connection request segment to B, when synchronization in the header is Syn=1, and an initial sequence number seq=x is selected. TCP Specifies that the SYN message segment (that is, the syn=1 segment) cannot carry data, but consumes a sequence number. At this point, the TCP client process enters the syn-sent (synchronous sent) state.
b After receiving the connection request message segment, if you agree to establish a connection, send a confirmation to a. In the confirmation message section should be the SYN bit and the ACK bit 1, the confirmation number is ack=x+1, but also for their own selection of an initial sequence number seq=y. Attention. 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 1, the confirmation number ack=y+1, and its own serial number seq=x+1. At this point, the TCP connection is established and a enters established (connected state).
When B receives the confirmation of a, it also enters the established state.
This is the three-time handshake process.
Questions:
1. Why can't it be a two-time handshake? Why does a also need to send a confirmation?
A: The main purpose is to prevent the failed connection request packet suddenly transmitted to B, resulting in an error.
For example, this anomaly: A sends the first connection request message segment is not lost, but in some network nodes for a long time, so that delay to the connection after the release of a certain time before reaching B. Originally this is a message segment that has already expired. However, after receiving this failed connection request packet, B mistakenly assumed that a new connection request was made. A confirmation message section is sent to a, agreeing to establish a connection. Assuming a three-time handshake is not used, the new connection is established as soon as B confirms.
Because a does not make a connection request now, it does not acknowledge the bank B and does not send data to B. But b thought the new connection had been established and waited for a to send the data. Many of the resources of B are wasted.
Four-time handshake: TCP connection Release Connection release Process:
The process is high-end, complex, replicating others ' (=. =):
The interrupt connection can be either the client side or the server side.
Suppose the client side initiates an interrupt connection request, which is to send a fin message. After the server receives the fin message, it means " my client has no data to send to you ", but if you have data that is not sent, you do not need to close the socket, you can continue to send data. So you first send an ACK, " tell the client that your request I received, but I am not ready, please continue to wait for my message ." At this point the client enters the fin_wait state and continues to wait for Fin messages on the server side. When the server side determines that the data has been sent, the fin message is sent to the client side, " tell the client side, OK, my side of the data is finished, ready to close the connection ." Client side received fin message, " I know can shut down the connection, but he still do not believe the network, afraid the server side do not know to shut down, so send an ACK into the time_wait state, if the server does not receive an ACK can be re-transmitted . "When the server side receives an ACK," You know you can disconnect . " Client side waiting for 2MSL still not received a reply, the server side has been properly shut down, well, I can also close the client terminal connection .
Problem:
1. Why is a three-time handshake when establishing a connection and four handshake when disconnecting?
A: The syn+ack message can be sent directly after the server receives the SYN connection request message from the client side. Where the ACK message is used to answer, the SYN message is used for synchronization. However, when the connection is closed, when the server side receives the fin message, it is likely that the socket will not be closed immediately, so you can only reply to an ACK message, tell the client side, "You send fin message I received." I can't send fin messages until all the messages on my server end are sent, so I can't send them together. Therefore, four-step handshake is required.
Computer network--tcp three times, four times handshake explanation