精华内容
下载资源
问答
  • UDP与TCP对比,TCP保证可靠性传输的详细说明
    2021-07-16 16:59:05

    目录

    1 UDP

    2 TCP

    2.1 TCP协议如何保证可靠传输

    2.2 流量控制

    2.2.1 TCP的滑动窗口

    2.3 拥塞控制

    2.3.1 慢开始

    2.3.2 拥塞避免

    2.3.3 快重传 

    2.3.4 快恢复

    2.4 ARQ协议

    2.4.1 停止等待ARQ协议

    2.4.2 连续ARQ协议

    3 UDP和TCP对比


    1 UDP

    UDP:User Datagram Protocol,用户数据报协议

    UDP的特点:无连接、不可靠

    • 无连接:意思就是在通讯之前不需要建立连接,直接传输数据
    • 不可靠:是将数据报的分组从一台主机发送到另一台主机,但并不保证数据报能够到达另一端,任何必须的可靠性都由应用程序提供。在 UDP 情况下,虽然可以确保发送消息的大小,却不能保证消息一定会达到目的端

            UDP没有超时和重传功能,当 UDP 数据封装到 IP 数据报传输时,如果丢失,会发送一个 ICMP 差错报文给源主机。

            即使出现网络阻塞情况,UDP 也无法进行流量控制。此外,传输途中即使出现丢包,UDP 也不负责重发,甚至当出现包的到达顺序杂乱也没有纠正的功能

            UDP 在传送数据之前不需要先建立连接,远地主机在收到 UDP 报文后,不需要给出任何确认。虽然 UDP 不提供可靠交付,但在某些情况下 UDP 确是一种最有效的工作方式(一般用于即时通信),比如: QQ 语音、 QQ 视频 、直播等等。

    2 TCP

    TCP:Transmission Control Protocol,传输控制协议

    TCP协议是面向连接的、可靠传输、有流量控制拥塞控制面向字节流传输等很多优点的协议。

            TCP 提供面向连接的服务。在传送数据之前必须先建立连接,数据传送结束后要释放连接。 TCP 不提供广播或多播服务。

            由于 TCP 要提供可靠的,面向连接的传输服务(TCP的可靠体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完后,还会断开连接用来节约系统资源),这一难以避免增加了许多开销,如确认,流量控制,计时器以及连接管理等。这不仅使协议数据单元的首部增大很多,还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

    2.1 TCP协议如何保证可靠传输

            TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和 流量控制等方法实现了可靠性传输。

    1. 应用数据被分割成 TCP 认为最适合发送的数据块。
    2. TCP 给发送的每一个包进行编号,接收方对数据包进行排序,把有序数据传送给应用层。
    3. 校验和: TCP 将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP 将丢弃这个报文段和不确认收到此报文段。
    4. TCP 的接收端会丢弃重复的数据。
    5. 流量控制: TCP 连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 
    6. 拥塞控制: 当网络拥塞时,减少数据的发送。
    7. ARQ协议(自动重传请求,Automatic Repeat-reQuest,ARQ): 也是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组。
    8. 超时重传: 当 TCP 发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。

    2.2 流量控制

            TCP 利用滑动窗口实现流量控制流量控制是为了控制发送方发送速率,保证接收方来得及接收。

            接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。

    2.2.1 TCP的滑动窗口

            在进行数据传输时,如果传输的数据比较大,就需要拆分为多个数据包进行发送。TCP 协议需要对数据进行确认后,才可以发送下一个数据包。这样一来,就会在等待确认应答包环节浪费时间。
            为了避免这种情况,TCP引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。

            从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组,滑动窗口右边是还没有轮到的分组。
            滑动窗口里面也分为两块,一块是已经发送但是未被确认的分组,另一块是窗口内等待发送的分组。随着已发送的分组不断被确认,窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动,让还没轮到的分组进入窗口内。
            可以看到滑动窗口起到了一个限流的作用,也就是说当前滑动窗口的大小决定了当前 TCP 发送包的速率而滑动窗口的大小取决于拥塞控制窗口流量控制窗口的两者间的最小值

    2.3 拥塞控制

            在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏,这种情况就叫拥塞(相对整个网络而言)。

            拥塞控制就是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不致过载。

            拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素

            相反,流量控制往往是点对点通信量的控制,是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率,以便使接收端来得及接收。

            为了进行拥塞控制,TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度,并且动态变化发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个

    TCP的拥塞控制采用了四种算法,即 

    1. 慢开始 
    2. 拥塞避免
    3. 快重传 
    4. 快恢复

            在网络层也可以使路由器采用适当的分组丢弃策略(如主动队列管理 AQM),以减少网络拥塞的发生。

    2.3.1 慢开始

            慢开始算法的思路是当主机开始发送数据时,如果立即把大量数据字节注入到网络,那么可能会引起网络阻塞,因为现在还不知道网络的符合情况。

            经验表明,较好的方法是先探测一下,即由小到大逐渐增大发送窗口,也就是由小到大逐渐增大拥塞窗口数值。cwnd(congestion window)初始值为1,每经过一个传播轮次,cwnd加倍

    2.3.2 拥塞避免

            拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大,即每经过一个往返时间RTT就把发送放的cwnd加1,而不是加倍。这样拥塞窗口按线性规律缓慢增长。当cwnd = ssthresh时,改用拥塞避免算法。
     

    2.3.3 快重传 

            我们可以剔除一些不必要的拥塞报文,提高网络吞吐量。

            比如接收方在收到一个失序的报文段后就立即发出重复确认,而不要等到自己发送数据时捎带确认

            快重传规定:发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期

    2.3.4 快恢复

            快恢复:主要是配合快重传。当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把ssthresh门限减半(为了预防网络发生拥塞)但接下来并不执行慢开始算法,因为如果网络出现拥塞的话就不会收到好几个重复的确认,收到三个重复确认说明网络状况还可以。

    拥塞控制中cwnd图示:


    2.4 ARQ协议

            自动重传请求(Automatic Repeat-reQuest,ARQ)是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认超时这两个机制,在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧,它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。 

    2.4.1 停止等待ARQ协议

            停止等待协议是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认(回复ACK)。如果过了一段时间(超时时间后),还是没有收到 ACK 确认,说明没有发送成功,需要重新发送,直到收到确认后再发下一个分组。

            在停止等待协议中,若接收方收到重复分组,就丢弃该分组,但同时还要发送确认

    优缺点:

    • 优点: 简单
    • 缺点: 信道利用率低,等待时间长

    2.4.2 连续ARQ协议

            连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口,凡位于发送窗口内的分组可以连续发送出去,而不需要等待对方确认。接收方一般采用累计确认对按序到达的最后一个分组发送确认,表明到这个分组为止的所有分组都已经正确收到了

    优缺点:

    • 优点: 信道利用率高,容易实现,即使确认丢失,也不必重传。
    • 缺点: 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如:发送方发送了 5条 消息,中间第三条丢失(3号),这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落,而只好把后三个全部重传一次。这也叫 Go-Back-N(回退 N)表示需要退回来重传已经发送过的 N 个消息

    3 UDP和TCP对比

    如下表所示

    更多相关内容
  • 二、TCP如何实现可靠性传输? 三、可靠传输的工作原理之实现应答确认、超时重传 (一)停止等待协议 (二)连续ARQ协议 四、TCP可靠传输之滑动窗口流量控制 (一)滑动窗口 (二)流量控制 (三)零窗口问题 (四)...

    一、基本概念

    在讲如何实现实现TCP可靠传输之前,我们需要了解几个基本概念。

    (一)复位报文段

    我们在TCP协议详解画出的TCP报文头中,报文首部有个标志位RST,当RST=1,表示复位报文段。在某些情况下,TCP连接的一端会向另一端发送携带RST标志的报文段,即 复位报文段,通知对方关闭连接或重新建立连接,这里介绍三种情况:

    • 当用户端程序访问一个不存在的端口时,目标主机给它发送一个复位报文段。
    • 异常终止连接。正常情况下,数据交换完成之后,一方给另一方发送FIN结束报文段 ,TCP提供了异常终止一个连接的方法,即给对方发送一个复位报文段,一旦发送了复位报文段,发送端所有排队等待发送的数据将会被丢弃。应用程序可以使用socket选项SO_LINGER来设置发送复位报文段,达到异常终止连接的目的。
    • 处理半打开连接。例如TCP一端关闭了连接,由于网络故障对方没有收到结束报文,对方误以为连接仍然正常,处于这种状态的连接称为半打开连接,此时如果对端向连接写入数据,就会收到本端回复的复位RST报文段。

    (二)交互数据流与成块数据流

    TCP按照携带应用程序数据长度可以分为两种:

    • 交互数据流:仅仅包含很少的字节。适合对实时性要求极高的应用程序,如telent远程登入,ssh安全外壳协议等。
    • 成块数据流:数据长度为TCP报文段允许的最大数据长度。适合对传输效率要求高的应用程序,如FTP文件传输协议。

    (三)带外数据

    有些传输层协议具有 带外数据的概念,用于迅速通告对方本端发生的重要事件。因此,带外数据比普通数据有更高的优先级,它应该总是立即被发送,而不论发送缓冲区中是否有排队等待发送的普通数据。

    UDP没有实现带外数据传输,TCP也没有真正的带外数据,不过TCP利用其 头部中的紧急指针标志URG和16位紧急指针两个字段,给应用程序提供了一种传输紧急数据的方式。一般只有一个字节数据,当URG=1时,紧急指针指出本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据),发送TCP会把紧急数据插入到本报文段数据最前面,优先发送紧急数据。值得注意的是:即使窗口为零时也可发送紧急数据。

    二、TCP如何实现可靠性传输?

    我们一直在讲TCP是有连接,可靠的,面向字节流的传输协议,那么TCP是如何实现其可靠性呢?主要 从下列三个方面来保证TCP可靠性

    1. 保证数据能够到达对方。通过应答确认,超时重传保证数据的无差错到达,滑动窗口保证发送方发送数据和接收方速率匹配,拥塞控制保证发送方发送数据的速率与当前网络情况匹配来保证这一点,下面我们详细讲解这些机制。
    2. 保证数据不重复,不乱序。通过32位seq序列号保证,因为seq的初始值是随机生成的,在三次握手结束后,保证了通信的双方知道彼此的初始化seq,这个序列号要作为以后的数据通信的序号,以保证应用层接收到的数据不会因为网络上的传输的问题而乱序,TCP会用这个序号来拼接数据,这样就可以保证数据的不重复,有序。
    3. 保证数据不失真通过报文首部的16位校验和保证,添加12字节的伪首部进行检验,一般采取CRC冗余检验实现。

    下面的文章我们讲详细讲解这些机制是如何实现TCP可靠性传输的。

    三、可靠传输的工作原理之实现应答确认、超时重传

    我们的网络不具备理想的传输条件,即不需要采取任何措施能够实现可靠传输。故就需要我们使用一些 可靠传输协议当出现差错时让发送方重传出现差错的数据,同时在接收方来不及处理收到的数据时,及时告诉发送方适当降低发送数据的数据即实现TCP传输数应答确认,超时重传,主要有两种协议:停止等待协议,连接ARQ协议

    (一)停止等待协议

    全双工通信的双方既是发送方也是接收方,我们现在假定A发送数据,B接收数据,因此A叫做发送方,B叫做接收方,传送给的数据单元都成为分组。

    停止等待协议的核心概念就是每发送完一个分组就停止发送,等待对方确认,在收到确认后再发送下一个分组。

    在使用停止等待协议时,A,B端会有以下几种情况出现:无差错情况,出现差错,确认丢失,确认迟到,我们对这几种情况进行描述。

    【1. 无差错情况】

    A发送的每一个分组B都收到了,A也收到了B的确认信息。如下图所示:
    在这里插入图片描述

    【2. 出现差错情况】

    出现差错的情况一般有两种:

    • B接收M1时检测出了差错
    • M1在传输过程中丢失了。

    这时B就会自动丢弃有差错的分组,并不会去通知A;A只要超过一段事件仍然没有收到确认,就认为刚才发送的分组丢失了,就重传前面发送的分组,这个就是 超时重传机制,如下图所示:
    在这里插入图片描述

    实现超时重传机制

    • 每发送的一个分组设置一个超时计时器,这个时间的设置采用TCP提供的自适应算法得到,如果在超时计时器到期之前收到对方的确认,就撤销已设置的超时计时器。
    • 否则就进行重传

    图中A为每一个发送的分组都设置了一个超时计时器,只要A在超时计时器到期之前收到了相应的确认,就撤销该超时计时器。

    超时重传对发送数据端A有以下要求

    • A在发送完一个分组后,必须暂时保留已发送的分组分副本,在超时重传时使用,只有在收到相应的确认后才能清除暂时保留的分组副本。
    • 分组和确认分组都必须进行编号,这样才能明确是哪一个发送出去的分组收到了确认,哪一个没有收到确认。
    • 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些

    【3. 确认丢失】

    B所发送的对M1确认丢失了A在设定的超时重传时间内没有收到确认,但并无法知道是自己发送的分组出错,丢失,或者是B发送的确认丢失了。因此A在超时计时器到期后就要重传M2。这时B又收到了重传的分组M2,这时会采取两个行动:

    • 第一,丢弃这个重复的分组M2,不向上层交付
    • 第二,向A发送确认,不能认为自己已经发送过确认就不再发送,因为A之所以重传M2就表示A没有收到对M2的确认。如下图:
      在这里插入图片描述

    【4. 确认迟到】

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

    在这里插入图片描述

    【总结】

    • 通常A最终总是可以收到对所有发出的分组的确认,如果A不断重传分组但总是收不到确认,就 说明通信线路太差,不能进行通信
    • 使用上述的 应答确认和重传机制,我们就可以在不可靠的传输网络上实现可靠的通信

    像上述这种可靠传输协议常称为 自动重传请求ARQ(Automatic Repeat reQuest,意思是重传的请求是自动进行的,接收方不需要请求发送方重传某个出错的分组。

    (二)连续ARQ协议

    滑动窗口协议就是使用的的连续ARQ协议,我们先来看一下什么是连续ARQ协议。

    下图表示发送方维持的发送窗口,它的意义是:位于发送窗口内的5个分组都可以连续发送出去,而不需要等待对方的确认,这样,信道的利用率就提高了。
    在这里插入图片描述
    连续ARQ协议规定: 发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置。 如下图表示发送方收到了对第一个分组的确认,于是就把发送窗口向前移动一个分组的位置,如果原来已经发送了前5个分组,那么现在就可以发送窗口内的第6个分组了。

    在这里插入图片描述
    接收方一般都采取累积确认的方式 ,这就是说,接收方不必对收到的分组逐个发送确认,而是在收到几个分组后,对按序到达的最后一个分组发送确认,这样就表示:到这个分组位置的所有分组都已正确收到了。

    累积确认有优点也有缺点:

    • 优点容易实现,及时确认丢失也不必重传。
    • 缺点不能向发送方反映出接收方已经正确收到所有的分组的信息。

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

    故TCP可靠传输的应答确认和超时重传可以通过停止等待协议,或者连续ARQ实现。

    四、TCP可靠传输之滑动窗口流量控制

    (一)滑动窗口

    在TCP报头中有一个字段叫做接收通告窗口,这个字段由接收端填充是接收端告诉发送端自己还有多少缓冲区可以接收数据,于是发送端就可以根据这个接收端的处理能力来发送数据这样就不会导致接收端处理不过来。保证了发送方发送数据和接收方速率匹配。

    这个发送窗口的大小由接收端填充的接收通告窗口的大小决定的,并且窗口的位置会随着发送端数据的发送和接收到接收端对数据的确认而不断地向右滑动将之称为滑动窗口。

    如下图所示,就是一个滑动窗口的变化:

    在这里插入图片描述
    从上图我们可以得出以下的 结论

    • 发送窗口表示,在没有收到接收端确认的情况下,发送端可以连续把窗口内的数据都发送出去,凡是已经发送的数据,在未收到确认之前都必须暂时保留,以便在超时重传时使用
    • 发送窗口里面的序号表示允许发送的序号,窗口越大,发送方就可以在收到对方确认之前连续发送更多的数据,因而可能获得更高的传输效率,但接收方必须来得及处理这些收到的数据。
    • 发送窗口后面部分表示已经发送且收到了确认,这些数据显然不需要再保留了。而发送窗口前面部分表示不允许发送的,因为接收方都没有为这部分数据保留临时存放的缓存空间

    发送窗口的 变化情况一般有两种

    1. 发送窗口通常时不断向前移动。表示收到了新的确认
    2. 也有可能不动。一是没有收到新的确认,对方通知的窗口大小也不变;二是收到了新的确认但对方通知窗口缩小了,使得发送窗口正好不动。

    TCP标准不赞成发送窗口向后移动。

    (二)流量控制

    TCP协议是利用滑动窗口实现流量控制的。一般来说,我们总是希望数据传输的更快一点,不会一次只发一个字节,但是如果发送把数据发的过快,接收方可能来不及接收,这就会造成数据的丢失。 所谓流量控制就是让发送方的发送速率不要太快,要让接收方来的及接收。

    利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。我们看下面的例子:

    假如A向B发送数据,在连接建立时,B通过报文段首部告诉A:“我的接收窗口rwnd=400”,因此,发送方即A的发送窗口不能超过接收方给出的接收窗口的数值。这里的TCP窗口单位是字节,不是报文段。设置一个报文段DATA为100字节长,数据报文段seq的初始值设为1,ack表示确认字段的值,那么流量控制如下图:

    在这里插入图片描述
    在整个过程中,接受方的主机B进行了 三次流量控制

    1. 第一次把窗口减少到rwnd=300,这时发送端的发送窗口缩小。
    2. 第二次又减到rwnd=100。
    3. 第三次减少到rwnd=0, 即不允许发送方再发送数据了。我们将这个窗口称为零窗口,这个状态将持续到主机B重新发出一个新的窗口值位置。

    注意,B向A发送的三个报文段都设置了ACK=1,只有再ACK=1时确认号字段才有意义。

    可以看到 通过滑动窗口,实现了流量控制,让发送方A发送的数据都可以被接受端B处理,保证了数据的可靠到达。

    (三)零窗口问题

    在上图中B最后给A发送了零窗口,此时A已经不能发送数据了,当B的接收缓存有了一些存储空间时, B向A发送了rwnd=400的报文段,但是这个报文段在传送过程中丢失了,A一直等待收到B发送的非零窗口的通知,而B也一直等待A发送的数据,如果没有其他措施,这种相互等待的死锁局面将一直延续下去,这就是零窗口问题。

    TCP规定,即使设置为零窗口,也必须接收以下几种报文段:

    • 零窗口探测报文段
    • 确认报文段
    • 携带紧急数据的报文段。

    【解决零窗口问题:】

    为了解决这个问题,TCP为每一个连接设有 一个持续计时器

    • 只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器
    • 若持续计时器设置的时间到期,就发送一个 零窗口探测报文段(仅携带1字节的数据),而对方就在确认这个探测报文段时给出了现在的窗口值
    • 如果窗口仍然是零,那么收到这个报文段的一方就重新设置持续计时器,如果窗口不是零,那么死锁的僵局就可以打破了

    (四)糊涂窗口综合征

    糊涂窗口综合征,有时会使TCP的性能变坏。

    设想一种情况:TCP接收方的缓存已满,而交互式的应用进程一次只从接收缓存中读取1个字节,这样就使得接收缓冲区仅腾出1个字节:

    • 接收端向发送方发送确认,并把窗口设置为1个字节,但发送的数据报是40字节长(20IP头+20TCP头)
    • 接着,发送方又发来1个字节的数据,那么数据报长度为41字节,固定头部40,真实数据1字节,接收端发回确认,窗口仍然设置为1个字节。

    这样循环进行下去,使网络的效率很低,这就是我们说的糊涂窗口综合征,又称为小窗口问题,总结来说就是每次发送很小的字节,却需要40字节的固定头部,数据报固定开销远远大于数据部分,这样会导致网路效率低。

    【解决糊涂窗口综合征的办法:】

    • 接收方:可以 让接受方等待一段时间,使得接收缓存已有足够空间容纳一个最长的报文段,或者 等到接收缓存已有一半空闲的空间。只要出现 这两种情况之一,接收方就发出确认报文,并向发送方通知当前窗口大小。
    • 发送方发送方也不要发送太小的报文段,否则会引起接收端的多次确认,浪费内存,而是把数据报积累成足够大的报文段,或达到接收方缓存的空间的一般大小,这就是Nagle算法。

    这两种办法可配合使用使得在发送方不发送很小的报文段的同时,接受方也不要在缓存刚刚有了一点小的空间就急忙把这个很小的窗口大小信息通知给发送方。

    (五)Nagle算法

    解决糊涂窗口综合征就可以用到Nagle算法,在TCP的实现种广泛使用Nagle算法。

    【对算法的功能描述如下:】

    • 若发送应用进程把要发送的数据 逐个字节的送到TCP的发送缓存,则 发送方就把第一个数据字节先发出去,把后面到达的数据字节都缓存起来。
    • 当发送方收到第一个数据字符的确认后,再把发送缓存中的所有数据组装成一个报文段发送出去, 同时继续对随后达到的数据进行缓存。

    只有在收到对前一个报文段的确认后才继续发送下一个报文段,当数据到达较快,而网络速率较慢时,用这样的方法可明显地减少所用的网络带宽。

    Nagle算法还规定, 当到达的数据已达到发送窗口大小的一半或已达到报文段的最大程度时,就立即发送一个报文段。

    五、TCP可靠传输之拥塞控制

    拥塞控制就是防止有过多的数据注入到网络中,保证发送方发送数据的速率与当前网络情况匹配。 这样可以使得网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷拥塞控制是一个全局性的过程, 涉及到所有的主机,路由器,以及与降低网络传输性能有关的所有因素。

    (一)拥塞控制和流量控制的区别

    • 流量控制往往指点对点通信量的问题,是个端到端的问题,接收端控制发送端,流量控制要做的是机制发送端发送数据的速率,以便使接收端来得及接受。
    • 拥塞控制则是整个网络的问题,它保证发送方发送数据的速率与当前网络情况匹配
    • 拥塞控制和流量控制之所以被弄混,是因为某些拥塞控制算法是向发送端发送控制报文,并告诉发送端,网络已出现麻烦,必须放慢速率,这点又和流量控制很相似。

    (二)拥塞控制的作用

    进行拥塞控制需要付出代价, 首先需要获得网络内部流量分布的信息,在实施拥塞控制时,还需要在节点之间交换信息和各种命令,以便选择控制的策略和实施控制。这样就产生了额外开销。拥塞控制有时需要将一些资源分配给个别用户单独使用,这样就使得网络资源不能更好地共享所以我们可以看到拥塞控制是一个动态地过程,它会因为网络状况、资源等问题不断变化。

    下图是 拥塞控制所起地作用,横坐标是提供的负载,代表单位时间内输入给网络的分组数目。因此提供的负载也称为输入负载和网络负载。纵坐标是吞吐量,代表单位时间内从网络输出的分组数目。

    在这里插入图片描述
    可以看到:

    • 具有理想拥塞控制的网络,在吞吐量饱和之前,网络吞吐量应等于提供的负载,故吞吐量曲线是45°的斜线,但当提供的负载超过某一限度时,由于网络资源受限,吞吐量不再增长而保持为水平线,即吞吐量达到饱和,这就表明提供的负载中有一部分损失掉了,如某些网络分组被丢弃等。在这种理想的拥塞控制作用下,网络的吞吐量仍然能维持在其所能达到的最大值。
    • 但实际网络的拥塞控制,随着提供的负载的增大,网络吞吐量的增长速率逐渐减小,也就是说,在网络吞吐量还未达到饱和时,就已经有一部分的输入分组被丢弃了。当网络吞吐量明显的小于理想的吞吐量时,网络就进入了轻度拥塞的状态。
    • 在没有进行拥塞控制的网络,当提供的负载达到某一数值时,网络的吞吐量反而随着提供的负载的增大而下降,这时网络就进入了拥塞状态,当提供的负载继续增大到某一数值时,网络的吞吐量就下降到零,网络已无法工作,这就是所谓的死锁

    可以看出一个好的拥塞控制策略可以提高网络的效率,不恰当的拥塞控制策略可能会导致网络性能恶化或者死锁。

    (三) 拥塞控制策略

    RFC定义了拥塞控制的四种算法,即慢开始,拥塞避免,快重传,快恢复。

    发送方维持一个拥塞窗口,拥塞窗口的大小取决于网络的拥塞程度,并且动态的在变化,发送方让自己的发送窗口等于拥塞窗口。

    1. 慢开始

    慢开始思路

    • 当主机开始发送数据时,如果里把大量的数据字节注入网络,那么就有可能引起网络拥塞,因为现在并不清楚网络的负荷。所以较好的办法是 先探测一下,即由小到大逐渐增大发送窗口
    • 通常在 刚开始的时候,把 拥塞窗口cwnd设置为一个最大报文段MSS,在 每收到一个报文段的确认后,则将窗口大小乘2的增加,即发送的报文段数量增大一倍

    一般在例子当中用报文段的个数作为窗口大小的单位,实际上TCP用字节作为窗口的单位。我们看下面的一个例子:在一开始时发送方先设置cwnd=1,发送第一个报文段M1,接收方收到后确认M1,发送方收到对M1的确认后把cwnd从1增大到2,于是发送方接着发送M2和M3两个报文段。收到对M2,M3的确认后,cwnd从2增加到4,以此类推,每次都以指数2增长

    在这里插入图片描述
    因此使用慢开始算法后,每经过一个传输轮次,拥塞窗口cwnd就加倍。

    传输轮次的时间:就是 往返时间RTT,指的是把拥塞窗口cwnd所允许发送的报文段都连续发送出去,并收到了对已发送的最后一个字节的确认,例如拥塞窗口cwnd=4,那么这时的往返时间RTT就是发送方连续发送4个报文段,并收到这4个报文段的确认,总共经历的时间。

    注意慢开始的慢不是指cwnd的增长速率慢,而是指在TCP开始发送报文段时先设置cwnd=1,使得发送方在开始时只发送一个报文段,目的是试探一下网络的拥塞情况,然后再逐渐增大cwnd,这当然比按照大的cwnd一下子把许多报文段突然注入到网络中要慢得多这对防止网络出现拥塞是一个非常有力的措施。

    2. 拥塞避免

    为了防止拥塞窗口cwnd增长过大引起网络拥塞,引入了拥塞避免算法:

    拥塞避免思路
    让拥塞窗口cwnd缓慢地增大,每经过一个往返时间RRT就把发送方的拥塞窗口cwnd加1,即可以多发送一个报文段,而不是加倍,这样,拥塞窗口cwnd按线性规律缓慢增长,比慢开始算法的拥塞窗口增长速率缓慢很多。

    慢启动和拥塞避免在传输开始时配合使用,为了防止拥塞窗口cwnd增长过快引起网络阻塞,还需要设置一个 慢开始门限ssthresh,用法如下:

    • cwnd<ssthresh时,使用慢开始算法。
    • cwnd>ssthresh时,停止使用慢开始算法,改用拥塞避免算法。
    • cwnd=ssthresh时,即可以使用慢开始算法,也可以使用拥塞避免算法。

    最开始只有这两个算法进行拥塞控制:
    故一旦产生网络拥塞,即没有按时收到确认,就马上把ssthresh设置为出现拥塞时的发送方窗口值的一半拥塞窗口cwnd重新设置为1执行慢开始算法

    随着新的拥塞控制算法的出现,这种方式已经被淘汰了。

    注意拥塞避免并非指完全能够避免了拥塞,利用以上措施要完全避免网络拥塞还是不可能的,拥塞避免只是实现了在拥塞避免阶段将拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞。

    3. 快重传

    快重传思路

    • 首先要求 接收方每收到一个失序的报文段后就立即发出重复确认,为的是 使发送方及早知道有报文段没有到达对方,而不要等待自己发送数据时才进行捎带确认。
    • 发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而 不必等待报文段的重传计时器到期。

    因为发送方可以尽快的重传为被确认的报文段,因此采用快重传后可以使整个网络的吞吐量提高约20%。

    下图就是快重传的一个例子:

    在这里插入图片描述
    描述整个过程:

    • 接收方收到了M1和M2后都发出了确认。现在假定接收方没有收到M3报文,但接着收到了M4报文,显然接收方不能确认M4,因为M4属于收到的失序报文段(按照顺序的M3还没有到达)。
    • 根据可靠传输原理,接受方可以什么都不做,也可以在适当时机发送一次对M2的确认。但是快重传算法规定,接收方应及时发送对M2的重复确认,这样做可以让发送方及早的知道报文段M3没有到达接收方。发送方接着发送M5,M6。
    • 接收方收到后,还要再次发送对M2的重复确认。
    • 这样,发送方共收到了接收方的四个对M2的确认,其中后三个都是重复确认, 那么 根据快重传算法,发送方只要收到三个重复确认就应当立即重传对方尚未收到的报文段M3,而不必继续等待为M3设置的重传计时器到期,这样大大提高了网络吞吐量。

    4. 快恢复

    和快重传配合使用的是快恢复算法,其 算法思路为:

    • 当发送方连续收到三个重复确认时,就执行乘法减小算法,把慢开始门限ssthresh减半,这是为了预防网络发生阻塞。
    • 由于发送方现在认为网络可能没有发送拥塞,因为如果网路发生严重的拥塞,就不会一连有好几个报文连续到达接收方,更不导致接收方连续发送重复确认,因此现在不执行慢开始算法,即cwnd=1,而是把cwnd值设置为慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法,使拥塞窗口缓慢地线性增大(每次增加一个)。

    (四) 拥塞控制过程

    使用慢开始,拥塞避免,快重传,快恢复算法进行拥塞控制,如下图所示:
    在这里插入图片描述
    可以看到,在使用快恢复算法时,慢开始算法只是在TCP建立连接时和网络超时时才使用

    六、总结窗口类型

    我们在讨论拥塞控制方式时假定了接收方总是有足够大地缓存空间,因而发送窗口的大小是由拥塞程度来决定的。但实际上接收方的缓存空间总是有限的。接收方根据自己的接收能力设定了接收窗口rwnd。
    那么现在总共有三种 【窗口类型:】

    • 接收端窗口rwnd接收缓冲区的大小,接收端将此窗口值放在TCP报文的首部中的窗口字段,传送给发送端。存放按序到达的,但尚未被接收应用程序读取的数据和未按序到达的数据。
    • 拥塞窗口cwnd大小取决于网络的拥塞程度,并且在动态的变化。
    • 发送窗口swnd:发送窗口的上限值=Min=[rwnd,cwnd],存放已发送未确认的数据和可发送但还没发送的数据

    如果把拥塞控制和接受方对发送方的流量控制一起考虑,那么很显然,发送方的窗口的上限值应当取为接收方窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个:

    发送窗口的上限值=Min=[rwnd,cwnd]

    即:

    • rwnd<cwnd时,是接收方的接收能力限制发送方窗口的最大值。
    • rwnd>cwnd时,则是网络拥塞限制发送方窗口的最大值

    所以,rwnd和cwnd中较小的一个控制发送方发送数据的速率。

    加油哦!🍲。

    展开全文
  • TCP 如何保证可靠性

    千次阅读 2022-02-16 13:43:20
    TCP 通过校验和、ACK 应答、超时重传来记录哪些数据发送了,哪些数据被接受了,哪些没有被接受,并且保证数据包按序到达,保证数据传输不出差错。 再次,TCP可靠性,还体现在可控制。通过流量控制(滑动窗口)和...

    首先,TCP 的连接是基于三次握手,而断开则是四次挥手。确保连接和断开的可靠性。
    其次,TCP 的可靠性,还体现在有状态;TCP 通过校验和、ACK 应答、超时重传来记录哪些数据发送了,哪些数据被接受了,哪些没有被接受,并且保证数据包按序到达,保证数据传输不出差错。
    再次,TCP 的可靠性,还体现在可控制。通过流量控制(滑动窗口)和拥塞控制来控制发送方发送速率

    1. 校验和

    TCP检验和的计算与UDP一样,在计算时要加上12byte的伪首部,检验和总共计算3部分:TCP首部、TCP数据、TCP伪首部。计算方法为:在发送方将整个报文段分为多个16位的段,然后将所有段进行反码相加,将结果存放在检验和字段中,接收方用相同的方法进行计算,如最终结果为检验字段所有位是全1则正确,否则存在错误。
    在这里插入图片描述

    2. 确认应答与序列号

    TCP将每个数据包都进行了编号,这就是序列号。
    序列号的作用:
    a、保证可靠性(当接收到的数据总少了某个序号的数据时,能马上知道)
    b、保证数据的按序到达
    c、提高效率,可实现多次发送,一次确认
    d、去除重复数据
    数据传输过程中的确认应答处理、重发控制以及重复控制等功能都可以通过序列号来实现

    TCP通过确认应答机制实现可靠的数据传输。在TCP的首部中有一个标志位——ACK,此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认,当标志位ACK=1时确认首部的确认字段有效。进行确认时,确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文,则继续传输下一部分数据;而如果等待了一定时间还没有收到确认报文就会启动重传机制。
    序列号错误示意图
    在这里插入图片描述

    3. 超时重传

    当报文发出后在一定的时间内未收到接收方的确认,发送方就会进行重传(通常是在发出报文段后设定一个闹钟,到点了还没有收到应答则进行重传)。
    一种情况是发送包丢失了,其基本过程如下:
    在这里插入图片描述
    发送包丢失导致的超时

    另一种情况是ACK 丢失,过程如下:
    在这里插入图片描述

    ACK 丢失导致的超时

    当接收方接收到重复的数据时就将其丢掉,重新发送ACK。而要识别出重复的数据,前面提到的序列号就起作用了。

    重传时间的确定:
    重传时间的确定:报文段发出到收到应答中间有一个报文段的往返时间RTT,显然超时重传时间RTO会略大于这个RTT,TCP会根据网络情况动态的计算RTT,即RTO是不断变化的。在Linux中,超时以500ms为单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍。其规律为:如果重发一次仍得不到应答,就等待2500ms后再进行重传,如果仍然得不到应答就等待4500ms后重传,依次类推,以指数形式递增,重传次数累计到一定次数后,TCP认为网络或对端主机出现异常,就会强行关闭连接。

    4. 连接管理

    连接管理机制即TCP建立连接时的三次握手和断开连接时的四次挥手。

    5. 流量控制

    接收端处理数据的速度是有限的,如果发送方发送数据的速度过快,导致接收端的缓冲区满,而发送方继续发送,就会造成丢包,继而引起丢包重传等一系列连锁反应。
    因此TCP支持根据接收端的处理能力,来决定发送端的发送速度,这个机制叫做流量控制。tcp通过滑动窗口来进行流量控制
    如果主机A是我们的发送方,他在发送数据的时候需要维护一个窗口,接受窗口就是告诉发送方,接收方还有多少的缓存空间,tcp是全双工通信,所以说通信的任何一方都维护着另一方的一个接收窗口
    接受窗口(表示表示接收方当前可用的缓存空间)
    主机A通过tcp协议需要向主机B发送一个大文件,主机B需要为这个链接分派一个接收缓存,这个缓存大小我们用receive buffer来表示,发送方发送的数据首先会进入缓存空间,接收方从缓存中读取数据
    因为发送方不断的写,接收方不断的读,那么一定存在两个位置
    lastByteRcvd(从网络中到达当前接收缓存的数据流的最后一个字节的编号) 和 LastByteRead(应用程序最后一次缓存中读的位置)

    我们必须保证 lastByteRcvd - LastByteRead = RcvBuffer(当前缓存空间的大小)
    rwnd(接收窗口) = RevBuffer - 【LastByteRcvd - LastByteRead】
    接受窗口表示接收方还能有多大的缓存空间
    因为这些数据是会动态变化的,我们这个接受窗口也是动态变化的,所以我们称这个窗口为滑动窗口那发送方是怎么拿到接收端的滑动窗口大小的数据呢?
    tcp是全双工通信,这个时候我们的接收方可以再发送一个报文告诉发送方,在tcp报头中,有一个位置是关于窗口大小的,这个位置就是关于流量控制的滑动窗口大小的数据发送方也需要关注两个变量,一个是lastByteSent(最后一次发送的比特位置),一个是LastBytedAcked(最近一次收到的确认包的比特位置)发送方只需要控制这两个的差小于等于接收窗口就可以了。
    在TCP报文段首部中有一个16位窗口长度,当接收端接收到发送方的数据后,在应答报文ACK中就将自身缓冲区的剩余大小,放入16窗口大小中。这个大小随数据传输情况而变,窗口越大,网络吞吐量越高,而一旦接收方发现自身的缓冲区快满了,就将窗口设置为更小的值通知发送方。如果缓冲区满,就将窗口置为0,发送方收到后就不再发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端。

    流量控制示意图
    在这里插入图片描述

    注意:窗口大小不受16位窗口大小限制,在TCP首部40字节选项中还包含一个窗口扩大因子M,实际窗口大小是窗口字段的值左移M位。

    6. 拥塞控制

    详解:https://blog.csdn.net/qq_41431406/article/details/97926927
    为了避免由于网络拥堵而采取的对发送方发送速率的限制称为拥塞控制
    TCP 通过拥塞窗口实现拥塞避免。

    每个 TCP 连接的发送方都会去感知网络的拥塞程度,然后去进行拥塞控制,那么 TCP 的发送方是如何感知到当前这个网络存在着拥塞呢,丢包,只要出现了超时就极有可能出现了网络拥堵。那 假设现在出现了网络拥塞,那么 TCP 如何限制传输的速率呢?TCP 的每一端除了维护进行流量控制的滑动窗口外,还会维护一个拥塞窗口(cwnd),拥塞窗口就是对 TCP 发送方的发送速率进行限制的,具体来说的就是 TCP 会控制发送方发送到连接中的但是还没有被接收方确认的数据量。

    那我们改变拥塞窗口的大小,就可以调节发送方发送数据的速率。那么发送的速率是多少呢?首先用 rtt 表示一次通信往返所用的时间,那么速率就等于 cwnd/rtt。一般来说 rtt 都是比较固定的,所以调整 cwnd 的值就可以调整发送速率。那我们应该如何确定当前发送速率是多少才合适呢?那就要依靠 TCP 的拥塞控制算法了。拥塞控制算法的实质就是如何来调整 cwnd 的大小。一说到大小就得有衡量单位,那窗口的衡量单位是 mss 最大的传输单元。那我们知道 TCP 分为 TCP 首部和数据两部分,mss 就是去控制数据字段的大小的,那这个值呢是需要通讯双方进行约定的。比如说一般的值呢是一千四百六十个字节。首先发送方发送数据的原则是什么呢,只要网络不堵,我就尽可能多的去发,网络赌的话,我就减小这个窗口的大小。

    TCP拥塞控制流程:
    TCP拥塞算法共有4种:慢开始、拥塞避免、快重传、快恢复
    在这里插入图片描述

    慢开始

    慢开始发生在最开始,这个时候不断试探网络是否把握的住,拥塞窗口(cwnd)以n²的增速开始增长,然后到了设置的阈值,我们就采取拥塞避免的算法每次加一的试探网络,当然后面肯定避免不了超时,我们这时候阈值设为当前阈值的一半,我们重新开始慢开始,到达现在的阈值开始拥塞避免。

    拥塞避免

    每个传输轮次,拥塞窗口cwnd只能线性加一,而不是像慢开始算法时,每个传输轮次,拥塞窗口cwnd按指数增长。

    快速重传

    接收器接收到一个不按顺序的数据段,接收器会立马给发送器发送重复确认,如果发送机接收到三个重复确认,它会假定确认件支出的数据段丢失了。这样就不会造成发送方对后面报文出发超时重传,而是提早收到了重传。然后开始快恢复算法。

    快恢复算法

    发送方一旦收到3个重复确认,就知道现在只是丢失了个别的报文段。于是不启动慢开始算法,而执行快恢复算法;
    1.发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半;开始执行拥塞避免算法。
    2.也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些,即等于新的ssthresh + 3。
    既然发送方收到3个重复的确认,就表明有3个数据报文段已经离开了网络;
    这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中;
    可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口犷大些。

    展开全文
  • TCP如何保证可靠传输

    千次阅读 2019-07-30 12:31:53
    TCP协议保证数据传输可靠性的方式主要有: 校验和 确认应答+序列号 超时重传 流量控制 拥塞控制 校验和 发送的数据包的二进制相加然后取反,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP...

    TCP协议保证数据传输可靠性的方式主要有:

    • 校验和
    • 确认应答+序列号
    • 超时重传
    • 流量控制
    • 拥塞控制

    校验和
    发送的数据包的二进制相加然后取反,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP将丢弃这个报文段和不确认收到此报文段。

    确认应答+序列号
    TCP给发送的每一个包(报文段)进行编号,接收方对数据包进行排序,把有序数据传送给应用层。

    超时重传
    当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段

    流量控制
    TCP连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议。

    接收方有接收窗口(即时窗口),随ACK报文发送

    拥塞控制
    当网络拥塞时,减少数据的发送
    发送方有拥塞窗口,发送数据前比对接收方发过来的接收窗口,取小
    慢启动、拥塞避免、快恢复、快重传

    应用数据被分割成TCP认为最适合发送的数据块(报文段)。
    TCP的接收端会丢弃重复的数据

    1. 校验和

    计算方式:在数据传输的过程中,将发送的报文段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃,补在后面,最后取反,得到校验和。

    发送方:在发送数据之前计算检验和,并进行校验和的填充
    接收方:收到数据后,对数据以同样的方式进行计算,求出校验和,与发送方的进行比对
    在这里插入图片描述
    注意:如果接收方比对校验和与发送方不一致,那么数据一定传输有误。但是如果接收方比对校验和与发送方一致,数据不一定传输成功。

    2. 确认应答与序列号

    序列号:TCP传输时将每个字节的数据都进行了编号,这就是序列号。 (TCP传输字节流)

    确认应答:TCP传输的过程中,每次接收方收到数据后,都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号,告诉发送方,接收到了哪些数据,下一次的数据从哪里发。
    在这里插入图片描述
    序列号的作用不仅仅是应答的作用,有了序列号能够将接收到的数据根据序列号排序,并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。

    3. 超时重传

    在进行TCP传输时,由于确认应答与序列号机制,也就是说发送方发送一部分数据后,都会等待接收方发送的ACK报文,并解析ACK报文,判断数据是否传输成功。如果发送方发送完数据后,迟迟没有等到接收方的ACK报文,这该怎么办呢?而没有收到ACK报文的原因可能是什么呢?

    首先,发送方没有接收到响应的ACK报文原因可能有两点:
    a、数据在传输过程中由于网络原因等直接全体丢包,接收方没有接收到
    b、接收方接收到了响应的数据,但是发送的ACK报文响应却由于网络原因丢包了

    TCP在解决这个问题的时候引入了一个新的机制,叫做超时重传机制。简单理解就是发送方在发送完数据后等待一个时间,时间到达没有接收到ACK报文,那么对刚才发送的数据进行重新发送。如果是刚才第一个原因,接收方收到二次重发的数据后,便进行ACK应答。如果是第二个原因,接收方发现接收的数据已存在(判断存在的根据就是序列号,所以上面说序列号还有去除重复数据的作用),那么直接丢弃,仍旧发送ACK应答。

    那么发送方发送完毕后等待的时间是多少呢?如果这个等待的时间过长,那么会影响TCP传输的整体效率,如果等待时间过短,又会导致频繁的发送重复的包。如何权衡?

    由于TCP传输时保证能够在任何环境下都有一个高性能的通信,因此这个最大超时时间(也就是等待的时间)是动态计算的

    超时以500ms(0.5秒)为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍。重发一次后,仍未响应,那么等待 2 * 500ms 的时间后,再次重传。等待4 * 500ms的时间继续重传。以一个指数的形式增长。累计到一定的重传次数,TCP就认为网络或者对端出现异常,强制关闭连接。

    4. 连接管理

    连接管理就是三次握手与四次挥手的过程,在前面详细讲过这个过程,这里不再赘述。保证可靠的连接,是保证可靠性的前提。

    4.1 流量控制

    接收端在接收到数据后,对其进行处理。如果发送端的发送速度太快,导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据,那么接下来发送的数据都会丢包,继而导致丢包的一系列连锁反应,超时重传呀什么的。而TCP根据接收端对数据的处理能力,决定发送端的发送速度,这个机制就是流量控制

    在TCP协议的报头信息当中,有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道,窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大,证明接收端接收缓冲区的剩余空间越大,网络的吞吐量越大。接收端会在确认应答发送ACK报文时,将自己的即时窗口大小填入,并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0,那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段,让接收端把窗口大小告诉发送端。
    在这里插入图片描述

    16位的窗口大小最大能表示65535个字节(64K),但是TCP的窗口大小最大并不是64K。在TCP首部中40个字节的选项中还包含了一个窗口扩大因子M,实际的窗口大小就是16为窗口字段的值左移M位。每移一位,扩大两倍。

    4.2 拥塞控制

    TCP传输的过程中,发送端开始发送数据的时候,如果刚开始就发送大量的数据,那么就可能造成一些问题。网络可能在开始的时候就很拥堵,如果给网络中在扔出大量数据,那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包,就对大量的超时重传,严重影响传输。

    所以TCP引入了慢开始的机制,在开始发送数据时,先发送少量的数据探路。探清当前的网络状态如何,再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1,每次收到ACK应答,拥塞窗口加 1。在发送数据之前,首先将拥塞窗口与接收端反馈的窗口大小比对,取较小的值作为实际发送的窗口。

    慢开始算法 和 拥塞避免算法

    发送方维护一个发送窗口,发送窗口的大小取决于网络的拥塞情况和接收窗口的大小,发送窗口是动态变化的。
    发送方还维护一个慢开始门限
    拥塞窗口 < 慢开始门限:使用慢开始算法
    拥塞窗口 > 慢开始门限:使用拥塞避免算法
    拥塞窗口 = 慢开始门限:使用慢开始算法或拥塞避免算法

    算法的具体过程:

    1. 通信开始时,发送方的发送窗口设为1,并发送第一个分组M1;
    2. 接收方收到M1后,返回确认应答,此时发送方发送窗口扩大两倍,并发送M2、M3;(即,发送方每次收到确认应答后,都将发送窗口设为当前值的两倍)
    3. 若拥塞窗口>慢开始门限,则使用拥塞避免算法,每次收到确认应答后都将发送窗口+1;
    4. 若发送方出现了超时重传,则表明网络出现拥塞,此时:
      a)慢开始门限设为当前发送窗口的一半;
      b)发送窗口设为1;
      c)启用拥塞避免算法;

    发送超时重传时,发送窗口有可能已经超过了慢开始门限,也有可能还没超过;此时不管何种情况,都一律启用拥塞避免算法,并执行上述三步操作!

    慢开始算法的作用:慢开始算法将发送窗口从小扩大,而且按指数级扩大,从而避免一开始就往网络中注入过多的分组从而导致拥塞;它将窗口慢慢扩大的过程其实也在探测网络拥塞情况的过程,当发现出现拥塞时,及时降低发送速度,从而减缓网络拥塞。慢开始算法不是增长很慢,只是初始值比较小。
    拥塞避免算法的作用:拥塞避免算法使发送窗口以线性方式增长,而非指数级增长,从而使网络更加不容易发生拥塞。

    AIMD算法(加法增大乘法减小算法)
    慢开始算法 和 拥塞避免算法 还有个名称叫做加法增大乘法减小算法。
    加法增加:指的是拥塞避免算法,使得发送窗口以线性的方式增长;
    乘法减小:指的是不管当前正使用慢开始算法还是拥塞避免算法,只要发生拥塞时,慢开始门限将会变成当前窗口的一半。

    快重传算法 和 快恢复算法

    上述慢开始算法和拥塞避免算法能保证网络出现拥塞时进行相应的处理,而快重传和快恢复是一种拥塞预防的方式,此时网络可能尚未出现拥塞,但已经有拥塞的征兆,因此得作出一些预防措施

    快重传原理:因为TCP具有累计确认的能力,因此接收者收到一个分组的时候不会立即发出应答,可能需要等待收到多个分组之后再同一发出累计确认。但快重传算法就要求,接收者如果接收到一个乱序的分组的话,就必须立即发出前一个正确分组的确认应答,这样能让发送者尽早地知道有一个分组可能丢失。

    快恢复原理:当发送者收到同一个分组的三个确认应答后,就基本可以判断这个分组已经丢失了;这时候无需等待超时,直接执行乘法减小加法增大(AIMD,将慢开始门限降为当前拥塞窗口的一半,然后直接采用拥塞避免算法,从慢开始门限开始):

    1. 将慢开始门限减半;
    2. 将发送窗口减半(不设为1);
    3. 使用拥塞避免算 ;
      在这里插入图片描述
      更多拥塞控制讲解以及滑动窗口讲解请参考:https://blog.csdn.net/jinjiniao1/article/details/90698643#334__151

    TCP为什么引入接受缓存这个数据结构?
    如果没有接受缓存的话,或者说只有一个缓存的话,为了保证接受的数据是按顺序传输的,所以如果位于x序号之后的序号分组先到达目的主机的运输层的话必然丢弃,这样的话将在重传上花费很大的开销,所以一般如果有过大的序号达到接收端,那么会按照序号缓存起来等待之前的序号分许到达,然后一并交付到应用进程

    TCP是以段为单位进行数据包的发送的。
    (1)在建立TCP连接的同时,也可以确定发送数据包的单位,称之为“最大消息长度”:MSS。最理想的情况是,最大消息长度MSS正好是IP层中不被分片处理的最大数据长度。
    (2)TCP在传送大量数据的时候,是以“段=MSS的大小”将数据进行分割发送的,进行重发时也是以MSS为单位的。
    (3)最大消息长度——MSS是在三次握手的时候,在两端主机之间被计算得出的。两端主机在发出“建立TCP连接请求的SYN包”时,会在SYN包的TCP首部中写入MSS选项,告诉对方自己所能够适应的MSS的大小,然后发送端主机会在两者之间选择一个较小的MSS值投入使用。

    TCP 粘包/拆包的原因及解决方法

    TCP是以流的方式来处理数据,一个完整的包可能会被TCP拆分成多个包进行发送,也可能把小的封装成一个大的数据包发送。

    TCP粘包/分包的原因:

    • 应用程序写入的字节大小大于套接字发送缓冲区的大小,会发生拆包现象,而应用程序写入数据小于套接字缓冲区大小,网卡将应用多次写入的数据发送到网络上,这将会发生粘包现象;
    • 进行MSS大小的TCP分段,当TCP报文长度-TCP头部长度>MSS的时候将发生拆包
    • 以太网帧的payload(净荷)大于MTU(1500字节)进行ip分片。

    解决方法

    • 消息定长:FixedLengthFrameDecoder类
    • 包尾增加特殊字符分割:行分隔符类:LineBasedFrameDecoder或自定义分隔符类 :DelimiterBasedFrameDecoder
    • 将消息分为消息头和消息体:LengthFieldBasedFrameDecoder类。分为有头部的拆包与粘包、长度字段在前且有头部的拆包与粘包、多扩展头部的拆包与粘包。

    5. 字节序号与报文段序号

    接下来的内容是学习后续内容的基础,必须先讲清楚。为了方便你回忆 TCP 首部,这里再次把这个图贴出来,以便对照。
    在这里插入图片描述

    5.1 序号

    5.1.1 序号存在的意义
    首先得弄清楚为什么要有序号。

    在 APUE 基础中,我们通过 TCP 协议将数据发送给对方,就比如 helloworld,这一串字节流,假设被拆分成了三个 TCP 报文段,第一个报文段携带了 hel,第二个报文段携带了 lowo,第三个报文段携带了 rld,这三个报文段不一定是按照顺序送到对端的,那么对端收到这三个段是如何确定他们的顺序的呢?此时序号的意义就体现在这里。

    5.1.2 序号
    序号占用 4 字节,即 32 位。它的范围是 [0 , 232−1] [ 0 , 232−1],也就是说一共有 4 294 967 296 个序号。TCP 协议中的序号,指的是报文段序号

    字节序号
    TCP 连接中,为传送的字节流(数据)中的每一个字节按顺序编号。也就是说,在一次 TCP 连接建立的开始,到 TCP 连接的断开,你要传输的所有数据的每一个字节都要编号。这个序号称为字节序号

    初始序号 ISN
    当新连接建立的时候,第一个字节数据的序号称为 ISN(Initial Sequence Number),即初始序号。ISN 一开始并不一定就是 1。在 RFC (规定网络协议的文档)中规定,ISN 的分配是根据时间来的。当操作系统初始化的时候,有一个全局变量假设为 g_number 被初始化为 1(或 0),然后每隔 4us 加 1. 当 g_number 达到最大值的时候又绕回到 0.当新连接建立时,就把 g_number 的值赋值给 ISN.

    在 BSD 系统中,这段代码实现时并未遵守协议,它将 g_number 初始化为 1,每 8us 加 1,也就是说,每隔 1 秒增加 125000,约 9.5 小时后 g_number 又绕回到了 0.

    初始序号是非常非常重要的概念,它告诉对端,第一个报文段是谁!而三次握手的目的,就是为了确认初始序号。

    报文段序号
    如果一个 TCP 报文段的序号为 301,它携带了 100 字节的数据,就表示这 100 个字节的数据的字节序号范围是 [301, 400],该报文段携带的第一个字节序号是 301,最后一个字节序号是 400.
    在这里插入图片描述上图中,报文段序号是 2379453244,它携带了 6 字节的数据 hello\0,这 6 字节的数据字节序号就是从 h->2379453244,e->2379453245 一直到最后一个空字符 \0->2379453249.

    注意:序号字段只有在下面两种情况的任意一种才有意义:
    数据字段至少包含一个字节
    这是一个 SYN 段,或者是 FIN 段,或者是 RST 段

    5.2 确认号

    每传送一个 TCP 段,都要等待对方回复一个确认。不过这种方式效率太低,在 TCP 协议中,一般采用累积确认的方式,即每传送多个连续 TCP 段,可以只对最后一个 TCP 段进行确认。

    对方通过回复一个确认号,来表示确认已经接收到了哪个 TCP 段。比如发送方发送了一个报文段序号为 301 的 TCP 段,这个段携带了 100 字节数据,则接收方应当回复的确认号是 401,它表示接收方已经收到了字节序号为 [0, 400] 的数据,现在期望你发送字节序号为 401 以及以后的数据。

    只有当 ACK 标志位被置位的时候,确认号这个字段才有效。

    一次完整的 TCP 连接到释放的过程
    在这里插入图片描述
    为了能够清晰的看到客户端与服务器的交互过程,这里将它画成了下面的时序图。

    在这里插入图片描述

    tcp如何保证传输的可靠性:

    • 合理分片:将数据分割成最适合tcp发送的数据块
    • 超时重传:tcp发送端发送数据后会启动一个计时器,当计时器超过某个时间没有收到接收端的确认就,重新发送数据。
    • 确认:tcp接收端接收到数据后发送确认给发送端。
    • 校验:tcp接收到数据检验发现数据有误,丢弃报文段,不给出相应,发送端会超时重传
    • 失序重排:tcp是用ip数据报传送数据的,ip数据报到达会失序,因此数据到达也会失序。Tcp会对失序的数据重新排列。
    • 重复丢弃:对收到的重复数据丢弃掉。
    • 流量控制:当接收端来不及处理发送端发送的数据,能提示发送端降低发送的速率,防止包丢失。
    • 拥塞控制:当网络拥塞时,减少数据的发送。

    序号部分参考:https://blog.csdn.net/q1007729991/article/details/69261780

    展开全文
  • TCP如何保证可靠性

    千次阅读 2022-01-19 15:17:59
    TCP如何保证可靠性校验和序列号与确认号超时重传滑动窗口 (TCP流量控制)拥塞控制三次握手(重点)四次挥手(重点) 校验和 TCP检验和的计算与UDP一样,在计算时要加上12byte的伪首部,检验范围包括TCP首部及数据部分...
  • TCP如何保证传输可靠性

    千次阅读 2021-01-31 15:33:44
    若想保证数据传输的可靠性,需要解决以上几个问题。具体解决方法体现为校验和、序列号、确认应答、重发控制、连接管理以及窗口控制机制实现可靠传输。 确认应答(ACK) 即发送端将数据发送给接收端,如果接收端返回一...
  • 这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP 将丢弃这个报文段和不确认收到此报文段。 TCP 的接收端会丢弃重复的数据。 流量控制: TCP 连接的每一方都有固定...
  • Tcp如何保证可靠传输呢? 什么是TCPTCP是一个运输层的传输协议,是面向连接的、可靠的、基于字节流的协议。 我们来看一下这几个概念: 面向连接:TCP的传输必须是有连接的,即要用三次握手建立可靠的通信信道,...
  • TCP如何保证可靠传输? 这是一个面试中经常被问到的问题,下面写一个详细的总结。 首先是一个简略版的回答: 建立连接 序号机制 合理分片(可以不说,是与UDP相比的,有些八股文上面没有这一条) 数据校验 超时重传...
  • 文章目录1 流量控制和...拥塞控制是一个全局的过程,涉及到所有的主机,路由器,以及与降低网络传输性能相关的所有因素。流量控制往往是点对点的控制,主要是抑制发送方发送数据的频率,是接收方来得及接收。 发送
  • TCP 可靠传输机制

    千次阅读 2022-01-11 23:52:54
    怎么保证可靠性?—> 确认机制 重传输机制 什么是面向连接?—>在传输数据之前,双方进行协商,保证双方可以收发数据 怎么保证面向连接?—>三次握手 可靠传输— 4种可靠机制 – 确认 重传 排序 流控(滑动...
  • TCP协议是如何保证传输可靠性

    千次阅读 2021-10-07 19:20:01
    确保传输可靠性的方式 校验和 序列号/确认应答 超时重传 连接管理 流量控制(滑动窗口控制) 拥塞控制 校验和: TCP校验和是一个端到端的校验和,由发送端计算,然后由接收端验证。其目的是为了发现TCP首部和数据...
  • TCP可靠性保证机制总结

    万次阅读 多人点赞 2018-05-28 23:33:44
    TCP保证可靠性主要依靠下面7种机制: 1、检验和 TCP检验和的计算与UDP一样,在计算时要加上12byte的伪首部,检验范围包括TCP首部及数据部分,但是UDP的检验和字段为可选的,而TCP中是必须有的。计算方法为:在发送...
  • TCP协议如何保证可靠传输

    千次阅读 2020-06-27 15:10:12
    文章正文编辑目錄TCP 协议基础面向连接的协议善始善终的连接管理TCP 容错功能 从编程实现角度看 TCP 连接 TCP 大包分裂和重组TCP 重传机制TCP 滑动窗口机制T...
  • TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。 还有拥塞控制与流量控制机制,我们重点聊一下这两个方面 流量控制: 如果发送方把数据发送得过快,接收方可能会来不及接收...
  • TCP协议保证数据传输可靠性的方式

    千次阅读 2020-08-07 19:46:01
    TCP协议保证数据传输可靠性的方式主要有: 校验和 序列号 确认应答 超时重传 连接管理 流量控制 拥塞控制 ###1、检验和 TCP检验和的计算与UDP一样,在计算时要加上12byte的伪首部,检验范围包括TCP首部及数据部分,...
  • 这里写目录标题超时重传滑动窗口滑动窗口机制概述发送窗口和接收窗口的工作原理滑动窗口的工作过程几种滑动窗口协议1比特滑动窗口协议(停等...TCP保证可靠性一般有以下几种方法: (1)面向字节流:以流的方式传输,缓
  • 面试题:tcp如何保证可靠传输

    千次阅读 2021-12-12 20:51:09
  • TCP协议如何保证可靠传输

    千次阅读 多人点赞 2021-11-19 23:26:38
    本文介绍TCP协议如何保证可靠传输。 本内容也是Java后端面试常见的问题。 概述 TCP协议保证数据传输可靠性的方式主要有: 大小控制 应用数据被分割成 TCP 认为最适合发送的数据块。 序列号 TCP 给发送的每一个包...
  • TCP如何保证可靠性

    2022-04-26 10:54:30
    TCP 是面向连接的、可靠的、传输层通信协议 ...TCP协议保证数据传输可靠性的方式主要有: 校验和 序列号 确认应答 超时重传 连接管理 流量控制 拥塞控制 校验和 计算方式:在数据传输的过程中,将发送
  • 网络基础:TCP协议-如何保证传输可靠性

    万次阅读 多人点赞 2018-05-24 13:04:51
    TCP协议传输的特点主要就是面向字节流、传输可靠、...TCP协议保证数据传输可靠性的方式主要有: 校验和 序列号 确认应答 超时重传 连接管理 流量控制 拥塞控制 校验和 在数据传输的过程中,将每个发送的数据...
  • TCP如何保证传输可靠性

    千次阅读 2019-05-19 09:40:07
    TCP协议保证传输可靠的方法主要有:校验和,序列号,确认应答,超时重传,连接管理,流量控制,拥塞控制。 (一)校验和:判断传输数据是否出现了修改 TCP在计算校验和时,会添加一个12个字节的伪首部。其内容为...
  • TCP协议保证通信可靠性的几种方法

    千次阅读 2020-05-25 12:37:06
    按层次分,TCP位于传输层,提供可靠的字节流服务。 所谓的字节流服务(Byte Stream Service)是指,为了方便传输,将大块数据分割成以报文段(segment)为单位的数据包进行管理。而可靠传输服务是指,能够把数据...
  • 全网最详细的 TCP 可靠传输

    千次阅读 2021-11-22 09:40:36
    而传输层使用 TCP 实现可靠传输,TCP 保证可靠传输的机制有如下几种: 1)校验和 2)序列号和确认应答机制 3)重传机制 4)滑动窗口 5)流量控制 6)拥塞控制 校验和 所谓 TCP 的校验和(Checksum)就是说:由发送端...
  • TCP如何保证可靠传输 TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制来实现可靠性传输 确认应答(ACK)机制 正常数据传输,若接收方收到了发送方的数据,就会返回一个ACK响应确认已经收到 ...
  • TCP如何保证可靠传输?三次握手过程?
  • TCP怎么保证数据的可靠性
  • TCP协议是如何保证可靠传输

    千次阅读 2019-03-28 23:58:19
    言归正传:TCP通过序列号、检验和、确认应答信号、重发控制、连接管理、窗口控制、流量控制、拥塞控制实现可靠性。 1、通过序列号和确认应答信号提高可靠性。 (1)如图1 所示:在TCP中,当接收端主机接收到来自...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 144,312
精华内容 57,724
关键字:

tcp如何保证可靠传输

友情链接: BINGO1.1-(1).rar