[HITCN]哈工大2020秋计算机网络复习笔记 (4)
文章目录
- 3 传输层
-
- 3.1 多路复用和多路分用
-
- 3.1.1 无连接的多路分用
- 3.1.2 面向连接的多路分用
- 3.2 无连接传输协议UDP
- 3.3 可靠数据传输
-
- 3.3.1 可靠数据传输原理
- 3.3.2 RDT
-
- 3.3.2.1 RDT1.0
- 3.3.2.2 RDT2.0
- 3.3.2.3 RDT2.1、2.2
- 3.3.2.4 RDT3.0
- 3.3.3 滑动窗口协议
-
- 3.3.3.1 流水线机制与滑动窗口协议
- 3.3.3.2 GBN（Go-Back-N）
- 3.3.3.3 SR (Selective Repeat)
3 传输层
网络层提供主机之间的逻辑通信机制，而传输层提供应用进程之间的逻辑通信机制
3.1 多路复用和多路分用
- 多路复用（发送端）：从多个Socket接收数据，为每块数据封装上头部信息，生成Segment，交给网络层
- 多路分用（接收端）：传输层依据头部信息将收到的Segment交给正确的Socket，即不同的进程工作方式：
- 主机接收IP数据报：每个数据报携带源IP地址和目的IP地址，还携带一个传输层的段(Segment)，每个段携带源端口号和目的端口号
- 收到Segment之后，传输层协议提取IP地址和端口号信息，将Segment导向相应的Socket：网络层不关心端口号信息
3.1.1 无连接的多路分用
- 利用端口号创建Socket
- UDP的Socket用二元组标识：(目的IP地址，目的端口号)
- 主机收到UDP段后检查段中的目的端口号，将UDP段导向绑定在该端口号的Socket，所以只要目的IP和目的端口号相同，来自不同源IP地址和/或源端口号的IP数据包被导向同一个Socket
3.1.2 面向连接的多路分用
-
TCP的Socket用四元组标识：(源IP地址，源端口号，目的IP地址，目的端口号)
-
接收端利用所有的四个值将Segment导向合适的Socket
-
服务器可能同时支持多个TCP Socket，每个Socket用自己的四元组标识：Web服务器为每个客户端开不同的Socket，可能创建多个进程，每个进程一个Socket；也可能创建多个线程，每个线程一个Socket
3.2 无连接传输协议UDP
UDP基于IP协议,解决了复用/分用、简单的错误校验两个问题，UDP协议不可靠，数据可能丢失，可能非按序到达
在应用层增加可靠性机制以实现可靠的数据传输（增加了实现难度）
无连接：UDP发送方和接收方之间不需要握手；每个UDP段的处理独立于其他段
-
优点：无连接减少了延迟（DNS使用UDP的原因），并且无需维护连接状态因此实现起来也简单；头部开销少；没有拥塞控制，应用可更好地控制发送时间和速率
-
用途：流媒体应用、DNS、SNMP
-
UDP报文段格式：
![[HITCN]哈工大2020秋计算机网络复习笔记 (4)_第1张图片](http://img.e-com-net.com/image/info8/9e6c2f8658314cfb85fe33ce566fcad2.jpg)
-
校验和checksum
目的：检测UDP段在传输中是否发生错误（如位翻转）
发送方：计算前将校验和字段设为全0，然后将段的内容视为16-bit整数，(校验和计算)计算所有整数的和，进位加在和的后面，将得到的值按位求反，得到校验和；将校验和放入校验和字段
接收方：计算所收到段的校验和，将其与校验和字段进行对比：不相等——检测出错误；相等——没有检测出错误（但可能有错误）
3.3 可靠数据传输
信道的不可靠特性决定了可靠数据传输协议(RDT)的复杂性
3.3.1 可靠数据传输原理
-
发送方调用
rdt_send()将待发送数据交给可靠数据传输协议 -
可靠数据传输协议调用
udt_send()将数据发送给传输层 -
数据发送到接收方的传输层，调用
rdt_rcv()将数据传给可靠数据传输协议 -
RDT整理后调用
deliver_data将完整的数据发给接收方上层应用
第2、3步的通信都是双向的，以保证传输数据的完整性（可靠性）
3.3.2 RDT
3.3.2.1 RDT1.0
可靠信道上的可靠数据传输协议
假设底层信道完全可靠，无丢失无错误，因此双方无需进行控制信息的传递，发送方只需把消息发送一次即可，接收方收到的消息即是完整的消息。
3.3.2.2 RDT2.0
可能产生位错误的信道上的可靠数据传输协议
利用校验和检测底层信道可能翻转分组中的位错误，双方要进行控制信息的传递以纠正错误：
- ACK (确认机制)——接收方显式地告知发送方分组已正确接收；
- NAK——接收方显式地告知发送方分组有错误，发送方收到NAK后，重传分组
基于这种重传机制的rdt协议称为ARQ(Automatic Repeat reQuest)协议
Rdt 2.0中引入的新机制：差错检测；接收方反馈控制消息: ACK/NAK；重传
在实现的过程中，利用了停-等协议，即发送方发送了一个packet后，只有在收到来自接收方的确认消息后才能继续下一步操作。
3.3.2.3 RDT2.1、2.2
在RDT2.0中没有ACK/NAK消息发生错误/被破坏的处理方案，于是提出了新的解决方案
-
RDT2.1
如果ACK/NAK坏掉发送方就重传，但这有可能会产生重复分组，所以RDT2.1为每个分组增加了序列号（使用0，1标识——基于停-等协议），所以接收方可以根据序列号丢弃重复分组
相比与2.0，发送方为每个分组增加了序列号，并且需要检验ACK/NAK消息是否发生错误，而且由于状态必须“记住”“当前”的分组，所以序列号FSM的状态数量翻倍；接收方需要判断分组是否重复即是否收到了期望的序列号
-
RDT2.2：无NAK消息协议
在RDT2.1的基础上删除NAK，接收方通过ACK告知最后一个被正确接收的分组，在ACK消息中显式地加入被确认分组的序列号，发送方收到重复ACK之后，处理方式与收到NAK相同，重传当前分组
3.3.2.4 RDT3.0
如果信道既可能发生错误，也可能丢失分组
在这个协议中，引入了定时器，发送方会等待合理的时间，如果时间内未收到ACK，则重传，而如果分组只是延迟而不是丢了也同样会引发重传，但序列号机制能够处理这种问题
Rdt 3.0能够正确工作，但由于停-等操作规定了需要等待接收方响应之后才进行下一步操作，所以性能很差
3.3.3 滑动窗口协议
3.3.3.1 流水线机制与滑动窗口协议
由于RDT3.0的性能限制在于等待ACK消息的过程中带宽资源闲置，所以在流水线机制下，允许发送方在收到ACK之前连续发送多个分组，因而也需要更大的序列号范围，发送方/接收方需要更大的存储空间以缓存分组
滑动窗口协议 (Sliding-window protocol)：窗口是允许的序列号的范围，窗口尺寸为N表示最多有N个等待确认的消息。随着协议的运行，窗口在序列号空间内向前滑动（序列号会越来越大）。
主要的滑动窗口协议：GBN、SR
3.3.3.2 GBN（Go-Back-N）
发送方：分组头部包含k-bit的序列号，窗口尺寸为N，即最多允许N个分组未确认，如果上层应用发来的数据没有可用的序列号时调用refuse_data(data) 拒绝。
ACK(n)：确认到序列号n(包含n)的分组均已被正确接收——累积确认
为空中的分组设置计时器(timer)，超时Timeout(n)事件：重传序列号大于等于n，还未收到ACK的所有分组
接收方：无缓存，只需要记住唯一的expectedseqnum (期望序列号)，对于乱序到达的分组直接丢弃，重新确认序列号最大的、按序到达的分组
ACK机制: 发送拥有最高序列号的、已被正确接收的分组的ACK
3.3.3.3 SR (Selective Repeat)
GBN的丢失信息会导致所有序列号高于已经确认的序列号的包全部重发，因而造成资源浪费。在GBN的基础上改进得SR协议：
-
发送方只重传那些没收到ACK的分组，为每个分组设置定时器
-
接收方对每个分组单独进行确认，设置缓存机制，缓存乱序到达的分组，设置一个接收方窗口，将乱序到达的分组缓存，等待前面的分组到达后与前面的分组一起合并和交给上层
- 收到在窗口内的分组时先发送ACK(n)，再判断是不是乱序到达的分组，是就缓存，不是就合并交付移动窗口
- 收到窗口左侧的分组发送ACK(n)
- 收到窗口右侧的分组忽略
序列号空间大小与窗口尺寸需满足：NS+NR<=2k