可靠数据传输原理
可靠数据传输只会出现在运输层吗？
不是的，在链路层和应用层也可以有可靠数据传输协议。例如Chorm浏览器使用的QUIC协议，该协议通过差错检测、快速链接建立和基于速率控制的拥塞算法提供可靠性，在使用UDP的应用层实现了数据的可靠传输。
构建可靠数据传输协议
在这部分，我们分3个递进的场景来介绍、完善可靠数据传输协议，并绘制数据发送方和接受方的有限状态机转移图来帮助厘清逻辑
1.0 经完全可靠信道的可靠数据传输：rdt1.0
假设数据的通信信道是可靠的，在数据的传输过程中不会出现数据的比特差错、丢包、乱序等问题，那么发送方运输层只需要将数据投入IP层，接收方只需将IP层交付的报文段传递给对应的套接字。如图所示：
2.0 具有比特差错的信道的可靠数据传输rdt2.0及停等协议
底层的信道更为实际的是数据比特可能受损的模型，而非rdt1.0中的理想模型。为了降低问题的复杂度，我们在这里假设通信信道可能使传输的数据发生比特差错，但是不会使分组丢失、失序。
要想在这种信道下实现数据的可靠传输，联想我们生活中的情景：
我们假设你与朋友打电话口述一条长报文，当你的朋友接受到报文时，通常情况下，接受者理解并记下每句话后会回复你一句OK，而如果接受者听到的是含糊不清的句子时，他可能会说：请重复一遍。然后你再重新复述该报文，直到接收方正确接受报文为之。在这种情景下，接收方在确定接受到的报文有问题时，会自然而然地要求发送方重发一遍报文。这种交互称之为自动请求重传（ARQ,Automatic Repeat reQest)。
显然，在上述情景中，要实现ARQ，必须引入三个另外的协议来处理比特差错的情况：
- 差错检测 接收方能够检测出报文发生了比特差错。这里只需在报文首部引入检验和即可。
- 接收方反馈 接收方接收到报文后，向接收方反馈收到报文（正确）与否。可以在正确接收时给予肯定确认（ACK），发现差错时给予否定确认（NAK)。
- 重传 发送方接收到否定确认时，将报文重新发送出去。
rdt2.0 FSM如图所示：
不难注意到，发送方在发送完数据后，即转入等待接收方发送确认报文的状态，此时发送方不能再发送新的报文段，除非接收方已经确认正确接受到发送的报文。定义这种行为的协议称之为停止-等待协议（stop-and-wait)。
2.1 如果接收方的确认发生比特差错？
rdt2.0似乎在这种情况下是完美的了？但我们忽略了确认分组发生比特差错的可能性。当接收方发送的NAK或ACK发生差错时，发送方该如何处理呢？一种简单的方法也是目前采用的方法是，发送方接受到含糊不清的确认分组时，直接重发上一个分组。
随之而来的问题是，如果接收方接受到一个受损的肯定确认分组（ACK）而重发上一个分组，接收方很可能把它当成一个新的分组而接收，这将使双方失去同步。
解决这个新问题的方法（几乎所有的数据传输协议都采用而方法）是，发送方对发送的数据编号，这需要在报文段的首部添加一个序号字段来标识它。
至此，我们引入了编号来区分发送的报文和重传的报文。
在停止等待协议中，我们只需要使用0和1来标识报文即可，接收方根据新接受的报文和上一个报文的序号是否相同，可以分辨出新到达的报文是否是一个重传的报文。
需要注意的是，由于停止等待协议的缘故，接收方并不需要知道收到的确认是对哪个序号的确认。
3.0 具有比特差错的丢包信道的可靠数据传输rdt3.0
现在除了比特受损，我们还假设信道可能丢包，这已经很接近实际情况下的通信信道了。
丢包导致协议面临着两个问题：
- 如何检测丢包？
- 如何处理丢包？
显然，rdt2.1已经很好地回答了第二个问题——重传。
现在我们只要解决第一个问题，如何检测丢包？
第一种情况是，发送的报文段丢失了，则接收方不知道该报文段的存在，也无法发送反馈报文。
第二种情况是，接收方发送的反馈报文（确认报文）丢失了，发送方接受不到反馈报文。
分析一下，丢包的结果似乎在发送方得到了统一，当丢包发生时，发送方无法收到确认。检测丢包显然是发送方的任务，那该如何检测呢，我们如何衡量丢包这一事件？
没错，当发送方在发送报文之后的一个时间间隔还没收到确认反馈时，即可认为发生了丢包现象，这个时间间隔显然至少为一个RTT，更具体的等待时间计算将在后面介绍。
基于时间的重传机制，发送方需要一个倒计数定时器，并且要做到：
- 每发送或重传一个分组，便启动一个定时器
- 能够响应定时器中断
- 终止定时器
找找看，这三个功能分别对应FSM图中的那个部分呢？
我们总结一下，通过检验和、确认分组、序号、定时、重发等技术的引入，我们得到了一个可靠传输协议
