tcp协议状态(TCp是什么协议)

      最后更新:2023-05-18 08:12

      分析tcp协议原理

      原理四个主要方面:一、tcp协议之连接建立、断开二、tcp协议之超时重传三、tcp协议之窗口管理四、tcp协议之拥塞控制TCP是一种面向有连接的协议,也就是说必须确认对方存在时才能发送数据而TCP通过检验和、序列号、确认应答、重发控制、连接管理、窗口控制等机制来实现可靠传输。1. 目的:TCP三次握手是客户端和服务器总共发三个数据包,通过三个数据包来确认主动发送能力和被动接收能力是否正常。2. 实质:通过指定的四元组(源地址、源端口、目标地址、目标端口)来建立TCP连接,同步双方各自发送序列号seq和确认号ACK,同时也会交换窗口大小信息三次握手过程的实现方式就是交换序列号seq。随便在网上找个地址,如果通过域名想看ip地址,可以ping下看连接。① 192.168.3.7发送[SYN]报文段至222.169.228.146,告知序列号x为0。② 222.169.228.146发送[SYN,ACK]报文段至192.168.3.7,告知序列号y为0,确认号ACK为x+1=1。③192.168.3.7发送[ACK]报文段至222.169.228.146,告知确认号ACK为y+1=1。报文段中的其他参数:MSS=1460:允许从对方接收到的最大报文段,图中为1460字节(指承载的数据,不包含报文段的头部)。win=8192:滑动窗口的大小为8192字节。SACK_PERM=1:开启选择确认。为什么会使用SACK:tcp确认方式不是一段报文段一确认,而是采用累积确认方式。服务器接收到的报文段无序所以序列号也是不连续,服务器的接收队列会出现空洞情况。为了解决空洞,提前了解当前空洞,应对丢失遗漏,采取重传。提前了解方式就是通过SACK选项信息,SACK信息包含接收方已经成功接收的数据块的序列号范围。而SACK_PERM字段为1表明,选择开启了SACK功能。网络层可能会出现丢失、重复、乱序的问题,tcp是提供可靠的数据传输服务的,为了保证数据的正确性,tcp协议会重传它认为的已经丢失的包。重传两种机制:一种基于时间重传,一种基于确认报文段提供的信息重传。RTT:数据完全发送完(完成最后一个比特推送到数据链路上)到收到确认信号的时间(往返时间)。RTO:重传超时时间(tcp发送数据时设置一个计时器,当计时器超时没有收到数据确认信息,引发超时而重传,判断的标准就是RTO)。思考:发送序列号为1、2、3、4这4个报文段,但是出现了序列号2报文段丢失,怎么办?发送端接收到seq1的确认报文(ACK=2)后,等待seq=2的确认报文。接收端当收到序列号为3的报文(2已丢失),发送ack为4的确认报文,发送端正等待ack为2的确认报文,面对跳跃的报文,那么发送端会一直等待,直到超出指定时间,重传报文2。为什么不跳跃确认呢?tcp是累积确认方式,如果确认报文3,那么意味着报文1和报文2都已经成功接收。超时处理方式:思考:上面计时器是以时间为标准重传,那么可以通过确认报文的次数来决定重传。发送端接收到seq1的确认报文(ACK=2)后,等待seq=2的确认报文。接收端收到报文3、4、5,但是没收到报文2,那么接收端发送三个ACK为2的确认报文,发送端收到这个三个确认报文,重传报文2。思考:如果快速重传中丢失包的地方很多(报文2,报文,7,报文9,报文30,报文300....),那么需要从头到尾都重传,这很蛋疼?思考:SACK重传对于接收到重复数据段怎样运作没有明确规定,通过DSACK重传可以让发送方知道哪些数据被重复接收了,而且明确是什么原因造成的。发送端没有收到100-199的ACK包,超过指定时间,重传报文。接收端都已经收到200-299的发送报文了,又来100-199是重复报文。再向发送端发送一个ACK报文,设置SACK 100-199,告知发送端,已经收到了100-199包,只是回应ACK包丢失。发送端发送包100-199,由于网络延迟,一直没有达到接收端。接收端连续发送三个ACK 200确认报文,触发快速重传,发送端收到了ACK 500的确认报文,表明之前的报文都已经交付成功。接收端又收到了延迟的报文100-199,再次向发送端发送一个SACK 100-199的ACK 500报文。发送端发现这是重复报文,判断为网络延迟造成的。计时器重传:根据超时,重传。快速重传:根据接收三次相同ACK报文,重传。选择确认重传:根据接收端提供的SACK信息,重传。DSACK重传:根据重复报文,明确丢失ACK报文还是网络延迟。Category1:已发送且已确认(已经收到ACK报文的数据)。Category2:已发送但未收到确认。Category3:即将发送。Category4:窗口移动前都不能发送。可用窗口:46-51字节。发送窗口:32-51字节。RCV.NXT:左边界RCV.WND:接收窗口RCV.NXT+RCV.WND:右边界接收端接收到序列号小于左边界,那么被认为重复数据而被丢弃。接收端接收到序列号大于右边界,那么被认为超出处理范围,丢弃。注意:tcp协议为累积ACK结构,只有当达到数据序列号等于左边界时,数据才不会被丢弃。如果窗口更新ACK丢失,对于发送端,窗口左边界右移,已发送数据得到ACK确认之后,左右边界距离减小,发送端窗口会减小,当左右边界相等时,称为零窗口。零窗口之后:接收端发送窗口更新能会发生窗口更新ACK丢失。<>解释:TCP是通过接收端的通告窗口来实现流量控制的,通告窗口指示了接收端可接收的数据量。当窗口值变为0时,可以有效阻止发送端继续发送,直到窗口大小恢复为非零值。当接收端重新获得可用空间时,会给发送端传输一个窗口更新告知其可继续发送数据。这样的窗口更新通常都不包含数据(纯ACK),接收端向发送端发送的窗口更新ACK可能丢失。结果双方处于等待状态,发生死锁。解决方案:发送端会采用一个持续计时器间歇性地查询接收端,看其窗口是否已增长。触发窗口探测,强制要求接收端返回ACK。发送几次探测,窗口大小还是0,那么断开连接。出现SWS的情况:① 接收端通告窗口太小。② 发送端发送的数据太小。解决方案:① 针对接收端:不应通告小窗口值[RFC1122]描述:在窗口可增至一个全长的报文段(接收端MSS)或者接收端缓存空间的一半(取两者中较小值)之前,不能通告比当前窗口更大的窗口值。标准:min(MSS , 缓存空间/2)。② 针对发送端:不应发送小的报文至少满足以下其一:(1)可以发送MSS字节的报文。window size >= MSS或者 数据大小>=MSS(2)数据段长度>=接收端通告过的最大窗口值的一半,才可以发送。收到之前发送的数据的ack回包,再发送数据,否则一直攒数据。(3) -1 没有未经确认的在传数据或者-2 连接禁用Nagle算法。tcp基于ACK数据包中的通告窗口大小字段实现了流量控制。当网络大规模通信负载而瘫痪,默认网络进入拥塞状态,减缓tcp的传输。发送方和接收方被要求承担超负荷的通信任务时,采取降低发送速率或者最终丢弃部分数据的方法。反映网络传输能力的变量称为拥塞窗口(cwnd)。通告窗口(awnd)。发送窗口swnd=min(cwnd,awnd)目的:tcp在用拥塞避免算法探寻更多可用带宽之前得到cwnd值,帮助tcp建立ACK时钟。[RFC5681] :在传输初始阶段,由于未知网络传输能力,需要缓慢探测可用传输资源,防止短时间内大量数据注入导致拥塞。慢启动算法针对这一问题而设计。在数据传输之初或者重传计时器检测到丢包后,需要执行慢启动。拥塞窗口值:每收到一个ACK值,cwnd扩充一倍。所以假设没有丢包且每个数据包都有相应ACK值,在k轮后swnd=,成指数增长。SMSS是发送方的最大段大小。慢启动阶段,cwnd会指数增长,很快,帮助确立一个慢启动阙值(ssthresh)。有了阙值,tcp会进入拥塞避免阶段,cwnd每次增长值近似于成功传输的数据段大小,成线性增长。实现公式:cwnd+=SMSS*SMSS/cwnd刚建立连接使用慢启动算法,初始窗口为4,收到一次ACK后,cwnd变为8,再收到一次ACK后,cwnd变为16,依次继续,32、64,达到阙值ssthresh为64。开始使用拥塞避免算法,设置ssthresh为ssthresh/2,值为32。重新从初始窗口4,线性递增到ssthresh=32。当cwnd < ssthresh时,使用慢启动算法当cwnd > ssthresh时,使用拥塞避免算法应用快速恢复算法时机:启动快速重传且正常未失序ACK段达到之前。启动快速恢复算法。实现过程:① 将ssthresh设置为1/2 cwnd,将cwnd设置为ssthresh+3*SMSS。② 每接收一个重复ACK,cwnd值暂时增加1 SMSS。③当接收到新数据ACK后,将cwnd设置为ssthresh。参考:<>
      分析tcp协议原理

      什么是TCP协议,它的主要特点是什么

      TCP/IP协议是现在互联网的基础。TCP/IP协议主要有如下的特点。 1、TCP/IP协议是一个开放的协议标准,所有人都可以免费试用,并且是独立于硬件和操作系统的。2、TCP/IP协议是不区分网络硬件的,它在局域网,广域网和互联网中都被广泛使用。3、TCP/IP协议使用统一的网络地址分配的方案。网络中的每台电脑都具有唯一的IP地址。 4、TCP/IP协议是一个标准的高层协议,拥有极高的可靠性,可以为用户提供可靠的服务。
      TCP/IP协议是现在互联网的基础。TCP/IP协议主要有如下的特点。 1、TCP/IP协议是一个开放的协议标准,所有人都可以免费试用,并且是独立于硬件和操作系统的。2、TCP/IP协议是不区分网络硬件的,它在局域网,广域网和互联网中都被广泛使用。3、TCP/IP协议使用统一的网络地址分配的方案。网络中的每台电脑都具有唯一的IP地址。 4、TCP/IP协议是一个标准的高层协议,拥有极高的可靠性,可以为用户提供可靠的服务。
      TCP/IP协议bai是du现在互联网的基础。TCP/IP协议主要有如下的特点zhi。 1、TCP/IP协议是一个开放dao的协议标准,所有人zhuan都可以免费shu试用,并且是独立于硬件和操作系统的。2、TCP/IP协议是不区分网络硬件的,它在局域网,广域网和互联网中都被广泛使用。3、TCP/IP协议使用统一的网络地址分配的方案。网络中的每台电脑都具有唯一的IP地址。 4、TCP/IP协议是一个标准的高层协议,拥有极高的可靠性,可以为用户提供可靠的服务。
      什么是TCP协议,它的主要特点是什么

      TCP状态转换图、TCP连接3次握手4次挥手

      两将军问题:红蓝两军作战,蓝军战斗力强大,红1军或红2军与其单独作战都打不过蓝军,所以需要红一军与红二军联合对蓝军发起进攻,红军1首先通知红军2明早10点发起总攻,如图1-1,红军2接到消息需要回复“好的红军1,我已经收到你得消息,确认明早10点发动总攻”。因为消息传递路线必须经过蓝军营地,所以双方传递消息的信使很有可能被蓝军俘获。为了确保消息的可靠性,红1、红2双方在发出一个消息之后都想得到对方的消息回执。但是这会导致消息无线循环下去,如图1-2。那么如何解决这个可靠性的问题呢,其实没有办法解决,只要保证双方各自都有一次成功的发送、回执就可以了。两将军问题也存在网络世界里,客户端、服务器建立连接不可能无限的确认下去,只要保证客户端和服务器分别对自己的收、发能力做一次确认即可,如下图。 客户端和服务器分别对自己的收、发能力做一次确认至少需要3次握手。3次握手的具体过程、状态如下:(1)首先客户端和服务器都处于CLOSED状态。(2)服务器处于LISTEN状态,具体为服务器调用Socket、bind、listen函数,进入阻塞状态。(3)客户端发送SYN(同步序列编号),发送完毕客户端进入SYN_SENT状态。(4)服务端收到SYN,发送SYN+ASK,发送完毕进入SYN_RCVD状态。(5)客户端收到服务端发来的SYN+ASK,发送服务端等待的ASK,发送完毕客户端进入ESTABLISHED状态,准备数据传输,到此客户端已经满足了对自己收发能力的一次验证。(6)服务端收到客户端发来的ASK,与客户端一样,到此服务端也已经满足了对自己收发能力的一次验证,所以也进入ESTABLISHED状态,准备数据传输。(7)准备开始传输数据TCP断开连接有两种情况或者说是场景,1 客户端先断开连接,当然也可能是服务器先断开连接,总之是一前一后。 2 双方同时发起断开连接操作。下面分别介绍两种场景:(1)客户端先发起断开连接操作,客户端向服务端发送FIN,发送完毕客户端进入FIN_WAIT_1状态。(2)服务端收到客户端发来的FIN,服务端发送ACK,发送完毕进入CLOSED_WAIT状态。(3)客户端收到服务端的ACK回复,客户端进入FIN_WAIT_2状态,如果后面服务端没有回应客户端,在TCP协议层面来讲,客户端将永远停留在这个状态了,不过还好,操作系统着这块做了处理,有一个超时时间。(4)此时TCP连接进入半关闭状态,即客户端主,服务端从的这条线路已经关闭,不过服务端主,客户端从的这条线路还处于打开状态。(5)服务端向客户端发送FIN,发送完毕,服务端进入LAST_ASK状态。(6)客户端收到服务端的FIN后回复服务端ACK,回复完毕进入TIME_WAIT状态,为什么要进入这个状态?因为第6步是客户端的最后一条回复,服务端很有可能收不到,收不到服务端就会重发,所以客户端还要等待一会。(7)服务端收到客户端的ACK回复之后,不再做响应,回到初始的CLOSED状态,在连接池中等待下一次的复用。(8)客户端保持TIME_WAIT状态,超时之后同样进入CLOSED状态。场景二(1)客户端、服务器双方同时发送FIN,双方同时进入FIN_WAIT_1状态(2)双方都接到了对方的ACK,此时双方都会进入CLOSING状态。(3)双方同时进入TIME_WAIT状态,为什么要进入这个状态而不是直接进入CLOSED状态呢?假设客户端和服务端本次是第X次建立连接、关闭连接。如果立即关闭,随后建立第X+1次连接,建立连接成功之后,第X次的丢包的数据有可能绕了一大圈又回来了,那就会出现数据错误,为了避免这种情况所以要进入TIME_WAIT状态,以保证旧连接的数据不会再回来。(4)TIME_WAIT超时之后,双双进入CLOSED状态。有了上面对TCP连接3次握手4次挥手的介绍,再来理解TCP的状态图就不困难了,无非就是对TCP连接3次握手4次挥手过程的打包概述而已。
      TCP状态转换图、TCP连接3次握手4次挥手

      图文并茂,讲解TCP和UDP协议的原理以及区别

      最近重新认知了一下TCP和UDP的原理以及区别,做一个简单的总结。首先,tcp和udp都是工作在传输层,用于程序之间传输数据的。数据一般包含:文件类型,视频类型,jpg图片等。TCP是基于连接的,而UDP是基于非连接的。tcp传输数据稳定可靠,适用于对网络通讯质量要求较高的场景,需要准确无误的传输给对方,比如,传输文件,发送邮件,浏览网页等等udp的优点是速度快,但是可能产生丢包,所以适用于对实时性要求较高但是对少量丢包并没有太大要求的场景。比如:域名查询,语音通话,视频直播等。udp还有一个非常重要的应用场景就是隧道网络,比如:VXLAN以人与人之间的通信为例:UDP协议就相当于是写信给对方,寄出去信件之后不能知道对方是否收到信件,信件内容是否完整,也不能得到及时反馈,而TCP协议就像是打电话通信,在这一系列流程都能得到及时反馈,并能确保对方及时接收到。如下图:tcp是如何保证以上过程的?分为三个步骤:三次握手,传输确认,四次挥手。三次握手是建立连接的过程。当客户端向服务端发起连接时,会先发一包连接请求数据,过去询问一下,能否与你建立连接?这包数据称之为SYN包,如果对端同意连接,则回复一包SYN+ACK包,客户端收到之后,发送一包ACK包,连接建立,因为这个过程中互相发送了三包数据,所以称之为三次握手。这是为了防止,因为已失效的请求报文,突然又传到服务器,引起错误,这是什么意思?假设采用两次握手建立连接,客户端向服务端发送一个syn包请求建立连接,因为某些未知的原因,并没有到达服务器,在中间某个网络节点产生了滞留,为了建立连接,客户端会重发syn包,这次的数据包正常送达,服务端发送syn+ack之后就建立起了连接。但是第一包数据阻塞的网络突然恢复,第一包syn包又送达到服务端,这时服务端会认为客户端又发起了一个新的连接,从而在两次握手之后进入等待数据状态,服务端认为是两个连接,而客户端认为是一个连接,造成了状态不一致,如果在三次握手的情况下,服务端收不到最后的ack包,自然不会认为连接建立成功。所以三次握手本质上来说就是为了解决网络信道不可靠的问题,为了在不可靠的信道上建立起可靠的连接,经过三次握手之后,客户端和服务端都进入了数据传输状态。一包数据可能会被拆成多包发送,如何处理丢包问题,这些数据包到达的先后顺序不同,如何处理乱序问题?针对这些问题,tcp协议为每一个连接建立了发送缓冲区,从建立链接后的第一个字节的序列号为0,后面每个字节的序列号就会增加1,发送数据时,从数据缓冲区取一部分数据组成发送报文,在tcp协议头中会附带序列号和长度,接收端在收到数据后需要回复确认报文,确认报文中的ack等于接受序列号加长度,也就是下包数据发送的起始序列号,这样一问一答的发送方式,能够使发送端确认发送的数据已经被对方收到,发送端也可以发送一次的连续的多包数据,接受端只需要回复一次ack就可以了。如图:六、四次挥手:处于连接状态的客户端和服务端,都可以发起关闭连接请求,此时需要四次挥手来进行连接关闭。假设客户端主动发起连接关闭请求,他给服务端发起一包FIN包,标识要关闭连接,自己进入终止等待1装填,服务端收到FIN包,发送一包ACK包,标识自己进入了关闭等待状态,客户端进入终止等待2状态,这是第二次挥手,服务端此时还可以发送未发送的数据,而客户端还可以接受数据,待服务端发送完数据之后,发送一包FIN包,最后进入确认状态,这是第3次挥手,客户端收到之后恢复ACK包,进入超时等待状态,经过超时时间后关闭连接,而服务端收到ACK包后,立即关闭连接,这是第四次挥手。为什么客户端要等待超时时间?这是为了保证对方已经收到ACK包,因为假设客户端发送完最后一包ACK包后释放了连接,一旦ACK包在网络中丢失,服务端将一直停留在 最后确认状态,如果等待一段时间,这时服务端会因为没有收到ack包重发FIN包,客户端会响应 这个FIN包进行重发ack包,并刷新超时时间,这个机制跟第三次握手一样。也是为了保证在不可靠的网络链路中进行可靠的连接断开确认。udp:首先udp协议是非连接的,发送数据就是把简单的数据包封装一下,然后从网卡发出去就可以了,数据包之间并没有状态上的联系,正因为udp这种简单的处理方式,导致他的性能损耗非常少,对于cpu,内存资源的占用也远小于tcp,但是对于网络传输过程中产生的丢包,udp并不能保证,所以udp在传输稳定性上要弱于tcp。所以,tcp和udp的主要区别:tcp传输数据稳定可靠,适用于对网络通讯质量要求较高的场景,需要准确无误的传输给对方。比如,传输文件,发送邮件,浏览网页等等,udp的优点是速度快,但是可能产生丢包,所以适用于对实时性要求较高但是对少量丢包并没有太大要求的场景。比如:域名查询,语音通话,视频直播等。udp还有一个非常重要的应用场景就是隧道网络,比如:VXLAN.
      图文并茂,讲解TCP和UDP协议的原理以及区别

      tcp连接状态详解

      unix的哲学是一切皆文件,可以把socket看成是一种特殊的文件,而一些socket函数就是对其进行的操作api(读/写IO、打开、关闭)。我们知道普通文件的打开操作(open)返回一个文件描述字,与之类似,socket()用于创建一个socket描述符(socket descriptor),它唯一标识一个socket。当我们调用socket创建一个socket时,返回的socket描述字它存在于协议族(address family,AF_XXX)空间中,但没有一个具体的地址。如果想要给它赋值一个地址,就必须调用bind()函数,sockfd即socket描述字,它是通过socket()函数创建了,唯一标识一个socket。bind()函数就是将给这个描述字绑定一个名字。在将一个地址绑定到socket的时候,需要先将主机字节序转换成为网络字节序,而不要假定主机字节序跟网络字节序一样使用的是Big-Endian。由于这个问题曾引发过不少血案,谨记对主机字节序不要做任何假定,务必将其转化为网络字节序再赋给socket。这里的主机字节序就是我们平常说的大端和小端模式:不同的CPU有不同的字节序类型,这些字节序是指整数在内存中保存的顺序,这个叫做主机序。引用标准的Big-Endian和Little-Endian的定义如下:listen函数的第一个参数即为要监听的socket描述字,第二个参数为socket可以接受的排队的最大连接个数。listen函数表示等待客户的连接请求。connect函数的第一个参数即为客户端的socket描述字,第二参数为服务器的socket地址,第三个参数为socket地址的长度。客户端通过调用connect函数来建立与TCP服务器的连接。TCP服务器端依次调用socket()、bind()、listen()之后,就会监听指定的socket地址了。TCP客户端依次调用socket()、connect()之后就向TCP服务器发送连接请求。TCP服务器监听到这个请求之后,就会调用accept()函数去接收请求,这样连接就建立好了(在connect之后就建立好了三次连接),之后就可以开始进行类似于普通文件的网络I/O操作了。如果accpet成功,那么其返回值是由内核自动生成的一个全新的描述字,代表与客户的TCP连接。accept的第一个参数为服务器的socket描述字,是服务器开始调用socket()函数生成的,称为监听socket描述字;而accept函数返回的是已连接的socket描述字。一个服务器通常通常仅仅只创建一个监听socket描述字,它在该服务器的生命周期内一直存在。内核为每个由服务器进程接受的客户连接创建了一个已连接socket描述字,当服务器完成了对某个客户的服务,相应的已连接socket描述字就被关闭。read函数是负责从fd中读取内容.当读成功时,read返回实际所读的字节数,如果返回的值是0表示已经读到文件的结束了,小于0表示出现了错误。如果错误为EINTR说明读是由中断引起的,如果是ECONNREST表示网络连接出了问题。write函数将buf中的nbytes字节内容写入文件描述符fd.成功时返回写的字节数。失败时返回-1,并设置errno变量。 在网络程序中,当我们向套接字文件描述符写时有俩种可能。1)write的返回值大于0,表示写了部分或者是全部的数据。2)返回的值小于0,此时出现了错误在服务器与客户端建立连接之后,会进行一些读写操作,完成了读写操作就要关闭相应的socket描述字,类似于操作完打开的文件要调用fclose关闭打开的文件。close一个TCP socket的缺省行为时把该socket标记为已关闭,然后立即返回到调用进程。该描述字不能再由调用进程使用,也就是说不能再作为read或write的第一个参数close操作只是使相应socket描述字的引用计数-1,只有当引用计数为0的时候,才会触发TCP客户端向服务器发送终止连接请求。我们知道tcp建立连接要进行“三次握手”,即交换三个分组。大致流程如下:客户端向服务器发送一个SYN J服务器向客户端响应一个SYN K,并对SYN J进行确认ACK J+1客户端再想服务器发一个确认ACK K+1socket中TCP的四次握手释放连接详解某个应用进程首先调用close主动关闭连接,这时TCP发送一个FIN M;另一端接收到FIN M之后,执行被动关闭,对这个FIN进行确认。一段时间之后,服务端调用close关闭它的socket。这导致它的TCP也发送一个FIN N;接收到这个FIN的源发送端TCP对它进行确认,这样每个方向上都有一个FIN和ACK。为什么要三次握手由于tcp连接是全双工的,存在着双向的读写通道,每个方向都必须单独进行关闭。当一方完成它的数据发送任务后就可以发送一个FIN来终止这个方向的连接。收到FIN只意味着这个方向上没有数据流动,但并不表示在另一个方向上没有读写,所以要双向的读写关闭需要四次握手,3. time_wait状态如何避免?首先服务器可以设置SO_REUSEADDR套接字选项来通知内核,如果端口忙,但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是,如果你的服务器程序停止后想立即重启,而新的套接字依旧希望使用同一端口,此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。1.客户端连接服务器的80服务,这时客户端会启用一个本地的端口访问服务器的80,访问完成后关闭此连接,立刻再次访问服务器的80,这时客户端会启用另一个本地的端口,而不是刚才使用的那个本地端口。原因就是刚才的那个连接还处于TIME_WAIT状态。2.客户端连接服务器的80服务,这时服务器关闭80端口,立即再次重启80端口的服务,这时可能不会成功启动,原因也是服务器的连接还处于TIME_WAIT状态。实战分析:状态描述:CLOSED:无连接是活动的或正在进行LISTEN:服务器在等待进入呼叫SYN_RECV:一个连接请求已经到达,等待确认SYN_SENT:应用已经开始,打开一个连接ESTABLISHED:正常数据传输状态FIN_WAIT1:应用说它已经完成FIN_WAIT2:另一边已同意释放ITMED_WAIT:等待所有分组死掉CLOSING:两边同时尝试关闭TIME_WAIT:另一边已初始化一个释放LAST_ACK:等待所有分组死掉命令解释:如何尽量处理TIMEWAIT过多?编辑内核文件/etc/sysctl.conf,加入以下内容:net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。net.ipv4.tcp_fin_timeout 修改系默认的 TIMEOUT 时间然后执行 /sbin/sysctl -p 让参数生效./etc/sysctl.conf是一个允许改变正在运行中的Linux系统的接口,它包含一些TCP/IP堆栈和虚拟内存系统的高级选项,修改内核参数永久生效。简单来说,就是打开系统的TIMEWAIT重用和快速回收。本文主要讲述了socket的主要api,以及tcp的连接过程和其中各个阶段的连接状态,理解这些是更深入了解tcp的基础!
      tcp连接状态详解

      本文由 在线网速测试 整理编辑,转载请注明出处。

          热门文章

          文章分类