tcp 三次握手和四次断连深入分析：连接状态和socket API的关系

说到tcp协议，凡是略微看过的人都能顺口说出三次握手和四次断连。再牛逼的一点的就能够把每一个状态（SYNC_SENT、CLOSE_WAIT。

。。。

。。等）都能背出来，

而说道socket编程。基本上写过网络编程的人都会熟悉那几个标准的API：socket、connect、listen、accept。。。。

。。等

可是。我敢打赌非常少有人明确tcp状态和socket编程API之间的关系。不信？ 看看例如以下几个问题你是否知道吧：

1）什么时候客户端才干够连接上server端， 是server端调用bind后还是listen后还是accept后 ？

2）什么情况下会出现FIN_WAIT_2状态

。

。

。。。。

。。。。

。。

。。。

。。

。。。。

本周打破砂锅问究竟的精神以及实事求是的精神，我用python脚本写了一些脚本測试这些情况。看完后你一定会大呼过瘾，对tcp的协议和socket编程的理解又更上层楼。

注：下面測试是在Linux（2.6.18）平台上用python（2.7）脚本測试。其他平台没有測试。有兴趣能够自己測试一下。

【连接过程測试和验证】

第1种情况：client调用connect，server仅仅是调用了socket + bind，没有调用listen

tcpdump抓包例如以下：

抓包结果显示：server端直接回复了RST包

此时使用netstat或者ss命令去查看，不管是client还是server，都查不到连接

第2种情况：client调用connect，server调用了socket + bind + listen

tcpdump抓包例如以下：

抓包结果显示：三次握手完毕

使用ss工具去查看，client和server都显示ESTAB

[liyh@localhost ~]$ ss  -t -n | grep 50000
ESTAB      0      0                10.1.73.45:55354           10.1.73.76:50000 

tcpdump抓包例如以下：

抓包结果显示：三次握手完毕，并且两方都能够发送和接受数据了

使用ss工具去查看。client和server都显示ESTAB

[liyh@localhost ~]$ ss  -t -n | grep 50000
ESTAB      0      0                10.1.73.45:41363           10.1.73.76:50000 

1）能够看到，仅仅有当server端listen之后，client端调用connect才干成功，否则就会返回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状态：

[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

[jws@jae_test ~]$ ss  -t -n | grep 50000
CLOSE-WAIT 1      0                10.1.73.76:50000           10.1.73.45:47630 

原因在于Linux系统内核中有一个參数能够控制FIN_WAIT_2的时间：tcp_fin_timeout

第2种情况：client调用close。server调用close

tcpdump抓包例如以下：

抓包结果显示：熟悉的四次断连来啦

使用ss工具去查看。client显示TIME-WAIT状态

[liyh@localhost ipv4]$ ss -a -n | grep 50000
TIME-WAIT  0      0                10.1.73.45:39751           10.1.73.76:50000 

第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显演示样例如以下：

[liyh@localhost ~]$ ss -a | grep 50000
TIME-WAIT  0      0              10.1.73.45:45641           10.1.73.76:50000 

关于shutdown的详解能够參考：http://www.gnu.org/software/libc/manual/html_node/Closing-a-Socket.html

归纳一下SHUT_RD的处理：

1）client端不再接收数据，假设有新的数据到来。直接丢弃(reject)

2）没有发送不论什么tcp包，所以server端并不知道这个状态，server端能够继续发送数据。但因为1）的原因，发了也白发

归纳一下SHUT_WR或者SHUT_RDWR的处理：

1）停止传送数据（不能再调用write操作），丢弃缓冲区中未发送的数据（已调用write但底层tcp协议栈还没发送的）

2）停止等待已发送数据的确认消息，已发送未确认的数据不再重发

【断连过程总结】

1）close仅仅是降低socket文件的引用计数，当计数减为0后，操作系统运行tcp的断连操作

2）client端close后server端不close。会导致client端连接状态为FIN_WAIT_2，server端连接状态为CLOSE_WAIT

     正常编程肯定不会这样处理，一般都是在异常处理跳转（C++/JAVA等）导致没有close，或者整个系统异常导致没有close（例      如JVM内存出现out of memory错误）

3）shutdown的处理逻辑比較复杂。非特殊情况不要乱用。非常easy出问题

4）进程退出后操作系统会自己主动回收socket。发起tcp关闭流程操作