用户投稿任何通讯协议在传递封包时都有可能因为外在因素导致封包遗失或是封包损毁导致传送失败，如果是不太重要的封包那还好，但如果是极度重要的资讯（转帐, 密码...) 的话，传送失败很有可能造成严重的后果，所以 Reliable Transmission 就诞生了，其目的就是为了保障传递封包的正确性与可靠性，详细的内容就继续看下去吧。
Reliable Transmission
在传递封包的过程中会因为各种原因的干扰导致封包损毁，为了避免收到损毁的封包，通常会进行 CRC 的检测，而也有一些封包会多添加资讯用于当错误发生时可以明确的知道错误发生在哪里，但相对的这种作法的负担也会比较高。
而如果今天某一个封包非常重要，那么就需要再检测到封包损毁的时候再次发送一次，这个行为就称为 Reliable Transmission ，通常会用两种方法确保 Reliable Transmission 行为。
Acknowledgements
Acknowledgements 代表当对方收到正确的封包的话，将会发送一个讯息用于告诉发送方他已收到正确的封包，由于回传的讯息只是为了通知发送方确实收到封包，所以该讯息不会携带 data，故这种讯息称为 control frame 。
Timeouts
如果今天发送方发送了一个封包但接收方完全没收到的话，那就会造成发送方在等接收方的 Ack 而接收方也在等发送方的封包，为了避免这种情况，发送方在发送一个封包后会开启一个计时器， 当计时器结束前都还没收到接收方的回应时，那发送方就会在发送一次封包。
传输封包时使用 Acknowledgements 和 timeout 机制可以确保接收方确实收到正确的资料，这个行为称为 Automatic Repeat reQuest (ARQ)
Stop and Wait Protocol
当发送方发送了一个封包后会停止发送下一个封包并等待一段时间，当收到接收方的 Ack 后才会在发送下一个封包，如果在等待的时间内没收到则会再次发送
Normal Case
当 Sender 发送一个封包后，在 timeout 的时间内接收到 Receiver 传来的 Ack 代表这个封包正确的传送到 Receiver。
The original frame is lost
当 Sender 发送的封包没有送到 Receiver 那边的话，Sender 就无法收到来自 Receiver 的 Ack，当时间超过 Timeout 的时间后，Sender 便会再次发送一次封包。
The ACK is lost
当 Sender 发送封包给 Receiver 后， Receiver 确实收到封包后回传一个 Ack，但回传的 Ack 发称损毁导致 Sender 无法收到 Ack 而超过 timeout 时间导致 Sender 重送一次封包。
这种情况会导致 Receiver 会收到一次以上相同的封包，Reciver 将无法分辨收到的封包是否为相同的资料。
The timeout fires too soon (or the ACK is delayed)
当 timeout 设定的时间太短或是 Receiver 的 Ack 被 delay 了，这样就会导致 Sender 再次发送一次封包，导致 Receiver 接收到一次以上相同的封包
上面的例子中可以看到，如果 Ack 发生延迟或损毁都会发生 Sender 发送重複的封包，为了避免 Reciver 收到重複的封包，可以再封包中添加一个编号，这样可以让 Reciver 以该编号作为 id 进行验证。
由于 Sender 每发送一次封包都需要等待 Receiver 的 Ack，会导致 Link 上只有一组封包再传输，无法有效地发挥 Link 的 capacity 而导致传输数率较差。
Sliding Window Protocol
为了解决 Stop and Wait Protocol 所产生 一次只能传递一个封包 的问题，Sliding Window Protocol 由此诞生，这个 Protocol 一次可以发送多个封包，已达到传输效率提高的目的。
Sender maintains three variables
为了达到一次可以发送多个封包的目的，该 Protocol 会在发送的封包上多添加一个用于识别该封包身份的 id，称为 SeqNum，而 Sender 需要多负责纪录三个参数
SeqNum
上面的 Gif 表示 Sender 端的 Sliding Window 是如何运作的:
SWS 设定为 7 的话，代表一次可以发送七个封包 (5 ~ 11)当 5 号封包接收到 Ack 时，LAR 将会变更为 5 号封包的SeqNum为了保持 SWS 为 7 则会发送下一个封包 (12)LFS 更改为 12 封包的 SeqNum![[img]https://i.imgur.com/sTGFcvH.gif/img
Receiver 回传的 Ack 并不会按照顺序的回传给 Sender，所以以上面的 gif 来说， 2 号封包一直没有收到 Ack 的情况下就不会发生 Sliding，必须等到收到封包 2 的 Ack ，而当接收到封包 2 的 Ack 后便会开始进行 Sliding 的动作。
Receiver maintains three variables
为了接收到 Sender 发送的封包，Receiver 也需要控制三个参数以确保接收封包的正确性与稳定性。
Receiving Window Size (RWS)：Sender 发送多个封包的过程中，可能因为传输环境问题导致发送的封包顺序错乱，而 RWS 代表 Receiver 可以接收封包的数量，而这些封包的SeqNum 必须是 Receiver 允许的，如果超过这个数量或 SeqNum 不对则不会接收该封包。Largest Acceptable Frame (LAF)：纪录可接收的封包的 SeqNum 最大值。Last Frame Received (LFR)：记录最后一个收到的封包的 SeqNum。
上面的 Gif 表示 Receiver 端的 Sliding Window 是如何运作
RWS 设定为 7 代表 Receiver 端一次可以接收 7 个封包且封包的SeqNum 需要是 4 ~ 10当 Receiver 接收到 SeqNum = 4 的封包时，LFR（接收到的封包的 SeqNum 的最大值）就变更为 4为了保持 RWS 设定的 7 所以将会往右滑动一格LAF（记录能接收的最后一个封包的 SeqNum） 更改为 11如个今天收到的封包的 SeqNum < LFR 或 SeqNum > LAF 的话，Receiver 则会忽视这个封包不接收，只接收 LFR < SeqNum < LAF 的封包。
Sender 发送的封包不会按照顺序传送给 Receiver，所以以上面的 Gif 来说，2 号封包一直没有收到的情况下， Receiver 就不会发生 Sliding，必须等到确实收到了2 号封包才会发生 Sliding。
Cumulative Acknowledgement
如果 Sender 一次可以发送多个封包，那相对的 Receiver 也要回复多个 Ack 表示接收的状况，但是每一个封包都要回覆一个 Ack 其实也会影像效率，所以出现了一个新的 Ack 形式称为 SeqNumToAck，他回覆的 Ack 表示 Receiver 目前接收到的封包的 SeqNum 的最大值，简单来说就是 SeqNum 小于这个 SeqNumToAck 的封包都已经收到了，这样就可以不用一个一个的回送 Ack 给 Sender。
如果 Receiver 收到的封包的 SeqNum 比 SeqNumToAck 还大的话，那 Receiver 依然还会发送 SeqNumToAck 给 Sender 而不是较大的封包的 SeqNum
Sender 发送 SeqNum = 1 的封包给 Receiver，当 Receiver 收到后回覆 SeqNumToAck = 2 代表 SeqNum = 2 以前（SeqNum = 1）的封包都收到了
如果 Sender 发送的 SeqNum = 2 的封包在发送过程中遗失了，那么 Receiver 就不会回送 Ack 给 Sender
当 Sender 发送 SeqNum = 3 的封包给 Receiver，虽然 Receiver 有收到但是因为 SeqNum = 2 的封包遗失了，所以无法发送 SeqNumToAck = 4。
因为如果发送了 SeqNumToAck = 4 的话，代表已经接收到了封包 1, 2, 3 (封包 2 已经遗失了)。
一样的就算 Receiver 接收到了 SeqNum = 3 的封包，一样因为 SeqNum = 2 的封包遗失了，所以只能发送 SeqNumToAck = 2
而当 SeqNum = 2 的封包发生 Timeout 而再次发送后，Receiver 才收到了 SeqNum = 2 的封包，这时才可以发送 SeqNumToAck = 5 表示 SeqNum = 5 之前的封包都收到了
微信扫一扫打赏
支付宝扫一扫打赏
