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 


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显示如下:

[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关闭流程操作






相关文章
|
7天前
|
存储 数据挖掘 API
购物平台数据抓取实战指南:从API到深度分析
本指南介绍如何通过API接口抓取淘宝、京东、拼多多等电商平台的数据,涵盖API选择、注册配置、数据抓取与处理、深度分析等内容,帮助企业和开发者挖掘数据价值,支持市场分析和决策制定。
|
10天前
|
安全 API 数据安全/隐私保护
商品详情API接口的优势分析与应用价值
在数字化时代,商品详情API接口为商家和开发者提供了实时更新、高效集成、丰富功能、安全稳定、易于扩展及提升用户体验的解决方案,助力提高运营效率、降低成本并增强市场竞争力。
|
23天前
|
JSON JavaScript API
(API接口系列)商品详情数据封装接口json数据格式分析
在成长的路上,我们都是同行者。这篇关于商品详情API接口的文章,希望能帮助到您。期待与您继续分享更多API接口的知识,请记得关注Anzexi58哦!
|
1月前
|
网络协议 Linux 网络性能优化
Linux基础-socket详解、TCP/UDP
综上所述,Linux下的Socket编程是网络通信的重要组成部分,通过灵活运用TCP和UDP协议,开发者能够构建出满足不同需求的网络应用程序。掌握这些基础知识,是进行更复杂网络编程任务的基石。
66 1
|
26天前
|
API 数据安全/隐私保护 开发者
淘宝 API:关键词搜商品列表接口,助力商家按价格销量排序分析数据
此接口用于通过关键词搜索淘宝商品列表。首先需在淘宝开放平台注册并创建应用获取API权限,之后利用应用密钥和访问令牌调用接口。请求参数包括关键词、页码、每页数量、排序方式及价格区间等。返回结果含总商品数量及具体商品详情。使用时需注意签名验证及官方文档更新。
|
3月前
|
存储 JavaScript 前端开发
探索React状态管理:Redux的严格与功能、MobX的简洁与直观、Context API的原生与易用——详细对比及应用案例分析
【8月更文挑战第31天】在React开发中,状态管理对于构建大型应用至关重要。本文将探讨三种主流状态管理方案:Redux、MobX和Context API。Redux采用单一存储模型,提供预测性状态更新;MobX利用装饰器语法,使状态修改更直观;Context API则允许跨组件状态共享,无需第三方库。每种方案各具特色,适用于不同场景,选择合适的工具能让React应用更加高效有序。
67 0
|
3月前
|
安全 API 网络安全
【Azure API 管理】APIM不能连接到 App Service (APIM cannot connect to APP service)
【Azure API 管理】APIM不能连接到 App Service (APIM cannot connect to APP service)
|
3月前
|
存储 Linux API
Linux源码阅读笔记08-进程调度API系统调用案例分析
Linux源码阅读笔记08-进程调度API系统调用案例分析
|
3月前
|
网络协议 Java
一文讲明TCP网络编程、Socket套接字的讲解使用、网络编程案例
这篇文章全面讲解了基于Socket的TCP网络编程,包括Socket基本概念、TCP编程步骤、客户端和服务端的通信过程,并通过具体代码示例展示了客户端与服务端之间的数据通信。同时,还提供了多个案例分析,如客户端发送信息给服务端、客户端发送文件给服务端以及服务端保存文件并返回确认信息给客户端的场景。
一文讲明TCP网络编程、Socket套接字的讲解使用、网络编程案例
|
2月前
|
网络协议 Linux
TCP 和 UDP 的 Socket 调用
【9月更文挑战第6天】