大白话了解TCP协议：了解TCP？先别急，来看看TCP的前世——“最简单的”可靠传输协议：停止等待协议

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发送确认的时间

网络协议限制了物理资源的利用!

所以为了解决这个问题：滑动窗口协议就应运而生（明日继续）

有兴趣的欢迎看看连载的下一文：

大白话解释TCP协议：等等，还有一些TCP协议的基础：滑动窗口协议

大白话了解TCP协议：TCP报文段首部的盛世美颜！？