TCP连接(client、server)状态转换

 客户端状态的变化:

客户端创建套接字之后会connect服务器,这时客户端会发送一个SYN到服务器,状态转换到SYN_SENT并等待服务器的回复,收到服务端的回复SYN+ACK(同一个报文)之后???客户端会回复ACK此时状态转换到ESTABLISHED,正常数据交互完成之后客户端会close套接字此时发送一个FIN报文,状态转换到FIN_WAIT_1,同时等待服务端的回复,此时有三种情况:

(1)收到服务端的ACK但此时服务端没有关闭套接字。状态转换到了FIN_WAIT_2,然后再等待服务端关闭套接字发出的FIN,如果收到则回复ACK,状态转换到TIME_WAIT状态,等待2MSL超时之后自动转换为CLOSED状态。

?(2)服务端同时也在关闭套接字,此时客户端会收到SYN并发出ACK,状态转换到CLOSING,之后等待服务端回复ACK,若收到ACK则转到TIME_WAIT状态。

(3)服务器在收到客户端FIN之后立马关闭套接字,此时客户端会收到一个ACK和FIN并发出ACK,状态?转换到TIME_WAIT状态。

服务器状态的变化:

服务端?创建套接字之后调用listen函数将套接字有一个未连接的主动套接字转换为被动套接字,指示内核应接受指向该套接字的连接请求,套接字状态由CLOSE转换为LISTEN,等待客户端连接。所以服务端是被动接收连接的,服务端会先收到SYN,收到之后会立马发送一个SYN+ACK(同一个报文),此时状态转换到SYN_RCVD并等待客户端回复ACK,此时套接字处于未完成连接队列中,如果收到ACK状态会转换到ESTABLISHED,套接字处于已完成连接队列中,注意的是未完成连接队列和已完成连接队列之和不能超过listen设置的最大连接个数。这时服务端和客户端可以进行数据交互,客户端接收完数据之后主动close套接字,此时服务端会收到FIN并回复ACK,状态转换到LOSE_WAIT,当服务端的应用层也close套接字时服务端会发生一个FIN状态转换到LAST_ACK然后会收到客户端回复的ACK,状态转换到CLOSED。

为什么释放连接需要TIME_WAIT?

回忆一下我们最终的那个FIN与ACK,被动关闭方发送FIN,并等待主动关闭方返回的ACK。我们假设最终的ACK丢失,被动关闭方将需要重新发送它的最终那个FIN,主动关闭方必须维护状态信息(TIME_WAIT),以允许它重发最终的那个ACK。如果没有了这个状态,当他第二次收到FIN时,会响应一个RST(也是一种类型的TCP分节),会被服务器解释成一个错误。

目的:为了TCP打算执行必要的工作以彻底终止某个连接两个方向上的数据流(即全双工关闭),那么他必须要正确处理连接终止四个分节中任何一个分节丢失的情况

处于TIME_WAIT这个状态时,此套接字上的绑定了资源,将在2MSL(最大报文生存时间)内不可再使用。选择2MSL这个时间是为了避免出现上一次连接中被动关闭端重复发送的数据包。

我们假设ip1:port1和ip2:port2 之间有一个TCP连接。我们关闭了这个链接,过一段时间后在相同IP和端口之间建立了另一个连接。TCP必须防止来自之前那个连接的老的重复分组在新连接上出现。为了做到这一点,TCP将不复用处于TIME_WAIT状态的连接。2MSL的时间足以让某个方向上的分组存活MSL秒后被丢弃,另一个方向上的应答也最多存活MSL秒后被丢弃。

原文地址:https://www.cnblogs.com/single-dont/p/11386241.html

时间: 2024-10-10 06:04:26

TCP连接(client、server)状态转换的相关文章

tcp连接出现close_wait状态?可能是代码不够健壮

一.问题概述 今天遇到个小问题. 我们的程序依赖了大数据那边的服务,大数据那边提供了restful接口供我们调用. 测试反映接口有问题,我在本地重现了.找了大数据方的同事,解决了. 刚开始怕对方不认账,就用wireshark抓包了.没想到对方还挺爽快地解决了. 然后我这边重新测试,自己抓包了下,结果反而发现我方程序的一个问题. 下图,是我方和大数据方的交互数据包. 前三个为tcp连接建立,中间(序号4,5,6)为http请求响应,序号7-8为大数据方在请求完毕后关闭连接. 好了,看下面的图:(下

TCP/IP详解--TCP连接中TIME_WAIT状态过多

转载自http://blog.csdn.net/yusiguyuan/article/details/21445883 TIMEWAIT状态本身和应用层的客户端或者服务器是没有关系的.仅仅是主动关闭的一方,在使用FIN|ACK|FIN|ACK四分组正常关闭TCP连接的时候会出现这个TIMEWAIT.服务器在处理客户端请求的时候,如果你的程序设计为服务器主动关闭,那么你才有可能需要关注这个TIMEWAIT状态过多的问题.如果你的服务器设计为被动关闭,那么你首先要关注的是CLOSE_WAIT. 原则

TCP连接的状态与关闭方式及其对Server与Client的影响

1. TCP连接的状态 首先介绍一下TCP连接建立与关闭过程中的状态.TCP连接过程是状态的转换,促使状态发生转换的因素包括用户调用.特定数据包以及超时等,具体状态如下所示: CLOSED:初始状态,表示没有任何连接.LISTEN:Server端的某个Socket正在监听来自远方的TCP端口的连接请求.SYN_SENT:发送连接请求后等待确认信息.当客户端Socket进行Connect连接时,会首先发送SYN包,随即进入SYN_SENT状态,然后等待Server端发送三次握手中的第2个包.SYN

TCP连接的状态与关闭方式,及其对Server与Client的影响

1. TCP连接的状态 首先介绍一下TCP连接建立与关闭过程中的状态.TCP连接过程是状态的转换,促使状态发生转换的因素包括用户调用.特定数据包以及超时等,具体状态如下所示: CLOSED:初始状态,表示没有任何连接. LISTEN:Server端的某个Socket正在监听来自远方的TCP端口的连接请求. SYN_SENT:发送连接请求后等待确认信息.当客户端Socket进行Connect连接时,会首先发送SYN包,随即进入SYN_SENT状态,然后等待Server端发送三次握手中的第2个包.

20160402_TCP连接的建立、终止和状态转换

原题: 以下不属于tcp连接断开的状态是? TIME_WAIT FIN_WAIT_1 SYNC_SENT FIN_WAIT_2 答案:SYNC_SENT -------------------------------------------------------------------------------- 本题知识点:计算机网络 TCP连接的建立:     下述步骤建立一个TCP连接:    1.服务器必须准备好接受外来的连接.这通过调用socket.bind和listen函数来完成,称

tcp连接状态以及netstat命令

tcp是可靠的数据传输协议,相对于udp来说,基于udp的通信速度更快,但是没有数据的完整性的保证,更重要的是udp不会保证数据是否到达了目的方. TCP协议建立的tcp连接是有状态的,称之为tcp的有限状态机 SYN_SENT:主动建立连接的一方发起连接建立请求,也就是SYN=1,当发出同步位,状态转换位SYN_SENT SYN_RCVD:服务器端收到了客户端发送的同步报文,按照tcp协议的规定,回复ACK报文同时SYN位至1,此时服务器的状态转换为SYN_RCVD ESTABLISHED:当

TCP/IP协议--TIME_WAIT状态存在的原因

1. 实际问题         初步查看发现,无法对外新建TCP连接时,线上服务器存在大量处于TIME_WAIT状态的TCP连接(最多的一次为单机10w+,其中引起报警的那个模块产生的TIME_WAIT约2w),导致其无法跟下游模块建立新TCP连接. TIME_WAIT涉及到TCP释放连接过程中的状态迁移,也涉及到具体的socket api对TCP状态的影响,下面开始逐步介绍这些概念. 2. TCP状态迁移        面向连接的TCP协议要求每次peer间通信前建立一条TCP连接,该连接可抽

TCP连接中time_wait在开发中的影响-搜人以鱼不如授之以渔

根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的

TCP连接

#xiaodeng #TCP连接 #HTTP权威指南 83 #HTTP连接时HTTP报文传输的关键通道.编写http应用程序的程序员需要理解http连接的来龙去脉及如何使用这些连接. #TCP连接: #世界上几乎所有的http通信都是tcp/ip承载.客户端应用横须可以打开一条tcp/ip连接,连接到可能运行在世界任何地方的服务器应用程序.一旦连接建立起来,在客户端和服务器的计算机之间交换的报文就不会丢失. #如:http://www.joes-hardware.com:80/power-too

网络基础---TCP连接

TCP协议原理:TCP每发送一个报文段,就启动一个定时器,如果在定时器超时之后还没有收到ACK确认,就重传该报文. 如图所示,数据包由A的缓冲区发往B,B在收到数据包以后,回发一个ACK确认包给A,之后A将该数据包从缓冲区释放.因此,该数据包会一直缓存在A的缓冲区,直到一个ACK确认为止. 在TCP/IP协议中,TCP协议提供可靠的面向连接的服务:三次握手(建立连接)和四次挥手(关闭连接):使用滑动窗口机制进行流量控制: 三次握手的详细图解 所谓三次握手(Three-way Handshake)