TCP连接状态变化

文章转自:TCP连接状态变化

TCP连接状态变化

参考文章:TCP连接的状态详解以及故障排查

TCP建立连接——三次握手

CLOSED:起始状态,无任何连接。

LISTEN:服务端建立socket之后需要listen进入LISTEN(侦听)模式,侦听来自远方的TCP连接请求。

SYN_SENT:客户端建立socket之后需要connect服务器,向服务端发送SYN=j(随机数)申请连接,然后会进入SYN_SENT状态。

SYN_RCVD:服务端在** 侦听模式 **下收到SYN后会向客户端回应ACK=j+1,同时发送SYN=k,然后进入SYN_RCVD状态。

ACK是确认标志,可以附带进别的消息中,将ACK附带进SYN中,所以只发送一个SYN/ACK。具体可以自行搜索,参考:TCP的确认系列——发送状态转换机

ESTABLISHED:客户端收到ACK后进行验证,同时回应服务端发来的SYN,返回ACK=k+1,然后进入ESTABLISHED状态。服务端收到最后一个ACK后验证,然后进入ESBABLESHED。表示双方的连接建立完成,可以进行数据传输。

还有一种少见的建立连接的方式,不分服务端与客户端,两端同时发起连接,后面会给出一篇文章链接TCP的连接和释放,里面有提到。


TCP断开连接——四次挥手

一般由客户端主动断开连接,服务端只做被动连接。但是如果有必要,服务端也可主动断开连接。

FIN_WAIT_1:在ESTABLISHED(连接)状态下,主动断开连接会向对端发送FIN,然后进入FIN_WAIT_1状态。

CLOSED_WAIT:被动断开连接的一端收到FIN之后,会回应ACK,然后进入CLOSED_WAIT状态,在CLOSED_WAIT状态下,连接只能发送数据不能接收数据。

FIN_WAIT_2:主动断开连接的一端收到FIN的ACK回应后会进入FIN_WAIT_2状态。此时无法再发送数据但是可以接受数据。

LAST_ACK:被动断开连接的一端在缓冲区数据发送完成后会发送FIN然后进入LAST_ACK状态。如果程序健壮性较差,在socket收到文件结束符之后没有关闭socket,此处不会发出FIN,导致连接停留在CLOSED_WAIT&FIN_WAIT_2状态。

TIME_WAIT:主动断开连接的一端在收到对端的FIN后回应ACK然后进入TIME_WAIT。此状态下连接已断开,但为了避免最后一个ACK在网络中迷路,而导致的状态紊乱,端口会被保留2*MSL的时长。

MSL(Maximum Segment Lifetime)——参考:什么是2MSL

CLOSED:在TIME_WAIT状态停留时间达到2*MSL之后进入CLOSED状态,表示无任何连接。

还有一种少见的断开连接的方式,两边同时主动断开连接,在这种情况下会有有一种其他状态——CLOSING状态,后面的文章链接TCP的连接和释放,里面有提及。


这篇文章有提及同时发起连接和同时断开连接的状态变换:TCP的连接和释放

原文地址:https://www.cnblogs.com/liqingwang/p/10172481.html

时间: 2024-10-17 00:26:49

TCP连接状态变化的相关文章

TCP连接的状态详解以及故障排查

转载自CSDN博客:http://blog.csdn.net/hguisu/article/details/38700899 TCP状态 TCP状态迁移路线图 TCP连接建立三次握手 TCP连接的终止四次握手释放 同时打开 同时关闭 TCP通信中服务器处理客户端意外断开 Linux错误信息errno列表 我们通过了解TCP各个状态,可以排除和定位网络或系统故障时大有帮助.(总结网络上的内容) 1.TCP状态 了解TCP之前,先了解几个命令:   linux查看tcp的状态命令: 1).netst

转载:TCP连接的状态详解以及故障排查

FROM:http://blog.csdn.net/hguisu/article/details/38700899 该博文的条理清晰,步骤明确,故复制到这个博文中收藏,若文章作者看到且觉得不能装载,麻烦请告知,谢谢. 我们通过了解TCP各个状态,可以排除和定位网络或系统故障时大有帮助.(总结网络上的内容) 1.TCP状态 linux查看tcp的状态命令: 1).netstat -nat  查看TCP各个状态的数量 2).lsof  -i:port  可以检测到打开套接字的状况 3).  sar

TCP连接的建立和终止

一.TCP连接建立(正常情况) 三次握手 (three-way handshake) 请求端发送一个SYN段指明客户端打算建立连接的服务器端口,以及初始序号 (ISN) 服务器发回包含服务器的初始序号的SYN报文段作为应答.同时,将确认序号设置为客户端的ISN加1以对客户的SYN报文段加以确认.一个SYN将占用一个序号. 客户端将确认序号设置为服务器的ISN加1以对服务器的SYN报文段进行确认. 发送第一个SYN字段的一端执行主动打开 (active open).接收SYN并发送下一个SYN的一

TCP 连接中的TIME_WAIT

原文:http://blog.csdn.net/wangpengqi/article/details/17245349 这就有个细节,一次http请求,谁会先断开TCP连接?什么情况下客户端先断,什么情况下服务端先断? 百度后,找到原因,主要有http1.0和http1.1之间保持连接的差异以及http头中connection.content-length.Transfer-encoding等参数有关: 当然,在nginx中,对于http1.0与http1.1也是支持长连接的.什么是长连接呢?我

如何在socket编程的Tcp连接中实现心跳协议

心跳包的发送,通常有两种技术 方法1:应用层自己实现的心跳包 由应用程序自己发送心跳包来检测连接是否正常,大致的方法是:服务器在一个 Timer事件中定时 向客户端发送一个短小精悍的数据包,然后启动一个低级别的线程,在该线程中不断检测客户端的回应, 如果在一定时间内没有收到客户端的回应,即认为客户端已经掉线:同样,如果客户端在一定时间内没 有收到服务器的心跳包,则认为连接不可用. 方法2:TCP的KeepAlive保活机制 因为要考虑到一个服务器通常会连接多个客户端,因此由用户在应用层自己实现心

解决不对称流量经过JUNIPER防火墙,tcp连接重置丢失问题

背景:公司网络增加一台JUNIPER防火墙,用于外网网关使用,其实配置上网配置很简单,配置完成后,外网连接测试也都正常,但在特殊的测试环境中会出现一种情况,该环境如图所示: 现象:当PC机的网关指定为防火墙的内网接口后(而不是核心交换机地址),当pc在telnet或者ssh连接10.10.2.*网段的服务器(网关在核心交换机上)等时,tcp连接均会在20s后重置.我的环境中其实存在一些问题的,就是流经防火墙的流量并不对称,其中pc→服务器的流量经过防火墙,而服务器→pc的流量不经过防火墙,造成的

TCP连接状态及TIME_WAIT

参考: TCP连接中的TIME_WAIT状态 - sunnydogzhou的专栏 - 博客频道 - CSDN.NET http://blog.csdn.net/sunnydogzhou/article/details/6572071 TCP连接状态详解及TIME_WAIT过多的解决方法_小强_新浪博客 http://blog.sina.com.cn/s/blog_8e5d24890102w9yi.html TCP协议三次握手连接四次握手断开和DOS攻击 - NowOrNever - 博客频道 -

TCP连接检测机制

采用TCP连接的C/S模式软件,连接的双方在连接空闲状态时,如果任意一方意外崩溃.当机.网线断开或路由器故障,另一方无法得知TCP连接已经失效,除非继续在此连接上发送数据导致错误返回.很多时候,这不是我们需要的.我们希望服务器端和客户端都能及时有效地检测到连接失效,然后优雅地完成一些清理工作并把错误报告给用户. 客户端采用如下步骤: 1, 连接 2, 拔掉网线 经过以上两步: 从上图中可以看到,此时服务端的连接依然存在. 所以,tcp只是数据的发送与接收,包括握手,断开以及rst,time_wa

服务器后台TCP连接存活问题

0. 背景 公司的服务器后台部署在某一个地方,接入的是用户的APP,而该地方的网络信号较差,导致了服务器后台在运行一段时间后用户无法接入,那边的同事反馈使用netstat查看系统,存在较多的TCP连接. 1. 问题分析 首先在公司内部测试服务器上部署,使用LoadRunner做压力测试,能正常运行,然后那边的同事反馈该地方信号较差.考虑到接入的问题,有可能接入进程的FD资源耗尽,导致accept失败.推论的依据是对于TCP连接来说,如果客户端那边由于一些异常情况导致断网而未能向服务器发起FIN关