在TCP中,一般有相似于心跳同样的定时器来保证传输的正常。对于每个链接,TCP管理了4个不一样的定时器。服务器
这里介绍三种。微信
TCP提供可靠的运输层。它使用的方法之一就是确认从另外一端收到的数据。但数据和确认都有可能会丢失。TCP经过在发送时设置一个定时器来解决这种问题。若是当定时器溢出时尚未收到确认,它就重传该数据。 对每一个链接而言,报文段中数据的起始序号也被记录下来。当收到一个包含这个序号的确认后,该定时器就被关闭。若是ACK到达时数据没有被重传,则被平滑的RTT和被平滑的均值误差将基于这个新测量进行更新。网络
咱们已经看到TCP经过让接收方指明窗口大小来对发送方进行流量控制的。当窗口大小为0,发送方将不会发送数据,直到接收方发送ack通知非0窗口大小。 可是当这个ack丢失了呢,又是什么状况?发送方窗口大小为0,接收方又认为发送方的发送窗口不为0。两个就这么僵持着,直到关闭链接。 这是个问题!为了防止这种死锁状况的发生,在每个TCP链接中,发送方都使用一个叫持久定时器(persist timer)来周期性的向接收方查询,以便发现窗口是否变大了。code
咱们会很惊奇地发现能够没有任何数据流经过一个空闲的TCP链接。也就是说, 若是TCP链接的双方都没有向对方发送数据, 则在两个TCP模块之间不交换任何信息。例如,没有能够在其余网络协议中发现的轮询。这意味着咱们能够启动一个客户与服务器创建一个链接,而后离去数小时、数天、数个星期或者数月,而链接依然保持。然而,许多时候一个服务器但愿知道客户主机是否崩溃并关机或者崩溃又从新启动。许多实现提供的保活定时器能够提供这种能力。这就是保活定时器。 事实上,keepalive timer 在RPC中是不被推荐的, 许多人认为若是须要,这个功能不该该在 TCP中提供,而应该由应用程序来完成。在大部分的协议中,也是关闭了这个的,缘由以下:cdn
保活功能主要是为服务器应用程序提供的。服务器应用程序但愿知道客户主机是否崩溃,从而能够表明客户使用资源。 一句话,keepalive timer就是咱们常常遇到的心跳包,在须要的时候能够在应用层实现。
资源
都看到这里了,要不要扫二维码关注一下微信公众号林湾村龙猫。 it