开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第6天，点击查看活动详情
对于自身不包含可靠传递数据机制的协议，他们可能会使用一种像校验和或 CRC 这样数学函数来检测接收到的有差错的数据，但是他们不尝试去纠正差错。对于 IP 协议根本没有实现差错纠正，而通信媒介可能会丢失或改变被传递的信息，所以需要差错检验：
差错校验有两种方法：
差错校正码：基本上是添加一些冗余的比特，使得即使某些比特被毁，真实信息也可以被恢复过来，这是纠正通信问题处理差错的一种非常重要的手段自动重复请求(Automatic Repeat Request, ARQ)：简单的“尝试重新发送”，直到信息最终被接收，这种方法构成了包括 TCP 在内的许多通信协议基础
ARQ 和重传
如果我们考虑的不只是单个通信信道，而是几个的多跳级联（如分组传递经过多个中间路由器），我们会发现不止会遇到分组比特差错，而且还会遇到其他问题：分组重排序、分组复制、分组丢失。像 IP 协议在多跳通信信道中使用，必须要处理这些问题。先制定一个简单的协议来处理这些问题：
重发分组与确认 ACK
一个直接处理分组丢失（和比特差错）的方法是重发分组直到它被正确的接收。这需要一种方法来判断：
- 接收方是否已收到分组
- 接收方收到的分组是否与之前发送方发送的一样
接收方给发送方发信号以确定自己已经接收到一个分组，这种方法称为确认（acknowledgment）或 ACK。一个简单的协议：发送方发送一个分组，然后等待一个 ACK，当发送方接收到这个 ACK，它再发送另一个分组，持续这个过程。这里会有一些有意思的问题：
- 发送方对一个 ACK 应该等待多长时间？
- 如果 ACK 丢失了怎么办？
- 如果分组收到了，但是里面有错这么办？
第一个问题，决定去等待多长时间与发送方期待（expect）为一个 ACK 等待多长时间有关；第二个问题，如果一个 ACK 丢失了，发送方不能轻易地把这种情况与原分组丢失的情况区分来看，所以它简单地再次发送原分组，这种情况下接收方会接收到重复的分组副本，一般都过分组上的序列号（sequence number）来去重；第三个问题，可以通过编码技术来解决如校验和和 CRC ，当接收方接收到一个含有差错的分组时，它不发送 ACK。
对于上面最简单的场景我们制定的“停止和等待”协议是可靠的，但是效率不太高，像卫星链路这种，从发送方到接收方传递即使一个很小的分组都需要较长的时间。假设没有分组丢失或损害的话，这种协议的吞吐量性能（每单位时间发送在网络中的数据量）与 M/R 成正比，M 是分组大小，R 是往返时间（RTT）。如果有分组丢失或损害的情况，那么情况会更糟糕：吞吐质（每单位时间传送的有用数据量）明显要比吞吐量要低。
提高吞吐量引入的问题
对于不会损害和丢失太多分组的网络，低吞吐量的原因是网络经常没有处于繁忙的状态，如果我们允许多个分组进入网络，就可以提高吞吐量。当多个分组同时进入网络使接收方和发送方变得复杂。发送方必须不仅要决定什么时间注入一个分组到网络中，还要考虑注入多少个，并且必须要指出在等待 ACK 时，怎样维持计时器，同时还必须要保存每个还没确认的分组的分组的一个副本以防需要重传；接收方需要有一个更复杂的 ACK 机制：可以区分哪些分组已经收到，哪些还没有，接收方可能需要一个更复杂的缓存（分组保存）机制——允许维护“次序杂乱”的分组（因为丢包和次序重排的原因，那些比预想要先到的分组更早到达的分组）。还有其他一些没有那么明显的问题，如果接收方的接收速率比发送方的发送速率慢？如果发送方简单地以很高的速率发送很多分组，接收方可能会因处理或内存的限制丢弃这些分组？中间的路由器也会有相同的问题。如果网络基础设施处理不了发送方和接收方想要使用的数据发送率怎么办？
在后续的章节中，我们依次介绍分组窗口和滑动窗口，变量窗口：流量控制和拥塞控制，设置超时重传等策略，以及系统介绍 TCP 协议。
资料来源
《TCP/IP 详解：卷1:协议》
