TCP是可靠传输协议的衍生、拓展
先了解可靠传输协议的基本概念就可以非常轻松得了解TCP协议了！
这是个有安全感的协议类型~
在漫长的线路中，这些数据要经过路由器、网线，甚至还有风风雨雨……数据就很容易遇到挫折一蹶不振……造成数据丢失、数据错乱等等。
比如：小明发给小红：你好！
数据走着走着就错乱了
结果小红啥都没收到
于是故事还没开始就已经结束啦
所以，可靠的传输十分得重要。
可靠传输协议就应运而生：它就是要保证小红收到的数据一定一定要是正确的、按序的，不能有错的！
可靠传输协议虽然不一定能保证数据一定到达（要是网线断了谁也没法保证是吧），但它能让对方知道数据没了。
妥妥的可靠，比某UDP可靠多了
可靠传输协议表示的是一类协议，它是一个big 伐木累。
数据链路层、网络层、应用层都可以用
可靠传输协议家族最简单的：停止等待协议的成长历程
加入有发送方A和接收方B
如果传输的时候，毫无问题，网络通畅~ 就是下图左边的情况。
如果传输的时候，数据有损失了，接收方等啊等、迟迟等不到发送方的确认，等不下去了没耐心了，就只能重传了~如右图所示
所以停止等待协议的概念就是：发送方A收不到接收方B的确认，它就停止它的等待，重新发包
思考：数据会不会出错呢
你看它这过程，都没有管数据对不对，就管丢不丢包。
所以：目前为止，数据在传输中可能会出错，但不会丢失！
既然会出错，就增加个差错机制呗。
产品经理：嗯？有需求？程序员，加！
程序员：……（靓仔语塞）
还是和上次说UDP一样：没有什么100%可靠的纠错算法。
好了我知道包错了，那么我该如何去让它的包是对的呢？
那还不简单，告诉A：“你的包出错了，再发一个”
于是就有了反馈机制和重传机制（也叫缓存机制）
- 接收方告诉发送方你的包错了，给了发送方反馈，就是反馈机制。
- 之前的包在发送方那里都有缓存，收到错误的信息（NAK）后就从缓存中调出对应的包重新发送。
- 直到收到确认（ACK）
数据总是再错误的路上越走越远：如果ACK或者NAK错了怎么办噢T…T
这个停止等待协议在慢慢成长：于是它给自己的包编上了序号：
过程是这样的：
- 发送方有很多分组，发送0号分组
- 接收方收到了0号分组，发送了0号确认，并且期待发送方的下一个分组：1号分组。
- 发送方收到了，发1号分组
- 接收方发现1号分组错了，就发0号的确认
- 发送方收到0号确认，就重新发送发1号分组
- 接收方终于收到对的了，发送1号分组确认。
- 但是这确认又错了，发送方重新发送1号分组。
- 这回收到对的，发送方收到 的确认也是对的
- 然后发送方就开始发下一个分组
我们都是在讲A出错了，那B出错了咋办。
B出错了，就是B发送的确认A收不到。要么丢失了、要么迟到了。
如果确认丢失了，那和上面的一样，A等不下去看再发一个包。
如果确认迟到了，再次收到和之前相同的确认就当没发生过一样。
所以：数据超时不一定丢失
特殊情况
这个情况比较迷，拓展
这样就会造成错误，所以我们需要更加复杂的编号机制来防止编号重复问题。
但是这样就像单线程一样、信道的利用率太低了
下图TD是指A发送所需要的时间、RTT是往返时延、TA是B发送确认的时间
网络协议限制了物理资源的利用!
所以为了解决这个问题：滑动窗口协议就应运而生（明日继续）
转载：https://blog.csdn.net/ZripenYe/article/details/115916561