📅  最后修改于: 2020-11-10 05:48:29             🧑  作者: Mango
TCP重传意味着通过网络重新发送丢失或损坏的数据包。在此,重传是诸如TCP之类的协议用来提供可靠通信的机制。在这里,可靠的通信意味着即使数据包丢失或损坏,该协议也可以保证包的传递。
网络不可靠,不能保证丢失或损坏的数据包的延迟或重新传输。结合使用确认和重新传输已损坏或丢失的数据包的网络可提供可靠性。
在此,重传意味着数据包已丢失,这导致缺乏确认。缺少确认会触发计时器超时,从而导致数据包的重新传输。在此,计时器表示如果在计时器到期之前未收到确认,则重新发送数据包。
让我们考虑以下重传场景。
场景1:数据包丢失或错误。
在这种情况下,该数据包被发送到接收器,但在该超时期限内未收到确认。超时时间到期后,将重新发送数据包。重发数据包后,将收到确认。一旦收到确认,就不会再次发生重传。
方案2:当收到数据包但确认丢失。
在这种情况下,在另一侧接收到数据包,但确认丢失,即,在发送方未接收到ACK。超时期限到期后,将重新发送数据包。另一侧有两个数据包副本。尽管正确接收了数据包,但未收到确认,因此发送方重新发送了数据包。在这种情况下,可以避免重传,但是由于ACK丢失,因此将重传该数据包。
方案3:提前超时发生时。
在这种情况下,将发送数据包,但是由于在实际超时之前已经发生了确认延迟或超时,因此将重新发送该数据包。在这种情况下,由于确认延迟或超时设置早于实际超时,因此已不必要地再次发送了数据包。
在上述场景中,无法避免第一种情况,但是可以避免其他两种情况。让我们看看如何避免这些情况。
发件人应等待多长时间?
发送方设置ACK的超时时间。超时时间可以有两种类型:
为了克服以上两种情况,TCP将超时设置为RTT(往返时间)的函数,其中往返时间是数据包从源传输到目的地然后再次返回的时间。
我们如何获得RTT?
RTT可以根据网络的特性而变化,即,如果网络拥塞,则意味着RTT很高。我们可以通过简单地观察ACK来估算RTT。
让我们看看如何测量RTT。
我们将使用原始算法来测量RTT。
步骤1:首先,我们测量每个段或ACK对的SampleRTT。当发送方发送数据包时,我们就知道发送数据包的计时器,而且,我们也知道收到确认的计时器。计算这两者之间的时间,即为SampleRTT。
第2步:我们将不只抽取一个样本。我们将继续获取不同的样本并计算这些样本的加权平均值,这就是EstRTT(估算的RTT)。
其中,α+β= 1
α在0.8到0.9之间
β在0.1到0.2之间
步骤3:根据EstRTT设置超时时间。
超时= 2 * EstRTT。
超时设置为估计的RTT的两倍。这是实际超时因子的计算方式。
这种方法的缺陷
原始算法存在缺陷。让我们考虑两种情况。
场景1。
上图显示发送方发送数据,该数据被称为原始传输。在超时时间内,未收到任何确认。因此,发送方重新传输数据。重新发送数据后,将收到确认。假设接收到的确认是针对原始传输的,而不是针对重传的。由于我们得到了原始传输的确认,因此在原始传输时间与接收到确认时间之间计算SampleRTT。但是实际上,SampleRTT应该在重传时间和确认时间之间。
场景2。
上图显示发送方发送了原始数据包,对此我们也得到了确认。但是,在重新发送数据之后,将收到确认。如果我们假设确认属于重传,则在重传时间和确认时间之间计算SampleRTT。
在以上两种情况下,都有一个模棱两可的含义:不知道该确认是针对原始传输还是针对重传。
以上算法的结论。
为了克服上述问题,通过卡恩/帕特里奇算法给出了一种简单的解决方案。该算法给出了一种简单的解决方案,该解决方案可以一次收集发送的样本,并且不考虑重传时的样本来计算估计的RTT。
在以上两种情况下,都会发生重传,并且我们已经考虑了RTT示例。但是此算法在重传时不考虑Sample RTT。由于发生了重新传输,这意味着在此往返时间内发生了某些情况,或者在网络中可能发生了一些拥塞。为克服此问题,此算法在每次重传后将超时时间加倍。该算法在TCP网络中实现。
局限性
它不考虑RTT中的差异。
为了克服上述限制,开发了将J方差因子引入RTT的Jacobson / Karels算法。
Jacobson / Karels算法
开发该算法是为了克服Karn / Partridge算法的局限性。它计算SampleRTT和EstimatedRTT之间的差异,并基于该差异提高RTT。
计算平均RTT
差异= SampleRTT-估算的RTT
EstRTT = EstRTT +(δ* Diff)
Dev = Dev +δ(| Diff |-Dev)
在此,Dev是偏差因子,而δ是0到1之间的因子。Dev是对EstRTT的方差的估计。
其中,μ= 1且ɸ= 4
基于超时的重传策略效率低下。 TCP是一种滑动窗口协议,因此无论何时发生重传,它都会从丢失的数据包开始发送。
假设我传输数据包0、1、2和3。由于在另一侧接收到数据包0和数据包1,因此网络中丢失了数据包2。我已经收到了数据包0和数据包1的确认,因此我又发送了两个数据包,即数据包4和数据包5。当发送数据包3、4和5时,我将得到数据包1的确认为TCP确认。是累积的,因此它最多确认已按顺序收到的数据包。我没有在超时时间内收到数据包2、3、4和5的确认,因此我重新传输数据包2、3、4和5。由于数据包2丢失,但是其他数据包(即3、4)丢失了,5在另一侧被接收,由于这种超时机制,它们仍然被重新发送。
如何消除这种超时效率低下的问题?
滑动窗口下的更好解决方案:
假设丢失了n个数据包,但仍然接收到n + 1,n + 2等数据包。接收器正在连续接收数据包并发送ACK数据包,表明接收器仍在等待第n个数据包。接收方正在发送重复或重复的确认。在上述情况下,由于丢失了数据包2,因此发送了3次数据包1的ACK。此重复的ACK数据包指示第n个数据包丢失,但后来的数据包被接收。
以上情况可以通过以下方式解决:
TCP使用三个重复的ACK作为触发器,然后执行重传。在上述情况下,当收到数据包1的三个ACK时,发送方应发送丢失的数据包(即数据包2),而无需等待超时周期的发生。