精华内容
下载资源
问答
  • 快速可靠网络传输协议 KCP

    千次阅读 2016-06-07 16:39:56
    KCP 是一个快速可靠协议,能以比 TCP浪费10%-20%的带宽的代价,换取平均延迟降低30%-40%,且最大延迟降低三倍的传输效果。纯算法实现,并负责底层协议(如UDP)的收发,需要使用者自己定义下层数据包的发送方式,...

    KCP 是一个快速可靠协议,能以比 TCP浪费10%-20%的带宽的代价,换取平均延迟降低30%-40%,且最大延迟降低三倍的传输效果。纯算法实现,并不负责底层协议(如UDP)的收发,需要使用者自己定义下层数据包的发送方式,以 callback的方式提供给 KCP。连时钟都需要外部传递进来,内部不会有任何一次系统调用。

    整个协议只有 ikcp.h, ikcp.c两个源文件,可以方便的集成到用户自己的协议栈中。也许你实现了一个P2P,或者某个基于 UDP的协议,而缺乏一套完善的ARQ可靠协议实现,那么简单的拷贝这两个文件到现有项目中,稍微编写两行代码,即可使用。HTTP://www.mobanhou.COM

    技术特性

    TCP是为流量设计的(每秒内可以传输多少KB的数据),讲究的是充分利用带宽。而KCP是为流速设计的(单个数据包从一端发送到一端需要多少时间),以10%-20%带宽浪费的代价换取了比 TCP快30%-40%的传输速度。TCP信道是一条流速很慢,但每秒流量很大的大运河,而KCP是水流湍急的小激流。KCP有正常模式和快速模式两种,通过以下策略达到提高流速的结果:

    RTO翻倍vs不翻倍:

    TCP超时计算是RTOx2,这样连续丢三次包就变成RTOx8了,十分恐怖,而KCP启动快速   模式后不x2,只是x1.5(实验证明1.5这个值相对比较好),提高了传输速度。

    选择性重传 vs 全部重传:

    TCP丢包时会全部重传从丢的那个包开始以后的数据,KCP是选择性重传,只重传真正   丢失的数据包。

    快速重传:

    发送端发送了1,2,3,4,5几个包,然后收到远端的ACK: 1, 3, 4, 5,当收到ACK3时,   KCP知道2被跳过1次,收到ACK4时,知道2被跳过了2次,此时可以认为2号丢失,不用   等超时,直接重传2号包,大大改善了丢包时的传输速度。

    延迟ACK vs 非延迟ACK:

    TCP为了充分利用带宽,延迟发送ACK(NODELAY都没用),这样超时计算会算出较大   RTT时间,延长了丢包时的判断过程。KCP的ACK是否延迟发送可以调节。

    UNA vs ACK+UNA:

    ARQ模型响应有两种,UNA(此编号前所有包已收到,如TCP)和ACK(该编号包已收到   ),光用UNA将导致全部重传,光用ACK则丢失成本太高,以往协议都是二选其一,而   KCP协议中,除去单独的 ACK包外,所有包都有UNA信息。

    非退让流控:

    KCP正常模式同TCP一样使用公平退让法则,即发送窗口大小由:发送缓存大小、接收   端剩余接收缓存大小、丢包退让及慢启动这四要素决定。但传送及时性要求很高的小   数据时,可选择通过配置跳过后两步,仅用前两项来控制发送频率。以牺牲部分公平   性及带宽利用率之代价,换取了开着BT都能流畅传输的效果。

    基本使用

    1. 创建 KCP对象:

      // 初始化 kcp对象,conv为一个表示会话编号的整数,和tcp的 conv一样,通信双
      // 方需保证 conv相同,相互的数据包才能够被认可,user是一个给回调函数的指针
      ikcpcb *kcp = ikcp_create(conv, user);
    2. 设置回调函数:

      1
      2
      3
      4
      5
      6
      7
      8
      9
      // KCP的下层协议输出函数,KCP需要发送数据时会调用它
      // buf/len 表示缓存和长度
      // user指针为 kcp对象创建时传入的值,用于区别多个 KCP对象
      int udp_output(const char *buf, int len, ikcpcb *kcp, void *user)
      {
       ....
      }
      // 设置回调函数
      kcp->output = udp_output;
    3. 循环调用 update:

      1
      2
      3
      // 以一定频率调用 ikcp_update来更新 kcp状态,并且传入当前时钟(毫秒单位)
      // 如 10ms调用一次,或用 ikcp_check确定下次调用 update的时间不必每次调用
      ikcp_update(kcp, millisec);
    4. 输入一个下层数据包:

      1
      2
      // 收到一个下层数据包(比如UDP包)时需要调用:
      ikcp_input(kcp, received_udp_packet, received_udp_size);

      处理了下层协议的输出/输入后 KCP协议就可以正常工作了,使用 ikcp_send 来向远端发送数据。而另一端使用 ikcp_recv(kcp, ptr, size)来接收数据。

    协议配置

    协议默认模式是一个标准的 ARQ,需要通过配置打开各项加速开关:

    1. 工作模式:

      int ikcp_nodelay(ikcpcb *kcp, int nodelay, int interval, int resend, int nc)

      nodelay :是否启用 nodelay模式,0不启用;1启用。interval :协议内部工作的 interval,单位毫秒,比如 10ms或者 20msresend :快速重传模式,默认0关闭,可以设置2(2次ACK跨越将会直接重传)nc :是否关闭流控,默认是0代表不关闭,1代表关闭。普通模式:`ikcp_nodelay(kcp, 0, 40, 0, 0);极速模式: ikcp_nodelay(kcp, 1, 10, 2, 1);

    2. 最大窗口:

      1
      int ikcp_wndsize(ikcpcb *kcp, int sndwnd, int rcvwnd);

      该调用将会设置协议的最大发送窗口和最大接收窗口大小,默认为32.

    3. 最大传输单元:

      纯算法协议并不负责探测 MTU,默认 mtu是1400字节,可以使用ikcp_setmtu来设置该值。该值将会影响数据包归并及分片时候的最大传输单元。

    4. 最小RTO:

      不管是 TCP还是 KCP计算 RTO时都有最小 RTO的限制,即便计算出来RTO为40ms,由于默认的 RTO是100ms,协议只有在100ms后才能检测到丢包,快速模式下为30ms,可以手动更改该值:

      1
      kcp->rx_minrto = 10;

    最佳实践

    内存分配器

    默认KCP协议使用 malloc/free进行内存分配释放,如果应用层接管了内存分配,可以  用ikcp_allocator来设置新的内存分配器,注意要在一开始设置:

    ikcp_allocator(my_new_malloc, my_new_free);

    前向纠错注意

    为了进一步提高传输速度,下层协议也许会使用前向纠错技术。需要注意,前向纠错会根据冗余信息解出原始数据包。相同的原始数据包不要两次input到KCP,否则将会导致kcp以为对方重发了,这样会产生更多的ack占用额外带宽。

    比如下层协议使用最简单的冗余包:单个数据包除了自己外,还会重复存储一次上一个数据包,以及上上一个数据包的内容:

    Fn = (Pn, Pn-1, Pn-2)
    
    P0 = (0, X, X)
    P1 = (1, 0, X)
    P2 = (2, 1, 0)
    P3 = (3, 2, 1)

    这样几个包发送出去,接收方对于单个原始包都可能被解出3次来(后面两个包任然会重复该包内容),那么这里需要记录一下,一个下层数据包只会input给kcp一次,避免过多重复ack带来的浪费。

    管理大规模连接

    如果需要同时管理大规模的 KCP连接(比如大于3000个),比如你正在实现一套类 epoll的机制,那么为了避免每秒钟对每个连接调用大量的调用 ikcp_update,我们可以使用ikcp_check来大大减少 ikcp_update调用的次数。 ikcp_check返回值会告诉你需要在什么时间点再次调用 ikcp_update(如果中途没有 ikcp_send, ikcp_input的话,否则中途调用了 ikcp_send, ikcp_input的话,需要在下一次interval时调用 update)

    标准顺序是每次调用了 ikcp_update后,使用 ikcp_check决定下次什么时间点再次调用ikcp_update,而如果中途发生了 ikcp_send, ikcp_input的话,在下一轮 interval 立马调用 ikcp_update和 ikcp_check。 使用该方法,原来在处理2000个 kcp连接且每个连接每10ms调用一次update,改为 check机制后,cpu从 60%降低到 15%。

    相关应用

    • dog-tunnel: GO开发的网络隧道,使用 KCP极大的改进了传输速度,并移植了一份 GO版本 KCP
    • lua-kcp:KCP的 Lua扩展,用于 Lua服务器
    • asio-kcp: 使用 KCP的完整 UDP网络库,完整实现了基于 UDP的链接状态管理,会话控制,KCP协议调度等
    • KCP协议开源地址:https://github.com/skywind3000/kcp

    协议比较

    如果永远不丢包那么 KCP和 TCP性能差不多,但网络会卡,造成卡的原因就是丢包和抖动。在内网里直接比较,大家都差不多,但是放到公网上,放到3G/4G网络情况下,或者使用内网丢包模拟,差距就很明显了。公网在高峰期有平均接近10%的丢包,wifi/3g/4g下更糟糕,这正是造成各种网络卡顿的元凶。

    感谢 asio-kcp 的作者 zhangyuan 对 KCP 与 enet, udt做过的一次横向评测,结论如下:

    • ASIO-KCP has good performace in wifi and phone network(3G, 4G).
    • Extra using 20% ~ 50% network flow for speed improvement.
    • The kcp is the first choice for realtime pvp game.
    • The lag is less than 1 second when network lag happen. 3 times better than enet when lag happen.
    • The enet is a good choice if your game allow 2 second lag.
    • UDT is a bad idea. It always sink into badly situation of more than serval seconds lag. And the recovery is not expected.
    • enet has the problem of lack of doc. And it has lots of functions that you may intrest.
    • kcp's doc is chinese. Good thing is the function detail which is writen in code is english. And you can use asio_kcp which is a good wrap.
    • The kcp is a simple thing. You will write more code if you want more feature.
    • UDT has a perfect doc. UDT may has more bug than others as I feeling.
    展开全文
  • rdt 可靠数据传输协议

    万次阅读 多人点赞 2018-05-20 11:22:54
    计算机网络的设计基本方案是复杂化,多功能化应用...为了保证数据传输的可靠性,我们选择在运输层采用复杂的rdt(可靠数据传输协议),以完成网络可靠性。 原理图如下所示: rdt协议经历了rdt1.0,rdt2.0,rd...

    计算机网络的设计基本方案是复杂化,多功能化应用层,运输层的协议设计,从而使得网络层,链路层,物理层变得相对简单,网络搭建的物质条件变得简单。由于网络层较为简单,采用了无连接的协议,在不可靠信道上传输,导致数据传输是不可靠的。为了保证数据传输的可靠性,我们选择在运输层采用复杂的rdt(可靠数据传输协议),以完成网络的可靠性。

    原理图如下所示:

    rdt协议经历了rdt1.0,rdt2.0,rdt2.1,rdt2.2,rdt3.0.一步步完善,使得网络得到很好的安全性稳定性。

    rdt1.0是基于理想情况下的协议,假设所有信道都是可靠的,没有比特位的翻转,没有数据包的丢失与超时,所以rdt1.0的传输功能就是 发送方发送数据,接收方接受数据。

    rdt2.0在rdt1.0的基础上解决了比特位翻转的问题,这里的比特位防撞发生在运输层下面的不可信信道中数据包中的1可能会变0,0可能会变成1。rdt2.0增加了3种新机制:1.错误检验 2.接收者反馈接受信息(ACK,NAK)3.重传机制。在运输层对应用层的数据进行打包处理时,新增checksum(校验和),从而接收端可以对其数据包进行检验,如果正确,返回ACK,发送者继续发送下一个数据包;如果不正确,返回NAK,发送者重传数据。

    但是rdt2.0有着一个致命的缺点,只考虑了发送方到接收方的数据传输,如果反馈信息ACK,NAK传输时发生比特位翻转会出现什么情况?如果ACK发生翻转,那么发送方会再次重复的发送相同的数据包;如果NAK发生翻转,那么发送方会认为数据传输情况很好,但是接收方却已经收到了一个错误的数据包。

     

    由此rdt2.1应运而生,在rdt2.0的基础之上,发送方在打包数据包时添加了0或者1编号,同样ACK,NAK字段上也添加了0,1字段,表示0.1号字段的确认或者否定。发送方就有了2种状态发送0号数据包,1号数据包,接收方也有了2种状态等待0号数据包和等待1号数据包。现在假设情景发送方向接收方发送0号数据包,如果接收方接收到0号数据包,返回ACK,但是ACK出现翻转,接收方处于等待1号数据状态,发送方重复发送0号数据,接收方会拒绝0号数据,避免重复。如果接收方接收到0号数据包出现错误,返回NAK,但是NAK出现翻转,接收方处于等待0号数据状态,发送方继续发送1号数据,接收方会拒绝1号数据,避免错序。

    rdt2.2是在rdt2.1上的基础之上做了小小的改善,摒弃了NAK,只需采用ACK。我们在ACK的信息上加上了期望的顺序号,现在假设情景发送方向接收方发送0号数据包,如果接收方接收到0号数据包,返回(ACK,1),发送方接着发送1号数据包。如果接收方接收到0号数据包出现错误,返回(ACK,0),发送方重传0号数据包。

    rdt2.2之前的版本都重在处理数据包的比特位翻转情况,却没有考虑到数据包在传输过程中出现的数据包丢失问题,这样数据包丢失会使得网络处于拥塞状态。

    rdt3.0在rdt2.2的基础之上处理了数据包丢失的情况,增加了计时器的机制,如果在RTT时间段内,发送方没有接收到反馈信息,那么发送方默认数据包已经丢失了,会自动重传。

    rdt3.0性能分析:

    rdt3.0 可以工作, 但是性能很差

    ex: 1 Gbps 链路, 15 ms 传播延迟, 8000 bit数据报:

    U sender: utilization – 发送者忙于发送的时间占比

    每30 msec发送 1KB pkt -> 33kB/sec (1 Gbps 链路)

    这是一个网络协议严重影响链路资源利用的一个例子!

    主要原因是在RTT时间段内,网络处于空闲状态,而RTT时间段比较长,使得利用率十分的低。

    在此基础上采用流水线协议来改进rdt3.0

    允许发送者发送多个, “在途(in-flight)”, 等待确认的数据报
    顺序号的范围必须扩大
    Sender /receiver必须使用缓冲区

    主要有两类流水线协议: go-Back-N, selective repeat。

    大致描述如下:

     go-Back-N(回退N重传协议):

    1.发送者在流水线中最多有 N 个未确认的数据报。

    2.接收者仅发送累计的确认 ,如果中间有数据报缺失,就不予以确认。

    3.发送者对最久未确认的数据报进行计时,如果计时器到点, 重传所有未确认的数据报。

    4.发送窗口大于1,接受窗口等于1(也就意味着如果某一个报文段出现错误,那么接受窗口会停留再次,之后收到的数据将会被丢弃)

    selective repeat(选择重传协议):

    1.发送者在流水线中最多有 N 个未确认的数据报。
    2.接收者对单个数据报进行确认。

    3.发送者对每一个未确认的数据报进行计时,如果计时器到点, 仅重传该个未确认的数据报。

    4.发送窗口大于1,接受窗口大于1(意味着可以缓存出错位置之后的报文段),最好是两者相同


    展开全文
  • 这一周做了一个计算机网络的实验,名字叫 可靠数据传输协议-GBN协议的设计与实现 感觉自己做的很认真,实现的效果也不错,就把自己的过程与结果记录一下 对于这个实验,实验要求上说实现SR协议是加分项,而SR协议又是以...

    这一周做了一个计算机网络的实验,名字叫 可靠数据传输协议-GBN协议的设计与实现
    感觉自己做的很认真,实现的效果也不错,就把自己的过程与结果记录一下

    对于这个实验,实验要求上说实现SR协议是加分项,而SR协议又是以GBN协议为基础,所以自己直接一步到位,只实现了 SR 协议(偷了个懒 ) (>ω<)
    首先先粘最最重要的资源,包括完整源代码和实验报告 : gitbub项目地址

    以下内容截取自实验报告:(提取有用信息)

    GBN的原理与实现

    原理:

    GBN是属于传输层的协议,它负责接收应用层传来的数据,将应用层的数据报发送到目标IP和端口

    滑动窗口: 假设在序号空间内,划分一个长度为N的子区间,这个区间内包含了已经被发送但未收到确认的分组的序号以及可以被立即发送的分组的序号,这个区间的长度就被称为窗口长度。(随着发送方方对ACK的接收,窗口不断的向前移动,并且窗口的大小是可变的)

    GBN一个分组的发送格式是 Base(1Byte) + seq(1Byte) + data(max 1024Byte)

    GBN协议的传送流程是: 从上层应用层获得到一个完整的数据报,将这个数据报进行拆分(一个GBN数据帧最大传输的数据大小限制为1024B,因为在以太网中,数据帧的MTU为1500字节,所以UDP数据报的数据部分应小于1472字节(除去IP头部20字节与UDP头的8字节)),如果发送方的滑动窗口中,如果窗口内已经被发送但未收到确认的分组数目未达到窗口长度,就将窗口剩余的分组全部用来发送新构造好的数据,剩余未能发送的数据进行缓存。发送完窗口大小的数据分组后,开始等待接收从接收方发来的确定信息(ACK),GBN协议采取了累积确认,当发送方收到一个对分组n的ACK的时候,即表明接收方对于分组n以及分组n之前的分组全部都收到了。对于已经确认的分组,就将窗口滑动到未确认的分组位置(窗口又有空闲位置,可以发送剩余分组了),对于未确认的分组,如果计时器超时,就需要重新发送,直到收到接收方的ACK为止。
    对于超时的触发,GBN协议会将当前所有已发送但未被确认的分组重传,即如果当前窗口内都是已发送但未被确认的分组,一旦定时器发现窗口内的第一个分组超时,则窗口内所有分组都要被重传。每次当发送方收到一个ACK的时候,定时器都会被重置。
    接收方只需要按序接收分组,对于比当前分组序号还要大的分组则直接丢弃。假设接收方正在等待接收分组n,而分组n+1却已经到达了,于是,分组n+1被直接丢弃,所以发送方并不会出现在连续发送分组n,分组n+1之后,而分组n+1的ACK却比分组n的ACK更早到达发送方的情况。

    实现:

    发送方:

    首先定义窗口大小,起始 base 的值, 窗口采用链表的数据结构存储
    private int WindowSize = 16;
    private long base = 0;
    进入一个循环,循环结束条件是所有需要传送的数据都已经发送完成,并且窗口中的分组都已经全部确认。
    在这个循环中,如果窗口内有空余,就开始发送分组,直到窗口被占满,计时器开始计时,之后进入接收ACK的状态,收到ACK之后,更新滑动窗口的位置,之后如果计时器超时,就将窗口内所有的分组全部重发一次。之后开始下一次循环。

    接收方:

    不需要有缓存,只需要记录一个seq值,每成功接收一个数据帧,seq+1,开始循环顺序接收数据帧,对于seq不是目标值得数据帧直接丢弃,如果是符合要求的数据帧,就给发送方发送一个ACK=seq的确认数据帧,直到发送方没有数据传来为止。
    GBN的实现就完成了。

    SR协议的原理与实现:

    SR协议的原理:

    SR协议是在GBN协议的基础上进行的改进。
    对于SR协议来说,发送方需要做到:
    为每一个已发送但未被确认的分组都需要设置一个定时器,当定时器超时的时候只发送它对应的分组。
    当发送方收到ACK的时候,如果是窗口内的第一个分组,则窗口需要一直移动到已发送但未未确认的分组序号。
    对于接收方,需要设置一个窗口大小的缓存,即使是乱序到达的数据帧也进行缓存,并发送相应序号的ACK, 并及时更新窗口的位置,窗口的更新原则同发送方。

    SR协议实现:

    发送方:

    在GBN发送方的基础上,增加一个基于链表数据结构的计时器,对每一个未被确认的分组进行计时。在每次判断是否超时时,需要对链表中所有的计时进行判断,与GBN重传不同的是,SR只对超时的那一个分组进行重传。

    发送方完整代码见gitbub项目中 SR.java中的void send(byte[] content) 函数

    接收方:

    需要增加一个同发送方的对分组的缓存,用于缓存乱序到达的分组,同样使用链表数据结构。
    List datagramBuffer = new LinkedList<>();
    首先进入一个循环, 一次循环需要进行如下工作:
    接收分组,将分组的数据缓存到datagramBuffer对应的位置(因为到达的数据可能是乱序的)
    然后发送数据分组对应seq的ACK,告知发送方自己已经成功接收。 之后更新滑动窗口的位置,更新的规则同发送方一样。之后进行下一次循环。
    直到发送方没有新的数据传来,超过接收方设定的最大时间,就结束循环,将接收到的数据拼接成一个完整的Byte数组,传给应用层。

    接收方的完整代码见github项目中 SR.java中的 ByteArrayOutputStream receive() 函数

    SR协议的实现就完成了。

    双向传输的实现:

    发送方发送数据需要占用一个固定的端口,而接收方也需要一个固定的端口来向发送方发送 ACK,所以就可以封装一个完整的协议类,类似于TCP的有连接传输一样,发送方和接收方之间在两个固定的ip和端口之间进行数据的传输,直到双方的传输结束。发送方在使用send()函数进行发送时,也可以同时使用receive()函数进行接收,两个过程并不冲突,可以同时进行。如果要同时收发,就需要同时开一个发送线程和一个接收线程,两个线程独立运行,没有冲突,这样就可以实现双向数据传输了。
    所以我构造了一个SR class,其中包含的成员变量有:

    private InetAddress host;
    private int targetPort, ownPort;
    private int WindowSize = 16;
    private final int sendMaxTime = 2, receiveMaxTime = 4; // max time for one datagram
    private long base = 0;
    private final int virtualLossRemainder = 17; // this value is used to simulate the loss of the datagram as a remainder
    

    包含的函数有两个:

    void send(byte[] content) // 负责数据的发送
    ByteArrayOutputStream receive()  // 负责数据的接收
    private ByteArrayOutputStream getBytes(List<ByteArrayOutputStream> buffer, long max) //负责将接收到的数据分组拼接成一个完整的数据报
    private boolean checkWindow(List<Integer> timers) 负责判断当前的窗口是否可以移动
    

    详细的代码见github项目中SR.java

    在Client 主函数中先使用SR协议发送一张图片, 在Server 主函数中使用SR协议接收这张图片,并保存。然后向Client发送另一张图片, Client由发送变成接收。
    这有就可以实现双向文件的发送和接收了。
    详细的代码见github项目中 Client.java 中 main函数和Server.java中的main函数

    模拟丢包

    在接收端,设立一个计数变量count, 然后每次收到数据帧就加一,如果count 对一个数取余=0就不发送ACK,模拟这一分组丢失的情况,然后测试发送方会不会重新发送丢失的分组。
    这一部分的代码实现详见github项目中 SR.java中 receive中 count这个变量。

    展开全文
  • 2017-02-10 可靠数据传输原理、可靠数据传输协议、自动重传请求协议、停等协议、冗余分组、比特交替协议、滑动窗口协议 ...由于可靠数据传输协议的下层协议也许是不可靠的,因此这是一项困难的任务。  

    2017-02-10 可靠数据传输原理、可靠数据传输协议、自动重传请求协议、停等协议、冗余分组、比特交替协议、滑动窗口协议

    《计算机网络-自顶向下方法》(原书第6版)


    3.4 可靠数据传输原理

        可靠数据传输协议(reliable data transfer protocol)。由于可靠数据传输协议的下层协议也许是不可靠的,因此这是一项困难的任务。

        单向数据传输(unidirectional data transfer)即数据传输是从发送端到接收端的。

        双向数据传输(bidirectional data transfer)(即全双工数据传输


    3.4.1 构造可靠数据传输协议

        先假定发送的分组按其发送的顺序被接收,且不丢失分组

        1:经完全可靠信道的可靠数据传输

            首先我们考虑最简单的情况,即底层信道是完全可靠的。

            有限状态机(Finite-State Machine,FSM)

        2:经具有比特差错信道的可靠数据传输

            肯定确认(positive acknowledgment)

            否认确认(negative acknowledgment)

            这些控制报文使得接收方可以让发送方知道哪些内容被正确接收,哪些内容接收有误并因此需要重复。在计算机网络环境中,基于这样重传机制的可靠数据传输协议称为自动重传请求(Automatic Repeat reQuest,ARQ)协议,这就需要差错检测、接收方反馈、重传三个功能。

        停等(stop-and-wait)协议:要等到上一个分组得到正确接收的确认后才能处理下一个分组。它存在一个致命的缺陷。尤其是我们没有考虑到ACK或NAK分组受损的可能性。

        考虑处理受损ACK和NAK的3种可能性

            第一种:接收方对受损的ACK或NAK继续做错误反馈,由于发出的错误反馈可能再次受损,这样就有可能进入死循环。

            第二种:增加足够的检验和比特,使发送方不仅可以检测差错,还可以恢复差错。对于会产生差错但不丢失分组的信道,这就可以直接解决问题。

            第三种:当接收方收到含糊不清的ACK或NAK分组时,只需重传当前数据分组即可。这种方法在发送方到接收方的信道中引入了冗余分组(duplicate packet)。冗余分组的根本困难在于接收方不知道他上次所发送的ACK或NAK是否被发送方正确的收到。因此他无法事先知道接收到的分组是新的还是一次重传。

            对于第三种情况,解决这个新问题的的简单方法是在数据分组中添加一新字段,让发送方对其数据分组编号,即将发送数据分组的序号(sequence number)放在该字段。

        3.经具有比特差错的丢包信道的可靠数据传输

            冗余数据分组(duplicate data packet)

            从发送方的观点来看,重传是一种万能灵药。发送方不知道是一个数据分组丢失,还是一个ACK丢失,或者只是该分组或ACK过度延时。在所有这些情况下,动作是同样的:重传。

            因为分组序号在0和1之间交替,因此rdt3.0有时被称为比特交替协议(alternating-bit protocol)



    Pasted Graphic 1.tiff


    3.4.2 流水线可靠数据传输协议

    流水线(pipelining)流水线技术对可靠数据传输协议带来如下影响:

        1:必须增加序号范围,因为每个输送中的分组(不计算重传的)必须有一个唯一的序号,而且也许有多个在输送中未确认的报文。

        2:协议的发送方和接收方两端必须缓存多个分组。发送方最低限度应当能缓冲那些已发送但是没有确认的分组。如下讨论,接收方或许也需要缓存那些已正确接收的分组。

        3:所需序号范围和对缓存的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。解决流水线差错恢复有两种基本方法是:回退N步(Go-Back-N,GBN)和选择重传(Selective Repeat,SR)。


    3.4.3 回退N步

        窗口长度(window size),滑动窗口协议(sliding-window protocol)

        序号空间可被看作是一个长度为2的k次方的环,其中序号2的k次方减1紧接着序号0,TCP有一个32比特的序号字段,其中的TCP序号是按字节流中的字节进行计数的,而不是按分组计数。

        基于事件的编程(event-based programming)


    3.4.4 选择重传

        GBN中单个分组的差错就能够引起GBN重传大量分组,许多分组根本没有必要重传。


    1:可靠数据传输协议(reliable data transfer protocol)、2:单向数据传输(unidirectional data transfer)、3:双向数据传输(bidirectional data transfer)、4:有限状态机(Finite-State Machine,FSM)、5:肯定确认(positive acknowledgment)、6:否认确认(negative acknowledgment)、7:自动重传请求(Automatic Repeat reQuest,ARQ)协议、8:停等(stop-and-wait)协议、9:冗余分组(duplicate packet)、10:分组的序号(sequence number)、11:比特交替协议(alternating-bit protocol)、12:流水线(pipelining)、13:窗口长度(window size)、14:滑动窗口协议(sliding-window protocol)、15:基于事件的编程(event-based programming)

    展开全文
  • 一、所实现停等协议简介 我设计的程序实现的是rdt3.0版本的停等协议,发送端将数据包以0、1交替的顺序发送数据包,当发送0数据包之后开始计时,只有接收到ack0才能继续发送1数据包,如果在没有接收到ack0的时候已经...
  • 可靠传输协议

    千次阅读 2015-04-09 22:17:06
    所谓可靠传输协议,通俗一点说,就是发送方给接收方发送数据,接收方保证能正确接收到数据。一个可靠传输协议一般需要有三个性质:ACK、超时重传、序列号(数据包的序列号与ACK的序列号)。 ACK肯定不用说必须有,...
  • 但是UDP协议是面向无连接的,它只提供最大努力的服务,也就是说UDP协议不带有在发送端进行数据报分组,在接收端再对收到的报文进行重新 排序和组装的功能。这样一来,当一个数据报从发送端出发后,系统是不对报文...
  • KCP网络传输协议

    千次阅读 2017-09-19 17:12:16
    KCP是一种快速的可靠的ARQ协议(A Fast and Reliable ARQ Protocol),但严格意义上讲KCP并不是一种网络传输协议,因为KCP并不负责网络底层的数据收发工作,通常由传统的UDP协议来完成底层数据的收发,KCP只是一种...
  • 可靠数据传输协议-Rdt协议

    千次阅读 2019-03-10 20:57:11
    1. Rdt 1.0 协议 2. Rdt 2.0 协议 3. Rdt 2.1 4. Rdt 2.2 5. Rdt 3.0 常用的Rdt 3.0的实例情况有以下几种: 一、引言 该文章来源于教材的思路。 使用FSM状态机描述发送方和接收方服务响应状态。 在阅读...
  • IP协议之所以是不可靠的是因为IP网络存在冲突丢包及传输错误甚至被恶意篡改的情况;虽然IP协议不可靠的,但其服务的上层协议为了规避这些不可靠的因素,有些协议就会自己设计机制从而保证自己传输的内容可靠;TCP...
  • 网络传输协议概述

    千次阅读 2015-03-13 10:40:30
    网络传输协议概述 第二讲:TCP/IP协议概述 网络传输协议或简称为传送协议(Communications Protocol),是指计算机通信的共同语言。现在最普及的计算机通信为网络通信,所以“传送协议”一般都指计算机...
  • SRT是由Haivision和Wowza共同创建的SRT联盟所发起的互联网传输协议,是一种开源、免费和应用灵活的规范,它的性能与专用的协议一样优秀,同时能够在不同制造商生产的产品之间工作。 SRT是时下非常受欢迎的开源低延迟...
  • 网络传输协议总结

    千次阅读 2014-04-05 13:51:29
    IP协议用于网络接口层,最常用的在于传输层(TCP\UDP—SSL\TLS),应用层(HTTP—-HTTPS, Socket,T3)注意HTTP基于TCP协议上,socket针对两类TCP\UDP传输都有对应的连接方法。注意互联网某个应用所用到的协议,应该...
  • 网络传输协议tcp和udp协议的区别

    千次阅读 2018-05-02 22:43:45
    1. tcp: 传输控制协议,全拼:Transmission Control Protocol 它是一个面向连接,可靠传输协议2. udp: 用户数据报协议,全拼:User Datagram Protocol 它不是面向连接,不是可靠传输协议, udp协议传输速度快3. tcp和...
  • 网络基础:TCP协议-如何保证传输可靠

    万次阅读 多人点赞 2018-05-24 13:04:51
    TCP协议传输的特点主要就是面向字节流、传输可靠、面向连接。这篇博客,我们就重点讨论一下TCP协议如何确保传输可靠性的。 确保传输可靠性的方式 TCP协议保证数据传输可靠性的方式主要有: 校验和 序列号 ...
  • 可靠数据传输协议之选择重传

    千次阅读 2017-11-12 21:14:07
    选择重传协议通过让发送方仅重传那些它怀疑在接收方出错的分组而避免了不必要的重传。选择重传要点选择重传个别的、按需的重传要求接收方逐个地确认接收的分组。 选择重传发送方的事件与动作 - 从上层收到数据。...
  • 26-tcp可靠传输——停止等待协议

    千次阅读 2018-04-30 18:39:39
      通过前面的学习可知,网络传输数据时是尽最大努力传输到目的地,并保障数据的可靠传输,对于网络拥塞,延迟,数据丢失等问题没有采取有效的措施。因此我们需要一种数据可靠传输的通信方式,即tcp来实现发送...
  • 传输层有两个协议,一个是TCP(可靠传输协议),一个是UDP(不可靠传输协议)。 根据五层模型,传输层接收的是网络层数据,也就是说TCP接收的数据(报文段)是由IP传送的,而IP只能提供不可靠传输服务,所以传输层在加...
  • 20170907_我是如何讲清楚TCP协议是如何保证可靠传输
  • 5.3.1计算机网络传输层之TCP可靠传输

    千次阅读 2020-04-15 00:10:58
    文章目录0.前言1.TCP可靠传输简介2....计算机网络传输层之TCP协议(tcp协议特点、tcp报文段首部格式、tcp连接—三次握手、tcp连接释放—四次握手) 1.TCP可靠传输简介 2.序号 3.确认 4.重传 ...
  • 构造可靠数据传输协议、滑动窗口协议、比特交替协议、回退N步协议、选择重传协议 1:冗余数据分组(duplicate data packet)、2:倒计数定时器(countdown timer)、3:比特交替协议(alternating-bit protocol...
  • TCP协议如何实现可靠传输

    千次阅读 2018-03-18 13:23:55
    这种可靠传输协议常称为自动重传请求ARQ(Automatic Repeat reQuest)。 3. ARQ表明重传的请求是自动进行的,接收方需要请求发送重传某个出错的分组。 2. 停止等待协议的优点是简单,缺点是信道利用率太低。...
  • ude是一款基于udp的可靠传输协议,专门用于在数据传输方面对实时性要求较高的应用领域。
  • 网络视频传输协议

    千次阅读 2018-01-04 08:58:11
    网络视频传输协议--RTP/RTCP/RTSP/SIP/SDP 之间关系 1、 RTP Real-time Transport Protocol,是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。...
  • 一种基于UDP的可靠传输协议

    千次阅读 2014-03-25 17:42:20
    一种基于UDP的可靠传输协议 摘要:传统的UDP协议通信效率高、可靠性较差,适合对可靠性要求较高的应 用环境。目前随着网络传输的快速发展,某些应用场合需要在保证高效性的基础上 提高通信双方传输...
  • rdt 3.0 协议性能分析 假设有两台主机,分别位于美国西海岸和东海岸,它们之间的往返传播实验 RTT 大约为 30ms,假定它们通过一条速率 R 为 1Gbps 的信道相连。包括首部字段和数据的分组长 L 为 1000 bytes(8000 ...
  • 几种常用的网络传输协议

    千次阅读 2019-10-07 10:36:08
    保持SNMP的独立性,依赖于具体的计算机、网关和网络传输协议。在最近的改进中,又加入了保证SNMP体系本身安全性的目标。  OSPF(Open Shortest Path First开放式最短路径优先)是一个内部网关协议(Interior Gateway...
  • 可靠传输协议 rdt 1.0、rdt 2.0、rdt 2.1、rdt 2.2、rdt3.0

    千次阅读 多人点赞 2019-03-06 08:17:51
    计算机网络的设计基本方案是复杂化,多功能化应用层,运输层的协议设计...为了保证数据传输的可靠性,我们选择在运输层采用复杂的rdt(可靠数据传输协议),以完成网络可靠性。 原理图如下所示: rdt协议经历了rd...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 201,582
精华内容 80,632
关键字:

不可靠网络传输协议的是