TCP零基础入门（二）

不知道为什么上篇文章为什么就审核未通过了。我把我的上一篇文章《TCP零基础入门（一）》放到百度网盘了

 

链接：https://pan.baidu.com/s/10bZinu5w3CuA-KZYeCX90A 
提取码：cm5e

TCP就两个内容，面向连接，还有可靠传输协议，面向连接上回已经讲过，现在讲可靠传输协议。

首先说一下可靠是什么意思，是指比特信息完好，完整，按序到达。不可靠就是比特信息从0变成1，1变成0，或者丢失，或者失序到达。而不是信息是否泄露，安全协议是SSL，会对数据加密，防止被窃取。那么可以说TCP是可靠不安全的协议。IP层是不可靠的传输，TCP将在不可靠的下层上建立可靠的传输协议。（类比汉明码，通过足够多的检错位和纠错位，就能无误差传输）

我们按照《自顶向下》一书的逻辑，从RDT可靠数据传输协议来说。）

假设有两秘书代替两个公司的老板通过打电话的方式进行通信，A收到老板的信息，然后发送给B，B从手机里取出收到信息，发给B的老板，完成沟通。我们假设A和B都很老实，而且嘴巴耳朵都没毛病，听力良好，吐词清晰，收到什么信息都准确无误的给上级。这里也不需要有人监督秘书A和B的行为。这种方式最简单，叫RDT1.0，经完全可靠信道的可靠数据传输。

 假如B秘书耳朵有点不太好，每次A说什么话，B没听清除，把卖听成买，那老板岂不是亏大。于是B很谨慎，没听清的就会告诉A，“没听清，能否再说一边？”，然后A老老实实再回复一遍。这里面涉及到了两个东西：反馈和重传，B没听清出A，于是反馈。A重新再说一遍，叫重传，加上我们之前讲的报文段首部的“检验和”字段（差错检验），这三个东西共同构成了RDT2.0协议，经具有比特差错信道的可靠数据传输。也叫ARQ协议（自动重传请求，不过网上搜到的ARQ是链路层的协议，不知道书中为什么在传输层讲到)这个反馈机制可以是听清了反馈，也可以是没听清

（ACK和NAK),A从老板那里获得信息，传输给B，当B给A反馈的时候，A就要停止发送新信息，当B准确无误收到了A的信息，A才能发送新信息，这个过程叫“停等”。举个不恰当的意思，两个人顺序数数01，一个人数奇数，另一个偶数，0101，这时B数1的时候，数的不对，或者A没听到1，这时A不能数0，得等B数1才行。

现在考虑这种情况，假如反馈出了问题怎么办，B没听清A说的是什么，于是B说：“没听清，再说一遍”。由于TCP协议是双向的，反馈也是双向的，（双向的真实含义应该是我收的时候可以发，这里的双向应该改成双工，比如我们用对讲机讲话，那个也是双向，但是是半双工，因为我说的时候你不能说。听歌就是单工通信了。只能一向到另一向，所以也是单向）所以考虑这种情况，A听B的反馈，也没听清，那么A就会像B说“你说什么，我没听清，你再说一遍”，B这时听清了，“我刚才说的是，没听清，再说一遍”，于是A也再说一遍……当反馈也出错的时候，会让通话进行不下去，必须加以修正，我们叫RDT2.1协议，引入序号这个东西，区分出来分组是重传还是新的分组。RDT2.2协议又在2.1上进行了修正，读者可以自行搜索关键词。

RDT3.0又叫比特交替协议。2.0的情况下只有出错，消息没有丢失，当分组丢失这个情况出现后，为了让我们的协议还能用，必须修正RDT2.0，我们需要做的是，如何检测丢失分组，丢失后如何应对。我们对发送方设置一个倒计数定时器，当定时器变成0，我们还没有收到反馈，就可以认为发生了分组丢失，可以是反馈丢失，也可能是发送的信息丢失，但是都不管，一律重发分组，假如接收方已经正确接受到了分组，由于定时器到0了，反馈还没来，或者反馈丢失，这种情况我们重发的分组，就变成了冗余数据分组。定时器设置的值要保证分组从发送方到接收方，接收方处理，再返回到发送放的这个时间，才能减小冗余数据分组发生的可能。但也不能太大，否装会降低数据传输速率。因为停等的存在。

也是因为停等降低信道利用率，因为发送信号的时候相当于信号往返的时间很小，我们需要构造构造流水线发射，也就是说跟停等不同，只是连续的发送分组，而不用等到反馈到来的时候再发送。本质上是由于传输时延大概是传播时延的千分之一。

为了讲清楚怎么连续发送分组，必须先介绍发送窗口，网上找的图如下：

我给一个另外的解释，

蓝色方块表示已经发送的分组，对勾表示分组确认，设窗口大小为8个，也就是一次性可以发送的最大分组数，可以看到发送方还有2个分组待发送。其中未被确认的最小序号叫基序号base，待发送的序号叫下一个序号nextseqnum，假如我们发送完毕，并补上已经发送并确认的，如下图。

 当收到一个回复后，如下图

 

base将会前移，由于窗口大小为8，也就是能允许未确认的分组最大为8，于是窗口也前移，变换过程如下图

 

 

 

可以看出窗口内空余了一个空白的格子，于是可以发送一个分组，如下图

这就是滑动窗口协议。（有一点，这里我说的分组，其它资料会说的是链路层的帧）

总结一下，就是发送窗口内的分组，当收到一个确认分组，则窗口往前滑动，可继续发送分组。确认可以是累积确认，比如我收到了窗口内的第5个分组的确认，则表示前四个也已经确认，窗口移动5格。

流水线发送分组，当分组丢失了，应该怎么办，如下图

1	2	3	4	5	6	7	8
√	√	√

1-8分组都已经发送，但是只有123得到了反馈，当定时器超时后，45678全部再次发送一边，这就叫做回退N步。

（我看书看了很多遍这个选择重传部分，搜到的别人写的文章也很多，花了很大力气才弄懂，这里我刚搜到了一个视频，王道考研2020的书我看的差不多了，视频因为要付费，没有看过，给大家一个链接。讲的挺好的，计算机组成原理内存管理那里我就没看了，看书看的头疼，还是视频好，建议大家学习的时候以书本为主，视频为辅，先书籍后视频。我读大学都是自己提前看书，基本上老师讲之前我就看完了，题先提前做一点，书看不懂的画出来，然后上课在认真听，工作之后学习完全就是看书，也没看过视频，觉得废时间听他慢慢讲，只能说看视频容易困，你先看书，我就不信你书都看的懂了，看不懂的地方 去找视频看，这样会好些，扯太多了，发链接https://www.bilibili.com/video/av70228743?p=25，视频里说的也是帧，书里说的分组，你们自己取舍吧，我个人理解自顶向下的分组就是指每一层的单元，在网络层分组就是指的包，链路层说的分组就是帧）

假如5678其实已经被成功接受了，只有4丢失，（可能是发送方丢失，也可能是反馈丢失，无论哪一种，发送方再定时器到时后，都认为丢失分组，必须重传4），通过回退N步协议，还是要重发5678，这样信道内会有大量的重发分组，为了降低这种无用重发现象。我们要求接收方接受乱序到达的分组，比如4丢失5678都正常接受，这时接受方缓存5678，给4留一个空。这里引入一个叫接收窗口的东西。窗口大小为N接受，发送窗口的大小为N发送，这里我们假设发送窗口等于接收窗口。还有一点，之前讲的序号是一个重复利用的序列，且大小为窗口的一半，（为什么是一半是因为要区分是因为设定序号有大小限制，比如序号这个字段只给你2位，能表示的十进制数的范围就是0-3，那么窗口大小就是8，序号01230123这么循环，只有序号是窗口的一半才能让接收方分清我来的这个序号是重发还是新的。但是TCP首部的序号有4G个字节啊，序号编码我觉得完全够用啊，先这样吧，谁叫我搜到的资料是链路层帧而不是传输层的分组），而且发送方也没有累计确认这一说法了，就是接收到了3，那不是代表接收到了窗口内的0123四个，而是就只收到一个3。接收窗口内最小的序号就是RCV_BASE。

先上图吧，对于发送方，除了累积确认变成单个确认，其它都一样，我用蓝色表示已经发送的，绿色表示确认，

以后我就说帧而不是分组了，以免引起误会。

这种情况，比如来的顺序是230，当1号帧来的时候，窗口滑动，其实并不这样，我画完才发现问题，当base帧到来的时候，也就是窗口内最左边的确认号，也是下界，对于上图，最左边的是0号，当0号帧来，不必等1号帧来，窗口就开始滑动。如下图

总结就是，窗口内的序号，确认，假如这个窗口内的序号是下界，滑动窗口，滑动的步数就是连续确认的最大序号。

对于接收方，来一个帧确认一个帧，当帧是在窗口内的，则发送确认，当来的帧等于BASE的时候，就移动窗口，而不用等到窗口满再移动

如图，A段是已经确认，且已经交付给上层的帧,B段属于窗口，当窗口内的123来的时候，发送确认并缓存，当0来的时候，而不管123来没来，要滑动窗口。并交付连续的帧。如果上图中，已经来的A中的序号为1的帧，需要发送确认吗？需要发送确认，因为不发送确认，发送窗口没法移动。

回顾一下可靠传输协议里，我们引入了哪些东西。

刚开始假设信道是可靠的，发什么是什么，也不会丢失分组，那么就是rdt1.0

假如有比特错误的存在发送，要引入检验和，反馈，重传。错误用检验和检测，告诉发送方出错了用反馈，发送方收到反馈重传

假如反馈也有比特错误，在重传的基础上，还要引入序号用于区分重传的还是新发的这里属于rdt2.0和2.1

假如丢包了，在重传的基础上，还要引入定时器。rdt3.0

假如接收方觉得停等的发送速录太慢了，就要引入流水线。引入流水线后，帧的确认和重传又会出现问题，这里又引入了GBN回退N步和选择重传SR。回退N步是因为发送方没收到确认，只能退回去再发一遍帧。又由于可能接收方接收到了，但是确认发送方没收到，防止发送方又发一遍所有的未确认的帧，引入选择重传，选择重传的核心就是对于接收方逐个确认，来一个缓存一个，当帧等于base的时候滑动窗口。对于发送方，确认帧等于base的时候滑动窗口。

可靠传输协议就讲完了。这里TCP两点都说明完了。有的人会说，TCP协议不是还有流量控制和拥塞吗？这个我们下次讲。