精华内容
下载资源
问答
  • 停止等待协议和连续ARQ协议

    千次阅读 2017-12-23 00:44:00
    停止等待协议(数据链路层): 工作原理:发送方每发送一帧就暂停,等待应答(ACK)到来。收方收到数据帧后发送应答(ACK)帧给发送方,发送方再发送下一个数据帧。 问题解决: 1. Data帧出错:收方用NAK应答。 ...

    协议:两台计算机通信时对传送信息内容的理解、信息表示形式以及各种情况下的应答信号都必须遵循的一个共同的约定。

     

    停止等待协议(数据链路层):

    工作原理:发送方每发送一帧就暂停,等待应答(ACK)到来。收方收到数据帧后发送应答(ACK)帧给发送方,发送方再发送下一个数据帧。

    问题解决:

    1. Data帧出错:收方用NAK应答。

    2. Data帧丢失:使用定时器,一定时间未收到ACK帧就重发。

    3. 收方收到重复的data帧:进行帧编号。

    缺点:数据每次发送都要等待应答帧的到来,效率较低。尤其是利用卫星进行通信的时候,卫星的传播延迟是270毫秒,每发一帧要用540毫秒。

     

    连续ARQ协议(数据链路层)ARQ(Automatic Repeat reQuest)--自动请求重发,又称GO-BACK-N

    特征:

    1. 一次可发多帧。

    2. 流水线发送和接收。

    工作原理:接收端只按序接收数据帧。虽然在有差错的2号帧之后接着又收到了正确的3个数据帧,但都必须将它们丢弃,因为这些帧的发送序号都不是所需的2号。结点A重传2号帧时, 以后的各帧也要全部进行重传。结点A在每发送完一个数据帧时都要设置超时定时器。在定时器超时(Timeout)后仍未收到确认帧,就要重发。在等待2#数据帧时,收到非2#,或出错的2#,有两种解决方法:一是收方发送应答帧“REJ 2#--拒收2#,要求发方重发2#数据帧;二是不发送应答帧。

     

    展开全文
  • TCP协议总结--停止等待协议,连续ARQ协议,滑动窗口协议 Posted on 2015-09-16 16:27 杨博东的博客 阅读(4459) 评论(0) 编辑 收藏 </div> <div class="postbody"><div id="cnblogs_post_...

    TCP协议总结--停止等待协议,连续ARQ协议,滑动窗口协议

    Posted on 2015-09-16 16:27 杨博东的博客 阅读(4459) 评论(0) 编辑 收藏
    	</div>
    	<div class="postbody"><div id="cnblogs_post_body" class="blogpost-body">
        <div class="markdown_views"><p>前言:在学习tcp三次握手的过程之中,由于一直无法解释tcpdump命令抓的包中seq和ack的含义,就将tcp协议往深入的了解了一下,了解到了几个协议,做一个小结.</p>
    

    先来看看我的问题:
    这是用tcpdump命令抓的三次握手的包,可以看到seq和ack都比较大,我自己也无法解释原因.
    这里写图片描述
    这里写图片描述
    第二张是在同一过程中用Wireshark抓的包,其中seq和ack还比较正常,难道原因就是我不懂tcpdump命令中的数据?我的解释是Wireshark和tcpdump中抓的包,数据的显示方式可能不同,最后学长说可以用 -S 将tcp的序列号以绝对值形式输出,而不是相对值。转化了一下,第三次的ack就正常了.主要还是得知道seq和ack一样,都是字节序列号,一共4个字节,范围都是从[0,2^32 - 1].

    $ tcpdump -S port 80

    这里写图片描述

    一:停止等待协议
    停止等待协议是tcp保证传输可靠的重要途径,”停止等待”就是指发送完一个分组就停止发送,等待对方的确认,只有对方确认过,才发送下一个分组.

    1:无差错情况:发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送……
    这里写图片描述
    2:超时重传有以下三种情况:
    (1)分组丢失:发送方发送分组,接收方没有收到分组,那么接收方不会发出确认,只要发送方过一段时间没有收到确认,就认为刚才的分组丢了,那么发送方就会再次发送.
    (2):确认丢失:发送方发送成功,接收方接收成功,确认分组也被发送,但是分组丢失,那么到了等待时间,发送方没有收到确认,又会发送分组过去,此时接收方前面已经收到了分组,那么此时接收方要做的事就是:丢弃分组,重新发送确认.
    (3):传送延迟:发送方发送成功,接收方接收成功,确认分组也被发送,没有丢失,但是由于传输太慢,等到了发送方设置的时间,发送方又会重新发送分组,此时接收方要做的事情:丢弃分组,重新发送确认. 发送方如果收到两个或者多个确认,就停止发送,丢弃其他确认.
    这里写图片描述

    停止等待协议的优点是简单,但是缺点是信道的利用率太低,一次发送一条消息,使得信道的大部分时间内都是空闲的,为了提高效率,我们采用流水线传输,这就与下面两个协议有关系了.

    二:连续ARQ协议和滑动窗口协议
    这两个协议主要解决的问题信道效率低和增大了吞吐量,以及控制流量的作用.

    • 连续ARQ协议:它是指发送方维护着一个窗口,这个窗口中不止一个分组,有好几个分组,窗口的大小是由接收方返回的win值决定的,所以窗口的大小是动态变化的,只要在窗口中的分组都可以被发送,这就使得TCP一次不是只发送一个分组了,从而大大提高了信道的利用率.并且它采用累积确认的方式,对于按序到达的最后一个分组发送确认.
    • 滑动窗口协议:之所以叫滑动窗口协议,是因为窗口是不断向前走的,该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认,因此该协议可以加速数据的传输,还可以控制流量的问题.
    • 累积确认:如果发送方发送了5个分组,接收方只收到了1,2,4,5,没有收到3分组,那么我的确认信息只会说我期望下一个收到的分组是第三个,此时发送方会将3,4,5,全部重发一次,当通信质量不是很好的时候,连续ARQ还是会带来负面影响.
        <div style="padding-top:20px">         
            <p style="font-size:12px;">版权声明:本文为博主原创文章,未经博主允许不得转载。</p>
        </div>
    
    0
    0
    « 上一篇:Linux&C———进程间通信
    » 下一篇:TCP报文段首部详解
    </div>
    
    展开全文
  • 停止等待协议连续 ARQ 协议

    千次阅读 2019-06-27 00:43:24
    一、停止等待协议 停止等待”就是每发送完一个分组就停止发送,等待对方的确认。在收到确认后再发送下一个分组。 全双工通信的双方既是发送方也是接收方。 为了讨论问题的方便,我们仅考虑 A 发送数据,而 B 接收...

    一、停止等待协议
    停止等待”就是每发送完一个分组就停止发送,等待对方的确认。在收到确认后再发送下一个分组。
    全双工通信的双方既是发送方也是接收方。

    为了讨论问题的方便,我们仅考虑 A 发送数据,而 B 接收数据并发送确认。因此 A 叫做发送方,而 B 叫做接 收方。

    1. 无差错情况
    在这里插入图片描述
    2. 出现差错情况:

    • 在接收方 B 会出现两种情况:
      (1)B 接收 M1 时检测出了差错,就丢弃 M1,其他什么也不做(不通知 A 收到有差错的分组)。
      (2)M1 在传输过程中丢失了,这时 B 当然什么都不知道,也什么都不做。
    • 在这两种情况下,B 都不会发送任何信息。
    • 但A都必须重发分组,直到B正确接收为止,这样才能实现可靠通信。

    问题1:A如何知道 B 是否正确收到了 M1 呢?
    解决方法:超时重传
    A 为每一个已发送的分组都设置了一个超时计时器
    A 只要在超时计时器到期之前收到了相应的确认,就撤销该超时计时器,继续发送下一个分组 M2 。
    若A在超时计时器规定时间内没有收到B的确认,就认为分组错误或丢失,就重发该分组。

    问题2:若分组正确到达B,但B回送的确认丢失或延迟了,A未收到B的确认,会超时重发。B 可能会收到重复的 M1 。B如何知道收到了重复的分组,需要丢弃呢?
    解决方法:编号
    A为每一个发送的分组都进行编号。若B收到了编号相同的分组,则认为收到了重复分组,丢弃重复的分组,并回送确认。
    B为发送的确认也进行编号,指示该确认是对哪一个分组的确认。
    A根据确认及其编号,可以确定它是对哪一个分组的确认,避免重发发送。若为重复的确认,则将其丢弃。

    二、连续 ARQ 协议
    基本思想
    发送方一次可以发出多个分组。
    使用滑动窗口协议控制发送方和接收方所能发送和接收的分组的数量和编号。
    每收到一个确认,发送方就把发送窗口向前滑动
    接收方一般采用累积确认的方式。
    采用回退N(Go-Back-N)方法进行重传。

    学习自课件

    展开全文
  • 当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时,只有位于网络边缘部分的主机的协议栈才有运输层,而网络核心部分中的路由器在转发分组时都只用到下三层的功能。 运输层的作用 运输层的...

    关注公众号凡花花的小窝,收获更多的考研计算机专业编程相关的资料
    第 5 章 运 输 层
    计算机网络体系结构
    在这里插入图片描述
    5.1.1 进程之间的通信
    从通信和信息处理的角度看,运输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,同时也是用户功能中的最低层。
    当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时,只有位于网络边缘部分的主机的协议栈才有运输层,而网络核心部分中的路由器在转发分组时都只用到下三层的功能。
    运输层的作用
    在这里插入图片描述
    在这里插入图片描述
    运输层的作用
    “逻辑通信”的意思是“好像是这样通信,但事实上并非真的这样通信”。
    从IP层来说,通信的两端是两台主机。但“两台主机之间的通信”这种说法还不够清楚。
    严格地讲,两台主机进行通信就是两台主机中的应用进程互相通信。
    从运输层的角度看,通信的真正端点并不是主机而是主机中的进程。也就是说,端到端的通信是应用进程之间的通信。
    端系统之间通信的含义
    “主机A和主机B进行通信”实际上是指:“运行在主机A上的某个程序和运行在主机B上的另一个程序进行通信”。端到端的通信是进程之间的通信。
    即“主机 A 的某个进程和主机 B 上的另一个进程进行通信”。
    简称为“计算机之间通信”。
    运输层的作用
    在这里插入图片描述
    网络层和运输层有明显的区别
    在这里插入图片描述
    基于端口的复用和分用功能
    在这里插入图片描述
    屏蔽作用
    运输层向高层用户屏蔽了下面网络核心的细节,它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道。
    在这里插入图片描述两种不同的运输协议
    但这条逻辑通信信道对上层的表现却因运输层使用的不同协议而有很大的差别。
    当运输层采用面向连接的 TCP 协议时,尽管下面的网络是不可靠的(只提供尽最大努力服务),但这种逻辑通信信道就相当于一条全双工的可靠信道。
    当运输层采用无连接的 UDP 协议时,这种逻辑通信信道是一条不可靠信道。
    可靠信道与不可靠信道
    在这里插入图片描述
    5.1.2 运输层的两个主要协议
    TCP/IP 的运输层有两个主要协议:
    用户数据报协议 UDP (User Datagram Protocol)
    传输控制协议 TCP (Transmission Control Protocol)
    在这里插入图片描述
    TCP 与 UDP
    两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)。
    TCP 传送的数据单位协议是 TCP 报文段(segment)。
    UDP 传送的数据单位协议是 UDP 报文或用户数据报。
    UDP 与 TCP
    在这里插入图片描述
    使用 UDP 和 TCP 的典型应用和应用层协议
    在这里插入图片描述
    需要解决的问题
    在这里插入图片描述
    还要强调两点
    运输层的 UDP 用户数据报与网际层的IP数据报有很大区别。
    IP 数据报要经过互连网中许多路由器的存储转发。
    UDP 用户数据报是在运输层的端到端抽象的逻辑信道中传送的。
    TCP 报文段是在运输层抽象的端到端逻辑信道中传送,这种信道是可靠的全双工信道。但这样的信道却不知道究竟经过了哪些路由器,而这些路由器也根本不知道上面的运输层是否建立了 TCP 连接。
    5.1.3 运输层的端口
    运行在计算机中的进程是用进程标识符来标志的。
    但运行在应用层的各种应用进程却不应当让计算机操作系统指派它的进程标识符。这是因为在互联网上使用的计算机的操作系统种类很多,而不同的操作系统又使用不同格式的进程标识符。
    为了使运行不同操作系统的计算机的应用进程能够互相通信,就必须用统一的方法对 TCP/IP 体系的应用进程进行标志。
    5.1.3 运输层的端口
    在这里插入图片描述
    需要解决的问题
    由于进程的创建和撤销都是动态的,发送方几乎无法识别其他机器上的进程。
    有时我们会改换接收报文的进程,但并不需要通知所有发送方。
    我们往往需要利用目的主机提供的功能来识别终点,而不需要知道实现这个功能的进程。
    端口号 (protocol port number)
    解决这个问题的方法就是在运输层使用协议端口号 (protocol port number),或通常简称为端口 (port)。
    虽然通信的终点是应用进程,但我们可以把端口想象是通信的终点,因为我们只要把要传送的报文交到目的主机的某一个合适的目的端口,剩下的工作(即最后交付目的进程)就由 TCP 来完成。
    软件端口与硬件端口
    两个不同的概念。
    在协议栈层间的抽象的协议端口是软件端口。
    路由器或交换机上的端口是硬件端口。
    硬件端口是不同硬件设备进行交互的接口,而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。
    TCP/IP 运输层端口
    端口用一个 16 位端口号进行标志,允许有65,535个不同的端口号。
    端口号只具有本地意义,即端口号只是为了标志本计算机应用层中的各进程。在互联网中,不同计算机的相同端口号是没有联系的。
    在这里插入图片描述TCP/IP 运输层端口
    端口用一个 16 位端口号进行标志,允许有65,535个不同的端口号。
    端口号只具有本地意义,即端口号只是为了标志本计算机应用层中的各进程。在互联网中,不同计算机的相同端口号是没有联系的。
    由此可见,两个计算机中的进程要互相通信,不仅必须知道对方的端口号(为了找到对方计算机中的应用进程) ,而且还要知道对方的 IP 地址(为了找到对方的计算机)。
    两大类端口
    服务器端使用的端口号
    熟知端口,数值一般为 0 ~ 1023。
    登记端口号,数值为 1024 ~ 49151,为没有熟知端口号的应用程序使用的。使用这个范围的端口号必须在 IANA 登记,以防止重复。
    客户端使用的端口号
    又称为短暂端口号,数值为 49152 ~ 65535,留给客户进程选择暂时使用。
    当服务器进程收到客户进程的报文时,就知道了客户进程所使用的动态端口号。通信结束后,这个端口号可供其他客户进程以后使用。
    两大类、三种类型的端口
    在这里插入图片描述
    常用的熟知端口
    在这里插入图片描述
    5.2.1 UDP 概述
    UDP 只在 IP 的数据报服务之上增加了很少一点的功能:
    复用和分用的功能
    差错检测的功能
    在这里插入图片描述
    UDP 的主要特点
    UDP 是无连接的,发送数据之前不需要建立连接,,因此减少了开销和发送数据之前的时延。
    UDP 使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的连接状态表。
    UDP 是面向报文的。UDP 对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。UDP 一次交付一个完整的报文。
    UDP 的主要特点
    UDP 没有拥塞控制,因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很适合多媒体通信的要求。
    UDP 支持一对一、一对多、多对一和多对多的交互通信。
    UDP 的首部开销小,只有 8 个字节,比 TCP 的 20 个字节的首部要短。
    面向报文的 UDP
    发送方 UDP 对应用程序交下来的报文,在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。
    应用层交给 UDP 多长的报文,UDP 就照样发送,即一次发送一个报文。

    面向报文的 UDP
    接收方 UDP 对 IP 层交上来的 UDP 用户数据报,在去除首部后就原封不动地交付上层的应用进程,一次交付一个完整的报文。
    应用程序必须选择合适大小的报文。
    若报文太长,UDP 把它交给 IP 层后,IP 层在传送时可能要进行分片,这会降低 IP 层的效率。
    若报文太短,UDP 把它交给 IP 层后,会使 IP 数据报的首部的相对长度太大,这也降低了 IP 层的效率。
    UDP 是面向报文的
    在这里插入图片描述
    UDP 是面向报文的
    在这里插入图片描述
    5.2.2 UDP 的首部格式
    用户数据报 UDP 有两个字段:数据字段和首部字段。
    首部字段有 8 个字节,由 4 个字段组成,每个字段都是 2 个字节。
    在这里插入图片描述
    UDP 基于端口的分用
    当运输层从 IP 层收到 UDP 数据报时,就根据首部中的目的端口,把 UDP 数据报通过相应的端口,上交给最后的终点——应用进程。
    请注意,虽然在 UDP 之间的通信要用到端口号,但由于 UDP 的通信是无连接的,因此不需要使用套接字来建立连接。
    在这里插入图片描述
    用户数据报 UDP 有两个字段:数据字段和首部字段。首部字段有 8 个字节,由 4 个字段组成,每个字段都是 2 个字节。
    在这里插入图片描述
    在计算检验和时,临时把 12 字节的“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和。
    计算 UDP 检验和的例子
    在这里插入图片描述
    5.3.1 TCP 最主要的特点
    TCP 是面向连接的运输层协议,在无连接的、不可靠的 IP 网络服务基础之上提供可靠交付的服务。为此,在 IP 的数据报服务基础之上,增加了保证可靠性的一系列措施。
    在这里插入图片描述
    5.3.1 TCP 最主要的特点
    TCP 是面向连接的运输层协议。
    每一条 TCP 连接只能有两个端点 (endpoint),每一条 TCP 连接只能是点对点的(一对一)。
    TCP 提供可靠交付的服务。
    TCP 提供全双工通信。
    面向字节流
    TCP 中的“流”(stream) 指的是流入或流出进程的字节序列。
    “面向字节流”的含义是:虽然应用程序和 TCP 的交互是一次一个数据块,但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。
    TCP 面向流的概念
    TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。
    但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。
    TCP 面向流的概念
    在这里插入图片描述
    在这里插入图片描述
    注 意
    TCP 连接是一条虚连接而不是一条真正的物理连接。
    TCP 对应用进程一次把多长的报文发送到 TCP 的缓存中是不关心的。
    TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP 发送的报文长度是应用进程给出的)。
    TCP 可把太长的数据块划分短一些再传送。
    TCP 也可等待积累有足够多的字节后再构成报文段发送出去。
    5.3.2 TCP 的连接
    TCP 把连接作为最基本的抽象。
    每一条 TCP 连接有两个端点。
    TCP 连接的端点不是主机,不是主机的IP 地址,不是应用进程,也不是运输层的协议端口。TCP 连接的端点叫做套接字 (socket) 或插口。
    端口号拼接到 (contatenated with) IP 地址即构成了套接字。
    5.3.2 TCP 的连接
    在这里插入图片描述
    套接字 (socket)
    在这里插入图片描述
    在这里插入图片描述
    TCP 连接,IP 地址,套接字
    TCP 连接就是由协议软件所提供的一种抽象。
    TCP 连接的端点是个很抽象的套接字,即(IP 地址:端口号)。
    同一个 IP 地址可以有多个不同的 TCP 连接。
    同一个端口号也可以出现在多个不同的 TCP 连接中。

    Socket 有多种不同的意思
    应用编程接口 API 称为 socket API, 简称为 socket。
    socket API 中使用的一个函数名也叫作 socket。
    调用 socket 函数的端点称为 socket。
    调用 socket 函数时其返回值称为 socket 描述符,可简称为 socket。
    在操作系统内核中连网协议的 Berkeley 实现,称为 socket 实现。

    IP 网络所提供的是不可靠的传输
    在这里插入图片描述
    理想的传输条件特点
    理想的传输条件有以下两个特点:
    传输信道不产生差错。
    不管发送方以多快的速度发送数据,接收方总是来得及处理收到的数据。
    在这样的理想传输条件下,不需要采取任何措施就能够实现可靠传输。
    然而实际的网络都不具备以上两个理想条件。必须使用一些可靠传输协议,在不可靠的传输信道实现可靠传输。

    5.4.1 停止等待协议
    “停止等待”就是每发送完一个分组就停止发送,等待对方的确认。在收到确认后再发送下一个分组。
    全双工通信的双方既是发送方也是接收方。
    为了讨论问题的方便,我们仅考虑 A 发送数据,而 B 接收数据并发送确认。因此 A 叫做发送方,而 B 叫做接收方。

    1. 无差错情况
      A 发送分组 M1,发完就暂停发送,等待 B 的确认 (ACK)。B 收到了 M1 向 A 发送 ACK。A 在收到了对 M1 的确认后,就再发送下一个分组 M2。在这里插入图片描述
    2. 出现差错
      在接收方 B 会出现两种情况:
      B 接收 M1 时检测出了差错,就丢弃 M1,其他什么也不做(不通知 A 收到有差错的分组)。
      M1 在传输过程中丢失了,这时 B 当然什么都不知道,也什么都不做。
      在这两种情况下,B 都不会发送任何信息。
      但A都必须重发分组,直到B正确接收为止,这样才能实现可靠通信。
      问题:A如何知道 B 是否正确收到了 M1 呢?
      解决方法:超时重传
      A 为每一个已发送的分组都设置了一个超时计时器。
      A 只要在超时计时器到期之前收到了相应的确认,就撤销该超时计时器,继续发送下一个分组 M2 。
      若A在超时计时器规定时间内没有收到B的确认,就认为分组错误或丢失,就重发该分组。
      问题:若分组正确到达B,但B回送的确认丢失或延迟了,A未收到B的确认,会超时重发。B 可能会收到重复的 M1 。B如何知道收到了重复的分组,需要丢弃呢?
      解决方法:编号
      A为每一个发送的分组都进行编号。若B收到了编号相同的分组,则认为收到了重复分组,丢弃重复的分组,并回送确认。
      B为发送的确认也进行编号,指示该确认是对哪一个分组的确认。
      A根据确认及其编号,可以确定它是对哪一个分组的确认,避免重发发送。若为重复的确认,则将其丢弃。

    在这里插入图片描述
    3. 确认丢失和确认迟到
    确认丢失
    若 B 所发送的对 M1 的确认丢失了,那么 A 在设定的超时重传时间内不能收到确认,但 A 并无法知道:是自己发送的分组出错、丢失了,或者 是 B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1。
    假定 B 又收到了重传的分组 M1。这时 B 应采取两个行动:
    第一,丢弃这个重复的分组 M1,不向上层交付。
    第二,向 A 发送确认。不能认为已经发送过确认就不再发送,因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认。

    确认迟到
    传输过程中没有出现差错,但 B 对分组 M1 的确认迟到了。
    A 会收到重复的确认。对重复的确认的处理很简单:收下后就丢弃。
    B 仍然会收到重复的 M1,并且同样要丢弃重复的 M1,并重传确认分组。

    在这里插入图片描述
    请注意
    在发送完一个分组后,必须暂时保留已发送的分组的副本,以备重发。
    分组和确认分组都必须进行编号。
    超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

    自动重传请求 ARQ
    通常 A 最终总是可以收到对所有发出的分组的确认。如果 A 不断重传分组但总是收不到确认,就说明通信线路太差,不能进行通信。
    使用上述的确认和重传机制,我们就可以在不可靠的传输网络上实现可靠的通信。
    像上述的这种可靠传输协议常称为自动重传请求 ARQ (Automatic Repeat reQuest)。意思是重传的请求是自动进行的,接收方不需要请求发送方重传某个出错的分组。
    4. 信道利用率
    在这里插入图片描述

    可以看出,当往返时间 RTT 远大于分组发送时间 TD 时,信道的利用率就会非常低。
    若出现重传,则对传送有用的数据信息来说,信道的利用率就还要降低。

    流水线传输
    为了提高传输效率,发送方可以不使用低效率的停止等待协议,而是采用流水线传输。
    流水线传输就是发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地传送。
    由于信道上一直有数据不间断地传送,这种传输方式可获得很高的信道利用率。

    流水线传输
    由于信道上一直有数据不间断地传送,
    这种传输方式可获得很高的信道利用率。
    在这里插入图片描述
    停止等待协议要点
    停止等待。发送方每次只发送一个分组。在收到确认后再发送下一个分组。
    编号。对发送的每个分组和确认都进行编号。
    自动重传请求。发送方为每个发送的分组设置一个超时计时器。若超时计时器超时,发送方会自动重传分组。
    简单,但信道利用率太低。
    在这里插入图片描述
    5.4.2 连续 ARQ 协议
    基本思想:
    发送方一次可以发出多个分组。
    使用滑动窗口协议控制发送方和接收方所能发送和接收的分组的数量和编号。
    每收到一个确认,发送方就把发送窗口向前滑动。
    接收方一般采用累积确认的方式。
    采用回退N(Go-Back-N)方法进行重传。

    5.4.2 连续 ARQ 协议
    在这里插入图片描述
    累积确认
    接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,这样就表示:到这个分组为止的所有分组都已正确收到了。
    优点:容易实现,即使确认丢失也不必重传。
    缺点:不能向发送方反映出接收方已经正确收到的所有分组的信息。

    Go-back-N(回退 N)
    如果发送方发送了前 5 个分组,而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落,而只好把后面的三个分组都再重传一次。
    这就叫做 Go-back-N(回退 N),表示需要再退回来重传已发送过的 N 个分组。
    可见当通信线路质量不好时,连续 ARQ 协议会带来负面的影响。

    TCP 可靠通信的具体实现
    TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。
    TCP 的可靠传输机制用字节的序号进行控制。TCP 所有的确认都是基于序号而不是基于报文段。
    TCP 两端的四个窗口经常处于动态变化之中。
    TCP连接的往返时间 RTT 也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。

    连续 ARQ 协议与停止等待协议
    在这里插入图片描述5.4.2 连续 ARQ 协议
    滑动窗口协议比较复杂,是 TCP 协议的精髓所在。
    发送方维持的发送窗口,它的意义是:位于发送窗口内的分组都可连续发送出去,而不需要等待对方的确认。这样,信道利用率就提高了。
    连续 ARQ 协议规定,发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置。
    累积确认
    接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,这样就表示:到这个分组为止的所有分组都已正确收到了。
    优点:容易实现,即使确认丢失也不必重传。
    缺点:不能向发送方反映出接收方已经正确收到的所有分组的信息。

    累积确认在这里插入图片描述
    滑动窗口协议
    在这里插入图片描述
    滑动窗口协议
    在这里插入图片描述
    滑动窗口协议
    在这里插入图片描述
    滑动窗口协议
    在这里插入图片描述
    滑动窗口协议
    在这里插入图片描述
    Go-back-N(回退 N)
    在这里插入图片描述
    5.5 TCP 报文段的首部格式
    TCP 虽然是面向字节流的,但 TCP 传送的数据单元却是报文段。
    一个 TCP 报文段分为首部和数据两部分,而 TCP 的全部功能都体现在它首部中各字段的作用。
    TCP 报文段首部的前 20 个字节是固定的,后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20 字节。
    5.5 TCP 报文段的首部格式
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    确认号字段——占 4 字节,是期望收到对方的下一个报文段的数据的第一个字节的序号。
    数据偏移(即首部长度)——占 4 位,它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字(以 4 字节为计算单位)。
    保留字段——占 6 位,保留为今后使用,但目前应置为 0。
    紧急 URG —— 当 URG  1 时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)。
    确认 ACK —— 只有当 ACK =1 时确认号字段才有效。当 ACK =0 时,确认号无效。
    推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的报文段,就尽快地交付接收应用进程,而不再等到整个缓存都填满了后再向上交付。
    复位 RST (ReSeT) —— 当 RST=1 时,表明 TCP 连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接。
    同步 SYN —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文。
    终止 FIN (FINish) —— 用来释放一个连接。FIN=1 表明此报文段的发送端的数据已发送完毕,并要求释放运输连接。
    窗口字段 —— 占 2 字节,用来让对方设置发送窗口的依据,单位为字节。
    检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时,要在 TCP 报文段的前面加上 12 字节的伪首部。
    在计算检验和时,临时把 12 字节的“伪首部”和 TCP 报文段连接在一起。伪首部仅仅是为了计算检验和。
    在这里插入图片描述
    紧急指针字段 —— 占 16 位,指出在本报文段中紧急数据共有多少个字节(紧急数据放在本报文段数据的最前面)。
    MSS (Maximum Segment Size)
    是 TCP 报文段中的数据字段的最大长度。
    数据字段加上 TCP 首部才等于整个的 TCP 报文段。
    所以,MSS是“TCP 报文段长度减去 TCP 首部长度”。
    选项字段 —— 长度可变。TCP 最初只规定了一种选项,即最大报文段长度 MSS。MSS 告诉对方 TCP:“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”
    为什么要规定 MSS ?
    MSS 与接收窗口值没有关系。
    若选择较小的 MSS 长度,网络的利用率就降低。
    若 TCP 报文段非常长,那么在 IP 层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的 TCP 报文段。当传输出错时还要进行重传。这些也都会使开销增大。
    因此,MSS 应尽可能大些,只要在 IP 层传输时不需要再分片就行。
    但最佳的 MSS 是很难确定的。
    其他选项
    窗口扩大选项 ——占 3 字节,其中有一个字节表示移位值 S。新的窗口值等于 TCP 首部中的窗口位数增大到 (16 + S),相当于把窗口值向左移动 S 位后获得实际的窗口大小。
    时间戳选项——占 10 字节,其中最主要的字段时间戳值字段(4 字节)和时间戳回送回答字段(4 字节)。
    选择确认选项——在后面的 5.6.3 节介绍。

    填充字段 —— 这是为了使整个首部长度是 4 字节的整数倍。
    5.6.1 以字节为单位的滑动窗口
    TCP 使用流水线传输和滑动窗口协议实现高效、可靠的传输。
    TCP 的滑动窗口是以字节为单位的。
    发送方 A 和接收方 B 分别维持一个发送窗口和一个接收窗口。
    发送窗口表示:在没有收到确认的情况下,可以连续把窗口内的数据全部发送出去。
    接收窗口表示:只允许接收落入窗口内的数据。

    根据 B 给出的窗口值,A 构造出自己的发送窗口。
    发送窗口表示:在没有收到 B 的确认的情况下,A 可以连续把窗口内的数据都发送出去。
    发送窗口里面的序号表示允许发送的序号。
    显然,窗口越大,发送方就可以在收在这里插入图片描述到对方确认之前连续发送更多的数据,因而可能获得更高的传输效率。
    根据 B 给出的窗口值,A 构造出自己的发送窗口。
    发送窗口表示:在没有收到 B 的确认的情况下,A 可以连续把窗口内的数据都发送出去。
    发送窗口里面的序号表示允许发送的序号。
    显然,窗口越大,发送方就可以在收到对方确认之前连续发送更多的数据,因而可能获得更高的传输效率。
    在这里插入图片描述
    根据 B 给出的窗口值,A 构造出自己的发送窗口。
    发送窗口表示:在没有收到 B 的确认的情况下,A 可以连续把窗口内的数据都发送出去。
    发送窗口里面的序号表示允许发送的序号。
    显然,窗口越大,发送方就可以在收到对方确认之前连续发送更多的数据,因而可能获得更高的传输效率。、
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    A 的发送窗口内的序号都已用完,
    但还没有再收到确认,必须停止发送。
    发送窗口内的序号都属于已发送但未被确认

    在这里插入图片描述
    发送缓存
    在这里插入图片描述
    接收缓存
    接收方的应用进程从 TCP 的接收缓存中读取字节流。
    在这里插入图片描述
    发送缓存与接收缓存的作用、
    发送缓存用来暂时存放:
    发送应用程序传送给发送方 TCP 准备发送的数据;
    TCP 已发送出但尚未收到确认的数据。
    接收缓存用来暂时存放:
    按序到达的、但尚未被接收应用程序读取的数据;
    不按序到达的数据。

    需要强调三点
    第一,A 的发送窗口并不总是和 B 的接收窗口一样大(因为有一定的时间滞后)。
    第二,TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程。
    第三,TCP 要求接收方必须有累积确认的功能,这样可以减小传输开销。

    接收方发送确认
    接收方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便捎带上。
    但请注意两点:
    第一,接收方不应过分推迟发送确认,否则会导致发送方不必要的重传,这反而浪费了网络的资源。。
    第二,捎带确认实际上并不经常发生,因为大多数应用程序很少同时在两个方向上发送数据。

    5.6.2 超时重传时间的选择
    重传机制是 TCP 中最重要和最复杂的问题之一。
    TCP 每发送一个报文段,就对这个报文段设置一次计时器。
    只要计时器设置的重传时间到但还没有收到确认,就要重传这一报文段。
    重传时间的选择是 TCP 最复杂的问题之一。
    往返时延的方差很大

    由于 TCP 的下层是一个互联网环境,IP 数据报所选择的路由变化很大。因而运输层的往返时间 (RTT) 的方差也很大。
    在这里插入图片描述
    TCP 超时重传时间设置
    如果把超时重传时间设置得太短,就会引起很多报文段的不必要的重传,使网络负荷增大。
    但若把超时重传时间设置得过长,则又使网络的空闲时间增大,降低了传输效率。
    TCP 采用了一种自适应算法,它记录一个报文段发出的时间,以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT。

    展开全文
  • 停止等待协议ARQ): (a)无差错情况:A发送分组M1,发送就暂停发送,等待B的确认。B收到M1就向A发送确认。A在收到了对M1的确认后,就再发送下一个分组M2。同样,在收到B对M2的确认后,再发送M3。 (b)超时重传...
  • 1.停等ARQ协议 ...连续ARQ协议是滑动窗口技术请求重发技术的组合。接收方有一个固定大小的窗口,接收方在收到一个帧以前不会移动窗口,发送方可以发送连续的帧而形成流动,因此称为连续ARQ协...
  • TCP可靠传输的工作原理-停止等待&连续ARQ(一)

    万次阅读 多人点赞 2017-06-26 20:10:24
    停止等待协议,TCP的可靠传输,连续ARQ协议
  • 停止等待协议中主要有4种情况:无差错情况、超时重传、确认丢失确认迟到; 停止等待协议对信道的利用率不高,因为发送方每发送一个消息,都需要等待确认消息回来,只要确认消息没有正确地到达,就一直等; 1)无...
  • 1.停止等待协议 1.1特征:发方每发送一帧就暂停,等待应答(ACK)到来。收方收到数据帧后发ACK帧给发方,发方再发送下—个数据帧。 1.2要解决的问题: DATA帧出错。 对策:收方用NAK应答。 DATA帧丢失。 对策:使用...
  • TCP连续ARQ协议和滑动窗口协议TCP协议通过使用连续ARQ协议和滑动窗口协议,来保证数据传输的正确性,从而提供可靠的传输。一、ARQ协议ARQ协议,即自动重传请求(Automatic Repeat-reQuest),是OSI模型中数据链路层...
  • 连续ARQ协议

    千次阅读 2014-12-29 16:34:21
    停止等待ARQ =1 =1 发送方每发送一帧之后就必须停下来等待接收方的确认返回,仅当接收方确认正确接收后再继续发送下一帧 所需要的缓冲存储空间最小 信道效率很低 ...
  • 关于停止等待ARQ通信协议的几种分析方法第一种分析方法第二种分析方法 第一种分析方法 stop-wait流量控制是最简单的流量控制形式,其工作原理如下。一个源端实体发送一个帧,目的端实体收到后就发回一个对收到帧的...
  • 27-tcp可靠传输——连续ARQ协议

    千次阅读 2018-05-01 09:01:01
    等待确认后再发送下一个分组,这种传输协议虽然实现了可靠传输,但是因为每发一个分组就要确认一次,使通信效率降低了,而连续ARQ协议停止等待协议的改进版。 图1-ARQ协议   在图1中,在发送方A设置了一个...
  • 计算机网络 (谢希仁) 第7版 习题题解 第5章 运输层 停止等待协议连续 ARQ 协议;TCP 数据报
  • 停止等待协议

    千次阅读 2020-05-08 16:03:35
    停止等待协议(stop-and-wati),是数据链据层一个很重要的协议,基本原理就是说每发送一个分组,必须要停下来等待,等接收方确认后才可继续发送下一个分组。如果没收到确认,就只能超时重传。 优点:很简单,每次...
  • ARQ协议

    2021-06-22 20:40:07
    它包括停止等待ARQ协议和连续ARQ协议。 (1)在停等式ARQ中,数据报文发送完成之后,发送方等待接收方的状态报告,如果状态报告报文发送成功,发送后续的数据报文,否则重传该报文。停等式ARQ,发送窗口和接受窗口的...
  • 分析了计算机网络数据链路层两个重要协议——— 停止等待协议和连续ARQ 协议的运行机制、算法实现, 并对两种协议的应用效果用链路控制方案的主要参数进行了定量分析.
  • 5.4.1 停止等待协议

    2021-05-02 11:56:01
    停止等待 每发送完一个分组就停止发送,等待对方的确认。 收到确认后发送方再发送下一个分组。 1、无差错情况 A发送分组M1,发完就暂停发送,等待B的确认。 B收到了M1就向A发送确认。 A收到了对M1的确认后就再...
  • ARQ自动重传协议模拟

    2012-04-21 13:27:00
    它包括停止等待ARQ协议和连续ARQ协议,错误侦测(Error Detection)、正面确认(Positive Acknowledgment)、逾时重传(Retransmission after Timeout)与负面确认继以重传(Negative Acknowledgment and ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,548
精华内容 1,019
关键字:

停止等待协议和连续arq协议