The establishment and shutdown of TCP connections

1. TCP establishes the connection (three times handshake)

The following two diagrams explain TCP's three handshake processes from the protocol and interface two angles (respectively from the computer network-Shehiren and UNIX Network Programming volume 1):

1.1. Tcpdump shook hands three times

The following is a tcpdump to view the process of TCP connection making: Testing with NC commands.

SERVER:NC–L 9000
CLIENT:NC 9000

[anonymalias@qcloud ~] $sudo tcpdump-i Lo Port 9000-x–s

Tcpdump by default, only the absolute sequence number is displayed in the SYN segment, and the other segment displays only the relative sequence number, so you need to add-s to display absolute sequence number in the phase other than the handshake. The-x parameter is used to parse and display the header and the package body of each package. Only the IP header + TCP packet is shown here, not the head of link layer link level.

6 control bit fields in the first TCP connection-setting request package in the figure: urg| ack| psh| Rst| SYN| Fin,syn is set to 1, which means a connection request packet;
The second TCP packet in the figure is the answer package for the server to the connection request, 6 control bit fields: urg| ACK| psh| Rst| SYN| Both Fin,ack and SYN are set to 1, representing the answer packet for the connection request. The TCP protocol stipulates that after the link is established, all the message's ACK control bits must be set to 1;
The third TCP packet in the figure is a confirmation package for the client to the answer package, 6 control bit fields: urg| ACK| psh| Rst| syn| Fin,ack is set to 1.

For TCP to establish a link, the control bit SYN will only be 1 when the link is established, and the other Stage's package cannot be set. The control bit ACK, which is set to 1 until the second handshake starts and after, until the last packet. Why do you have to shake hands three times, not two times?

This is mainly to prevent the failed connection request message segment suddenly sent to the server, resulting in errors.
failed connection Request message segment reason : When client A sends a connection request, but the connection request message is lost and not received confirmation. So a will retransmit the connection request again, at which point Server B receives the connection request again retransmission, establishes the connection, then carries on the data transmission, after the data transmission is over, releases this connection. Let's say that a connection request sent for the first time is not lost, but is stuck in the network node for too long to reach B after the AB communication is complete. At this point, the connection request is actually lost by a. If you do not have a third handshake, then Server B may receive this failed connection request, the confirmation, and then unilaterally into the established state, and a at this time does not respond to B's confirmation, so wasted the resources of the server. 1.2. TCP opens at the same time

The TCP protocol is also supported at the same time, although this probability is very small, because it requires both sides of the communication to know each other's port number, which requires both sides bind () their respective ports, and simultaneously issue a SYN packet. TCP establishes only one connection, not two connections, for situations that are open at the same time.
For both parties that open the connection at the same time, after sending the SYN package, all entered the Syn_send state, after receiving the SYN packet to the end, enter the SYN_RCVD state, and the SYN packet back to the SYN packet to confirm, when both sides received the SYN packet ack, Will enter the established state. As follows:

TCP opens at the same time requires 4 handshake, more than a normal connection to establish a packet. 1.3. TCP Release connection (four waves)

The following two graphs explain the release process of TCP from the protocol and interface two angles (respectively from computer network-Shehiren and UNIX Network programming volume 1)

1.3.1 Tcpdump waved four times.

As with the three-time handshake that establishes the connection, after the link is established and then closes the link, the tcpdump results are as follows:

The results of the tcpdump are as follows:
6 control bit fields in the first TCP request package in the figure: urg| ACK| psh| Rst| syn| fin, ack, and fin control position 1, client initiates a request to close the TCP connection.
The second TCP packet in the figure, which is the shutdown package for the server response client, where 6 control bit fields: urg| ACK| psh| Rst| syn| fin, ACK and fin control position is 1, and back packet ack = previous packet seq + 1,
The third TCP packet in the figure, which answers the link for the client to the server, where 6 control bit fields: urg| ACK| psh| Rst| syn| Fin,ack control bit is set to 1, this package represents the formal closure of the link;

TCP stipulates that the fin segment consumes an ordinal number even if it does not carry data .
TCP shutdown status two points need to be explained: close_wait State
In the case of a passive shutdown connection, the connection is in the close_wait state when the fin has been received but has not yet sent its own fin, at which point the TCP connection is in a semi shutdown state. time_wait State
The client does not enter the closed state immediately after the client receives the last connection release segment on the server side. You must pass 2MSL (Maximum Segment Lifetime) Before you enter the closed state.
To ensure that the last ACK message sent by the client can reach the server side. Prevents the "Defunct connection request segment" from being described in the TCP connection as it appears in this connection. After the client sends the last ACK message and passes 2MSL, all the messages in the duration of the connection can be lost from the network. This allows the old connection request message not to appear in the next new connection. 1.3.2. TCP shuts down simultaneously

The TCP protocol is to allow both sides of the communication to perform a shutdown at the same time, that is, send the fin packet, when both sides send the FIN packet, both enter the Fin_wait_1 state (each side has not known each other has sent fin, so and normal shutdown), when both sides received the fin package, TCP protocol layer will know that both sides are closed at the same time, and then will enter the closing state, and the other side of the SYN packet for ACK confirmation, when the two sides received the ACK confirmation, will enter the TIME_WAIT state. The process is shown below:
1.4. TCP Semi-shutdown (half-close)

TCP is waving four times when it releases a link because the TCP link is full-duplex because the links in each direction need to be closed separately. This is the most basic principle of the TCP protocol, which requires that when one party completes sending the data, it sends a FIN packet to terminate the link in this direction.
Therefore, thehalf shutdown of TCP is the ability to receive data from the other end when the end of the connection is sent and closed.

However, this feature only a very small number of applications will use it, we usually basically through close () directly all closed a link. If the application is to use this feature, you can call shutdown, and the second argument passes 1

Here's a look: the difference between shutdown and close functions

int close (int sockfd);

Close a TCP socket, the default behavior is to mark the socket as closed, and then immediately back to the calling process , the socket descriptor can no longer be used by the calling process, that is, it can not be read or write, or it will error, bad file Descriptor, then TCP will attempt to send any data that has been queued to be sent to the right end, and a normal TCP termination sequence occurs after the send is completed.
When the close () function is called on the server side, the link is no longer half closed, but all closed. The caller TCP protocol layer identifies the link's FD as fully closed. After the server sends the FIN package, the client is not aware of the so-called full shutdown, because clients will only receive a FIN packet, according to the TCP protocol: Client will only know that the server to the client direction of data transfer has been closed , So the client is theoretically allowed to send data again to the server side.
If, at this point, the client sends the data back to the server successfully, send () is only responsible for sending the data to the kernel TCP send buffer, and then returns successfully, so there is no error. However, the client's TCP kernel protocol layer receives a single RST back package from the server, indicating that the server is no longer receiving data and the connection is reset. Client's TCP kernel protocol layer receives this RST back packet, cannot immediately notify the application layer, just save this state if the client does it again: Read (): Returns 0, indicating that the link is closed. Write () Operation: The TCP protocol layer is already in the RST state, which triggers the sigpipe signal, and the default signal terminates the program.

int shutdown (int sockfd, int how);

Shutdown () You can choose to turn off TCP Full-duplex, one-way or two-way connections. The second parameter how value is as follows:

How

the value	Description
0	Further receives are disallowed
1	Further sends are disallowed
2	Further sends and receives are disallowed (like Close ())

When how is 0 o'clock, shutdown () closes the read channel of the connection and discards all data that has not been read by the upper level and the data arrived after the call shutdown, and the fin package is not sent at this time.
When how is 1 o'clock, shutdown () closes the write channel of the connection, all the remaining data is sent, the FIN packet is sent, and the half shutdown of TCP is performed .

This needs to be pointed out ( basically not happening ):
Close () does not guarantee that the FIN packet will be sent, and only if a SOCKFD reference count is 0,close will the fin segment be sent, otherwise the reference count will be reduced by only 1. That is, close does not send a fin segment until all processes (possibly fork multiple child processes have opened the socket) have closed this socket. 1.5. TCP Half-open (Half-open)

Semi-open TCP is a very common link exception case where one side is closed or terminates the connection abnormally, while the other side is not aware of it.
In this case, after the server calls close () closes the connection, the client receives the fin packet and does not close the link, when the TCP link is ajar, at which point the client sends the data to the end-to-end to trigger the RST back packet at the TCP protocol layer, For example, the following tcpdump grab bag:

And, of course, what happens is that TCP is partially open on the other end due to network disconnection and power outages.

Because the diversity of the client network is complex, the server side is very easy to produce a lot of half-open connections, half open link detection, there are many methods, through the application layer, each connection to add timer monitoring, timeout without data on the shutdown operation. TCP's live timer is started with the keepalive option of the TCP protocol layer, but it is not a TCP standard specification (but it is implemented in many TCP implementations), and the TCP RFC gives 3 reasons not to use the live timer:
In the event of a transient error, a very good connection may be released; the retention function consumes unnecessary bandwidth; In the case of flowmeter charges, it will cost more money;

The following is the So_keepalive option to set up a TCP connection to support the live code:

int open = 1;       Open the KeepAlive property. Default value: 0 (OFF)  
int idle =;    If there is no data interaction within 60 seconds, the probe is performed. Default value: 7200 (s)  
int interval = 5;  Probe packets are sent at intervals of 5 seconds. Default value: (s)  
int retry_cnt = 2;  The number of probe retries. All timeouts determine that the connection is invalid. Default value: 9 (Times)  
setsockopt (S, Sol_socket, so_keepalive, &open, sizeof (open));  
SetSockOpt (S, sol_tcp, tcp_keepidle, Idle, sizeof (idle));  
SetSockOpt (S, sol_tcp, TCP_KEEPINTVL, interval, sizeof (interval));  
SetSockOpt (S, sol_tcp, tcp_keepcnt, retry_cnt, sizeof (RETRY_CNT));  

1.6. TCP Reset Message Segment

TCP's reset message is a very common data, citing TCP/IP detailed words: whenever, a message segment to the Datum of the connection (referenced connection) error, TCP will issue a reset message segment .
There are three main cases: the previously mentioned Half-open State : The other end of a connection has been closed, sending data to the opposite end, triggering the RST back packet; connection requests to nonexistent ports : Requests to connect a port that is not listening, TCP returns RST ( UDP will produce an ICMP Port unreachable information). An exception terminates a connection : When the connection is closed, it is not normally closed through the fin message, but is closed by sending the RST directly. The difference between the two:
The fin packet is turned off, also known as ordered release , because Close ()/shutdown () sends all the data in the buffer before sending the fin orderly. Through the RST reset package to shut down, also known as: abnormal release (abortive released). Characteristics of Abnormal release:
Discards all data in the send buffer, sends the RST message immediately, and the RST receiver distinguishes between a normal shutdown or an abnormal shutdown performed by the other end.

The code for connecting directly by sending the RST message is as follows, as detailed in the following section, TCP delay shutdown :

struct linger So_linger;
So_linger.l_onoff = true;
So_linger.l_linger = 0;

ret = setsockopt (EVENTS[I].DATA.FD, Sol_socket, So_linger, &so_linger, sizeof (So_linger));
if (Ret < 0)
{
    printf ("%s"): [ERROR]: setsockopt ERROR, errno:%d, info:%s\n ", \
        __function__, errno, Strerror (errno));

Close (EVENTS[I].DATA.FD);

delayed shutdown of 1.7. TCP

TCP supports setting the connection delay shutdown with the So_linger option. The default behavior of the close () one socket is that it marks the socket as closed and immediately returns to the calling process, and then the TCP protocol layer attempts to send any data that has been queued to be sent to the end, and a normal TCP termination sequence occurs after it has been sent.
The So_linger option can change the default behavior of close (), and the option requires that the parameters of the incoming kernel be structured as follows:

struct linger{
    int l_onoff;        0=off, Non-zero = on
    int l_linger;       Delayed shutdown time, unit second
};

When the L_onoff is turned on, L_linger is not 0, when call Close () closes the connection, in the case of FD blocking, if the socket's sending buffer remains the data being sent, then the process will be put into sleep until all the data has been sent and a confirmation or l_linger time timed out. Close () returns a ewouldblock error and discards all data from the sending buffer if the delay time timeout is not sent to the data that sent the buffer. In the case of FD non-blocking, close () returns immediately, and then the TCP protocol layer is the same operation as the FD blocking condition.

When the L_onoff is turned on, the L_linger is 0, and when you call Close () closes the connection, it triggers the previously described process of abnormal release, that is, sending a reset message to connect the shutdown. For specific TCP protocol layer operations and the benefits of doing so see the preceding article.

The following figure is the behavior of close () under the So_linger option, truncated from UNIX network programming Securities 1: Socket network API
1.8. TCP Status Description

The two sides of a TCP connection are at different stages of the connection, and understanding of each phase is a good basis for using TCP, and the following table is the state of the TCP connection:

waits for a connection to the local user to terminate the request The

TCP port Status	description
LISTEN	waits for a connection request from any remote TCP and port
syn_sent	waits for a matching connection request after sending a connection request.
syn_received	sends a connection request and waits for a connection request confirmation after receiving a matching connection request. The
established	represents an open connection, and the data received can be delivered to the user. The normal state of the data transfer phase of the connection. The
fin_wait_1	waits for a remote TCP connection to terminate the request, or to wait for confirmation of the connection termination request that was sent earlier.
fin_wait_2	pending connection termination requests for remote TCP
close_wait
CLOSING	(at the same time shutdown) wait for connection termination request confirmation for remote TCP
L Ast_ack	waits for confirmation of a connection termination request that was previously sent to a remote TCP (including its byte connection termination request confirmation)
time_wait	waiting for enough time Go to ensure that the remote TCP receives its connection termination request confirmation
CLOSED	is not in the connection state (this is for the convenience of describing the hypothetical state, actually does not exist)

The following figure is a TCP state transition diagram (excerpt from: UNIX Network programming Securities 1: Socket network APIs)
5.9. For reference

http://zheming.wang/blog/2013/08/18/4417B74D-F037-414A-A291-CEF7B3CD511D/
Http://xstarcd.github.io/wiki/shell/tcpdump_TCP_three-way_handshake.html
Http://www.cnblogs.com/lshs/p/6038458.html
http://blog.csdn.net/jnu_simba/article/details/9068059
UNIX Network Programming Securities 1: Socket network API
"TCP/IP detailed 1: agreement"
"Computer Network (Shehiren)"