TCP/IP three-time handshake explanation

Original: http://www.cnblogs.com/CBDoctor/archive/2012/10/17/2727073.html

In the TCP/IP protocol, the TCP protocol provides a reliable connection service with a three-time handshake to establish a connection.

First handshake: When a connection is established, the client sends a SYN packet (SYN=J) to the server and enters the Syn_send state, waiting for the server to confirm;

Second handshake: The server receives the SYN packet, it must confirm the customer's SYN (ACK=J+1), and also send itself a SYN packet (syn=k), that is, the Syn+ack packet, when the server enters the SYN_RECV state;

Third handshake: The client receives the server's Syn+ack packet, sends the acknowledgment packet ack (ACK=K+1) to the server, the packet is sent, the client and the server enter the established state, and the handshake is completed three times.

After three handshakes, the client and server begin transmitting data, and in the above process there are some important concepts:

Not connected queue: In the three-time handshake protocol, the server maintains an disconnected queue, which is listed as a SYN package (SYN=J) for each client, which indicates that the server has received a SYN packet and has issued a confirmation to the customer that it is waiting for the customer's confirmation package. The connections identified by these entries are in the SYN_RECV state of the server, and when the server receives the customer's confirmation package, the entry is deleted and the server enters the established state.
Backlog parameter: Represents the maximum number of seats that are not connected to a queue.

Syn-ack the number of times the server sends the Syn-ack package, if not received the customer confirmation package, the server for the first retransmission, waiting for a period of time still not received the customer confirmation package, the second retransmission, if the retransmission times than the system specified maximum retransmission times, the system will remove the connection information from the semi-connection queue. Note that the time to wait for each retransmission is not necessarily the same.

Half-Connection survival time: Refers to the maximum time that the entry of a semi-connected queue survives, that is, the maximum time that the service receives a SYN packet to confirm that the message is invalid, which is the maximum waiting time sum of all retransmission request packets. Sometimes we also call the half-connection survival time timeout time, syn_recv survival time.
====================================================================
Now, let's look at a complete process of how the system calls connect on a TCP socket to establish a connection to the peer. We also take the experimental environment 172.16.48.2 to 172.16.48.1 Port 5002 to initiate a connection request as an example.
In the first step, 172.16.48.2 initiates a connection request to the 172.16.48.1, sends a SYN segment, indicates the destination port 5002, advertises its initial sequence number (ISN, a 32-digit number randomly generated by the protocol stack), and sets the confirmation sequence number to 0 (because no data has been received from the peer). Advertise your own sliding window size of 5840 (to the end is 5792, which seems to be problematic, to be further detailed), the window enlargement factor is 2 (in the first option), the maximum message segment length is 1460 (local area network), the following is the data content (Stripped link layer Ethernet header and IP header of the network layer) ：
Meaning of data content
Basic Header
0e Source Port (32782)
8a Destination Port (5002)
XX BC initial serial number isn
00 00 00 00 Confirm Serial Number
A header length
0 02 Flag bit, Syn=1
D0 sliding window size (5840)
9e Checksum
00 00 Emergency Hands
TCP Options
B4 maximum message segment Length (1460)
04 02 Allow Sack
0a 0a 79 14 00 00 00 00 Timestamp (0x000a7914), echo timestamp (0)
01 occupies a position.
03 03 02 Window Enlargement factor (2)
In the second step, 172.16.48.1 receives the request packet, checks the flag bit, discovers Syn=1, thinks it is a request to initialize the connection, responds to this SYN, and also sends its own SYN segment (that is, Ack,syn simultaneously). Because the SYN itself takes up a sequence number (and the sign Fin also takes a serial number). So, confirm that the ordinal is set to 172.16.48.2 's isn plus 1 (that is, 172.16.48.1 expects to receive the first ordinal of the next package from 172.16.48.2 to 0X07BD. Also notice their initial serial number, sliding window size, window enlargement factor, the maximum message segment length, etc., the following is the data content:
Meaning of data content
Basic TCP Header
8a Source Port (5002)
0e Destination Port (32782)
98 8e 40 91 initial serial number isn
BD Confirmation serial number (to end isn+1)
A header length
0 12 flag, ack=1, syn=1
a0 sliding window size
The D7 checksum
00 00 Emergency Hands
TCP Options
B4 maximum message segment Length (1460)
04 02 Allow Sack
0A 3c 8a XX 0a 79 14 timestamp (0X003C258A), echo timestamp (000a7914)
01 placeholder
03 03 02 Window Enlargement factor (2)
The third step, 172.16.48.2 to the SYN segment from 172.16.48.1 to confirm, at this point, the TCP three handshake protocol is complete, the connection is established, when the 172.16.48.2 received the SYN segment, the state of the corresponding socket is Tcp_syn_ Sent change to tcp_established, enter the connection establishment state, the following is the data content:
Meaning of data content
0e Source Port (32782)
8a Destination Port (5002)
The BD number (no longer isn)
98 8e 40 92 Confirm serial number (to end isn+1)
8 Ministerial degrees (8*4=32, with 12-byte options)
0 10 Mark, ack=1
B4 sliding window size (1460, is there a problem?) Pending confirmation)
A5 8a Checksum
00 00 Emergency Hands

        01                                     placeholder
        01                                     placeholder
         08 0a 0a, 3c 8a        time stamp (0x0a007914), echo timestamp (0x003c258a)
=====================================================================

7, briefly describe the TCP three handshake process, and explain why the handshake is 3 times
TCP Three-time handshake
A TCP connection is initialized by a three-time handshake. The purpose of the three-time handshake is to synchronize the serial number and confirmation number of both parties and Exchange TCP window size information. The following steps outline the process that a client computer typically contacts a server computer:
1. The client sends a SYN-set TCP message to the server that contains the initial sequence number x of the connection and a window size (indicating the size of the buffer on the client that is used to store incoming segments sent from the server).
2. After receiving the SYN message sent by the client, the server sends a SYN and ACK to the client TCP message, which contains the initial sequence number y selected and the confirmation of the serial number of the client x+ 1 and a window size (indicating the size of the buffer on the server that is used to store incoming segments sent from the client).
3. After the client receives the Syn+ack message returned by the server, a standard TCP connection is completed by returning an ACK message to the server that confirms the number y+1 and the sequence number x+1.
TCP uses a similar handshake process to end the connection. This ensures that two hosts are able to complete the transfer and ensure that all data is received
TCP Client Flags TCP Server
1 Send syn (seq=x)----SYN---> SYN Received
2 Syn/ack Received <---syn/ack----Send SYN (seq=y), ACK (x+1)
3 Send ack (y+1)----ACK---> ACK Received, Connection established
W:ISN (Initial Sequence number) of the Client
X:isn of the Server

==========================================================
Handshake Stage:
Ordinal direction seq Ack
1 a->b 10000 0
2 B->a 20000 10000+1=10001
3 A->b 10001 20000+1=20001
Explain:
1: A to B initiates a connection request, Initializes a SEQ with a random number, here is assumed to be 10000, at this time ack=0

2: B After receiving a connection request, also initializes a SEQ of B with a random number, this is assumed to be 20000, meaning: Your request I have received, my this side of the data flow from this number began. The Ack of B is a SEQ plus 1, which is 10000+1=10001

3: A received B's reply, its SEQ is its last request SEQ plus 1, that is, 10000+1=10001, meaning: Your reply I received, I this side of the data flow from this number began. A The ACK at this time is the seq of B plus 1, i.e. 20000+1=20001


Data transfer phase:
Ordinal direction seq ACK size
A->b 40000 70000 1514
B->a 70000 40000+1514-54=41460 54
A->b 41460 70000+54-54=70000 1514
B->a 70000 41460+1514-54=42920 54
Explain:
23:b received a seq=40000,ack=30000,size=1514 packet from a.
24: So B to a also send a packet, tell B, your last bag I received. The seq of B is populated with the ACK of the packet it receives, and the ACK is the SEQ of the packet it received plus the size of the packet (not including the Ethernet protocol header, IP header, TCP header) to verify that the data sent by B is all received.
25:a received B sent over the SEQ 41460 packet, a see 41460, just the last packet of its SEQ plus the size of the packet, it is clear that the last sent packet has arrived safely. Then it sends a packet to B. The SEQ of the packet being sent is also populated with the ACK of the packet it receives, and the ACK is populated with the packet's SEQ (70000) plus the size (54) of the package, i.e. ack=70000+54-54 (all head length, no data items).
26: the same.

What is the meaning of the TCP three-time handshake?
It's better to be detailed and considered comprehensive.
I can think of:
1. Use shorter SYN packets to detect if the destination host port and intermediate network are working
2. Initialize the serial number
Question: Why does TCP use a random initial sequence number?
I've read that the explanation is to prevent the socket from being reused after the connection fails so that the previously remaining packets are incorrectly accepted. But now the host has just released the socket is not to be used immediately?
3. Synchronizing MSS
Would you please add.

1. I think you're right. On the one hand,, and another aspect is that, let the server for the client to reserve a portion of the server resources,,,,,,,,,,,,,,,,,,, and we all know the DOS (denial of Service) as well as derived DDoS (distributed Dos),, the latter is more frightening and difficult to analyze and monitor, and its principle is,,, to send a SYN to the server, and then,,, and not to further communicate with the server,, so,,, Causes the server to allocate a lot of resources for it in vain,, we can think of is,, when this SYN reaches a certain amount,,,, the server will certainly explode,,, this kind of attack is quite horrible,, the legend accumulates has the loss of tens of billions of dollars,,, at the same time,,, This is also a hotspot in the research of network security today,
2. First of all, I think you have to think about using random serial number The problem is very serious,,,
Should be this,,, this is in the network security angle to do,, if there is no random generation of TCP serial number,,,,, Hacker can easily take some means to guess you and others to communicate the TCP serial number,, and make TCP serial number attack,,, This is already a common attack on the network today,, TCP at the time the designers did not consider these,,, even so,,, TCP serial number attack is also a way to do,, in order to prevent this attack,, has been a lot of TCP serial number generation algorithm has been proposed and improved,, You can pour the IEEE up and down,,, more,,, as far as I know, Unix is doing better than Windows

TCP/IP three-time handshake explanation