前言
让咱们来回顾一下 TCP，TCP 位于传输层 (也有人称之为运输层)，TCP 提供牢靠交付的服务，无差错、不失落，不反复，并且按序达到 , 这句话出自教科书。其实这个不失落我感觉能够了解为就算是有个数据包失落的状况下，TCP 提供的超时重传也能保障你能收到残缺的数据包。失落的最奢侈的场景就是数据包被确定要走哪一片光缆的时候，这片光纤被挖断了，我大学的时候某个月，光纤就老是被挖断，那被调配到这片光缆上的数据包就能够了解为失落了。那失落了怎么办呢，再重传一次。但其实在网络这里，重传并不是一件简略的事件，因为有的时候，数据包未必失落，也可能是早退，除此之外，还要思考效率问题。
让咱们从最简略的模型谈起
全双工的通信的意思是，单方既是发送方也是接管方，然而为了探讨问题不便，咱们目前只思考 A 发送数据，而 B 接管，这里是探讨牢靠传输的原理，所以不思考 数据包在哪一个档次进行传输，因而把传送的数据单元称之为分组 (传输层传送的数据单元叫报文段，网络层传输的协定数据单元叫做 IP 数据包)。让咱们先从最简略的模型谈起，也就是进行期待协定，进行期待的意思是，每发送完一个分组就进行发送，期待对方的确认。在收到确认之后再发送下一个分组。
在这种模型下有以下几种状况:
- 无差错
这种状况最简略，A 发送分组 M1，发送完就暂停发送，期待 B 的确认。B 收到了 M1 就向 A 发送确认。A 在收到了对 M1 的确认之后，就再发送下一个分组 M2。
- 呈现过错
分组在传输过程中呈现过错。B 接管 M1 时检测出了过错，就抛弃了 M1，其余什么也不做（不告诉 A 收到有过错的分组，在牢靠传输的协定中，也能够检测出有过错时发送“否定报文”给对方。这样做的益处是可能让发送方及早晓得呈现过错。不过因为这样解决会使协定变得复杂，当初实用的牢靠传输协定都不应用这种否定报文了）。也可能是 M1 在传输的过程中失落了，这时 B 当然什么都不晓得。在这两种状况下，B 都不会发送任何信息，个别的牢靠传输协定是这么设计的: A 只有超过了一段时间依然没有收到确认，就认为方才发送的分组失落了，因此重传后面发送过的分组。这叫超时重传。要实现超时重传，就要在每发送完一个分组时设置一个超时计时器，如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。
- 确认失落和确认早退
B 发送的对 M1 的确认失落了。A 在设定的超时重传工夫内没有收到确认，并无奈晓得是本人发送的分组出错、失落，或者 B 发送的确认失落了。因而 A 的超时计时器失落之后就会重传 M1。假设在这种状况下 B 就又收到了 M1，对于 B 来说解决这个重传的 M1 就要采取两个口头:
- 抛弃这个反复的分组 M1，不向下层进行交付。
- 向 A 发送确认，不能认为曾经发送过确认就不再发送。因为 A 之所以重传 M1，就示意没有收到对 M1 的确认。
再有一种状况，B 对 M1 的确认报文没有失落，而是早退了，在这种状况下 A 可能就会反复收到确认。对反复确认的解决很简略：收下后，就抛弃。B 依然会收到反复的 M1，并且同样抛弃反复的 M1，并重传确认分组。
通常 A 最终总是能够收到对所有收回的分组的确认。如果 A 一直重传分组但总是收不到确认，就阐明通信线路太差，不能进行通信。设想一下，你的手机在弱网环境下，收回去的音讯会转圈圈，如果转了很长时间也没收回去，微信就认为这条音讯没收回去。
应用上述的确认和重传机制，咱们就能够在不牢靠的传输网络上实现牢靠的通信。介绍这个模型次要是为了引出为了牢靠传输会遇到哪些问题，这个模型的传输效率是非常低的，信道的利用率只有 5.66%，这意味着信道在大多数工夫内都是闲暇的。
为了进步传输效率，发送方采取了流水线传输，流水线传输就是发送方能够间断发送多个分组，不用每发送一个分组就停顿下来，期待对方的确认。当应用流水线传输时，就引出了间断 ARQ 协定和滑动窗口协定。滑动窗口协定比 ARQ 协定简单，咱们这里先介绍间断 ARQ 协定，再介绍滑动窗口协定。
间断 ARQ 协定
下面是一个典型 TCP 报文首部格局，我这里不打算一一介绍 TCP 首部中各个字段的意思，这里只介绍一些咱们本篇所须要的字段:
- 源端口和目标端口
各占两个字节，别离写入源端口号和目标端口号
- 窗口
占两个字节，窗口值是 [0, 2^16^-1] 之间的整数，是指接管方容许对方发送的数据量，之所以有这个限度，起因就在于接管方的数据缓存空间是无限的。
窗口字段明确指出了当初容许对方发送的数据量。窗口值常常在动静的变动着。
- 序号
占 4 字节。序号范畴为是 [0,2^32^ -1], 共 2^32^ 个序号，序号达到最大值之后，又回到 0。在一个 TCP 连贯中传送的字节流中每一个字节都按程序编号，TCP 报文首部的序号值则指的是本报文段所发送的数据的第一个字节的序号。
- 确认号
占 4 字节，是冀望收到对方下一个报文段的第一个数据字节的序号。
TCP 是双工的协定，会话的单方都能够同时接管、发送数据。TCP 会话的单方都各自保护一个“发送窗口”和一个“接管窗口”。其中各自的“接管窗口”大小取决于利用、零碎、硬件的限度（TCP 传输速率不能大于利用的数据处理速率）。各自的“发送窗口”则要求取决于对端通告的“接管窗口”，要求雷同
下图示意的是发送方维持的发送窗口:
示意的意义是：位于发送窗口内的 5 个分组都能够间断发送进来，而不须要期待对方的确认。这样，信道利用率就进步了。
间断 ARQ 协定规定，发送方没收到一个确认，就把发送窗口向前滑动一个分组的地位。接管方个别都采纳累积确认的形式。这就是说，接管方不用对收到的分组一一发送确认，而是在收到几个分组之后，对按序达到的最初一个分组发送确认，这就示意: 到这个分组为止的所有分组都曾经正确收到了。
然而累积确认有长处也有毛病, 长处是：容易实现。毛病是不能向发送方反映出接管方曾经正确收到的所有分组的信息。
举一个例子: 发送方发送了五个分组，两头第三个分组失落了，留神咱们下面的确认形式是对按序达到的最初一个分组发送确认，咱们收到了 1、2、4、5，就只能发送对 2 的确认，于是发送方就只好将 3、4、5 再重传一次，咱们将这种状况称之为 Go-back-N（回退 N），示意须要再退回来重传曾经发送过的 N 个分组。可见当通信线路品质不好时，间断 ARQ 协定会带来负面的影响。对于这种协定 TCP 打上的补丁为抉择确认 SACK，咱们前面会讲。
滑动窗口协定
上面咱们探讨 TCP 中的滑动窗口协定，为了探讨问题，咱们还是先假设数据传输只在一个方向进行，即 A 发送数据，B 接收数据，这个模型其实曾经足够阐明滑动窗口协定了。
现假设 A 收到 B 发来的确认报文段，其中窗口是 10 字节，而确认号是 31(这表明 B 冀望收到的下一个序号是 32)，而序号 30 为止的数据曾经收到了），依据这两个数据，A 就结构进去本人的滑动窗口:
下面的发送窗口示意：在没收到 B 的确认的状况下，A 能够间断把窗口内的数据都发送进来。但凡曾经发送过的数据，在未收到确认之前都必须临时保留，以便在超时重传时应用。发送窗口也可能变小，当对方告诉的窗口放大，但 TCP 的规范强烈不倡议这样做。因为很可能发送方在收到这个告诉以前曾经发送了窗口的很多数据，当初又要膨胀窗口，不让发送这些数据，这样就会产生一些谬误。
当初假设 A 发送了序号为 31-35 的数据，这时发送窗口地位并未产生扭转，但发送窗口内靠后面有 5 个字节示意已发送但未收到确认。而发送窗口靠前面的五个字节（36-40）是示意容许发送但尚未发送的。
从以上所述能够看出，要形容一个发送窗口的状态须要是三个指针: P1,P2 和 P3:
小于 P1 的是已发送并已收到确认的局部，而大于 P3 的是不容许发送的局部。P3-P1= A 的发送窗口，P2-P1 = 曾经发送但尚未收到确认的字节数。P3-P2= 容许发送但以后尚未发送的字节数。
再看下 B 的接管窗口。B 的接管窗口大小是 10. 在接管窗口里面，到 30 号地位的数据是曾经发送过确认。因而 B 能够不再保留这些数据，接管窗口内的序号（31-40）是容许接管的。在上面的图中，B 收到了序号为 32-33 的数据。这些数据没有按序达到，因为序号为 31 的数据没有收到 (兴许失落了，兴许滞留在网路中的某处)，因为 31 没收到，所以 B 发送的确认报文段中的确认号依然是 31(即冀望收到的序号)，而不能是 32 或 33.
当初假设 B 收到了 A 重传的 31-33 的数据，并把序号 31-33 的交付给应用层的程序，而后 B 删除这些数据。接着把接管窗口向前挪动 3 个序号，同时给 A 发送确认，其中窗口值依然是 10，但确认号是 34。这表明 B 曾经收到了到序号 33 为止的数据。
收到确认之后，A 的可用滑动窗口变大，这个时候如果 A 发送完序号 36-43 的数据，P2 会和 P3 重合。发送窗口内的序号曾经用完，但还没有再收到确认。A 的发送窗口已满，就不能再发送数据，必须进行发送数据。此时存在两种状况:
- 数据包还在路上，未达到 B
- B 曾经给 A 发送了确认，然而还在路上。
为了保障牢靠传输，A 通过一段时间之后 (在超时计时器到期之后)，就会重传这部分数据，从新设置超时计时器，直到收到 B 的确认地位。如果 A 收到确认号落在发送窗口内，那么 A 就能够发送窗口持续向前滑动，并发送新的数据。
抉择确认 -SACK
下面的阐述中还有一个问题，就是 B 遗失了两头序号的数据包，会申请 A 再重传，然而在下面的探讨中窗口值较小，影响还不是很大，然而如果窗口值很大，遗失了两头的一个包，这样有的时候可能导致网络拥挤，对于这种状况，TCP 提出了抉择确认。咱们举一个例子来阐明抉择确认的原理.
假如 A 收到了以下三个字节流:
从图中咱们能够看到短少了 1001-1500、3001-3500，一个直白的思路就是，收到这三个字节流的时候，算出短少的区间，再申请回传的时候带上这些区间。咱们下面画出了 TCP 首部，目前看来没有哪个字段可能提供边界信息。RFC 2018 对此做了规定，如果要应用抉择确认 SACK，那么在建设 TCP 连贯时候，就必须在 TCP 的首部的选项中增加上“容许 SACK”的选项，而单方必须当时约定好。
超时工夫的抉择
下面咱们提到了超时重传，这里来进行详尽的探讨，设置固定的超时工夫是齐全不可取的，因为不同地区的网络品质不同，所以这个超时工夫该当是自适应的，这也是 TCP 的思路，TCP 采纳了一种自适应算法，记录一个报文段收回的工夫，以及收到相应的确认的工夫。这两个工夫之差就是报文段的往返工夫 RTT。TCP 保留了 RTT 的一个加权均匀往返工夫 RTTs(这又被称为平滑的往返工夫，S 示意 Smoothed。因为进行的是加权均匀，因而得出的后果更加平滑)。
每当第一次测量到 RTT 样本时，RTTs 值就取为所测量到的 RTT 样本值。但当前每测量到一个新的 RTT 样本，就按上面的共识从新计算一次 RTTs:
新的 RTTs = (1 – α) ×（旧的 RTTs）+ α ×（新的 RTT 样本）
在上式中，0 ≤ α ≤ 1. 若 α 很靠近 0，则示意新的 RTTs 值和旧的差距不大，若 α 靠近于 1，则示意新的 RTTs 受新的 RTT 样本影响较大。RFC 6298 举荐 α 值为 1 /8。
显然超时计时器设置的超时重传工夫 RTO(Retransmission Time-Out) 该当略大于下面得出的加权均匀往返工夫 RTTs。RFC6298 举荐应用上面的算式计算 RTO:
RTO = RTTs + 4 × RTT~D~。而 RTT~D~ 是 RTT 的偏差加权平均值，它与 RTTs 和新的 RTT 样本之差无关。RFC6298 倡议这样计算 RTT~D~。当第一次测量时，RTT~D~ 值取为测量到的 RTT 样本值的个别。在当前的测量中，则应用下式计算加权均匀的 RTT~D~：
新的 RTT~D~ = (1 – β) × (旧的 RTT~D~) + β × |RTTs – 新的 RTT 样本 |。
这个 β 是个小于 1 的系数，它的推荐值是 1 /4, 即 0.25。
下面说的往返工夫测量，事实上实现起来相当的简单，咱们这里举一个例子：发送一个报文段，设定的重传工夫到了，还没有收到确认。于是重传报文段，过了一段时间后，收到了确认报文段。当初的问题是: 如何断定此确认报文段是对先发送的报文的确认，还是对起初重传的报文段的确认? 因为重传的报文段和原来的报文段齐全一样，因而源主机在收到确认后，就无奈作出正确的判断，而正确的判断对确定加权 RTTs 的值关系很大。
若将收到的确认当作是对重传报文段的确认，但却被源主机当成是对原来的报文段的确认，则这样计算出的 RTTs 和超时重传工夫 RTO 就会偏大。前面再发送的报文段又是通过重传之后才收到确认报文段，则按此办法得出的超时重传工夫 RTO 就会越来越长。
同样，若收到的确认是对原来报文段的确认，但被当成是对重传报文段的确认。则由此计算出来的 RTTs 和 RTO 都会偏小。这就必然导致报文段过多地重传，这样就会导致报文会被过多重传。
依据以上所述，Karn 提出了一个算法：在计算加权均匀 RTTs 时，只有报文重传，就不采纳其往返工夫样本。这样得出的加权均匀 RTTS 和 RTO 就比拟精确。
然而这个算法还脱漏了一点，就是如果网络时延忽然增大了很多。因而在原来得出的重传工夫内，不会收到确认报文段。于是重传报文段，但依据 Karn 的算法，不思考重传的报文段的往返工夫样本，这样，超时重传工夫就无奈更新。
因而咱们须要为 Karn 的算法打上一个补丁: 报文段每重传一次，就把超时重传工夫 RTO 增大一些。典型的做法是取新的重传工夫为旧的重传工夫的 2 倍。当不产生报文段的重传时，才依据下面给出的:RTO = RTTs + 4 × RTT~D~ 计算超时工夫。实践证明，这种策略是比拟正当的。
总结一下
TCP 的牢靠传输依赖于滑动窗口和超时重传，咱们从最简略的进行期待协定谈起，为了确认接管方的确收到了分组，接管方须要发送确认给发送方，进行期待协定对信道的利用率比拟低，咱们不大可能采纳这种算法来做，TCP 采纳了滑动窗口来晋升信道的利用率，为了避免分组在途中失落或者出了过错，TCP 引入了超时重传，超时重传工夫的计算是一个自适应算法。本篇基本上取材于《计算机网络 (第 7 版)》的 TCP 一节，用本人的形式梳理了一下。
参考资料
- 《计算机网络 (第 7 版)》谢希仁 编著
- TCP 滑动窗口（发送窗口和承受窗口）https://www.cnblogs.com/hongd…