TCP向调用它的因特网应用提供所提供的服务模型
数据可以通过一条可靠的信道进行传输。借助于可靠的信道，传输比特就不会受到损坏或丢失，而且所有数据都是按其发送顺序进行交付。
可靠传输协议
实现服务模型就需要可靠的传输协议。但是由于可靠传输协议的下层协议可能是不可靠的，所以可靠传输协议的实现比较复杂。
构造可靠传输协议
1. 经完全可靠信道的可靠数据传输：rdt 1.0
??先是考虑最简单的情况，底层信道是完全可靠的。因为信道是完全可靠的，所以发送方传输给接收方的数据会没有比特差错，接收方也不必向发送方提供任何反馈信息。
2. 经具有比特差错信道的可靠数据传输：rdt 2.0
??在实际底层信道中传输的分组中的比特可能会受损。在分组的传输、传播或者缓存的过程中，这种比特差错常发生在网络的物理部件中。现在我们继续假定所有发送的分组（某些比特会受损）将按其发送顺序被接收。
??接收方接收到发送方的分组后，需要告知之发送方自己收到的分组是正确的、还是有比特错误的（发送发就会重传该分组）。基于这样的传重传机制的可靠传输协议称为自动重传请求(Automatic Repeat reQuest ARQ)协议。
??在ARQ协议中需要三种协议功能来处理比特差错
差错检测
差错检测机制使得接收方能够检测到分组中出现了比特差错。
例如：UDP中的检验和字段是一种差错检测机制，在数据连路层会使用CRC循环冗余检测机制进行差错检测。接收方反馈
因为发送方和接收方通常在不同端系统上执行，发送方要了解接收方的情况（分组是否被正确接收）的唯一途径就是让接收方提供明确的反馈消息给发送方。
rdt2.0协议将从接收方向发送方回送ACK或者NAK分组。理论上分组只需一个比特长，如0表示NAK，1表示ACK。重传
接收收到有差错的分组时，发送方将重传该分组。
??需要注意：当发送发处于等待ACK或者NAK的状态时，它不能从上层获得更多的数据。也就是说发送方不会发送一块新的数据，除非发送方确信接收方已正确接收当前分组。此时的rdt 2.0被称为停止等待(stop-and-wait)协议。
??协议rdt2.0看起来虽然可以运行了，但是有一个致命的缺陷，没有考虑到ACK/NAK分组受损的可能性！
??通常解决受含糊不清的ACK/NAK时，发送方会重传当前数据分组。
这样会让接收方的信道中出现冗余分组。
??解决冗余分组的方法是在数据分组中添加一新字段，让发送方对其数据分组进行编号，将分组的编号填入该字段中。接收方只需要检查序号就可以得知该分组是否是一次重传。
??对于停止等待协议来说，1比特序号就可以了，重传的分组序号与最近接收到的分组序号相同，新的分组序号会变化（使用模2使序号前移）。目前我们假定的是信道不会丢失分组，所以ACK/NAK分组本身不需要指明他们要确认的分组序号。发送方接收到ACK/NAK分组是为响应最近发送的数据分组而生成的。
??rdt2.1反映出目前正在发送的分组或希望接收的分组的序号是0还是1。
??rdt2.1使用了从接收方收到的肯定确认和否定确认。当接收方收到失序分组时，发送肯定确认。如果收到受损分组，则发送否定确认。
??如果不发送NAK，而是对正确接收到的分组发送一个ACK，那么也能得到与NAK一样的效果。发送方收到对同一个分组的两个ACK（接收到了冗余ACK）后，就可以知道接收方没有正确接收被确认两次的分组后面的分组。
??这也产生了协议rdt2.2。rdt2.2是在有比特差错信道上实现的一个无NAK的可靠传输协议，此时ACK报文就需明确所确认的分组序号。
3. 经具有比特差错的丢包信道的可靠传输：rdt3.0(比特交替协议)
??在今天的计算机网络中除了比特会出现受损也会出现丢包的情况。所以，现在协议需要关注两个问题：怎样检测丢包以及丢包后该做些什么。
??有很多方法用于解决丢包问题。这里，我们让发送方负责检测和恢复丢包工作。接收方确实没有接收到数据分组和接收方响应给发送方的ACK丢失，都会让发送发收不到接收方的响应。发送方等待足够长的时间来确认分组丢失，然后进行重传分组。如果是因为ACK丢失，发送方重传分组则会造成冗余数据分组。但是,rdt2.2中的序号可以解决接收方收到冗余分组的问题。
??在发送方的眼里，重传是一种万能灵药。无论数据分组丢失还是ACK丢失都可以采用同样的动作：重传。基于时间的重传机制，需要一个倒计时定时器,在一个给定的时间量过期后，可中断发送方。因此，发送方需要做到 ① 每次发送一个分组（包括第一次和重传分组）时，便启动一个定时器 ② 响应定时器中 断 ③ 终止定时器
??归纳：在构造可靠传输协议的过程中我们用到了检验和、序号、定时器、肯定和否定确认分组技术。
