可靠传输协议

《计算机网络-自顶向下方法》配套小程序链接

Q&A

（一）可靠数据传输

Q1:可靠传输协议实现step by step
（1）假设底层信道不会传输错误时：

（2）底层信道有可能出现比特受损，加入检验机制(如UDP检验和)，如果接受方发现信息错误，则发送NAK，发送方重传，正确则发送ACK，这种模型的问题是发送方无法处理ACK/NAK分组受损的情形。
（3）面对ACK/NAK分组可能受损的情形，发送方有三种解决方案
1、要求接受方重新发送ACK/NAK，直到不出错为止
2、面对ACK/NAK错误的情况，直接重传报文
3、给ACK/NAK分组加上校验和，使发送方能够修复受损的ACK/NAK分组
现代传输层协议采用的大都是第二种方案，但缺陷是接受方可能会收到重复分组，为此采用了序号方法，如果接受方发现收到序号重复的分组，则直接丢弃。
当接受方等待序号的0的分组时收到序号为1的分组时(或相反)，需要发送ACK，如果不发送，发送方的状态会一直停留在等待ACK的状态，陷入死锁，NAK实际上可以省略掉，如果接受方发现数据包损坏，可以发送最后一个完好的ACK。

（4）之前的假设没有考虑到底层信道丢包的情况，考虑到这种情形，可靠的传输层协议应该考虑面对这种情形，即如何检测丢包并做出应对。
一种解决方案是设定往返时延，如果超出设定的时间发送方还没有接收到确认消息，即重传分组，序号机制能够处理这种情况下重传分组的情形。
这种解决方案的问题是性能较差，因为这是一个停等协议，因此可以使用流水线优化传输层协议，提高性能。

（5）使用流水线机制优化传输层协议
相较于停等协议，流水线机制需要
1、更大的序列号范围
2、发送和接收方更大的缓存空间，混存更多的分组
为了使用流水线机制，计算机网络中使用了滑动窗口机制, GBN和SR协议基于此。

Q5:回退N步(GBN)协议？
GBN功能演示程序

窗口尺寸N（Window size）：代表最多可以有N个分组未得到确认，因此序号范围为0～N-1
如果第n个分组在传输的过程中丢失，但n+1个分组到达接收方，GBN协议规定接受方要丢弃第n+1个分组。

Q6:选择重传(SR)协议的优势与缺陷？
SR功能演示程序
GBN协议的缺陷：一旦一个分组没有收到，序号后收到的分组也会重传，造成网络拥堵。
改进：只重传没有收到ACK的分组 ——选择重传
实现方法：为每个分组单独设定计时器，接收方的窗口长度不再是1，而和发送方一样。
注意：序号范围和窗口长度不等同！
SR协议相比GBN的问题：GBN接受方收到不连续的分组会将其丢弃，而SR不会。假设窗口长度为3，序号范围为0～2，想象以下情形：分组0，1，2被发送方正确接收，然而三个ACK在传回接受方的过程中损坏，timeout和发送方重传0，1，2分组。此时接收方等待的也是序号为0，1，2的分组，因此会正确接收。但是！此0，1，2是上一回合的，而接受方只能根据序号进行判断，因此产生接收错误的问题。
产生问题的根本原因：在GBN协议中，接受方的窗口长度为1，只有当目标序号的分组达到且正确才会发送ACK，不会产生对应错误的问题。而在SR协议中，接受方的窗口长度不再是1，
当序号范围小于窗口长度时，接收方可能发生序号和目标分组对应不上的情况。
解决方法：发送方窗口尺寸+接受方窗口尺寸 <= 2^k,k为序号的位数。

(二)TCP与UDP

Q1:UDP与TCP的差异？
（1）TCP是面向连接的全双工协议，只支持“点对点”，TCP的socket用四元组表示，相较于UDP，多了源ip和源端口号。
（2）TCP有拥塞控制和流量控制机制

Q3：UDP与TCP的报文段结构？
UDP：首部四个字段，每个字段两个字节，length为UDP报文的字节数，接受方用检验和来检查数据是否出现差错。发送方对报文中所有16bit的和做反码运算，溢出回卷，生成检验和，存储到UDP报文的头部。接收方也对报文中16bit取和，然后与检验和相加，如果结果不是16个1，则说明报文内容在传输中出错。

TCP：
Sequence number(序号)和Acknowlegment number(确认号)字段被用来实现可靠传输机制；
Receive window(接收窗口)字段被用来做流量控制，用来指示接受方愿意接受的字节数量；

序号：TCP的序号字段是文段的首字节编号，而不是GBN和SR里面的序号；
确认号：TCP的确认号字段是希望从发送方得到下一个字节流的序号，体现TCP的累积确认机制；

Q4:选择UDP而不是TCP的原因？
（1）TCP建立连接所需三次握手，拥塞控制机制，可靠性，导致时延较UDP长；
（2）TCP报文首部较UDP大12字节（TCP20，UDP12）；
（3）TCP维护连接状态需要接受和发送拥塞参数等信息，而UDP不用，因此能够支持更多的活跃客户
常见应用层协议的传输层协议选择：

Q5:TCP RTT设置,快速重传
如何设置超时？
（1）EstimatedRTT：多次发送样本RTT，用样本RTT往返时间设置超时间隔。
公式：

（2）测量RTT变化：
公式
超时时间间隔应大于EstimatedRTT，但又不能大太多，因此就用到了DevRTT，TCP时间间隔计算公式如下：

快速重传机制：通过冗余ACK检查到分组丢失，TCP规定当遇到3个冗余ACK即重传，而不必等待定时中断。

Q6:TCP是采用GBN还是SR？
TCP可以看成是GBN和SR的综合体；
和GBN相似的地方在于：都采用了累积确认机制，TCP头部包含序号字段和确认号字段，累积确认机制由接受方返回给发送方的段中包含的确认号体现。
和SR相似的地方在于：都在接收方设置缓存，接收方返回当前收到最大的ACK

Q7:TCP流量控制机制？
为防止接收方缓存溢出，TCP使用了流量控制机制。
实现方式是发送接受两端维护一个窗口，LastByteRead表示对方从缓存读出最后一个字节的编号，LastByteRcvd表示对方缓存接收的最后一个字节的编号 ，
LastByteRead-LastByteRced表示当前接收方向上层完整交付所需的缓存大小，值必须小于等于缓存的大小，发送方限制已经发送但还未收到ACK的数据不超过这个值。

当接受方告诉发送方RcvWindow为0时，此时接受方的缓存已满，这样会陷入死锁，因此TCP规定发送方仍然可以发送一个很小的段，返回接受方的缓存大小信息。

Q7:TCP连接的建立？
TCP连接的建立要经过“三次握手”
（1）客户向服务器发送了一个SYN报文段（TCP头部SYN位被置1），随机选择一个初始序号client_isn放入序号字段，是为一次握手
（2）服务器向客户返回响应的报文段，SYN同样被置1，确认号client_isn+1,服务器选择自己的初始序号server_isn，放入序号字段，服务器会为连接分配缓存等资源，是为二次握手
（3）客户再向服务器发送第三个报文段，SYN被置0，可以携带数据，是为三次握手。
图示：

注：SYN洪泛攻击：当大量客户向服务器发送建立连接的请求，却不执行第三次握手，因为在第二次握手时服务器就会为连接分配资源，因此会造成灾难性的后果。

Q8:TCP连接的释放？四次挥手
TCP两端的进程都可以终止连接。
（1）想要关闭连接的客户向服务器发送一个FIN位被置1的报文段。
（2）服务器向客户发送确认报文段
（3）服务器向客户发送自己的终止报文段，FIN被置1.
（4）客户向服务器发送确认报文段

Q9:拥塞控制和流量控制的关系？
流量控制是指发送方不要发送的太快使接收方无法处理
拥塞控制是指控制网络中的拥堵情况

Q10：拥塞控制原理？
分几种场景讨论，假设网路由两台发送主机，一台路由器，两台接收主机构成。
（1）假设中间路由器有无限缓存，网络中吞吐率则只与路由器出口带宽有关，应先线性增长然后不再变化；而时延则随着接近路由器带宽呈指数增长。

吞吐率，横坐标是发送速度，纵坐标是路由器处理速度：

时延：

（2）当缓存不再是无限大，当数据过快到达会发生缓存溢出的情况，因此发送方需要重传。当发送方发送速率大于R/2时，由于发生了重传，吞吐率会低于R/2，重传现象越多，吞吐率越低。
（3）假设有四个发送方，四个接收方，四个中间路由器（多跳），这种情况下由于竞争现象加多了分组丢失，会发生一旦下游分组丢失，上游的存储转发也被浪费，此时的吞吐率图像如下：

面对上面这种情况，如何设计处理机制？思想是控制发送方的发送速率，有两种设计方法
（1）端到端拥塞控制，通过host观察网络行为判断是否发生拥塞，进而控制发送速率，TCP采用的就是这种方法
（2）网络辅助拥塞控制，路由器向host反馈网络拥塞信息，ATM ABR采用的是这种方法。

Q11：TCP拥塞控制机制？
思路：通过丢包感知网络的拥塞，感知后降低发送速率
（1）TCP发送方如何感知到丢包？
1、发生超时 2、收到3个冗余ACK
（2）TCP如何调整发送速率？两种机制
1、AIMD
加性增：没丢包前，逐渐增加发送速率，探测可用带宽，直到发生loss。
乘性减：一旦丢包，说明发生拥塞，直接将发送速率减半。
图像：

2、SS（slow-start），慢启动
背景：可用带宽往往远远高于初始值，因此如果开始线性增长的话，可能需要很长时间。针对这种情况，设计了慢启动机制，在开始时指数增长,算法如下：

如何由指数增长切换到线性增长？将threshold设置为上次loss时拥塞窗口值的1/2，如果再次发生丢包，threshold也需要进行更新。而在此丢包后的拥塞窗口更新则分情况看
1、丢包是因为3次ACK，表明拥塞没那么严重
拥塞窗口(发送速率)切换到之前的一半，然后线性增长
2、丢包是因为timeout，表示拥塞比较严重
拥塞窗口直接切换到最小值，然后指数增长，到达threshold后线性增长

（3）TCP拥塞控制算法：
先指数增长发送速率，到达threshold后线性增长。发生丢包，将threshold变为之前的一半，如果丢包是因为3个ACK，则将发送速率切换到之前的一半；如果是timeout，切换到一个MSS。