C/C++教程

TCP协议的四种计数器

本文主要是介绍TCP协议的四种计数器,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

TCP协议中有四种计时器(Timer),分别是:

  1.重传计时器:Retransmission Timer

  2.坚持计时器:Persistent Timer

  3.保活计时器:Keeplive Timer

  4.时间等待计时器:Timer_Wait Timer

1 重传计时器

  RTT:发送一个数据包到收到对应的 ACK,所花费的时间。

  RTO:定时器,重传时间间隔,没有回应 ACK 则等到 RTO 到期进行重传,根据 RTT 计算出来。

  带确认的重传机制可以保证TCP数据的可靠传输。在滑动窗口协议中,接受窗口会在连续收到的包序列中的最后一个包向接收端发送一个ACK,当网络拥堵的时候,发送端的数据包和接收端的ACK包都有可能丢失。TCP为了保证数据可靠传输,就规定在重传的“时间片”到了以后,如果还没有收到对方的ACK,就重发此包,以避免陷入无限等待中。

  当TCP发送报文段时,就创建该特定报文的重传计时器。可能发生两种情况:

  1)若在计时器截止时间到之前收到了对此特定报文段的确认,则撤销此计时器。

  2)若在收到了对此特定报文段的确认之前计时器截止时间到,则重传此报文段,并将计时器复位。

2 坚持计时器

  先来考虑一下情景:发送端向接收端发送数据包知道接受窗口填满了,然后接受窗口告诉发送方接受窗口填满了停止发送数据。此时的状态称为“零窗口”状态,发送端和接收端窗口大小均为0。直到接受TCP发送确认并宣布一个非零的窗口大小。但这个确认会丢失。在TCP中,对确认是不需要发送确认的。若确认丢失了,接受TCP并不知道,而是会认为他已经完成了任务,并等待着发送TCP接着会发送更多的报文段。但发送TCP由于没有收到确认,就等待对方发送确认来通知窗口大小。双方的TCP都在永远的等待着对方。

  要打开这种死锁,TCP为每一个链接使用一个持久计时器。当发送TCP收到窗口大小为0的确认时,就启动坚持计时器。当坚持计时器期限到时,发送TCP就发送一个特殊的报文段,叫做探测报文。这个报文段只有一个字节的数据。他有一个序号,但他的序号永远不需要确认;甚至在计算机对其他部分的数据的确认时该序号也被忽略。探测报文段提醒接受TCP:确认已丢失,必须重传。

  坚持计时器的值设置为重传时间的数值。但是,若没有收到从接收端来的响应,则需发送另一个探测报文段,并将坚持计时器的值加倍和复位。发送端继续发送探测报文段,将坚持计时器设定的值加倍和复位,直到这个值增大到门限值(通常是60秒)为止。在这以后,发送端每个60秒就发送一个探测报文,直到窗口重新打开。

3 保活计时器

  保活计时器使用在某些实现中,用来防止在两个TCP之间的连接出现长时间的空闲。假定客户打开了到服务器的连接,传送了一些数据,然后就保持静默了。也许这个客户出故障了。在这种情况下,这个连接将永远的处理打开状态。

  要解决这种问题,在大多数的实现中都是使服务器设置保活计时器。每当服务器收到客户的信息,就将计时器复位。通常设置为两小时。若服务器过了两小时还没有收到客户的信息,他就发送探测报文段。若发送了10个探测报文段(每一个像个75秒)还没有响应,就假定客户除了故障,因而就终止了该连接

  这种连接的断开当然不会使用四次握手,而是直接硬性的中断和客户端的TCP连接。

4 时间等待计时器

  时间等待计时器是在四次挥手的时候使用的。四次握手的简单过程是这样的:假设客户端准备中断连接,首先向服务器端发送一个FIN的请求关闭包(FIN=final),然后由established过渡到FIN-WAIT1状态。服务器收到FIN包以后会发送一个ACK,然后自己有established进入CLOSE-WAIT。此时通信进入半双工状态,即留给服务器一个机会将剩余数据传递给客户端,传递完后服务器发送一个FIN+ACK的包,表示我已经发送完数据可以断开连接了,就这便进入LAST_ACK阶段。客户端收到以后,发送一个ACK表示收到并同意请求,接着由FIN-WAIT2进入TIME-WAIT阶段。服务器收到ACK,结束连接。此时(即客户端发送完ACK包之后),客户端还要等待2MSL(MSL=maxinum segment lifetime最长报文生存时间,2MSL就是两倍的MSL)才能真正的关闭连接。

参考:https://www.cnblogs.com/duan2/p/9180861.html

这篇关于TCP协议的四种计数器的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!