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
第3种情况：client调用connect + send，server调用了socket + bind + listen + accept + recv + send
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
server显示CLOSE-WAIT状态
[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状态
[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
server显示连接已经被关闭了。
关于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的处理逻辑比较复杂，非特殊情况不要乱用，很容易出问题
4）进程退出后操作系统会自动回收socket，发起tcp关闭流程操作