http://www.cnblogs.com/cy568searchx/p/3711670.html
TCP (Transmission Control Protocol) transport control protocol
Three-way handshake
TCP is the host to host transmission control protocol layer, to provide reliable connectivity services, three-way handshake to establish a connection confirmation:
I.e. tcp flag bit code, there are six kinds Flag: SYN (synchronous connection establishment) ACK (acknowledgement acknowledgment) PSH (push transfer) FIN (finish end) RST (reset Reset) URG (urgent emergency)
Sequence number (sequence number) Acknowledge number (confirmation number)
The first handshake: Host A sends bit code syn = 1, randomly generated seq number = 1234567 packet data to the server, by the host B knows SYN = 1, A requirement to establish a connection;
Second handshake: Host B after receiving the request for a connection acknowledgment message, to send ack number A = (host A seq + 1), syn = 1, ack = 1, randomly generated packet seq = 7654321
Third handshake: Host A receives the ack Number check is correct, i.e., the first transmission seq number + 1, and the ack bit code is 1, if correct, then the host A transmits ack number = (host B seq + 1), ack = 1, the host B receives the acknowledgment seq value ack = 1 the connection is successfully established.
Three-way handshake is completed, the host A and the host B starts transmitting data.
In the TCP / IP protocol, TCP protocol provides reliable connectivity services, three-way handshake to establish a connection.
The first handshake: a connection is established, the client sends syn packets (syn = j) to the server, and enters SYN_SEND state, waiting for the server to confirm;
second handshake: server receives syn packets, must confirm the customer SYN (ack = j + 1), while themselves sends a SYN packet (syn = k), i.e., SYN + ACK packet, then the server enters a state SYN_RECV; third handshake: the client receives the SYN + ACK packet to the server, the server sends a confirmation packet ACK (ack = k + 1) , this packet is sent, the client and server into the ESTABLISHED state, complete the three-way handshake. Complete three-way handshake, the client and the server begins transmitting data.
Example:
IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1
The first handshake: 192.168.1.116 transmit bit code syn = 1, randomly generated data packet seq number = 3626544836 192.168.1.123,192.168.1.123 to know the SYN = 1 192.168.1.116 claim establish a connection;
Second handshake: 192.168.1.123 after receiving a request for a connection acknowledgment message, to send ack number = 3626544837 192.168.1.116, syn = 1, ack = 1, randomly generated seq = 1739326486 of packets;
Third handshake: 192.168.1.116 after receiving the inspection ack number is correct, that is, for the first time sent seq number + 1, and the ack-bit code is 1, if correct, 192.168.1.116 will then send ack number = 1739326487, after receiving confirmation 1,192.168.1.123 = ack seq = seq + 1, ack = 1 the connection is successfully established.
Illustration:
a three-way handshake process (FIG. 1, FIG. 2)
(FIG. 1)
(FIG. 2)
The first handshake flag (Figure 3)
we can see that there is only one flag synchronization bits, that is, do request (the SYN)
(3)
second handshake flag (Figure 4)
we can see there are a confirmation flag bits and synchronization bits, that is, do answer (the SYN + ACK)
(Figure 4)
flag (Figure 5) third handshake
we can see that there is only one flag acknowledge bit, that is, do reconfirmed (ACK)
(Figure 5)
a complete three-way handshake is requested --- --- response to reconfirm
Four break up:
Since a TCP connection is full-duplex, so each direction must be shut down separately. The principle is that when one task completes its data transmission can send a FIN to terminate the connection direction. Receive a FIN only means that no data is flowing in this direction, a TCP connection can still send data after receiving a FIN. First off will be the one to perform active close, while the other performs a passive close.
(1) A client sends a FIN, for closing the client A to the server B transmits data (segment 4).
(2) Server B receives the FIN, it sends back an ACK, acknowledgment received sequence number plus 1 (segment 5). And SYN as a FIN will take a number.
(3) closes the server B is connected to the client A, the client sends a FIN A (segment 6).
(4) A client sends back ACK message ACK by incrementing the received sequence number by 1 (segment 7).
Detailed status:
CLOSED: there's really nothing, and that the initial state.
LISTEN: This is also very easy to understand a state, represents a SOCKET server in a listening state, you can accept the connection.
SYN_RCVD: This status means receives a SYN packet, under normal circumstances, this state is an intermediate state of the server-side session SOCKET three-way handshake when establishing a TCP connection process, very short, basically you are hard to see with netstat this state, unless you deliberately write a client test program, deliberately TCP handshake process three times last ACK packet will not be sent. Therefore, when this state, when the client receives the ACK packet, it enters the ESTABLISHED state.
SYN_SENT: The state SYN_RCVD Way back echoes, when the client SOCKET execute CONNECT connection, it first sends a SYN packet, and therefore then it will enter into SYN_SENT state, and waiting to be sent three times the service side of the handshake in the first two messages. SYN_SENT state that the client has been sending a SYN packet.
ESTABLISHED: This is easy to understand that a connection has been established.
FIN_WAIT_1: The state to properly explain the true meaning of FIN_WAIT_1 and in fact FIN_WAIT_2 states are represented FIN messages waiting for the other side. The difference between these two states is: FIN_WAIT_1 state is actually when SOCKET in the ESTABLISHED state, it wants to take the initiative to close the connection, sends a FIN packet to each other, then that is the SOCKET into FIN_WAIT_1 state. And when the other party to respond to ACK packet, it enters the FIN_WAIT_2 state, of course, in the actual normal circumstances, no matter under what circumstances the other side, should immediately respond to ACK packets, so FIN_WAIT_1 state is generally more difficult to see, and FIN_WAIT_2 state when there can often see with netstat.
FIN_WAIT_2: As already explained in detail in this state, in fact SOCKET FIN_WAIT_2 state, represents a semi-connected, that one party requires close connection, but also tell each other, I do a little data to transmit to you again later close the connection.
TIME_WAIT: acknowledge the receipt of each other's FIN packet, and sends the ACK packet, would be to return to the state after 2MSL CLOSED available. If the next FIN_WAIT_1 state, while the other received a packet with the FIN flag and the ACK flag, you can go directly to the TIME_WAIT state, without going through FIN_WAIT_2 state.
CLOSING: This state is rather special, the reality should be rare, it is a relatively rare state of exception. Under normal circumstances, when you send FIN messages, logically, it should first receive (or received simultaneously) each other's ACK packet, stop receiving FIN messages. But CLOSING state means after you send a FIN packet, and receives no ACK packet, but they also received each other's FIN packet. This can happen then under what circumstances? In fact, think of it, is not difficult to conclude: that is, if the two sides almost at the same time close a SOCKET, then appeared the case sides also send FIN messages, also will appear CLOSING state, said both sides are being closed SOCKET connection .
CLOSE_WAIT: implication of this fact is a closed state in waiting. How to understand it? When the other party close a SOCKET send FIN messages to yourself, your system will no doubt respond with an ACK packet to the other party, then proceeds to CLOSE_WAIT state. Now what, in fact, what you really need to consider is whether you look there is more data to send to the other party, if not, then you can also close the SOCKET, send FIN messages to each other, that is, close the connection. So you're in CLOSE_WAIT state, it needs to be done is to wait for you to close the connection.
LAST_ACK: This state is relatively easy to better understand, it is a passive shut down the party after sending FIN packets, waiting for the other side of the last ACK packet. Upon receiving the ACK packet, i.e., can enter into the CLOSED state is available.
to sum up:
1. Why is a three-way handshake to establish a connection agreement, and close the connection handshake is it?
This is because the SOCKET LISTEN state service in the end of the construction even after receipt of the request SYN packet, it can SYN and ACK (ACK response from the role, and SYN for synchronization) placed in a packet to send. But it closes the connection when it receives each other's FIN message notification, it merely indicates that the person no data is sent to you; but not necessarily all of you have all the data is sent to the other party, so you can not necessarily immediately closed SOCKET, That you might also need to send some data to each other after, then send FIN messages to each other to indicate that you agree we can now close the connection, so under most circumstances it here ACK packets and FIN packets are sent separately.
2. Why TIME_WAIT state after 2MSL have to wait to return to the CLOSED state?
This is because although both sides agreed to close the connection, and four handshake packets are also coordinating and sent, supposedly can return to the CLOSED state (like that from SYN_SEND ESTABLISH state to state); but because we have to imaginary network is not reliable, you can not guarantee that you sent last ACK packet will definitely be received by the other party, the other party will be in the next SOCKET LAST_ACK state may not receive overtime because ACK packets, and retransmits packets FIN, so the role of the TIME_WAIT state is used to retransmit ACK packets may be lost.
-------------------
Speaking tcp agreement, all little people can read fluently speak four three-way handshake and disconnection, and then be able to Niubi each state (SYNC_SENT, CLOSE_WAIT ...... etc.) can be a little back out,
And he said socket programming, network programming is basically wrote that several people will be familiar with standard API: socket, connect, listen, accept. . . . . . Wait
But I bet very few people understand the relationship between the state and tcp socket programming API. Do not believe? Take a look at the following questions if you know it:
1) When the client was able to connect on the server side, after the server end or after a call to bind or listen after accept?
2) there will be FIN_WAIT_2 state under what circumstances
。。。。。。。。。。。。。。。。。。。。。
This week, the inquisitor asked in the end the spirit and the spirit of seeking truth from facts, I use python script written some scripts to test these circumstances, after reading it you will be hooked, and understanding of the protocol of tcp socket programming to new heights again.
Note: The following tests are on Linux (2.6.18) platform with python (2.7) test script, other platforms have not tested, are interested can test it yourself.
[Connection process testing and verification]
Case 1: client calls connect, server just call socket + bind, do not call listen
tcpdump packet capture as follows:
Ethereal results showed: server terminal RST packets directly replied
This time using the netstat command to view or ss, either client or server, are finding out connections
Case 2: client calls connect, server called socket + bind + listen
tcpdump packet capture as follows:
Ethereal results showed that: three-way handshake is completed
Ss Use tools to view, client and server are displayed ESTAB
[html] view plain copy
- [liyh@localhost ~]$ ss -t -n | grep 50000
- ESTAB 0 0 10.1.73.45:55354 10.1.73.76:50000
Case 3: client calls connect + send, server called socket + bind + listen + accept + recv + send
tcpdump packet capture as follows:
Ethereal results showed that: three-way handshake is completed, and both sides can send and receive the data
Ss Use tools to view, client and server are displayed ESTAB
[html] view plain copy
- [liyh@localhost ~]$ ss -t -n | grep 50000
- ESTAB 0 0 10.1.73.45:41363 10.1.73.76:50000
[Summary] connection process
1) It can be seen only when the server end after listen, client-side call connect to succeed, otherwise it will refuse to connect response is returned RST
2）只有当accept后，client和server才能调用recv和send等io操作
3）socket API调用错误不会导致client出现SYN_SENT状态，那么只能是网络设备丢包（路由器、防火墙）才会导致SYNC_SENT状态
【断连过程测试和总结】
第1种情况：client调用close，但server没有调用close
tcpdump抓包如下：
抓包结果显示：client发送了fin包，server端应答了ack包
使用ss工具去查看，client显示FIN_WAIT_2状态：
[html] view plain copy
- [liyh@localhost ~]$ 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显示CLOSE-WAIT状态
[html] view plain copy
- [jws@jae_test ~]$ ss -t -n | grep 50000
- CLOSE-WAIT 1 0 10.1.73.76:50000 10.1.73.45:47630
而且有一个值得注意的现象是：client的连接过一段时间就没有了，而server的连接一直处于CLOSE_WAIT状态
原因在于Linux系统内核中有一个参数可以控制FIN_WAIT_2的时间：tcp_fin_timeout
第2种情况：client调用close，server调用close
tcpdump抓包如下：
抓包结果显示：熟悉的四次断连来啦
使用ss工具去查看，client显示TIME-WAIT状态
[html] view plain copy
- [liyh@localhost ipv4]$ ss -a -n | grep 50000
- TIME-WAIT 0 0 10.1.73.45:39751 10.1.73.76:50000
server端使用ss工具去看已经看不到连接了
第3种情况：server端被kill了
tcpdump抓包如下：
抓包结果显示：熟悉的四次断连来啦
咦，怎么会和正常的server close一样呢？答案就在于操作系统的实现：
close函数其实本身不会导致tcp协议栈立刻发送fin包，而只是将socket文件的引用计数减1，当socket文件的引用计数变为0的时候，操作系统会自动关闭tcp连接，此时才会发送fin包。
这也是多进程编程需要特别注意的一点，父进程中一定要将socket文件描述符close，否则运行一段时间后就可能会出现操作系统提示too many open files
第4种情况：client端调用shutdown操作
shutdown操作有三种关闭方式：SHUT_RD、SHUT_WR、SHUT_RDWR，分别测试后发现有趣的现象。
1）如果是SHUT_RD，则tcpdump抓包发现没有发送任何包；
2）如果是SHUT_WR或者SHUT_RDWR，则client会发送FIN包给server，
若server收到后执行close操作，则server发送FIN给client，最终连接被关闭。
SHUT_WR或者SHUT_RDWR抓包显示如下：
使用ss命令查看，client显示如下：
[html] view plain copy
- [liyh@localhost ~]$ ss -a | grep 50000
- TIME-WAIT 0 0 10.1.73.45:45641 10.1.73.76:50000
server显示连接已经被关闭了。
Detailed explanations shutdown can refer to: http: //www.gnu.org/software/libc/manual/html_node/Closing-a-Socket.html
Summarize the process SHUT_RD:
1) client terminal is no longer receiving data, if new data arrives directly discards (Reject)
2) does not send any tcp packets, the server side does not know this state, the server end may continue to send data, but due to 1), also made of hair
Summarize SHUT_WR or SHUT_RDWR of treatment:
1) stops transmitting data (write operation can not be invoked), discards the untransmitted data buffer (write has been called but not the underlying transmission protocol stack tcp)
2) Stop Request message transmitted data, sent unacknowledged retransmitted data is no longer
[Disconnection process summary]
1) close socket file simply reduce the reference count, when the count is decremented to 0, the operating system performs disconnection operation tcp
2) After the client-side end close server does not close, will cause the client-side connection status is FIN_WAIT_2, server end of the connection state is CLOSE_WAIT
Normal program certainly not so treated, are generally in the exception process jumps (C ++ / JAVA, etc.) does not lead to close, or the entire system abnormality cause not close (e.g. JVM memory appears out of memory errors)
3) shutdown of the processing logic is more complex, non-special circumstances do not mess with, it is easy to go wrong
4) process exits the operating system will automatically recover socket, tcp closed process initiated operations