由于个人精力和智商有限，又喜欢想太多、钻牛角尖，导致学习系统性知识很痛苦，尝试改变学习方式，慢慢摸索
现在看到 rdt2.0，又有点看不下去
现在的想法：
要有个目标，且有截止时间（作业模式、考试模式），在过程中，如果遇到对整体没有致命影响的难点，可以暂时跳过，在特定时间内把目标内的其他地方解决即可（即先解决简单的其他部分，在考虑进攻难点，这样的话，前期心态不会太焦灼，而且等回过头进攻难点的时候，有一种从四面八方将难点包围的感觉）
写博客也换个思路：
边写博客，边摸索写博客的方式，而且可以把摸索过程也记在博客里
记录一下本章的说明问题的思路，值得学习
大思路：
由于一个能提供可靠数据传输和拥塞控制的协议必定是复杂的，采用基本原理与 TCP 交替介绍方式（从一般走向具体）
在一般环境下讨论可靠数据传输，然后讨论 TCP 是怎样具体提供可靠数据传输的
在一般环境下讨论拥塞控制，然后讨论 TCP 是怎样实现拥塞控制的
小思路：
在讨论可靠数据传输原理的时候，将底层信道从理想状况逐步向现实情况靠拢，进而逐步引出相关概念
从简单模型到复杂模型，一点点把复杂的事情说清楚
本章整体情况
理想情况到现实情况分别是：
理想：底层信道完全可靠（比特不受损，分组不丢失，比特不会被重排序）
现实一：底层信道会让比特受损（比特受损，分组不丢失，比特不会被重排序）
现实二：底层信道会丢包（比特受损，分组丢失，比特不会被重排序）
注意，本章贯穿始终的一个假设是分组将以它们发送的次序进行交付，某些分组可能会丢失，即底层信道不会对分组重排序
理想情况：发送发和接收方只需做简单的发送和接收操作就行了（对应协议：rdt1.0）
现实一需要的技术：检验和、肯定和否定确定、重传、序号、ACK 分组（对应协议：rdt2.0）
现实二需要的技术：检验和、肯定和否定确定、重传、序号、ACK 分组、定时器（对应协议：rdt3.0）
由 rdt3.0 的缺点（停等协议，链路利用率低），引入流水线可靠数据传输协议
为了保证是流水线可靠数据传输协议的有效性（主要是为实现其差错回复功能），引入回退 N 步的的方法
而回退 N 步的方法，可能会导致一些性能问题（一个出错，之前的全部需要重传，如果失败率较高，则可能导致信道中充斥着冗余的分组），于是引入了选择重传的方法
有一点值得注意的是
我们一般写程序都不用考虑这么多，是因为我们选择了 TCP 协议，虽然 IP 层（即网络层）及以下是不可靠的，但是运输层的 TCP 帮助我们解决了这些不可靠，使我们可以专注于开发应用程序，而不用担心数据是否会按照预想、没有误差到达目的地
以下是对我来说有用的零散知识点：
最简运输层功能：
进程到进程的数据交付、差错检查
附加功能：
可靠数据传输、拥塞控制
运输层协议只运行在端系统，而不是路由器中，运输层协议将报文在应用进程和网络边缘（即网络层）之间移动（在发送方，移动方向是 应用进程→网络边缘；在接收方，则反过来）
网络层为主机之间提供通信，运输层为不同主机上的进程之间提供通信
多路复用与多路分解
看微信“文件传输助手”中的聊天记录
IP 层是不可靠的
把这次看不懂的地方记录一下：
对于协议 rdt2.1，有个问题想不明白：
接收方成功接受了分组 0，向发送方反馈了一个 ACK，而由于比特受损，发送方收到了一个含糊不清的回复，于是发送方重传了分组 0，而此时接收方已经在等待分组 1 到的了，这样的话，当接收方在此接收到分组 0 的时候（与预期的分组 1 不符），会给发送发返回一个 NAK，发送发以为重传分组 0 失败，继续重传分组 0，而接收方此时预期接收的还是分组 1，于是造成了一个死循环
这种情况会发生吗？是不是我没有完全看懂协议 rdt2.1？