TCP three-way handshake fourth wave understand and face questions

A, TCP Overview

Each TCP connection has two endpoints, the endpoints of this we call socket (socket), which is defined as the port number of the IP address that is spliced to form the socket,

For example, if the IP address is 192.0.0.1 and port number 8000, then you will get a socket for the 192.0.0.1:8000

Two, TCP packet format

ACK, SYN and FIN flags of these capitalized words represent bits whose value is either 1 or a 0; ACK, SEQ number word representation lowercase

Synchronizing the SYN : (the Synchronize), the SYN =. 1 indicates that this is a connection request packet, or the connection acceptance message. The SYN flag only if the TCP connection construction production will be set after the completion of the handshake SYN flag is set to 0

Confirmed the ACK : ACK = 1 only when the acknowledgment number field is valid. When ACK = 0, the acknowledgment number is invalid. Such as: When the SYN = 1, ACK = 0 indicates that this is when a connection request packet segments, if agreed connection, in the response message segments that SYN = 1, ACK = 1

Terminating the FIN : for releasing a connection. FIN = 1 represents: a data sender of this segment has been transmitted, and for the release of

SEQ ID SEQ : (Sequence Number The), 4 bytes representing segment carrying the first byte of data the number of bytes transmitted in TCP stream connection in each byte are numbered sequentially. For example, a section of the packet sequence number value is 301, and the data carried by the total of 100 fields, is clearly the next segment (if there is any) should start from the data number 401; FIG x and y,

No acknowledgment ACK : 4 bytes, the next expects to receive the other of the first data byte sequence number of a segment, for example, B receives the packet sent from the segment A, which is a sequence number seq, and the data length is 100 bytes, B which indicates the correct receipt of data transmitted to the a number from 1 up to 100. Thus, B expects to receive next data number A + 1 is 100, then B in acknowledgment sent to the A segment of the acknowledgment number is set to 101

Third, the three-way handshake, waving four

3.1 TCP connection establishment process - three-way handshake

The process of establishing a two-way channel called three-way handshake to establish channels of the initiator may be a client may also be a server, here we are with a client to initiate an Example

The client sends a request to the server towards the service side asked: "I can not dig a tunnel leading to your home."
The server receives the request, replied: "Well you dig it", because TCP is a two-way channel, client service side of the channel to dig only to the client toward the server using a message, the server would like to send to the client this news is no way to take a channel, you need to dig a channel leading to the client

So in reply to the server and the client agreed to dig the channel will ask: "So, can I also dig a channel leading to your home."
After the client receives the server requests the client to the service end of the tunnel dug successful, then the request will agree to the server, the server to the client to dig a channel will be successful

1. Server ready: TCP server process to create a Transmission Control Block TCB, always ready to accept connection requests from the client process, the server at this time to enter the LISTEN (monitor) state
2. The client is ready: TCP client process is to create a Transmission Control Block TCB
3. The first handshake : the client sends a connection request packet to the server, the message header of the synchronization flags SYN = 1, while generating an initial sequence number seq = x, In this case, TCP client process passes the SYN-SENT (sent state synchronization) state. TCP predetermined, the SYN segment (SYN = 1 segment) can not carry data, but requires a number consumed
4. The second handshake : TCP server receives a request message, if you agree connections, is a confirmation message. Acknowledgment packet acknowledgment flag ACK = 1, SYN = 1, the acknowledgment number is ack = x + 1, but also initializes a sequence number seq = y for itself, at this time, TCP server process passes to the SYN-RCVD (received synchronization to) state. This message can not carry data, but also have to consume a number
The third handshake : TCP client after receiving confirmation, but also gives confirmation to the server again. Confirmation flag acknowledgment packets ACK = 1, an acknowledgment number ack = y + 1, their sequence number seq = x + 1, In this case, TCP connection is established, the client enters the ESTABLISHED (connection established) state. TCP predetermined, the ACK segment may carry data, but if the number does not carry data is not consumed
6. successful connection: When the server receives confirmation client also enters ESTABLISHED state, then the two sides can begin to communicate the

LISTEN - listen for connection requests from the remote TCP port; 

the SYN -SENT - waiting for a connection request match after transmitting a connection request; 

the SYN -RECEIVED - waiting for an acknowledgment of a connection request after receiving a connection request and transmitting; 

the ESTABLISHED - Representative an open connection, data can be transmitted to the user; 

the FIN -WAIT- . 1 - waiting for remote TCP connection interrupt requests, or the previous connection acknowledgment of the interrupt request; 

the FIN -WAIT- 2 - waits for a connection interrupt request from the remote TCP; 

the CLOSE - wAIT - waiting to be sent to the interrupt request from the local user is connected; 

the CLOSING - request for remote TCP connection is broken; 

LAST -ACK - request originally issued the interrupt request to the connection of remote TCP; 

the tIME -WAIT - waiting for sufficient time to ensure that the remote TCP connection acknowledgment received interrupt request; 

the CLOSED - there is no connection state;

The meaning of each state

3.2 TCP link the release process - Four waving

Establish a connection requires three-way handshake, and terminate a connection to go through the four-way handshake

When the server or the client did not want to communicate with each other, either one of the two sides can initiate unlink request, we initiate a client case study

Because the client has no need to send any messages to the service side, so disconnect the client to the server to initiate a channel request
We agreed after the server receives the request to this client to the server of the individual channels off
This time server is not immediately towards the client send requests to say that I have to disconnect your home right channel, the server needs to think about my hand there is no need to send a message to the client, if there is, then, I can not immediately disconnect, finished first data to off

After the inspection is completed and other server sent no data to give the client, and this time it will initiate a disconnect service towards the client-to-client channel request
The client agreed to the request, so far completed four wave

After sending end sends user data break request, the server will immediately agree, but the server does not issue its own request to immediately break up, because there may be no data transfer is completed, will break off after detecting whether data is sent, once among the two can not merge

Client process data transmission is completed, stop sending data , send a connection release message, the release flag FIN = 1, the sequence number seq = u (equal to the sequence number of the last byte previously transmitted from the data plus 1), then The client enters the FIN-wAIT-1 (1 terminating wait) state. TCP provisions, FIN segment, if not carrying data , but also consume a serial number.
Server receives a connection release message, after they have been confirmed that all the data, send a confirmation packet agrees off acknowledge flag ACK = 1, an acknowledgment number ack = u + 1, and bring its own sequence number seq = v, In this case, the server entered (closed waiting) CLOSE-wAIT. TCP server to inform high-level application process, the client-server direction of a channel to immediately shut down . This time in a TCP semi-connected state , that is, the client has no data to send, but if the server sending data, the client still has to be accepted. This state will continue for some time, that is, the entire CLOSE-WAIT state duration.
The client receives confirmation request to the server, disconnect own a channel. In this case, the client enters the FIN-WAIT-2 (2 termination waiting) state, during which the need to pass over the server receives data, wait for the server transmits a connection release message
After the data has been sent the server, the client sends a connection release message, FIN = 1, ack = u + 1, since the half-closed state, and the server is likely to transmit some data, the sequence number is assumed at this time seq = w, at this time, the server into the lAST-ACK (acknowledgment last) state, waiting for an acknowledgment of the client.
The client receives a connection release message server, after receiving confirmation all their data to be sent acknowledgment, ACK = 1, ack = w + 1, and their serial number seq = u + 1, at this time, the client end entered the tIME-wAIT (wait) state. Note that the TCP connection has not been released at this time, after the MSL be 2 * (maximum segment lifetime) of time elapses after the revocation of the client corresponding to the TCB, before entering the CLOSED state.
As long as the server received confirmation sent by the client, immediately enter CLOSED state. You can see, the server TCP connection time earlier than the client

Fourth, the common interview questions

[Question 1] TCP Why a three-way handshake, the use of secondary handshake can do?

Certainly not, three-way handshake has failed can effectively avoid the connection request packet sent to the server suddenly, resulting in errors and waste of resources.

If a two-way handshake to establish a connection, assuming such a scenario, the client sends a request to the first connection is lost and is not, simply because the network nodes retention time is too long, because the client has yet to TCP receive a confirmation message that the server has not received, then re-send this packet to the server, then the client and server are connected via two-way handshake is completed, data transmission, and then close the connection. At this point the error that had stranded a connection request, the network open to reach the server, the text of the report is invalid, however, two-way handshake mechanism will allow the client and server to establish a connection again, which will lead to unnecessary and waste of resources.

If a three-way handshake, even if it is a failure of the transmission packet to the server, service termination by the failure of a piece of the message and reply confirmation message, but the client is clear that he did not send additional requests, knowing it the request is invalid, it will not send a confirmation again. Since the server does not receive confirmation, we know that the client did not request a connection,

From another perspective, the only three-way handshake to confirm each other's ability to accept and transmit is normal, but the two can not

First: The client sends a request to the server, the server knows that the client sends, receives its own normal
Second: the server to the client, the client know that they send, receive, the server receives, sends a normal
Third: the client to the server: the server knows the client to send, receive normal that he received, sent also normal

[Question 2] three-way handshake may carry data?

The first, second handshake can not carry data, while the third handshake can carry data.

The first can not carry data, nor can first cached data, such as a handshake successful submission to the application, it will enlarge SYN FLOOD attack. If someone were to malicious server, that he always put a lot of data in the first handshake SYN packet, because the attacker simply ignore receive, transmit power of the server is normal, then frantically focus on relapse SYN message, then makes the server takes a lot of time and memory space to receive these messages. In other words, the first handshake can put the data, in which a simple reason for this is to make the server more vulnerable to attack.

Third, it can send handshake packets of the third host, certainly received second handshake packets, fake IP because the host is not receiving the second message. Therefore, the third handshake can send messages, users should be legal. Although the state of the server side has not "established", the moment received third handshake, the state switches to the "established", which carry the data down accordance with normal procedures like

[Question 3] how to do if you have established a connection, but the client suddenly broke down?

TCP is also a keep-alive timer SYN Timeout, apparently, a client if a failure occurs, the server can not keep on waiting, wasted resources. Each time the server receives the client's request will reset the timer set time is usually 2 hours, if two hours has not received any data from the client, the server sends a detection message segment, then every 75 seconds to send one. If sending 10 consecutive probe packets still did not respond, the server brought out customers considered a failure, and then they close the connection.

[4] problem SYN flood attack Principle

Defect using TCP protocol, sending a large number of bogus TCP connection request, so the attacker attacks the depletion of resources (CPU full load or insufficient memory) of

Specific principle is: the three-way handshake TCP connection, suppose a user sends a SYN packet after a sudden crash or dropped to the server, the server SYN + ACK is issued after the response message is not received client's ACK packet ( third handshake can not be completed), the server in this case typically retries (SYN + ACK transmission to the client), and again after a period of time to wait for outstanding connections discarded. This length of time we called SYN Timeout, in general this time is the order of minutes (approximately 30 seconds to 2 minutes); abnormal causes the server to a user of a thread wait 1 minute is not a big problem, but if a malicious attacker to simulate a large number of such cases (fake IP address), the server will be very large in order to maintain a list of connections half consumed a lot of resources. Even a simple save and traverse will consume a lot of CPU time and memory, not to mention also continue to carry out this list of IP SYN + ACK retry. In fact, if the server's TCP / IP stack is not strong enough, the final result is often a stack overflow crashes - even if the server system is strong enough, the server will also be busy with the attacker forged TCP connection requests and no time to ignore the normal request of customers ( after normal request client ratio is very small), then the normal client's point of view, the server freezes

[5] Why the issue TIME_WAIT state need to go through 2MSL (Maximum Segment Lifetime) (maximum segment lifetime) CLOSE to return to the state?

Although Logically, the four packets have been sent, we can go directly to the CLOSE state, but the network is unreliable, it is possible to lose the last ACK.

After sending the final ACK reply Client, the ACK may be lost. Therefore TIME_WAIT state is used to check that they have received the ACK, if the server does not receive the ACK, the client does not know whether the received data is not completely closed portion of their passage, the third wave will repeat FIN segment sent. So the client can not be closed immediately, it must be confirmed Server receives the ACK.

Client enters the TIME_WAIT state after sending the ACK. Client will set a timer, waiting 2MSL time. If you receive FIN again within that time, then the Client will resend ACK 2MSL and wait again. The so-called 2MSL is twice the MSL. MSL refers to a segment of the network the maximum survival time, 2MSL is transmitted and a maximum time required for a response. If until 2MSL, Client have not received FIN again, then the Client concluded that ACK has been successfully received, the TCP connection

[6] RFC793 clearly defined problem, in addition to the first except for a handshake packets SYN, all other packets must be ACK = 1, behind the provisions of RFC certainly rational side, can go into the reasons?

TCP as a reliable transport protocol, its reliability is dependent on the feedback mechanism after receiving each other's data, only with acknowledgment ACK flag to each other, so the other side can be sure the data has been received, in order to close the channel release boldly assured cache data

TCP packets are transmitted over the IP network, packet loss is a common practice, the receiver should seize every opportunity to tell the sender of the message . The most convenient way is, TCP packets to send us any, should incidentally ACK status bits.

ACK status bits alone can bear the messaging task?

Can not! Ack need confirmation number with the job.

The client after the sequence number seq = x, then the terminal receives the service data unit should tell exactly opposite ack = x + 1, the client knows the server has received all the

If it issued ack = 10001, before 10000 bytes and that means that the serial number has been successfully received

[7] problem (ISN) seq fixed it

An important function of the three-way handshake is the client and server exchange ISN (Initial Sequence Number), in order to let each other know when the next receive data on how the data assembled by serial number.

If the ISN is fixed, it is easy for an attacker to guess the subsequent acknowledgment number, so ISN is dynamically generated.

[8] question about the SYN-ACK retransmission times the problem

The server has finished sending SYN-ACK packet, if the client has not received confirmation packet, the server first retransmission, wait some time yet to receive customer confirmation pack, a second retransmission, if the retransmission count exceeds the specified maximum weight system transfer number, the connection information deleted from the system half-connection queue. Note that each retransmission waiting time is not necessarily the same, the general will be exponential growth, such as interval is 1s, 2s, 4s, 8s, ....