说到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
抓包结果显示:三次握手完成
使用ss工具去查看,client和server都显示estab
第3种情况:client调用connect + send,server调用了socket + bind + listen + accept + recv + send
抓包结果显示:三次握手完成,并且双方都可以发送和接受数据了
【连接过程总结】
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
抓包结果显示:client发送了fin包,server端应答了ack包
使用ss工具去查看,client显示fin_wait_2状态:
server显示close-wait状态
而且有一个值得注意的现象是:client的连接过一段时间就没有了,而server的连接一直处于close_wait状态
原因在于linux系统内核中有一个参数可以控制fin_wait_2的时间:tcp_fin_timeout
第2种情况:client调用close,server调用close
抓包结果显示:熟悉的四次断连来啦
使用ss工具去查看,client显示time-wait状态
server端使用ss工具去看已经看不到连接了
第3种情况:server端被kill了
咦,怎么会和正常的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显示如下:
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关闭流程操作