TCP Three handshake (connection established) and four waves (close connection)

Reference:

Http://course.ccniit.com/CSTD/Linux/reference/files/018.PDF

Http://hi.baidu.com/raycomer/item/944d23d9b502d13be3108f61

To establish a connection:

Understanding: Windows and sliding windows
Traffic Control for TCP

TCP uses window mechanism for flow control what is a window?

When a connection is established, each end allocates a buffer to store the received data and send the buffer's dimensions to the other end

The acknowledgement sent by the receiver contains its own remaining buffer size

The number of remaining buffer spaces is called a window

2. TCP's flow control process (sliding window)

TCP (transmission Control Protocol) transmission protocol

Three-time handshake

TCP is the host-to-host layer of the Transmission Control Protocol, providing a reliable connection service, using three-time handshake confirmation to establish a connection:

The bit code is the TCP flag bit, and there are 6 types of markings:

SYN (synchronous set up online)

ACK (Acknowledgement confirmation)

PSH (push transfer)

FIN (end of finish)

RST (Reset reset)

URG (Urgent emergency)

Sequence number (sequential numbers)

Acknowledge Number (confirmation)

Client TCP State Migration:
Closed->syn_sent->established->fin_wait_1->fin_wait_2->time_wait->closed
Server TCP State Migration:
Closed->listen->syn received->established->close_wait->last_ack->closed

the meanings of each state are as follows:
LISTEN-listens for connection requests from remote TCP ports;
Syn-sent-waits for a matching connection request after the connection request is sent;
Syn-received-Waits for confirmation of the connection request after receiving and sending a connection request;
established-represents an open connection, the data can be transmitted to the user;
Fin-wait-1-a connection interruption request waiting for a remote TCP, or confirmation of a previous connection interruption request;
Fin-wait-2-Waits for a connection interrupt request from a remote TCP;
Close-wait-waits for a connection interruption request from a local user;
CLOSING-Wait for the remote TCP acknowledgement of the connection interruption;
Last-ack-Acknowledgement of the connection interrupt request that was originally sent to the remote TCP;
Time-wait-wait enough time to ensure that the remote TCP receives the acknowledgement of the connection interrupt request;
CLOSED-no connection status;

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

(1) First handshake: When a connection is established, client A sends a SYN packet (SYN=J) to Server B and enters the syn_send state, waiting for Server B to confirm.

(2) Second handshake: Server B receives the SYN packet, must confirm the SYN (ACK=J+1) of customer A, and also sends a SYN packet (syn=k), that is, the Syn+ack package, at which point Server B enters the SYN_RECV state.

(3) Third handshake: Client A receives Server B's Syn+ack package, sends acknowledgment packet ACK (ack=k+1) to Server B, the packet is sent, client A and Server B enter the established state, complete three handshake.

Three handshake is completed and the client and server begin to transfer data.

Confirmation Number: Its value equals the sender's Send the ordinal +1(that is, the next serial number the receiver expects to receive).

Figure 1 TCP Three-time handshake establishment connection

TCP the Baotou structure:
Source Port 16-bit
Destination Port 16-bit
Serial Number 32 bits
Response Number 32 bit
TCP Header Length 4 bits
Reserved 6-bit
Control Code 6 Bits
Window size 16 bits
Offset 16 bits
Checksum 16-bit
Option 32-bit (optional)
This gives us the minimum length of the TCP header, which is 20 bytes

• 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.

Here's a concrete example:1. This figure contains two pieces of information: TCP's three handshake (the contents of the box) (SYN, (Syn+ack), ACK) 2. TCP data transfer ([TCP segment of a reassembled PUD]) can be seen that the server is the data TCP layer to the message packet is fragmented (1) the server side receives an HTTP request such as GET, constructs a response message, which carries the Web content, The HTTP layer on the server side sends messages to the TCP layer on the Ok->server side;
(2) The TCP layer on the server side transmits the message packet in a shard;
(3) The TCP layer on the client side interfaces with each message packet received by the fragment echo response;
(4) The TCP layer on the client side is confirmed with an ACK each time a part is received, and then the server continues the transfer, the client continues to confirm, until all shards of the response message are completed, the server Send Combo HTTP response PackageK, which can be displayed in message tracking on the client side at this time HTTP OKThe Message pack

To close the connection:

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.

The removal of the CP connection requires four packets to be sent, so it is called a four-time wave (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.

(1) Client A sends a fin to turn off the data transfer from client A to Server B.

(2) Server B receives this fin, which sends back an ACK, confirming that the serial number is received plus 1. As with Syn, a fin will occupy a sequence number.

(3) Server B closes the connection to client A and sends a fin to client a.

(4) Client A sends back ACK message confirmation, and sets the confirmation sequence number to receive the serial number plus 1.

TCP uses four waves to close connection 2 as shown.

Figure 2 TCP Four waves to close the connection

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.

deep understanding of TCP connected to Release:

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.
The connection to the TCP protocol is a full-duplex connection, and a TCP connection has a bidirectional read-write channel.
In short, "First shut down, then write", there is a total of four stages. Take a client-initiated shutdown connection as an example:
1. Server Read Channel shutdown
2. Client Write channel shutdown
3. Client Read channel shutdown
4. Server Write channel shutdown
The shutdown behavior is to send a fin (finish) data segment to the sender after the initiator data has been sent. Until you receive the fin sent by the other party, and the other party receives the acknowledgement ACK, the data communication between the two sides is completely terminated, and each receive in the process needs to return the acknowledgment segment ack.
Detailed process:
First StageAfter the client sends out the data, it sends the server AFINData segment, serial number isI；
1. The server receivesFIN (i), Return to confirmation segmentACK, the serial number isi+1，turn off the server read channel；
2. The client receivesACK (i+1)AfterTurn off client write channels；
(At this point, the client can still read the server's data through the read channel, the server can still write data through the Write channel)
Phase IIAfter the server sends the data, send a fin data segment to the client, the serial number is J;
3. The client receivesFIN (j), Return to confirmation segmentACK, the serial number isj+1，Turn off the client read channel；
4. The server receivesACK (j+1)AfterTurn off server write channel。
This is a standard TCP shutdown of two stages, and both the server and client can initiate shutdown, completely symmetric.
The fin ID is set when the last piece of data is sent, in the standard example, the server is still sending data, so wait until the send is finished, set fin (this can be called a TCP connection insemi-closed state,Because the data can still be transmitted from the passive shutdown in one direction to the active shut-down party. If there is no data to send when the server receives fin (i), it is possible to set the Fin (j) identifier when the ACK (I+1) is returned, which is equivalent to merging the second and third steps.Read "Linux network Programming" to close the TCP Connections section and make the following notes:

time_wait and close_wait states of TCP

Interview to see the candidate resume written proficient in network, TCP programming, I often ask a question, TCP to establish a connection need a few handshake? More than 95% of the applicants are able to answer 3 times. Ask TCP to disconnect a couple of handshake, 70% of the candidates can answer is 4 communication. Again ask Close_wait,time_wait is what state, how to produce, to the service has what influence, how to eliminate? A part of the students can not answer. Not that I buckle the details, but on the communications-based front-end server, you must have the ability to handle various TCP states. such as statistics on a front-end machine in the factory peak time TCP connection situation, statistics command:

1. Netstat-n | awk '/^tcp/{++s[$NF]} END {for (a in S) print A, S[a]} '

Results:

In addition to established, you can see that the number of connections more than a few states are: Fin_wait1, time_wait, close_wait, Syn_recv and Last_ack; The following article is about the conditions of these States, The influence of the system and the processing method are briefly described.

TCP Status

The TCP status is as follows:

Maybe a little dazzled? And take a look at this timing chart.

Let's look at the three kinds of TCP states that we generally care about

Syn_recv

The server receives a connection to the SYN without receiving the ACK packet when it is in the SYN_RECV state. There are two related system configurations:

1,net.ipv4.tcp_synack_retries:integer

The default value is 5

For a remote connection request SYN, the kernel sends a SYN + ACK datagram to confirm receipt of the last SYN connection request packet. This is the second step of the so-called three-time handshake (threeway handshake) mechanism. This determines the number of syn+ack that the kernel sends before discarding the connection. should not be greater than 255, the default value is 5, which corresponds to about 180 seconds of time. Usually we do not modify this value because we want the TCP connection not to be established because of occasional drops.

2,net.ipv4.tcp_syncookies

The general server will set Net.ipv4.tcp_syncookies=1 to prevent SYN flood attacks. Assuming a user sends a SYN message to the server and suddenly freezes or falls off, the server will not be able to receive an ACK message from the client after sending the Syn+ack response message (The third handshake cannot be completed), in which case the server typically retries (sending syn+ again ACK to the client) and wait for a period of time to discard the unfinished connection, the length of the time we call the Syn Timeout, in general this time is the order of the Minutes (about 30 seconds-2 minutes).

These TCP connections in SYNC_RECV are called semi-connections and are stored in a semi-connected queue in the kernel, where the kernel receives an ACK packet from the peer, finds a semi-connection queue, stores the compliant Requst_sock information in the queue of the connection that completes the three handshake, and then deletes the half connection. A large number of SYNC_RECV TCP connections can cause a half-connection queue overflow so that subsequent connection establishment requests are discarded directly by the kernel, which is the SYN flood attack.

One of the means to effectively protect against SYN flood attacks is the Syn Cookie. The original reason for the SYN cookie is d. J. Bernstain and Eric Schenk invented. The SYN cookie is a means of modifying the three-time handshake protocol on the TCP server side to protect against SYN flood attacks. The principle is that when the TCP server receives the TCP SYN packet and returns the TCP Syn+ack packet, it does not allocate a dedicated data area, but calculates a cookie value based on the SYN packet. When a TCP ACK packet is received, the TCP server checks the validity of the TCP ACK packet against that cookie value. If it is legal, then the dedicated data area is allocated for processing future TCP connections.

The number of SYN_RECV connections on the observing service is: 7314, which is more normal for a communication server with high concurrent connections.
Close_wait

The party that initiates the TCP connection shutdown is called the client, and the passive shutdown is called the server. After the passive shutdown of the server receives the fin, but the TCP status of the ACK is not issued is close_wait. This situation is generally due to server-side code problems, if you have a large number of close_wait on the server, you should consider checking the code.

Time_wait

According to the TCP protocol defined by the 3-time handshake disconnection rules, initiate the socket active shutdown of the socket will enter the TIME_WAIT state. The TIME_WAIT state will last 2 MSL (Max Segment Lifetime), and the default is 4 minutes, or 240 seconds, under Windows. The socket in the TIME_WAIT state cannot be reused. The specific phenomenon is for a server processing a large number of short connections, if the server actively shut down the client connection, will result in a large number of servers in the TIME_WAIT state of the socket, or even more than the socket in the established state, Severely affects the processing power of the server and even exhausts the available sockets to stop the service.

Why do I need time_wait? Time_wait is a logical guarantee that the TCP protocol is used to ensure that a reassigned socket is not affected by a previously lingering delay redistribution.

The system parameters related to the TIME_WAIT state are generally made up of 3, the factory is set as follows:

Net.ipv4.tcp_tw_recycle = 1

Net.ipv4.tcp_tw_reuse = 1

Net.ipv4.tcp_fin_timeout = 30

Net.ipv4.tcp_fin_timeout, default 60s, decrease fin_timeout, reduce the number of time_wait connections.

Net.ipv4.tcp_tw_reuse = 1 means turn on reuse. Allows time-wait sockets to be re-used for new TCP connections, which defaults to 0, which means shutdown;

Net.ipv4.tcp_tw_recycle = 1 means a fast recycle of time-wait sockets in the TCP connection is turned on, and the default is 0, which means shutdown.

To facilitate the description, I named the client to the end of the TCP connection and named the other end server. Describes the process of client active shutdown, as is the case in the FTP protocol. If you want to describe the process of server active shutdown, just swap the server and client in the description process, as is the case with the HTTP protocol.

Describe the process:
The client calls the close () function, sends a fin to the server, requests that the connection be closed, the server returns a confirmation ACK to the client after receiving the fin, and closes the read channel (it is unclear to see the difference between shutdown and close), This means that you can no longer read from this connection and now read returns 0. The TCP state of the server is now converted to the close_wait state.
After the client receives confirmation of its fin, it closes the write channel and no longer writes any data to the connection.
The server then calls close () to close the connection, sends a fin,client to the client when it receives the ACK acknowledgment, and the client closes the read channel and enters the TIME_WAIT state.
The server receives a confirmation ACK from the client to its own fin, closes the write channel, and the TCP connection is converted to closed, that is, the connection is closed.
The client waits twice times the maximum data segment lifetime in the TIME_WAIT state before entering the closed state, and the TCP protocol closes the connection process completely.

The above is the TCP protocol to close the connection process, now say the time_wait state.
As you can see from the above, the party that initiates the operation to close the connection will reach the TIME_WAIT state, and this state should be kept maximum Segment lifetime twice times. Why do you do this instead of going directly into the closed state?

There are two reasons:
One, to ensure that the TCP protocol full-duplex connection can be reliably shut down
Second, to ensure that the connection of the duplicate data segment from the network disappeared

First, the 1th, if the client directly closed, then due to the IP protocol is not reliable or other network reasons, causing the server did not receive the client's final reply ack. Then the server will continue to send fin after timeout, when the client is already closed, unable to find the connection to the re-issued fin, and finally the server will receive the RST instead of Ack,server will think it is a connection error report to the top. Such a situation does not result in data loss, but it causes the TCP protocol to not meet the requirements of a reliable connection. Therefore, the client is not directly into the closed, but to maintain the time_wait, when again received fin, can ensure that the other side received an ACK, and finally close the connection correctly.

Besides, 2nd, if the client closed directly and then initiates a new connection to the server, we cannot guarantee that the new connection will be different from the port number of the newly closed connection. That is, it is possible that the port number of the new connection and the old connection is the same. Generally, there is no problem, but there is a special case: Assume that the new connection and the old connection port number that has been closed is the same, if some data of the previous connection is still stranded in the network, the delay data after establishing a new connection before the server, because the new connection and the old connection port number is the same, And because the TCP protocol determines that different connections are based on the socket pair, the TCP protocol considers the deferred data to be a new connection, which is confused with a real new connected packet. So the TCP connection also waits twice times the MSL in the TIME_WAIT state, which ensures that all data for this connection disappears from the network.

All kinds of agreements are the standard and norm after the predecessors thoroughly tempered. You can feel the sophistication and rigor from the details. Each depth has the same feeling, subtle.

TCP Three handshake (connection established) and four waves (close connection)