一、引言
在TCP中，通常有类似于心跳一样的定时器来保证传输的正常。对于每一个连接，TCP管理了4个不同的定时器。
- 定时重传；
- 持久定时器（persist）；
- 保活定时器（keepalive）;
- 2MSL定时器，用来测量处于TIME_WAIT状态的连接。
这里介绍三种。
二、定时重传定时器
TCP提供可靠的运输层。它使用的方法之一就是确认从另一端收到的数据。但数据和确认都有可能会丢失。TCP通过在发送时设置一个定时器来解决这种问题。如果当定时器溢出时还没有收到确认，它就重传该数据。
对每个连接而言，报文段中数据的起始序号也被记录下来。当收到一个包含这个序号的确认后，该定时器就被关闭。如果ACK到达时数据没有被重传，则被平滑的RTT和被平滑的均值偏差将基于这个新测量进行更新。
三、持久定时器（persist timer）
我们已经看到TCP通过让接收方指明窗口大小来对发送方进行流量控制的。当窗口大小为0，发送方将不会发送数据，直到接收方发送ack通知非0窗口大小。
但是当这个ack丢失了呢，又是什么情况？发送方窗口大小为0，接收方又认为发送方的发送窗口不为0。两个就这么僵持着，直到关闭连接。
这是个问题！为了防止这种死锁情况的发生，在每一个TCP连接中，发送方都使用一个叫持久定时器（persist timer）来周期性的向接收方查询，以便发现窗口是否变大了。
四、保活定时器(keepalive timer)
我们会很惊奇地发现可以没有任何数据流通过一个空闲的TCP连接。也就是说， 如果TCP连接的双方都没有向对方发送数据， 则在两个TCP模块之间不交换任何信息。例如，没有可以在其他网络协议中发现的轮询。这意味着我们可以启动一个客户与服务器建立一个连接，然后离去数小时、数天、数个星期或者数月，而连接依然保持。然而，许多时候一个服务器希望知道客户主机是否崩溃并关机或者崩溃又重新启动。许多实现提供的保活定时器可以提供这种能力。这就是保活定时器。
事实上，keepalive timer 在RPC中是不被推荐的， 许多人认为如果需要，这个功能不应该在 TCP中提供，而应该由应用程序来完成。在大部分的协议中，也是关闭了这个的，原因如下：
- 在出现短暂差错的情况下，这可能会使一个非常好的连接释放掉；
- 它们耗费不必要的带宽；
- 在按分组计费的情况下会在互联网上花掉更多的钱。
保活功能主要是为服务器应用程序提供的。服务器应用程序希望知道客户主机是否崩溃，从而可以代表客户使用资源。
一句话，keepalive timer就是我们经常遇到的心跳包，在需要的时候可以在应用层实现。
都看到这里了，要不要扫二维码关注一下微信公众号林湾村龙猫。
微信公众号rudy_tan_home
网友评论