计算机网络W10:3.4传输层的可靠性
- 传输层的协议都会需要的两个功能,即多路复用和多路分解;
- 网络层和传输层的接口是多路复用和多路分解;
- 损坏例子:比特位重置/置返;
如何设计出可靠的数据传输?
在设计可靠的数据传输时需要注意哪些方面?
可靠的数据传输
Challenge
希望传输层提供可靠的服务给应用层;
但传输层使用的网络层的服务却是不可靠的;
调用函数介绍
以packet分组为基本单位;
- rdt_send应用层,
- udt_send,rdt调用udt
- rdt_rcv,消息到达后
- Deliver_data;rdt调用deliver_data,可靠的data;
处理challenge的状态从简单到复杂,难度一层层增加;
rdt1.0 理想状态:无差错
表达协议的有限状态机
利用FSM表示状态迁移,state从1迁移到状态2,往往是因为event causing state transition;
为了讲解方便:数据流单项,控制流双向;
数据流:数据信息是单向的
控制流:确认信息是双向的
假定网络层是一个可靠的数据传输
可靠:
- no bit errors
- no loss of packets
因为是可靠的,所以sender端一直是同一个状态;receive端也是如此;
rdt2.0数据损害状态(停等模式,即不会有并行的流水线)
此时bit error:flip bits,当产生差错的时候,使用checksum to detect bit errors(检查到发生差错了);当我校验到错误时,如何从错误恢复过来?
最基本的解决方法即为:重发
停等模式:对于单个packet而言,采用停等模式
ACK:返回给sender,checksum通过时;
NAK:返回给sender,checksum不通过时;
此时FSM变为:
Sender:
State1:wait for call from above(same as rdt1.0)
State2:wait for ACK or NAK(发送后不是接着发送,而是等待一个ACK)
event cause state transition here:发送packet这一事件
Receiver:
只有一个状态wait for call from below
rdt2.0的致命弱点:当传回的ACK/NAK会损坏时如何解决呢?
ACK/NAK损坏后,一定会重传,此时唯一差别是给消息加编号,重传会有duplicate的问题;
Rdt2.1
此时,接受者可能会收到两份一摸一样的packet,如何区分这两份一摸一样的packet,即我还是不知到接受者是否完好无损的发送了消息;
此时,我如果给packet加一个sequence number0/1,就可以避免duplicate的问题了.
即此时只需要0/1,即一个表示原始的包,另一个表示下一个新的重传;
rdt2.2是否能只用ACK,而不使用NAK?
如何只用ACK既能表达肯定又能表达否定?
对上一次啊接受的序号重复发ACK,即接受者不发送NAK,send ACK for last pkt receiverd ok
如果接受者对同一个序号连续发送了两个相同ACK,即
Rdt3.0数据丢包状态
考虑timeout机制;
rdt3.0仍还是停等模式,
停等模式的性能很低;
性能up,流水线
串行时为停等模式,pipeline并行模式;
即一次传时,传了很多包,即很多包并行传送;
回退N步
发送方最多保留N个已发送未确认的包;
接受者这里发送累计确认cumulative ack;
同时发送者也要设置超时定时器,一旦发生超时以后,把所有没有确认的消息都会再重复发送一遍;
维护一个滑动窗口window N ;
一个窗口只有一个定时器,定时器,send_base:最早未被确认的;
回退N步,假如send_base设置在2,当超时以后,从2开始,所有滑动窗口中的可发送的都要被重传;
- 窗口滑动:有数据被确认
- 窗口size:可发送的数据的个数;
base=nextsequence为最早的已发送未确认;
只有连续序号才会传输到上层应用;
故假设发送1,2,3,4,5;
2发了,但是2发送失败.即使3,4,5都收到了也会被扔掉;
只能等2;
故此时必须goback,即即使收到也会被丢掉重传;
选择重传
GBN的改进:选择重传,失序的会被选择重传,
在选择重传中,每一个packet一个定时期,而GBN只维护一个send_base处的定时器;
sender和rec的窗口是不一样的;
性能finalup
没有学得拔尖，也没有玩得通透。既没有好好读书，也没有好好恋爱。还把眼睛给弄近视了[泪]，没有为喜欢的事全力以赴。“那道题我会做，那个人我是真的喜欢过。”
