Chapter3：DataLinkLayer_LLC：计网笔记
Chapter3：DataLinkLayer_LLC
3.1 数据链路层概述
-
数据链路层的作用
跨过物理网络，试图实现可靠的通信。数据链路层在物理层连接上提供一条高效可靠的逻辑连接，为网络层提供服务。
Data Link Layer的作用 Data Link Layer的两个子层 1. 实现frame数据帧的可靠传输 LLC: Logical Link Control sublayer 逻辑链路控制子层【上】 2. 实现共享信道的竞争问题 MAC: Media Access Control sublayer 介质访问控制子层【下】 -
数据链路层要向网络层提供服务：【我觉得指的是：不同的网络应用场景对网络的质量有不同要求】
-
非确认【发送方只管发送，不管对方是否收到】、无链接的【没有连接，直接发送】。
适用于出错率很低的通信，这样能大大减少控制文件的数量。
适用于对出错率无所谓的应用，就是出错一些没关系，不影响它的应用。
-
确认的【接收方要给发送方一个“收到！”】、无链接的
适用于不可靠的信道，即：易出错，所以要确认
-
确认的、有链接的
适用于：确认所有的frame都要收到，一个都不缺。
并且每一个都被接受一次，没有重复。
-
数据链路层的知识覆盖：
- Framing
- Flow control
- Error control
- Shared channel
- Competition/access
-
Framing帧的形成
DLL从上一层【Network Layer网络层】获取packets，然后加上header、trailer 就变成了frame
再通过下一层【物理层】传输frame.
接下来就是：发送方的DLL，传输frames，到接收方的DLL。
-
传输中的理想情况与实际情况
同时满足假定一和二就不需要协议，但理想情况是不存在的，所以肯定要有协议：流量控制、差错控制
流量控制：防止发送方一直发一直发发的贼快，接受方来不及处理。
差错控制：总是多少会出错的，噪音失真衰减。
-
QoS网络的服务质量
服务性能的集体效应，它决定了用户对网络服务的满意度。
例子：Waterfall照片的不同出错率的接收效果。
3.2 差错控制
-
Error Control 差错控制
物理网络是一个不靠谱的通信，我们要进行计算校验和checksum：
双方事先商量了一套相同的检验算法。发送方：发送数据 + 校验和checksum，接收方：重新计算校验和，并与发送方的checksum对比，若不同则判断数据出错。这时候可能要求重发，也有可能接收方自己纠错。
差错控制涉及到Framing数据帧的形成：
发送方发送的是一连串的bits，接收方如何判断不同Frame之间的边界呢？共有四种方法，但我们比较常用的是Bit Stuffing 位填充的方法【使用特定的位模式来表示一个数据帧frame的开始和结束】。
尝试1：用0111隔开。【注意frame里还包了header/packet/trailer】存在问题：如果frame里面也有0111呢？
解决方法：发送方在frame中逐位检测。如果出现连续n个1，那么在后面插个0；接受方收到时也逐位检测，发现连续n个1后面接个0的时候，去掉这个0
例子：连续五个1后加一个0
3.3 流量控制：
-
流量控制
在处理数据时，接收方为来自发送方的数据保留一些缓冲区空间；如果发送方发送数据的速度比接收方处理数据的速度快，那么就会出现缓冲区overflow
解决：接收方主机来通知发送方：你啥时候该发，发什么——停止等待协议
3.3.1 Stop and Wait Protocols（停止等待协议）
尝试1：A发frame1，B接受到后确认，A再发frame2，B接受frame发现有错，说一句nak，A就重发frame2
问题1：如果连续两次、三次、很多次都出错呢？那么就得一直重发，get trapped！那么怎么办呢？尝试2：限制一个最大重发次数。
问题2：若网络太差了，A发送的frame半路丢失了，B根本没收到，A就不可能得到B的回复
尝试3：设置一个timeout timer超时计时器，若一段时间内A没有得到回复，那么A就重发一遍。
问题3：重发的Frame或许会被B重复接收
尝试4：给每一个Frame分配一个sequence numbers序列号。B就能区别是否重复。如果不同，正常接收，如果相同，也要回复一下A，不然A以后可能还会重发导致效率变低。
最终三点：最大重发次数【max. number】、超时计时器【timeout timer】、序列号【sequence numbers】
ARQ协议【Automatic Repeat request】
内容：发送方在进入下一个数据项之前，一直等待确认，的协议通常被称为ARQ(自动重复请求)。
代码：见ppt
缺陷：ARQ协议的 link utilization rate 链路利用率 太低了。
- 链路利用率的例题——PPT43+ 很重要！
计算链路利用率：见ppt【其中 t a c k t_{ack} tack远小于 t f r a m e t_{frame} tframe，所以就没有参与计算Total delay】算出 T d 和 U T_d和U Td和U
例子1：注意单位换算。结论：frame大小为160bits的时候，效率是50%
例子2：不要想当然，注意协议效率的问题。
例子3：球同步卫星的例子【联想到记者前方连线说话会有延迟】【round-trip代表往返】
发送方发数据用1000/50=20ms，传输到接收方要250ms，接收方再回复要250ms,效率4%
3.3.2 Sliding Window Protocols (滑动窗口协议)
停止等待协议效率太低了。想到新的解决方法。
比如我这里一次性发5个帧【之前是1个帧】
限制（已经发出，但是还没有收到对方的回应的）帧的数量
停止等待协议 是 滑动窗口协议 的一个特例（frame=1）！
具体过程看ppt71+，很清楚
n个帧允许发送方连续发送且不需要应答的。每一个帧都必须有一个sequence number，记录在数据帧的头部，且序列号不用太长。发送和接收方都需要维护sequence number。
假设占用 k 位来做序列号，那么我们可以得到几个序列号呢？ 答案很明显
效率方面：
我们用滑动窗口协议来解决之前的问题，这里设N=26
当第26个帧发送结束后，发送方接收到第1个帧的回复，理论上效率100%，但忽略了发送方发送的ack的时延。
那我们需要几位序列号呢？5位就ok了，因为2的5次方= 32 >26 真正用起来应该要取模MOD。
3.3.3 Go Back n（后退n帧协议）
问题：如果N=5,1245都是对的，3是错的，那该怎办？==》Go Back n 后退 n 帧协议
扔掉出错帧后面的所有帧，从出错帧开始重发。把指针拨回去。
优点：控制简单。缺点：浪费链路资源，万一重发的里面又有出错的呢？
改进：发送方n窗口，接收方1窗口。每次接受1个，若3出错了我就一直等3一直等3。但还是有些浪费链路资源
3.3.4 Selective Repeat选择性重传
-
由于选择性重复,只有那些被损坏的帧被重新发送，但 接收方必须有足够的缓冲空间,可以从发送方那里存储所有优秀帧。
优点：链路资源浪费少
缺点：要开辟比较大的缓冲区。 -
Go Back n 和 Selective Repeat
当出错率小，网络环境干扰小，比如校园：选 Go Back n
当出错率大，网络环境干扰大，比如工厂：选 Selective Repeat
3.3.5 双向通信
到目前为止，我们看到的协议都是单向发送数据。当然，数据通常是双向流动的。
在这些frames上piggyback acks是有意义的。
这节省了发送单独的帧来携带ACK所涉及的开销。
当然，如果没有帧返回，我们将别无选择，只能返回一个单独的ACK帧。
3.4 差错控制
3.4.1 概述
接收方收到数据帧后怎么知道数据出错了没？
两种差错：
1.Lost frame 面目全非了（头部信息都出错了）
2.Damaged frame 有一些损坏但仍能得到一些信息
检错、确认、纠错
方法1：检错-重传：发送方只包含足够的冗余，允许接收方推断出发生了错误，但不包括哪个错误(错误检测代码); 接收者让它请求重传。
方法2：前向纠错：要确认有错，还要确认哪一位出错。
若面目全非了：接收方一脸懵逼，因为收到了这个啥也不清楚的数据帧。如何解决呢？发送方：超时重传。但这种方法也带来了问题：同一个数据帧重复接收。【确认帧丢失的情况下】。发送的重复帧和之前的帧采用同一的sequence number
3.4.2 三点
(1) Acknowledgements确认
(2) Timers计时器
要考虑三点：1.发送方到接收方的传输时间 2.处理的时间 3.确认帧back的传输时间
所以Timers设的时间要＞三者之和。否则？
但是不能太大：会显著降低通信系统的效率。
NACK：有些系统如果发送方收到了接收方的NACK，那么可以不用等Timers了，直接重传把。当然也有系统就按Timers算，不用烦了。这取决于不同的TCP/IP协议。
(3) Sequence Numbers序列号
避免duplicate frames
3.4.3 CRC 循环冗余校验
循环冗余码【A cyclic redundancy check (CRC) 】是一种复杂的checksum。
如果使用了CRC，错误一定溜不掉。
虽然该技术看起来有点复杂，但在实际中计算CRC很简单，可以在硬件上实现。
具体见ppt118+