为什么说TCP协议是可靠的？

TCP 实现可靠通信的两种方式

我们都知道 IP 协议是“不太靠谱”。因为 IP 协议是不可靠的，所以 IP 数据包可能在传输过程中发生错误或者丢失。这就意味着，TCP 协议不得不面对以下三个问题。1）每个数据包有可能发送不成功 2）数据包在传输过程中有可能被丢弃 3）接收端有可能接受不到数据包

TCP 为了解决这丢包问题，提出两个补救措施。

1.ACK 回复

在每收到一个正确的、符合次序的片段之后，就向发送方(也就是连接的另一段)发送一个特殊的 TCP 片段，用来知会(ACK，acknowledge)发送方：我已经收到那个片段了。这个特殊的 TCP片段叫做 ACK 回复。如果一个片段序号为 L，对应ACK 回复有回复号 L+1，也就是接收方期待接收的下一个发送片段的序号。

2.重新发送机制

如果发送方在一定时间等待之后，还是没有收到 ACK 回复，那么它推断之前发送的片段一定发生了异常。发送方会重复发送那个出现异常的片段，等待 ACK 回复，如果还没有收到，那么再重复发送原片段… 直到收到该片段对应的 ACK 回复(回复号为 L+1 的 ACK)。

TCP 的滑动窗口

虽然采用 “ACK 回复” + “重新发送机制” 方式能实现不丢包，但是会存在两个问题。

1.效率低的问题。 stop-and-wait。stop-and-wait 虽然实现了 TCP 通信的可靠性，但同时牺牲了网络通信的效率。同时，在等待ACK的时间段内，我们的网络都处于闲置(idle)状态

2.有点小缺陷

TCP 为了进一步优化解决这两个问题，提出滑动窗口(sliding window)的概念。滑动窗口被同时应用于接收方和发送方, 发送方和接收方各有一个滑窗。当片段位于滑窗中时，表示 TCP 正在处理该片段。此外，如果滑窗中可以有多个片段，也就是可以同时处理多个片段。

我们借助一些图片来进一步了解下滑动窗口内部机制。

黄色框框表示可以容纳三个片段的固定大小的滑窗。在图中，并假设片段从左向右排列。实际运用中，滑动窗口是可变的，窗口大小是字节(byte)来计算的。

对于发送方来说，滑窗的左侧为已发送并已 ACK 过的片段序列，滑窗右侧是尚未发送的片段序列。如果滑动窗口第一个片段一直没有收到 ACK 回复，窗口不会向右滑动。但是发送方还是可以继续发送后面两个片段数据包。

对于接受方来说，滑窗的左侧是已经正确收到并 ACK 回复过的片段，也就是正确接收到的文本流。滑窗中的片段是期望接收的片段。如果滑窗中第一个片段先收到，滑窗会向右移动。如果滑窗中后面两个片段先收到，但是第一个片段没有收到。窗口不会向右滑动。

发送端已经发送三个数据包（1、2、3），在等待每个数据包的 ACK 回复

接收端成功收到两个数据包，回复两个 ACK。还有一个数据包没有收到。当收到数据包 1 时，接收端会回复一个 ACK 1，然后将窗口向有滑动一个位置。

发送端成功接收到 ACK 1 回复

发送端的窗口向右滑动一个位置

在没有收到 ACK 2 和 3 的回复，还能继续发送数据包 4

之前数据包 4 已经发送了。在之后成功收到 ACK 2 和 3 的回复，窗口向右滑动两个位置，现在又能继续发送数据包 5，6
通过上面一系列图片，我们可以大致知道滑动窗口的机制。我们来做下小总结：

对于发送端

如果滑动窗口第一个片段一直没有收到 ACK 回复，窗口不会向右滑动。但是发送方还是可以继续发送后面两个片段数据包。

对于接受端

如果滑窗中第一个片段先收到，滑窗会向右移动。如果滑窗中后面两个片段先收到，但是第一个片段没有收到。窗口不会向右滑动

那么实际应用中确实是这样吗？如果接收方每接受一个片段，就回复一个 ACK。这种效率有点低。所以实际应用中， TCP 协议为了减少了 ACK 回复所消耗的流量，采用的是累计 ACK 回复。接收方往往利用一个 ACK 回复来知会连续多个片段的成功接收。通过累计 ACK，所需要的 ACK 回复通常可以降到 50%。

我们同样通过图片的形式来了解累计 ACK 回复的原理。

在图中，橙色为已经接收的片段。方框为滑窗，滑窗可容纳3个片段。

情况1：滑窗还没接收到片段 7 时，已接收到片段 8，9。这样就在滑窗中制造了一个“空穴”(hole)。

情况2：当滑窗最终接收到片段7时，滑窗送出一个回复号为 10 的 ACK 回复。发送方收到该回复，会意识到，片段 10 之前的片段已经按照次序被成功接收。整个过程中节约了片段 7 和片段 8 所需的两个 ACK 回复。