• 停止等待协议问题


    1.在停止等待协议中,如果收到重复的报文段时不予理睬(即悄悄地丢弃它,而其他什么也不做)是否可以?试着举出具体例子说一下你的理解与看法?

     哈哈,绝对不可行的呀 ~。

    我们来看一看下面这个图:

     

    A 发送报文段 M1,B 收到后发送确认,但这个确认丢失了。  

    A 发送报文段 M1,B 收到后不予理解。这就导致 A 再次超时重传报文段 M1。

    B 收到重复的报文段都不予理睬,A 就一直超时重传报文段 M1,将会导致 A 的资源浪费呀 ~ 。

    可见,如果收到重复的报文段时不予理睬是不行的。

    2.在停止等待协议中,如果不使用编号是否可行?请说下你的理由?

    不使用编号是不可以的。我们可以看看下面这个图:

     如果在 A 发送报文段 M1,B 收到后发送确认(无编号),这个确认很晚才送到 A。

    这样 A 就没法在规定时间等待确认,认为发送的报文段在 B 没收到,启动超时重传机制,重新发送报文段 M1。

    在一段时间后,B 发送的第一个确认到达了 A,于是 A 发送下一个报文段 M2,但 M2 丢失了。

    B 收到 A发送的重传 M1.但 B 并不知道是重传中,因为报文段没有编号。 B 是无法判断报文段属于重传的报文段,还是

    最新的报文段。 B 这样只能收下重新传过来的报文段,并发送确认给 A。这样会让 A 误以为是对 M2 报文段的确认,认为发送的两个报文段都已经到达B。

    哈哈,我们是不是可以看出来问题了呀~,如果不使用编号的话,接收方是不清楚收到的报文段有没有重复类别。

    3.假定在传输层使用停止等待协议。发送方在发送报文段M0后设定的时间内未收到确认,于是重传M0,但M0又迟迟不能到达接收方。不久,发送方收到了迟到的对M0的确认,于是发送下一个报文段M1,不久就收到了对M1的确认。接着发送方发送新的报文段M0,但这个新的M0在传送的过程中丢失了。正巧,一开始就滞留在网络中的M0现在到达接收方。接收方无法分辨出M0是旧的。于是就收下M0,并发送确认。显然,接收方后来收到的M0是重复的,协议失败了。

    你可以画下双方交换报文段的过程吗?

    从上面的图我们可以看到,接收方在第二次的时候把超时的 M0 当成了新的 M0,。(无法判断 M0 是否为发送方发送的最新报文段) 

     参考:谢希仁老师的《计算机网络第七版》~

  • 相关阅读:
    Http请求头和相应头分析
    linux扩充容量经典篇
    Redis持久化以及其原理
    redis简单应用
    Python Requests库使用2:请求方法
    加快访问GitHub的速度
    GET和POST两种基本请求方法的区别
    Python Requests库介绍
    Python urllib、urllib2、urllib3用法及区别
    Django中操作cookie和session
  • 原文地址:https://www.cnblogs.com/xiaowei123/p/13143884.html
Copyright © 2020-2023  润新知