tcp 三次握手和四次断连深入分析:连接状态和socket API的关系
Posted zhchoutai
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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
[[email protected] ~]$ 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
[[email protected] ~]$ 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状态:
[[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显示CLOSE-WAIT状态
[[email protected]_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状态
[[email protected] 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显演示样例如以下:
[[email protected] ~]$ 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的处理逻辑比較复杂。非特殊情况不要乱用。非常easy出问题
4)进程退出后操作系统会自己主动回收socket。发起tcp关闭流程操作
以上是关于tcp 三次握手和四次断连深入分析:连接状态和socket API的关系的主要内容,如果未能解决你的问题,请参考以下文章