精华内容
下载资源
问答
  • 可靠传输协议

    2015-05-08 10:23:50
    该文件基于C语言编程对可靠传输协议进行模拟仿真,希望对你有借鉴作用。
  • 可靠传输的原理,TCP可靠传输的实现 (1)差错控制:确认和重传机制(超时重传,累积确认) (2)流量控制:滑动窗口(平衡双方的发送接收速度) TCP可靠传输的实现: 以字节为单位的滑动窗口 超时重传(超时...

    可靠传输的原理,TCP可靠传输的实现

    (1)差错控制:确认和重传机制(超时重传,累积确认)

    (2)流量控制:滑动窗口(平衡双方的发送接收速度)

    TCP可靠传输的实现:

    1. 以字节为单位的滑动窗口
    2. 超时重传(超时时间主要为加权平均往返时间)
    3. 选择确认

    TCP流量控制:

    1. 利用滑动窗口实现流量控制
    2. 考虑传输效率(最大报文段长度MSS,只要达到MSS就发送报文)

    TCP拥塞控制:

    1. 慢开始:由小到大逐渐增大拥塞窗口数值
    2. 拥塞避免:拥塞窗口cwnd按线性规律缓慢增长
    3. 快重传:接收方每收到一个失序报文段后立即发出重复确认。
    4. 快恢复:当发送方连续收到三个重复确认时,把慢开始门限减半,预防网络拥塞。然后把cwnd值设为慢开始门限减半后的值,然后执行拥塞避免算法。
    展开全文
  • rdt可靠传输实验。实现了rdt3.0协议和GBN协议 内含实验报告
  • 关于数据链路层和传输层提供的可靠传输的疑问和回答 传输层协议UDP,书上说不必事先建立连接,是无连接的不可靠的协议,只是尽最大努力交付,但UDP仅是传输层协议,下面还有数据链路层协议啊,该层中有超时重传,...

    原文地址: 数据链路层和TCP传输层的迷思

    关于数据链路层和传输层提供的可靠传输的疑问和回答

    1. 传输层协议UDP,书上说不必事先建立连接,是无连接的不可靠的协议,只是尽最大努力交付,但UDP仅是传输层协议,下面还有数据链路层协议啊,该层中有超时重传,差错重传的ARQ协议,这样,原始的数据帧就能可靠通信了,上层数据也是通过下层数据表现的,不同样也能保证可靠通信吗?为什么说UDP是不可靠的?

    数据链路层可以实现无差错的数据帧的交付,但是并不一定一定要实现,这个实现是需要有代价的,比如HDLC协议等等。

    • HDLC采用CRC校验,并且对所有的帧进行编号,通过序和确认机制,可以防止漏发和重发。事实上,HDLC是互联网初期的时候较常使用的数据链路层的协议,因为那个时候数据链路层的传输不是非常可靠。

    • 现在使用的大部分是PPP协议,PPP协议只提供差错检测但不提供纠错,他同样使用的也是CRC校验,只能够保证无差错接收,但是由于不适用序列号和确认机制,所以无法检测重发和漏发。

    如果对于所有的数据帧都使用可靠的数据链路层协议来保证数据链路层的可靠传输的话,那么无疑会极大地增加网络的负担。事实上,网络中许多的数据并不一定都需要保证可靠传输,因此随着网络的发展,数据链路层将保证数据可靠传输交由上层的传输层来控制(UDP和TCP等等)。而数据链路层大部分使用不一定可靠的PPP协议等等。

    最最重要的是:传输层是端到端的,数据链路层是点到点的,想要保证端到端的可靠传输就必须在传输层做文章,仅仅在保证数据链路层各个点之间的可靠传输也不能保证上层数据的可靠性,依然会出现丢包等情况的出现。


    1. 如果有数据链路层的差错重传和超时重传,还要TCP的的重传机制干嘛?

    数据链路层有差错重传和超时重传功能,但是不是所有的数据帧都需要可靠的传输。


    1. 数据链路层和传输层的TCP都有滑动窗口,这不重复了吗?为什么
    • 在数据链路层,由于收发双方是点到点的连接,其流量控制策略相对较为简单,接收窗口和发送窗口即为固定大小的缓冲区的个数,发送方的窗口调整,即缓冲区的覆盖依赖于确认帧的到达,由于信号传播延时和CPU的处理时间等都对相对较为稳定,所以发送方的数据帧和接收方的确认帧,其发送和接收时间是可估计的。
    • 在TCP层,由于一个TSAP可同时与多个TSAP建立连接,每个连接都将协商建立一个窗口(即一对发送和接收缓冲区),所以窗口的管理较为复杂,其流量控制策略是通过窗口公告来实现的,当接收方收到数据后发送的确认中将通报剩余的接收缓冲区大小,发送方的发送窗口调整是根据接收方的窗口公告进行的,也就是即使收到接收方的确认也不一定就能对发送窗口进行调整,一旦发送方收到一个零窗口公告,必须暂停发送并等待接收方的下一个更新窗口公告,同时启动一个持续定时器。

    1. 其它层的首部我看都有长度字段,但TCP的首部中没有长度字段,那怎么知道该报文到哪里结束?

    TCP的报文封装在IP内部,在IP头部中,有两个字段,分别是IP头部长和IP总长,因此,总长减去头部长就可以得到数据部分的长度,也就是传输层封装的数据的长度,TCP的首部中包含有头部的长度,因此可以得到TCP报文的数据的部分的长度。

    展开全文
  • TCP 的可靠传输

    千次阅读 2017-05-22 21:14:05
    TCP 的可靠传输

    摘自:《深入理解计算机网络》 王达著 机械工业出版社
    相关知识链接
    1. IPV4数据报头部格式
    2. IPv6数据报头部格式
    3. IPv4数据报的封装与解封装
    4. IPv4数据报的分段与重组
    5. ARP协议报文格式及ARP表
    6. ARP地址解析原理
    7. ICMP协议及报文格式
    8. IPv6协议族的其它协议
    9. TCP的主要特性
    10. TCP的套接字
    11. TCP端口
    12. TCP连接状态转移
    13. TCP传输的建立
    14. TCP 传输链接的释放
    15. TCP 数据段格式

    TCP 的可靠传输

    TCP是一个可以提供可靠数据传输的传输层协议,那么它到底是如何来保障可靠传输的呢?下面进行具体的分析。

    TCP可靠传输方面,主要采用以下4中机制:

    1. 字节编号机制。TCP 数据段以字节为单位对数据段中的“数据”部分进行一一编号,确保每个字节的数据都可以有序传送和接受。
    2. 数据段确认机制。TCP 要求每接受一个数据段都必须由接收端向发送端返回一个确认数据段(可以用一个去人数据段一次确认全面多个数据段),其中的“确认号”表明接收端已正确接受的数据段序号(“确认号”前面的所有数据段,确认号表示将要接收的下一个数据段编号)。
    3. 超时重传机制。在 TCP 中有一个重传定时器(Retransmission Timer, RTT),在发送一个数据段的同时也启动了该定时器。如果在定时器过期之前该数据段还没有被对方确认的话,且定时器停止,然后重传对应序号的数据段。
    4. 选择性确认(Selective ACK, SACK)机制。在 SACK 支持下,仅可以重传缺少部分的数据,而不会重传那些已经正确接受的数据段。

    以上所说的“字节编号机制”比较好理解,因为是按字节进行编号,所以接收端根据所接收到的数据段中的序号就可以知道前面是否还有数据没有接收到,数据可以按顺序向应用进程提交,在对经过了数据段的数据进行重组时也可以根据这个序号进行正确重组。下面我们将会重点介绍 2、3、4 机制的运行原理。

    TCP 的数据段确认机制

    几个重要概念的理解

    若想详细了解TCP数据段,请点击TCP数据段格式

    1. 数据段

    数据段指 TCP 对从应用层接受的数据进行分割所得到的数据块(也可以是没有经过分割的整个报文,只要它的大小在 MSS 之内),通常包括千个以上的字节,而且必须是整数倍字节数。正因如此,TCP 发送的是字节流,而不是通常所说的报文流,因为在 TCP 数据段中没有报文边界。

    2. 序号

    TCP 发送的数据段中“数据”部分(不包括数据段头部),每个字节都有一个序号,每个数据段中的“序号”字段是以该数据段中第一个字节的序号进行填充的。

    3. 窗口大小

    窗口大小是本端要告诉对端当前可以接受的数据量,也暗示着对端此时可以一次性发送的数据大小,以字节为单位,但这里仅是针对数据段中的“数据”部分,不包括 TCP 数据段头部,因为数据段到了对端的应用层后仅提交“数据”部分。TCP 可以一次性连续发送窗口大小的数据(但实际上发送数据的大小还会受到当前可用的“发送窗口大小”影响),其中包括一个或多个 TCP 数据段。但窗口大小必须小于对应网络中的 MTU (最大传输单元)值大小,否则到了数据链路层还是要进行数据分割。同时要注意的是,“窗口大小”字段是随着接收端可用“接受窗口大小”变化而变化的,不是固定的。


    注意:无论是发送端,还是接收端,都分别有“发送窗口”和“接收窗口”这两个窗口,其大小分别用于发送数据和接受数据的缓存大小。这两个缓存的物理大小对于具体的主机来说是固定不变的,除非人为扩展物理内存,否则不会再扩大,只能沿着缩小的方向进行变化。


    4. 确认号

    确认号指发送包含这个“确认号”的数据段的一段期望接收另一端的下一个数据段的起始序号。同时也暗示了在此序号前的所有字节数据均已正确接收。

    5. ACK

    ACK 是一个表明“确认号”字段是否有效的标志位。只有 ACK 字段的值为1,数据段中的“确认号”才有意义,否则数据段中的“确认号”没有意义,即不具有上面所说得“确认号”含义,因为 TCP 通常不会针对单个数据段进行确认,而是一次性对多个连续数据段进行确认。只需要最近收到的那个数据段进行确认,即表明前面所有数据段均已正确接收。

    TCP 确认机制的特性

    1. TCP 可一次连续发送多个数据段

    TCP 不需要等待接受对方发送的确认数据段(“ACK”字段值为1的数据段)就可以一次性连续发送多个数据段,这样可大大提高数据发送效率。但一次性可发送多少个数据段是受对方返回的“窗口大小”字段值和当前可用“发送窗口”大小双重限制的。因为发送端对还没有收到确认的数据段要进行缓存,这需要占用一定的“发送窗口”大小。

    假设发送端的物理“发送窗口”和接收端的物理“接受窗口”大小均为2000字节,设每个数据段大小为100字节,而接收端返回的数据段中显示“窗口大小”字段值也为2000,同时发送端此时的“发送窗口”还有两个数据段(200字节)还没有收到确认,则此时发送端可发送的数据段数量为18(2000/100 - 2),即1800字节,不能发送全部的2000字节数据。

    如果接收端返回的数据段中显示的“窗口大小”值为1000,则此时发送端可以发送1000字节数据,因为所发送的1000字节数据,在加上原来还没有收到确认的200字节数据,小于发送端的物理“发送窗口”大小——2000。

    仅对连续接收的数据段进行确认

    返回的确认数据段中的“确认号”字段值仅代表对端已正确接收的连续数据段(最高字节序号+1),而不一定是已正确接收数据段中的“最高序号 + 1”,因为中间可能还有数据段因为网络延迟而暂时未收到,或出现了传输错误而丢失。

    假设每个数据段的长度大小均 100 字节,接收端接收到了序号为 1、101、201、401 四个数据段。其中序号为 301 的数据段暂时还没有收到,此时接收端返回的确认数据段中的“确认号”只能是301,而不会是501,(尽管401~501的数据已经正确接受)也就是只对前三个数据段进行确认,不会对后面的401数据段进行确认,因为中间的301数据段还没有收到。当后面收到了301数据段后,可能会返回一个“确认号”为501的数据段,这时就代表301和401数据段均以正确接收了。

    不连续序号的数据将先缓存

    当主机接收到的数据段序号不连续时,不连续部分向应用层的应用进程进行提交,而是先缓存在“接收窗口”中,等待接收到中断的序号的数据段后再一起提交。这时,尽管接收端已正确接受了某些数据,但仍不能及时向应用层提交,需要占用“接收窗口”空间。对于没有按先后次序正确接受的数据,在向应用层提交时会重新按数据段序号重新组合,然后再提交给应用层。

    如某主机先后接收到了对端发来的序号分别为 1、101、201、301、601、501、801 的数据段(假设数据段大小均为100字节),则该主机首先把 1、101、201、301 这4个数据段向应用层提交并向发送端发送一个“确认号”为401的确认数据段,从而可以从“接受窗口”中删除这4个数据段,释放“接受窗口”;然后再把 601、501、801 这3个数据段先缓存在“接受窗口”中,直到接受到了401号数据段,再按 401、501、601 顺序重组并向应用层提交,接着发送一个“确认号”为701的确认数据段,从而又可以从“接受窗口”中删除这三个数据段,释放“接受窗口”,但此时“接受窗口”中仍缓存有801号数据段,因为701号数据段还没有得到确认。

    TCP 超时重传机制

    “超时重传” 是TCP保证数据可靠的另一个重要机制,其原理是在发送某一个数据段以后就开启一个超时重传计时器(Retransmission Timer,RTT)。如果在这个定时器时间内没有收到来自对方的某个数据段的确认,发送端启动重传机制,重新发送对应的数据段,知道发送成功为止。需要注意的是,并不是 RTT 定时器一到,就会立即重传数据,毕竟从“发送窗口”缓存中找到对应的数据段,然后安排重新发送都是需要时间的,实际上,超时重发时间间隔(Retransmission Time Out)要大于 RTT 值。

    SRTT 计算

    这里涉及两个重要问题:一是如何确定 RTT 值,另一个是如何计 RTO 值。表明上看起来 RTT 值很容易确定,因为它就是一个数据段往返发送端和接收端的时间总和,但在 TCP 通信中,中间可能经过了多个性能不一样的网络,而且不同时刻网络的拥塞程度可能不一样,这就造成了不同数据段的 RTT 时间并不一致,甚至波动非常大。但 TCP 必须适应这种情况,必须能动态地跟踪这些变化并相应地改变其超时重传时间。

    正因为 RTT 值不是固定的,所以就出现平滑 RTT(SRTT)的概念,就是在充分考虑历史 RTT 值的情况下所设计的一个 RTT 值计算公式。在最初的 RFC793 中,SRTT 的计算公式如下:


    SRTT(新的SRTT) = α SRTT(旧的 SRTT 值)+ 1α RTT (新的 RTT 样本值)

    SRTT 的初始值就是第一个 RTT 值。这里 α 是一个平滑因子,它决定了旧的 SRTT 值所占的权重, 0α<1 。RFC2988 推荐的 α 典型值为0.125. 如果 α 很接近1,则表示新的 SRTT 值与旧的 SRTT很接近,变化不大。相反,则表示变化很大。显然,用这种方法计算得出的各个时刻的 SRTT 值更加平滑,更加接近当时的网络环境。

    RTO(ReTransmission Time Out,超时重发时间间隔) 的计算

    虽然可以通过公式计算出 SRTT 值,但是 RTP 的得出仍不是一件简单的事,因为到底是 RTT 定时器到后就重传,还是要再等多长时间才重传,这是必须考虑的问题。正常情况下,TCP 利用 β SRTT 作为重传超时间隔 ( β>1) ,而且最初的值总为2(也就是两倍的 SRTT 时间后还没有收到对应数据段的确认才重传该数据段)。

    但经验表明,采用常数的 β 值不够灵活。于是,在1988年,Jacobson 提出使用平均偏差作为标准偏差(就是 β SRTT)的新估计法,要求维护另一个被平滑的偏差 RTTD 。当一个确认数据段到达时,可以得出 SRRT 的新的 RTT 样本值之间的偏差 RTTD=(SRTTRTT)

    第一次测量时, RTTD 为测量到的 RTT 样本值的一半,在以后的测量中按照以下的公式进行计算:


    RTTDRTTD=αRTTDRTTD+(1α)×(SRTTRTT)

    这里的 α 可能与计算 SRTT 时的值相同,也可能不同,通常取值 0.25. SRTT 是平滑 RTT 值, RTT是新的 RTT 样本值。虽然 RTTD 并不能完全等同于标准偏差,但已能足够的反应 SRTT 值的动态变化。现在大多数 TCP 实现都是使用这个算法,并且将超时重传时间设置为:


    RTO=SRTT+4RTTD

    这里有一个重要的问题,那就是对于重传的数据段如何计算其 RTT 的值。假设发送端发送了一个数据段,但在重传定时器内没有收到该数据段的确认数据段,于是重新发送了这个数据段,可过了一段时间,发送端又收到了该数据短短额确认数据段。这是发送端就迷糊了,这个确认数据段到底是对原来发送的那个数据段确认,还是对重发的数据段的确认呢?这两个数据段的序号是一样的,如果在上次发送的数据段后没有再重新发送新的数据段的话,接收端返回的确认数据段中的确认号都可能一样。如何收到的确认数据段是对重传数据段的确认,但却被发送端认为是对原数据段的确认,则这样计算出的 SRTT 和 RTO 值可定会偏大,否则会偏小。为此,以为发现这个问题的无线电爱好者 Karn 提出了一个建议,就是在计算加权平均 RTT 时,只要数据段被重发就不采用其往返时间作为计算 SRTT 和 RTO 的样本,这样得出的加权平均 SRTT 值和 RTO 值就比较准确了。

    TCP 的选择性确认机制

    在上面介绍的 TCP 重传机制中,如果在重传定时器超时后仍没收到一个数据段的确认,则可能会重传对应序号后面的所有数据段,因为后面的这些数据段均暂时不会被确认,这明显大大降低了 TCP 数据传输性能。

    同样假设每个数据段大小为 100 字节,接受端已接受到了 1、101、201、401、501 这5个序号的数据段,其中 301 号数据段没有收到。按照前面介绍的确认机制,虽然 401、501 这两个序号的数据段均已收到,但因为 301 号这个数据段一直没收到,所以仍然不能像向发送端确认。在某个时间上,如果 301 号数据段重传定时器超时了,则发送端肯定会重传这个数据段,但毕竟重传的 301 数据段到达对端也是要时间的。在这个 301 号数据段的重传过程中,401 号,甚至 501 号数据段的重传定时器也可能超时,这是发送端可能由对 401号、501 号这两个数据段进行重传。这样的重传显然是不必要的,也会造成接收端重复接受 401 号、501 号这两个数据段。

    为了避免这种现象的出现,在 RFC3517 中出现了一种称为 “选择性确认” (SACK)的机制,就是在 TCP 数据段格式的头部 “可选项” 字段中添加一个代表支持 SACK 选项。但这个选项在不同的数据段格式的头部 “可选项” 字段中添加一个代表支持 SACK 的选项。但这个选项在不同的数据段中有不同的字段名称和不同的含义。

    首先,必须在建立 TCP 传输连接时的 SYN 数据段中包含 “SACK-Permit” (SACK 允许)字段选项,表示在今后的传输中希望收到 SACK 选项,然后在其他的数据段中包括需要包含 “SACK”字段,在这个字段中,会包含本段要告诉对端已经接收到的不连续数据段。原来的 “确认号” 字段同样有效,但此时的 SACK 扩展选项也仅在确认数据段(“ACK” 字段值为1)中才有效。

    “SACK-Permit” 字段中包括 Kind (类型)和 Length(长度)两个子字段。,如下图所示。Kind 字段值固定为4,占8位,表示允许使用 SACK 扩展确认选项;Length 字段的值固定为2,占8位,表示在 SYN 数据段中 SACK 允许扩展选项占两字节。


    SYN 数据中的“SACK-Permit”选项格式
    SYN 数据中的“SACK-Permit”选项格式

    在其他非 SYN 数据段的 “SACK-Permit” ,包括 Kind、Length,以及各不连续数据段的起始字节号和结束字节号,如下图所示。Kind 字段固定值为5,占8位,表示这是非 SYN 数据段的 SACK 选项;Length 字段值可变,占8位,以字节为单位表示 SACK 扩展选项的长度。后面是 n 个标识不连续数据段起始和结束序号的部分,每个序号占32位。


    其他数据段中的“SACK”选项格式
    其他数据段中的 “SACK” 选项格式

    由于 TCP 数据段头部的“可选项”字段最长为40字节,Kind 和 Length 这两部分一共占了2字节,而表示一个不连续数据段的起始序号和结束序号要占用8字节(因为一个序号要占4字节)。因此,实际上在一个数据段中最多可以标识4个不连续数据段,因为标识4个数据段的起始序号和结束序号一共要占用32字节,加上前面 Kind 和 Length 部分,就有34字节。而要标识5个数据段的起始序号和结束序号,则还要8字节,超出了“可选项”字段40字节的限制范围。所以,在“Length”子字节中,最大值其实就是34.

    发送端通过识别接收端返回到确认数据段中的 SACK 扩展选项就可以得知接收端已收到了哪些不连续序号的数据段,这样发送端就可以不再发送这些数据段,而只发送已经丢失的数据段(发送端已经发送,且在重传定时器超时后接收端仍没有收到的数据段)。

    假设接收端已经收到 1、101、201、401、501 这五个序号的数据段,在发送确认号为 301 的确认数据段时,在 SACK 扩展选项中标记 401(起始序号为 401,结束序号为 600)这两段不连续的数据段。这时发送端就会知道,不需要再发送 401 和 501 这两个数据段了,只需要发送301号数据段即可。这样大大节省了网络资源,也提高了数据传输的效率。

    展开全文
  • Tcp可靠传输flash动画

    2014-01-10 12:34:09
    flash动画 TCP可靠传输 停止等待协议
  • 5.3.1计算机网络传输层之TCP可靠传输

    千次阅读 2020-04-15 00:10:58
    前言1.TCP可靠传输简介2.序号3.确认4.重传 0.前言 再看此篇文章之前,得熟悉一下TCP首部报文等知识 计算机网络传输层之TCP协议(tcp协议特点、tcp报文段首部格式、tcp连接—三次握手、tcp连接释放—四次握手) 1....


    0.前言

    1.TCP可靠传输简介

    在这里插入图片描述

    2.序号

    在这里插入图片描述

    3.确认

    在这里插入图片描述
    在这里插入图片描述

    4.重传

    在这里插入图片描述

    展开全文
  • tcp 文件可靠传输

    2014-05-16 09:12:21
    利用tcp协议,对信息进行分帧胡,利用scoket发送出去,服务端功能,可靠传输
  • UDP 可靠传输协议 UDT ,实现原理
  • 基于UDP的可靠传输

    2013-01-10 12:26:34
    基于UDP的可靠传输代码,包括一个客户端和一个服务端。
  • TCP的可靠传输机制

    万次阅读 多人点赞 2018-11-01 20:06:30
    TCP的报文是交给IP层传送的,但是IP层只能提供尽最大努力交付的服务,也就是说,TCP下面的网络所提供的是不可靠传输,其实就是传输信道是不可靠的(所谓的信道,就是指连接信号发送方和接收方的传输线路,包括双绞...
  • TCP 可靠传输机制详解

    万次阅读 多人点赞 2019-08-31 20:23:44
    TCP可靠传输 TCP流量控制 TCP拥塞控制 面试相关问题 前言 本篇博文主要是为了复习TCP协议而做的总结。其中很多内容都是来自于《计算机网络》,《Linux网络编程》,《TCP/IP详解》等书籍。首先可以从TCP协议思维...
  • 实 验 七 传 输 层 可 靠 传 输 协 议 G B N 编 程 实 验 报 告 序号姓名学号成绩 指导老师 一实验目的 1通过编写实现一个简单可靠的数据传输协议 GBN的发送和接收代码模拟可靠数据传输 2理解 TCP协议可靠传输的差错...
  • 行业分类-设备装置-实现帧中继网络中传输帧可靠传输的方法.zip
  • 可靠传输的工作原理

    千次阅读 2017-07-21 10:26:00
    TCP发送的报文段是交给IP层传送的。但IP层只能提供尽最大努力服务,也就是说,TCP下面的网络所提供的是不可靠的传输。因此,TCP必须采用适当的措施才能使得两个运输层...像上述的这种可靠传输协议常称为自动重传请求A
  • UDT网络传输协议开源包,是基于UDP的可靠传输协议,UDP访TCP
  • 计算机网络学习:封装成帧、差错检测和可靠传输

    千次阅读 多人点赞 2021-04-05 16:33:20
    数据链路层的封装成帧、差错检测和可靠传输可靠传输原理中很奇妙地发现,在不可靠的信道上加上合适的可靠协议(SW、GBN或者SR),就可以向上提供可靠的服务。在数据链路层要实现可靠的传输为上层提供服务。
  • UDP如何实现可靠传输

    千次阅读 2019-05-15 18:16:54
    传输层无法保证数据的可靠传输,只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式,只是实现不在传输层,实现转移到了应用层。 最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞...
  • 正确理解tcp的可靠传输------其实并不100%可靠.pdf
  • 用UDP实现的可靠传输源码。用UDP实现的可靠传输源码用UDP实现的可靠传输源码
  • 我们知道数据链路层和传输层都提供可靠传输服务,传输层是一定要提供的,比如TCP就是可靠传输协议,保证了端到端的可靠传输,确保每一个报文段都能按序送达对方,如果下层传输丢失,也能及时通过ARQ协议来重传,那么...
  • TCP为什么可以做到可靠传输

    千次阅读 2020-03-14 23:52:10
    TCP又称为可靠传输协议,这个可靠是指数据一定可以毫无遗漏的交给对方。但是是不是说我们开发了一个应用程序给另一个应用程序发送消息,他就一定能够收到呢?我们开发的时候用了TCP,而且TCP又是可靠的传输协议,那...
  • UDP可靠传输那些事

    万次阅读 多人点赞 2012-12-25 14:40:41
    有空来论坛走走,发现讨论udp可靠传输又热了起来,有人认为udp高效率,有人认为udp丢包重传机制容易控制,还有朋友搞极限测试,当然也有人推销自己的东西,这里写一点我个人的看法。  udp可靠传输其实非常非常的...
  • Python UDP实现可靠传输 停等协议
  • 26-tcp可靠传输——停止等待协议

    千次阅读 2018-04-30 18:39:39
    1. tcp可靠传输   通过前面的学习可知,网络层传输数据时是尽最大努力传输到目的地,并不保障数据的可靠传输,对于网络拥塞,延迟,数据丢失等问题没有采取有效的措施。因此我们需要一种数据可靠传输的通信方式,...
  • 设计一种基于UDP的可靠传输协议,江苏大学网络工程的课程设计,基于C#实现的socket通信,带用户上下线的显示,有没有用户管理功能忘了。带两个独立的程序,一个客户端,一个服务端。基于C#的用户界面
  • UDP数据包可靠传输实现方案

    千次阅读 2015-09-21 20:58:06
    本文的主要工作是解决网关B下主机和网关C下主机之间的udp数据包可靠传输问题,采用基于udp的可靠传输协议UDT来实现udp数据包的可靠传输。网关B下的客户端A是发送udp数据包的请求端,网关C下的服务器D是udp数据包的...
  • 针对延迟容忍移动传感器网络(DTMSN)的随机移动特性和连通的间歇性等问题,提出了基于网络编码的可靠传输机制。基于DTMSN传感器节点的移动性和网络编码技术,综合考虑了影响DTMSN服务质量保障的各种因素,将数据包...
  • 在了解了TCP的面向连接传输之后我们讲解TCP的可靠传输相关的机制和面向字节流传输 一,TCP的可靠传输 可靠应答机制 超时重传机制 报文中的序号和确认序号 可靠应答机制 就是在每次发送数据或者请求之后对方都要回复...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 338,440
精华内容 135,376
关键字:

可靠传输