TCP three-time handshake and four-time disconnection in-depth analysis: Connection status and Socket API relationships

When it comes to the TCP protocol, anyone who has seen it lightly can say three handshakes and four disconnection. A little bit more is able to put each state (Sync_sent, close_wait.

。。。

。。 etc) can be back out,

and says socket programming. Basically the person who writes the network programming will be familiar with those several standard api:socket, connect, listen, accept ....

。。 such as

But. I bet very few people explicitly define the relationship between the TCP state and the socket programming API . Don't believe me? Take a look at some of the questions you know:

1) When is the client capable of connecting to the server side, is the server side calling bind or after listen or after accept?

2) What happens when the fin_wait_2 state is present

。

。

。。。。

。。。。

。。

。。。

。。

。。。。

This week to break the spirit of the casserole and the spirit of seeking truth from facts, I wrote some scripts in the Python script to test these situations. After reading you will be very enjoyable, TCP protocol and socket programming understanding of the upper floor.

Note: The following test is tested on the Linux (2.6.18) platform using the Python (2.7) script. Other platforms are not tested. Be interested to test it yourself.

"Connection process testing and verification"

1th Case: Client call Connect,server just call socket + bind, no call listen

Tcpdump grab packages such as the following:

Grab packet results show: Server side directly reply to the RST package

At this time using the netstat or SS command to see, whether the client or the server, can not find the connection

2nd case: Client call Connect,server socket + bind + Listen

Tcpdump grab packages such as the following:

Grab bag results show: three handshake complete

Use the SS tool to view, both client and server display Estab

[[Email protected] ~]$ SS  -t-n | grep 50000ESTAB      0      0                10.1.73.45:55354           

3rd case: Client call to connect + send,server call Socket + bind + Listen + accept + recv + send

Tcpdump grab packages such as the following:

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvexvuahvhx2xlzq==/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/southeast "/>

Clutch results show: Three handshake complete, and both sides are able to send and receive data

Use the SS tool to view. Both client and server display Estab

[[Email protected] ~]$ SS  -t-n | grep 50000ESTAB      0      0                10.1.73.45:41363           

"Connection Process Summary"

1) can see that only when the server side listen, the client side calls connect talent succeeds, otherwise it will return the RST response to reject the connection

2) Only when accept, client and server talent call recv and send and other IO operations

3) The socket API call error does not cause the client to appear syn_sent state, then only the network device drops (routers, firewalls) will cause the sync_sent state

"Test and summary of the disconnection process"

1th Scenario: Client calls Close, but server does not call close

Tcpdump grab packages such as the following:

Packet Capture results: Client sends fin packet, server side answers ACK packet

Use the SS tool to view. Client Displays fin_wait_2 status:

[[Email protected] ~]$ SS  -t-n | grep "10.1.73.76:50000" Fin-wait-2 0      0                10.1.73.45:47630           10.1.73.76:50000

Server Display close-wait status

[[Email protected]_test ~]$ SS  -t-n | grep 50000close-wait 1      0                10.1.73.76:50000           

and there is a notable phenomenon is:The client's connection has not been for some time, and the server connection has been in the close_wait state

The reason is that there is a parameter in the kernel of the Linux system that controls fin_wait_2 time: Tcp_fin_timeout

2nd scenario: Client calls Close. Server calls Close

Tcpdump grab packages such as the following:

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvexvuahvhx2xlzq==/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/southeast "/>

Clutch results show: familiar with the four-time disconnection

Use the SS tool to view. Client Display time-wait Status

[Email protected] ipv4]$ ss-a-n | grep 50000time-wait  0      0                10.1.73.45:39751           

the server side uses the SS tool to see that the connection has not been seen

3rd Scenario: Server side is killed

Tcpdump grab packages such as the following:

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvexvuahvhx2xlzq==/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/southeast "/>

Clutch results show: familiar with the four-time disconnection

Well, how could it be the same as the normal server close? the answer lies in the implementation of the operating system:

The close function does not, in fact, cause the TCP stack to send the fin packet immediately, but only the reference count of the socket file minus 1. When the reference count of the socket file becomes 0. The operating system will voluntarily shut down the TCP connection, and the FIN packet will not be sent at this time.

This is also a point of special attention in multi-process programming, the parent process must be the socket file description descriptor close. Operating system prompts may appear after running for a period of time too many open files

4th Scenario: Client-side invoke shutdown operation

Shutdown operation has three kinds of closure methods: Shut_rd, SHUT_WR, Shut_rdwr, respectively, after testing to find interesting phenomenon.

1) The hypothesis is shut_rd. Then the tcpdump catches the bag and finds no packages to send no matter what.

2) The assumption is SHUT_WR or shut_rdwr. The client sends a FIN packet to the server.

If the server receives a close operation after it is received, the server sends fin to the client, and finally the connection is closed.

SHUT_WR or Shut_rdwr capture a presentation sample such as the following:

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvexvuahvhx2xlzq==/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/southeast "/>

Use the SS command to view. The client shows a demo sample such as the following:

[Email protected] ~]$ Ss-a | grep 50000time-wait  0      0              10.1.73.45:45641           

the server shows that the connection has been closed.

A detailed explanation of shutdown can be tested: http://www.gnu.org/software/libc/manual/html_node/Closing-a-Socket.html

Summarize treatment of SHUT_RD:

1) The client side no longer receives data, assuming that new data arrives. Direct Discard (Reject)

2) No TCP packets are sent, so the server side does not know the status, and the server can continue to send data. But because of 1) the reason that hair was also white hair

Summarize the treatment of SHUT_WR or shut_rdwr:

1) Stop transmitting the data (no more calls to the write operation), Discard unsent data in the buffer (write is called but the underlying TCP stack is not yet sent)

2) Stop waiting for a confirmation message for the sent data, sent unconfirmed data no longer re-sent

"Disconnection Process Summary"

1) Close only reduces the reference count of the socket file, and when the count is reduced to 0, the operating system runs a TCP disconnection operation

2) client side close after server side is not close. Causes the client-side connection state to be the fin_wait_2,server-side connection state of close_wait

Normal programming is certainly not handled in this way, typically in exception handling jumps (C++/java, etc.) resulting in no close, or an entire system exception resulting in no close (for example, JVM memory appearing out of a memory error)

3) The processing logic of shutdown is more complicated. Don't use it in non-special cases. Very easy problem

4) When the process exits, the operating system will voluntarily reclaim the socket itself. Initiating a TCP shutdown process operation

TCP three-time handshake and four-time disconnection in-depth analysis: Connection status and Socket API relationships