精华内容
下载资源
问答
  • 一种简单的UDP网络重传机制

    千次阅读 2015-02-03 20:26:32
    功能要求是消息发送间隔1秒,需要有三次重传机制,当超过三次则改发送间隔为3秒。 1、建立消息处理结构:包括消息ID、消息状态(是否发送成功)、重传次数、重传超时时间。 2、建立接收消息线程,当受到消息...

    工作一年多,在技术层面上一直没有太大的成就。总感觉每天都在重复着一件事情,需求,改,需求,再改。在这种重复中,开始变得有些暴躁。很希望能也有所突破,今天刚刚开通了CSDN博客。决定在这个满是大牛的平台上,留下自己的每一点学习过程,也在大家面前呈现自己的编程错误和误区。希望各位大牛能不惜赐教,对文章中有的错误一定要指出来,这会是我最大的收获。

    前段时间,经手一个网络相关软件的开发。由于是新手,在接触到这个项目的时候一时没有太多的头绪。其中有一个关于UDP网络传输中的重传问题,思考了好久自己只能想到一个很耗费资源和调度的方法。最初的想法是这样的:

    功能要求是消息发送间隔1秒,需要有三次重传的机制,当超过三次则改发送间隔为3秒。

    1、建立消息处理结构:包括消息ID、消息状态(是否发送成功)、重传次数、重传超时时间。

    2、建立接收消息线程,当受到消息时,通过消息的ID将消息的状态设定为发送成功。

    3、建立发送消息方法,将消息加入发送队列,调用线程循环:判断消息状态(break)、发送消息、sleep、重传次数++、判断重传次数,修改sleep时间。


    如此一来,虽说实现了消息的发送,但是对于程序的执行起来,每一次发送都需要新起调用线程进行处理。一来程序的开销变得很大;二来,受Windows系统线程最大数量的限制,当连续收发一段时间之后软件最终崩溃了。查询得知可能是系统限制上的问题之后,居然考虑到了调用线程池的方式来处理这样的问题。在进行过一番尝试之后,发现这样的处理只是使这一块的调度变得很是复杂,且多线程之间的数据同步也出现了问题。后来在老大的建议和方案之下,进行了如下的改进。这里就用简单的代码进行说明下。

    class Message
    {
        public int Status { get; set; }	//记录消息的发送状态
        public DateTime SendTime { get; set; }	//记录消息发送的时间
        public int SendCounts { get; set; }	//记录消息发送的次数
        public int TimeOut { get; set; }		//超时时间
        ...					//其他与消息有关的项
    }

    在消息发送处理的同一事务中(注:事务在循环执行)。查询当前时间和消息发送时间的差值。

    if (msg.Status != SUCCESS)		//判断是否发送成功
    {
        TimeSpan span = DateTime.Now - msg.SendTime;
        int total = span.TotalSeconds;		//获取到当前距离发送时间的秒数。
        if (total >= msg.TimeOut)
        {
            send(msg);
            msg.SendTime = DateTime.Now;
            msg.SendCounts++;
            if (msg.SendCounts >= 3)
            {
                msg.TimeOut = 3;
            }
        }
    }

    这样当事务在循环体执行的时候会检测消息是否发送成功,也会根据发送时间来判断处理超时重发和超时将时间延长的处理了。

    上面的代码根据脑海中存留的思路进行书写的,可能在正式的使用中会出现很多问题。这里只是将这个处理过程写下来,希望能得到好的建议和改进优化的方法。

    展开全文
  • 这里写目录标题一级目录二级目录三级目录重传机制超时重传快速重传SACKD-SACK 一级目录 二级目录 三级目录 TCP 是通过序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输的。 重传机制 TCP 实现...

    在这里插入图片描述

    TCP 是通过序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输的。

    TCP 实现可靠传输的方式之一,是通过序列号与确认应答。
    在 TCP 中,当发送端的数据到达接收主机时,接收端主机会返回一个确认应答消息,表示已收到消息。
    在这里插入图片描述
    但在错综复杂的网络,并不一定能如上图那么顺利能正常的数据传输,万一数据在传输过程中丢失了呢?
    所以 TCP 针对数据包丢失的情况,会用重传机制解决。
    接下来说说常见的重传机制:

    超时重传

    重传机制的其中一个方式,就是在发送数据时,设定一个定时器,当超过指定的时间后,没有收到对方的 ACK 确认应答报文,就会重发该数据,也就是我们常说的超时重传。
    TCP 会在以下两种情况发生超时重传:

    数据包丢失

    确认应答丢失

    在这里插入图片描述

    超时时间应该设置为多少呢?

    我们先来了解一下什么是 RTT(Round-Trip Time 往返时延),从下图我们就可以知道:
    RTT

    RTT 就是数据从网络一端传送到另一端所需的时间,也就是包的往返时间。
    超时重传时间是以 RTO (Retransmission Timeout 超时重传时间)表示。
    假设在重传的情况下,超时时间 RTO 「较长或较短」时,会发生什么事情呢?
    在这里插入图片描述

    上图中有两种超时时间不同的情况:

    1.当超时时间 RTO 较大时,重发就慢,丢了老半天才重发,没有效率,性能差;
    2.当超时时间 RTO 较小时,会导致可能并没有丢就重发,于是重发的就快,会增加网络拥塞,导致更多的超时,更多的超时导致更多的重发。
    精确的测量超时时间 RTO 的值是非常重要的,这可让我们的重传机制更高效。

    根据上述的两种情况,我们可以得知,超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。

    在这里插入图片描述
    至此,可能大家觉得超时重传时间 RTO 的值计算,也不是很复杂嘛。
    好像就是在发送端发包时记下 t0 ,然后接收端再把这个 ack 回来时再记一个 t1,于是 RTT = t1 – t0。没那么简单,这只是一个采样,不能代表普遍情况。
    实际上「报文往返 RTT 的值」是经常变化的,因为我们的网络也是时常变化的。也就因为「报文往返 RTT 的值」 是经常波动变化的,所以「超时重传时间 RTO 的值」应该是一个动态变化的值。

    超时触发重传存在的问题是,超时周期可能相对较长。那是不是可以有更快的方式呢? 于是就可以用「快速重传」机制来解决超时重发的时间等待。

    快速重传

    TCP 还有另外一种快速重传(Fast Retransmit)机制,它不以时间为驱动,而是以数据驱动重传
    快速重传机制,是如何工作的呢?
    在这里插入图片描述
    在上图,发送方发出了 1,2,3,4,5 份数据:

    1.第一份 Seq1 先送到了,于是就 Ack 回 2;
    2.结果 Seq2 因为某些原因没收到,Seq3 到达了,于是还是 Ack 回 2;
    3.后面的 Seq4 和 Seq5 都到了,但还是 Ack 回 2,因为 Seq2 还是没有收到;
    4.发送端收到了三个 Ack = 2 的确认,知道了 Seq2 还没有收到,就会在定时器过期之前,重传丢失的 Seq2。
    5.最后,收到了 Seq2,此时因为 Seq3,Seq4,Seq5 都收到了,于是 Ack 回 6 。

    所以,快速重传的工作方式是当收到三个相同的 ACK 报文时,会在定时器过期之前,重传丢失的报文段

    快速重传机制只解决了一个问题,就是超时时间的问题,但是它依然面临着另外一个问题。就是重传的时候,是重传之前的一个,还是重传所有的问题。
    比如对于上面的例子,是重传 Seq2 呢?还是重传 Seq2、Seq3、Seq4、Seq5 呢?因为发送端并不清楚这连续的三个 Ack 2
    是谁传回来的。 根据 TCP 不同的实现,以上两种情况都是有可能的。可见,这是一把双刃剑。 为了解决不知道该重传哪些 TCP 报文,于是就有了SACK 方法

    SACK

    还有一种实现重传机制的方式叫:SACK( Selective Acknowledgment 选择性确认)。
    这种方式需要在 TCP 头部「选项」字段里加一个 SACK 的东西,它可以将缓存的地图发送给发送方,这样发送方就可以知道哪些数据收到了,哪些数据没收到,知道了这些信息,就可以只重传丢失的数据
    如下图,发送方收到了三次同样的 ACK 确认报文,于是就会触发快速重发机制,通过 SACK 信息发现只有 200~299 这段数据丢失,则重发时,就只选择了这个 TCP 段进行重复。
    在这里插入图片描述

    D-SACK

    Duplicate SACK 又称 D-SACK,其主要使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。

    例一;ACK 丢包

    在这里插入图片描述
    「接收方」发给「发送方」的两个 ACK 确认应答都丢失了,所以发送方超时后,重传第一个数据包(3000 ~ 3499)

    于是「接收方」发现数据是重复收到的,于是回了一个 SACK = 3000~3500,告诉「发送方」 3000~3500 的数据早已被接收了,因为 ACK 都到了 4000 了,已经意味着 4000 之前的所有数据都已收到,所以这个 SACK 就代表着 D-SACK。

    这样「发送方」就知道了,数据没有丢,是「接收方」的 ACK 确认报文丢了

    例2:网络延时

    在这里插入图片描述
    1.数据包(1000~1499) 被网络延迟了,导致「发送方」没有收到 Ack 1500 的确认报文。
    2.而后面报文到达的三个相同的 ACK 确认报文,就触发了快速重传机制,但是在重传后,被延迟的数据包(1000~1499)又到了「接收方」;
    3.所以「接收方」回了一个 SACK=1000~1500,因为 ACK 已经到了 3000,所以这个 SACK 是 D-SACK,表示收到了重复的包。
    4.这样发送方就知道快速重传触发的原因不是发出去的包丢了,也不是因为回应的 ACK 包丢了,而是因为网络延迟了。

    可见,D-SACK 有这么几个好处: 1. 可以让「发送方」知道,是发出去的包丢了,还是接收方回应的 ACK 包丢了; 2. 可以知道是不是「发送方」的数据包被网络延迟了; 3. 可以知道网络中是不是把「发送方」的数据包给复制了;

    展开全文
  • TCP重传机制

    万次阅读 2018-09-18 21:47:57
    TCP使用两套独立的机制来完成重传,一是基于时间,二是基于确认信息的构成。  第一种基于时间的重传在其下的数据链路层、网络层乃至同层的UDP协议都有使用,即设置一个计时器来判断数据传输是否超时,当然它们...

           由于TCP的下层网络(IP)可能出现丢失、重复或失序的情况,TCP协议提供可靠数据传输服务。为保证数据传输的正确性,TCP会重传其认为已丢失(包括报文中的比特错误)的包。TCP使用两套独立的机制来完成重传,一是基于时间,二是基于确认信息的构成。

           第一种基于时间的重传在其下的数据链路层、网络层乃至同层的UDP协议都有使用,即设置一个计时器来判断数据传输是否超时,当然它们对于计时器时间的设定规则有所不同。本文主要聚焦于TCP的第二种重传机制。

    快速重传

           快速重传机制[RFC5681]基于接收端的反馈信息来引发重传,而非基于计时器超时重传。与超时重传相比,快速重传能更加及时有效地修复丢包情况。

           快速重传机制要求当接收到失序报文段时,TCP需要立即生成确认信息(重复ACK),并且失序情况表明在后续数据到达前出现了丢包,发送端的工作即为尽快填补丢包带来的数据段空缺。

           所谓重复ACK,举个例子,假设A与B之间建立连接,A向B发送数据,有4个TCP报文段,序列号分别为:N-1,N,N+1,N+2。再假设序列号N的报文段丢失(也许只是延迟到达),将会导致失序:N-1,N+1,N+2。此时接收端回复的ACK将会是N,N,N(接收到N-1的报文段后接收端认为下一个应该是N)。因此TCP等待一定数目的重复ACK(称为重复ACK阙值或dupthresh),来决定数据是否丢失并触发快速重传。通常这个阙值为常量3,但也有一些协议实现可基于当前的失序程度动态调节该值。

           快速重传算法可以概括如下:TCP发送端在观测到至少dupthresh个重复ACK后,即重传可能丢失的数据分组,而不必等到重传计时器超时。不采用SACK时,在接收到有效ACK前最多只能重传一个报文段。根据重复ACK推断的丢包通常与网络拥塞有关,因此快速重传也会触发拥塞控制机制。采用SACK(见下文),ACK可包含额外信息,使得发送端在每个RTT时间内可以填补多个空缺。

    SACK

           由于TCP采用累积ACK确认,因此TCP有时候并不能正确地确认之前已经接收的数据。由于接收的数据是无序的,所以接收到的数据的序列号也是不连续的。在这种情况下,TCP接收方的数据队列中会出现空洞的情况。因此在提供字节流传输服务时,TCP接收方需要防止应用程序使用超出空间的数据。一种方法是直接禁止交付存在空洞的数据,直到空洞被填补。而另一种方法则是使用SACK选项。

           如果TCP发送方能够了解接收方当前的空洞(以及序列空间中超出空洞的乱序数据块),它就能在报文段丢失或接收方遗漏时更好地进行重传工作。接收方通过SACK选项能够提供确认信息描述乱序数据,以帮助发送方有效地利用信息进行重传。

           SACK信息保存于SACK选项中,包含了接收方已经接收的数据块的序列号范围,每个范围被称作一个SACK块,由一对32位的序列号表示。因此,一个SACK选项包含了n个SACK块,长度为(8n+2)个字节,增加的2个字节用于保存SACK选项的种类与长度。由于TCP头部选项的空间有限,因此一个报文段中发送的最大的SACK块数目为3(假设使用了时间戳选项)。虽然只用SYN报文段才能包含“选择确认”选项,但是只要发送方已经发送了该选项,SACK块就能通过任何报文段发送出去。

    带选择确认的重传

           合理采用SACK信息能更快地填补数据空洞,且能减少不必要的重传,原因在于一个RTT内能获知多个空缺。当采用SACK时,一个ACK可包含3个告知失序数据的SACK信息,每个SACK信息包含32位的序列号,代表接收端存储的失序数据的起始至最后一个序列号(加1)。

    伪超时与重传

           在很多情况下,即使没有出现数据丢失也可能引发重传。这种不必要的重传称为伪重传(spurious retransmission),造成伪重传的主要原因是伪超时(spurious timeout),即过早判定超时,其他因素如包失序、包重复,或ACK丢失也可能导致该现象。在实际RTT显著增长以致超过了当前RTO时,就可能出现伪超时。

    包失序

           在IP网络中出现包失序的原因在于IP层不能保证包传输是有序进行的,但这种策略是有利的,因为IP可以选择不同的传输链路,合理利用现有链路。还有其他的原因,例如一些高性能路由器会采用多个并行数据链路进行分组转发,以及不同的处理延时也会导致包的离开顺序与到达顺序不匹配。

           当传输出现失序时,TCP可能会在某些方面受到影响。如果失序发生在反向(ACK)链路,就会使得TCP发送端窗口快速前移,接着又可能会收到一些显然重复而应被丢弃的ACK。由于TCP的拥塞控制行为,这种情况会导致发送端出现不必要的流量突发(即瞬时的高速发送)现象,影响可用网络带宽。

           如果失序发生在正向链路,TCP可能无法正确识别失序和丢包——数据的丢失和失序都会导致接收端收到无序的包,造成数据空缺。当失序程度不是很大时(如两个相邻的包交换顺序),这种情况可以迅速得到处理。反之,当出现严重失序时,TCP会误认为数据已经丢失,这就会导致伪重传。对此问题,可以设置一个合适的快速重传触发阙值来一定程度解决这一个问题。

    包重复

           IP协议可能出现将单个包传输多次的情况。例如,当链路层网络协议执行一次重传,并生成同一个包的两个副本。包的多次重复会使接收端生成一系列的重复ACK,这足以触发伪快速重传。使用SACK(特别是DSACK)就可以简单地忽略这个问题。

     

                                                                                       本文内容摘自《TCP/IP详解 卷1:协议(中文版)第2版》,有改动

           

    展开全文
  • TCP的快速重传机制

    万次阅读 多人点赞 2018-07-10 14:51:37
    一、快速重传机制 上一篇讲到了TCP 的超时重传,但是超时重传往往会带来许多微妙的问题,比如说: 当一个报文段丢失时,会等待一定的超时周期然后才重传分组,增加了端到端的时延。 当一个报文段丢失时,在其等待...

    一、快速重传机制

    上一篇讲到了TCP 的超时重传,但是超时重传往往会带来许多微妙的问题,比如说:

    • 当一个报文段丢失时,会等待一定的超时周期然后才重传分组,增加了端到端的时延。
    • 当一个报文段丢失时,在其等待超时的过程中,可能会出现这种情况:其后的报文段已经被接收端接收但却迟迟得不到确认,发送端会认为也丢失了,从而引起不必要的重传,既浪费资源也浪费时间。

    幸运的是,由于TCP采用的是累计确认机制,即当接收端收到比期望序号大的报文段时,便会重复发送最近一次确认的报文段的确认信号,我们称之为冗余ACK(duplicate ACK)。
    如图所示,报文段1成功接收并被确认ACK 2,接收端的期待序号为2,当报文段2丢失,报文段3失序到来,与接收端的期望不匹配,接收端重复发送冗余ACK 2。
    这里写图片描述

    这样,如果在超时重传定时器溢出之前,接收到连续的三个重复冗余ACK(其实是收到4个同样的ACK,第一个是正常的,后三个才是冗余的),发送端便知晓哪个报文段在传输过程中丢失了,于是重发该报文段,不需要等待超时重传定时器溢出,大大提高了效率。这便是快速重传机制。


    二、为什么是3次冗余ACK

    首先要明白一点,即使发送端是按序发送,由于TCP包是封装在IP包内,IP包在传输时乱序,意味着TCP包到达接收端也是乱序的,乱序的话也会造成接收端发送冗余ACK。那发送冗余ACK是由于乱序造成的还是包丢失造成的,这里便需要好好权衡一番,因为把3次冗余ACK作为判定丢失的准则其本身就是估计值。
    假定通信双方如下:

    A为发送端,B为接收端
    A的待发报文段序号为 N-1,N,N+1,N+2
    假设报文段N-1成功到达

    `
    这里写图片描述
    从以上罗列的情况可以看出,
    在没丢失的情况下,有40%的可能出现3次冗余ACK
    在乱序的情况下必定是2次冗余ACK
    在丢失的情况下,必定出现3次冗余ACK

    基于这样的概率,选定3次冗余ACK作为阈值也算是合理的。在实际抓包中,大多数的快速重传都会在大于3次冗余ACK后发生。

    三、快速重传应用实例

    快速重传机制比较好理解,这里贴上笔者做的两幅图供大家学习参考,若有建议可以提出。第一幅图是在某报文段的超时重传定时器溢出前重传丢失报文段,第二幅图是对应的接收端缓存队列的窗口移动示意。
    快速重传:在某报文段的超时重传定时器溢出前重传丢失报文段

    接收端缓存队列的窗口移动示意

    展开全文
  • TCP超时重传机制

    千次阅读 2015-08-04 19:40:54
    TCP可靠性中最重要的一个机制是处理数据超时和重传。TCP协议要求在发送端每发送一个报文段,就启动一个定时器并等待确认信息;接收端成功接收新数据后返回确认信息。若在定时器超时前数据...影响超时重传机制协议效率
  • TCP超时与重传机制

    千次阅读 2019-07-12 16:16:11
    TCP协议是一种面向连接的可靠的传输层协议,它保证了数据的可靠传输,对于一些出错,超时丢包等问题TCP设计的超时与重传机制。其基本原理:在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送...
  • 文章目录目录TCP 的重传机制(可靠性保障)超时重传快速重传SACK 方法Duplicate SACKACK 丢包场景网络延时场景 TCP 的重传机制(可靠性保障) 常见的重传机制有: 超时重传。 快速重传。 SACK(选择性确认)。 D-...
  • 为什么有些网络用纠错码而不用检错码和重传机制?请给出理由 解:原因一是实时服务质量的要求所致,即使发现错误,也没有时间重发一次。但是数据必须连续发送,这里可使用前置纠错。另一个原因是信道质量很差的情况下...
  • TCP协议的确认重传机制

    千次阅读 2019-07-16 14:52:46
    TCP协议是面向连接的传输层协议,TCP的传输特点具有可靠性,它具有面向连接服务来确保可靠稳定传输,而确认重传机制是TCP协议保证可靠稳定传输最重要的机制,他包括累计确认、超时时间计算、快速重传等几个方面。...
  • TCP的重传机制

    千次阅读 2011-12-30 10:25:50
    重传机制是TCP 中最重要和最复杂的问题之一。 TCP 每发送一个报文段,就对这个报文段设置一次计时器。只要计时器设置的重传时间到 但还没有收到确认,就要重传这一报文段。 由于TCP 的下层是一个互连网环境,IP ...
  • TCP的超时重传机制与拥塞避免

    万次阅读 2016-04-04 21:45:33
    TCP超时与重传机制    TCP协议是一种面向连接的可靠的传输层协议,它保证了数据的可靠传输,对于一些出错,超时丢包等问题TCP设计的超时与重传机制。其基本原理:在发送一个数据之后,就开启一个定时器,若是在这...
  • TCP的阻塞和重传机制

    2017-03-21 19:52:16
    TCP的阻塞和重传机制 网络拥堵 现在网络上大部分的网络请求都是以TCP的方式进行传输的了。网络链路是固定的,各种链路情况也是不一样的。网络拥堵一直是TCP协议设计和使用的时候尽力要避免的。比如,从TCP协议...
  • 【原创】TCP超时重传机制探索

    千次阅读 2015-06-07 17:51:07
    TCP对比UDP协议是一个稳定的协议,依赖于三次握手和重传重试机制来保证数据的稳定传输,本文主要是深入探索TCP协议在超时重传方面的内部机制
  • TCP 确认应答/超时重传机制

    千次阅读 2018-08-16 15:01:27
    确认应答机制(ACK) TCP将每个字节的数据都进行了编号,即为序列号: 每一个ACK都带有对应的确认序列号,意思是告诉发送者,我们已经收到了哪些数据,下一吃发送数据应该从哪里开始。 如上图,主机A给主机B...
  • UDP是不可靠的,它只是一直发送数据,而不管数据有...2. 如果发送方在一定的时间内没有收到确认,则重传数据。 在我们的UDP回射客户和服务器例子中,客户发送的数据报都会被服务器回射,也就是每个数据报都对应了一个回
  • tcp/ip 上,丢包重传机制

    万次阅读 2015-01-07 20:23:14
    上篇中,主要向你介绍TCP协议的定义和丢包时的重传机制。下篇中,重点介绍TCP的流迭、拥塞处理。 废话少说,首先,我们需要知道TCP在网络OSI的七层模型中的第四层——Transport层,IP在第三层——Network层,ARP...
  • UDP 超时重传机制

    万次阅读 2012-03-14 14:43:13
    问题来源: 老式方法:UDP传输设定超时未N秒,发送一个请求后等待N秒钟,若超时都没有收到确认,则重发请求,重发一定次数后便丢弃。...RTO:重传超时 Srtt:平滑化的RTT估算因子 Reevar:平滑化平均偏差估
  • 确认应答机制 超时重传机制 滑动窗口机制 拥塞控制机制 慢启动 拥塞避免 快重传 快恢复 延时应答机制和捎带应答机制
  • TCP 滑动窗口/快速重传机制

    千次阅读 2018-08-17 12:11:19
    我们知道TCP有确认应答机制,对每一个发送的数据段,都要给一个ACK确认应答,收到ACK后再发送ACK中携带的序列号。这样保证了可靠传输。但是有时数据往返的时间比较长时,性能就比较差了。 既然这样一发一收的方式...
  • 我们都知道 TCP 协议具有重传机制,也就是说,如果发送方认为发生了丢包现象,就重发这些数据包。很显然,我们需要一个方法来「猜测」是否发生了丢包。最简单的想法就是,接收方每收到一个包,就向发送方返回一个 ...
  • 想彻底理解一个TCP的机制,有个四部曲:1.读与其相关的RFC;2.看Linux协议栈的TCP实现;3.通过抓包以及其它工具来确认事实就是如此;4.解决一个与之相关的网络问题。经历了以上四步骤,相信任何人都可以在相关领域内...
  • 于是我就想起了在计算机网络中讲数据链路层协议时的“选择重传ARQ”协议(见《计算机网络》第四版 AndrewS.Tanenbaum的p187)来解决丢包问题。我不是一个好学生,所以具体细节忘了一些,遂找出那本书,把那一小节...
  • WebRTC中丢包重传机制的实现

    千次阅读 2017-08-08 09:28:17
    网络质量突然变的很差并开始丢包时,声音听起来音质会变差,画面帧速会下降,甚至会完全卡住。我们可能需要某种机制来应对这种情况。...重传:当接收方检测到有丢包时,它会发送NACK类型的RTCP包给
  • TCP/IP协议栈:TCP超时重传机制

    千次阅读 2020-10-10 08:32:45
    超时重传是TCP协议保证数据可靠性的另一个重要机制,其原理是在发送某一个数据以后就开启一个计时器,在一定时间内如果没有得到发送的数据报的ACK报文,那么就重新发送数据,直到发送成功为止。 TCP可靠性中最重要...
  • linux下的tcp协议栈超时重传机制

    千次阅读 2012-07-14 01:25:54
    TCP协议有个超时重传机制,想必大家都比较熟悉。TCP协议是一种传输可靠的协议,因此这个机制是必不可少的。那么今天要探讨的是在发送队列还有数据的情况下,网络连接异常断开后,协议栈是到底是怎样来处理这些数据的...
  • TCP-IP详解:超时重传机制

    万次阅读 2016-09-11 00:52:22
    超时重传是TCP保证数据传输可靠性的又一大措施
  • 确认应答(ACK)机制 一、什么是确认应答机制 收到一条报文后,向发送端发送一条确认ACK,此ACK的作用就是告诉发送端:接收端已经成功的收到了消息,并且希望收到下一条报文的序列号是什么 序列号 一、什么是...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 91,658
精华内容 36,663
关键字:

网络重传机制