前言

我们平常经常说UDP是不可靠连接，TCP是可靠连接，然而TCP为什么是可靠的呢

TCP和UDP的优缺点

TCP缺点：

  1. 三次握手四次挥手，传输更多包，浪费一些带宽
  2. 为了进行可靠通信，双方都要维持在线，通信过程中服务器server可能出现非常大的并发连接，浪费了系统资源，甚至会出现宕机
  3. 确认重传也会浪费一些带宽，且在不好的网络中，会不断的断开和连接，降低了传输效率

UDP优点：

  1. 没有握手，起步快延时小
  2. 不需要维持双方在线，server不用维护巨量并发连接，节省了系统资源
  3. 没有重传机制，在不影响使用的情况下，能更高效的利用网络带宽

TCP相比UDP为什么是可靠的

  1. 确认和重传机制
    建立连接时三次握手同步双方的“序列号 + 确认号 + 窗口大小信息”，是确认重传、流控的基础
    传输过程中，如果Checksum校验失败、丢包或延时，发送端重传

  2. 数据排序
    TCP有专门的序列号SN字段，可提供数据re-order

  3. 流量控制
    窗口和计时器的使用。TCP窗口中会指明双方能够发送接收的最大数据量

  4. 拥塞控制
    TCP的拥塞控制由4个核心算法组成。
    “慢启动”（Slow Start）
    “拥塞避免”（Congestion avoidance）
    “快速重传 ”（Fast Retransmit）
    “快速恢复”（Fast Recovery）

TCP 协议的作用

ISO（国际标准化组织）曾提出一个 OSI 七层模型。将网络的协议划分为 7 个层，从低到高排序是：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。但是这个模型仅停留在理论阶段。因为该模型过于庞大、复杂，以至于无法被广泛应用。
后来技术人员在 TCP/IP 等协议集问世之后，提出 TCP/IP 协议栈。该模型很贴近实际场景，所以被广泛的应用。TCP/IP 协议栈一共分为 4 个层次。从低到高依次排序是：数据链路层（有书籍称之为网络接口层)、网络层、传输层、应用层。

  • 网络接口层：针对不同物理网络的连接形式的协议：以太网、FDDI 光纤分布式数据接口。其中协议有 ARP 协议(地址解析协议)、RARP 协议(反向地址转换协议)
  • 网际层：负责数据的传输，路由以及地址选择。最主要的协议是 IP 协议。
  • 传输层：确认数据传输以及进行纠错处理。传输层中中有两个非常重要的协议，即 TCP 协议和 UDP 协议。
  • 应用层：各种服务以及应用程序。常见的应用层协议有 HTTP 协议、FTP 协议(文件传输协议)、SMTP 协议(简单邮件传输协议)等

TCP 协议通信特点

TCP 协议是实现端口到端口的通信。它虚拟了本文流(byte stream)的通信。我们知道，计算机数据的本质是有序的 0/1 序列(如果以byte为单位，就叫做文本流)。计算机的功能就是储存和处理文本流。所以TCP是采用“流”通信。
但是传输层的下一层是网络层。即 TCP 协议的下一层协议是 IP 层。这就意味着 TCP 协议最终还是由 IP 协议规定的形式传输数据。而IP 协议是以数据包方式传送。同时，IP 数据包的 MTU 也有长度限制。所以TCP 协议会将数据切割为一个个片段，然后丢给网络层，接着打包成一个个数据包进行传输。

但是这样，流数据变成了一个个片段数据，这会无法保证数据到达的次序。因为 IP 协议在传输过程中，不会按顺序进行发送和接受数据包。针对这问题，TCP 协议为了确保数据到达的顺序与文本流顺序相同。TCP 协议将每个 TCP 片段中分为头部(header)和数据(payload)两部分。每个头部中带有一个序号。这相当于给每个片段增加一个序号标记，方便后续排序。

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

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

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

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

TCP 的滑动窗口

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

  1. 效率低的问题。
    发送方保持发送 -> 等待ACK -> 发送 -> 等待ACK…的单线工作方式，这样的工作方式叫做 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 回复。

参考链接

TCP/IP协议-为什么说TCP是可靠连接
为什么说 TCP 协议是可靠的？