欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  网络运营

【传输层】传输控制协议TCP概述之一

程序员文章站 2022-09-21 17:19:10
【传输层】传输控制协议TCP概述之一   一,TCP的主要特点          1)面向连接    ...

【传输层】传输控制协议TCP概述之一

 

一,TCP的主要特点

         1)面向连接

         2)点对点

         3)可靠交付,无差错、不丢包、不重复、按需到达

         4)全双工通信,接收端和发送端都设有发送缓存和接受缓存

         5)面向字节流:TCP把应用程序交付下来的数据仅仅看成 ”一连串无结构字节流“,但TCP不知道字节流含义。TCP也不保证接收方收到的数据块和发送方应用程序所发出的数据块具有对应大小。应用程序应具备能力识别收到的字节流,把它还原成有意义的数据。

二,细节

        1)TCP对应用程序一次把多长的报文送到TCP缓存中是不关心的,TCP根据对方给出的窗口值和网络拥塞程度来决定一个报文段应包含多少字节。UDP发送的报文长度是应用程序给出的。

        2)每一条TCP链接,被两个端点的两个套接字唯一的确定。

三,可靠传输的工作原理

         理想的传输条件:传输信道不产生差错、不管发送方以多快速度传输,接收方都来得及出路

        1)停止等待协议

               无差错情况:每次发送完一个数据,就等待确认,收到确认再发送下一个数据。      

               出现差错:    超时重传(大于一个来回的时间)

                                        A    发送完分组,保存已发送的分组的副本,收到确认后再丢弃。

                                        B    分组和确认分组都进行编号,这样才能知道那个是哪个的确认

                                        C    超时重传时间应大于一个来回的时间

               确认丢失和确认迟到:

                                        A    确认丢失就超时重传,对方明明发送确认,但是还收到重复数据,则丢弃重复数据,再发确认。

                                        B     类似确认丢失,只是在发送方再次收到 迟来的确认时,丢弃并什么也不做。

         2)连续ARQ协议 (Automatic  Repeat-ReQuest)

                发送方:每收到一个分组的确认,把窗口向前移动一个分组的位置。

                接收方:采用积累发送确认的方式,对按序到达的最后一个分组发送确认(不比所有都确认)

          缺点:不能向发送方反映 接受到的所有分组的信息。

                Go-Back-N:发送五个分组,第三个丢失了。接收方只能对第二个确认,这样发送方,只能重传后三个分组。

四,TCP可靠传输的实现

         1)以字节为单位的滑动窗口

                

【传输层】传输控制协议TCP概述之一
【传输层】传输控制协议TCP概述之一
【传输层】传输控制协议TCP概述之一

                

             2)发送缓存和接收缓存

                    

【传输层】传输控制协议TCP概述之一

 

         发送缓存与接收缓存的作用

         (1) 发送缓存用来暂时存放:

              a) 发送应用程序传送给发送方 TCP准备发送的数据;

              b) TCP 已发送出但尚未收到确认的数据。

        (2) 接收缓存用来暂时存放:

              a)按序到达的、但尚未被接收应用程序读取的数据;

              b)不按序到达的数据。 

 

      3) 注意

           (1) A 的发送窗口并不总是和 B 的接收窗口一样大(因为有一定的时间滞后)。

           (2) TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程。

           (3) TCP 要求接收方必须有累积确认的功能,这样可以减小传输开销。接收方可以在有消息发送时,顺便把确认消息带上。但不能过分推迟确认,以免造成重传浪费。

 

      4) 超时重传时间的选择

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

 

           1 往返时延的方差很大

              由于 TCP 的下层是一个互联网环境,IP 数据报所选择的路由变化很大。因而运输层的往返时间的方差也很大。

 

           2 加权平均往返时间

              TCP 保留了 RTT 的一个加权平均往返时间 RTTS(这又称为平滑的往返时间)。

              第一次测量到RTT样本时,RTTS 值就取为所测量到的 RTT样本值。以后每测量到一个新的RTT 样本,就按下式重新计算一次RTTS:

                   新的 RTTS = (1 - a) * (旧的 RTTS) + a *(新的 RTT 样本)

                            式中,0<= a < 1。若 a 很接近于零,表示 RTT 值更新较慢。若选择 a 接近于 1,则表示 RTT 值更新较快。(RFC 2988 推荐的 a 值为 1/8,即 0.125)

          3 超时重传时间 RTO (RetransmissionTime-Out) 

               (1) RTO 应略大于上面得出的加权平均往返时间RTTS 。

               (2) RFC 2988 建议使用下式计算 RTO:

                   RTO = RTTS + 4 *RTTD     

               (3) RTTD是 RTT 的偏差的加权平均值。

               (4) RFC 2988 建议这样计算 RTTD。第一次测量时, RTTD 值取为测量到的 RTT 样本值的一半。在以后的测量中,则使用下式计算加权平均的 RTTD:

新的 RTTD= (1 - b) *(旧的RTTD)+ b *|RTTS - 新的 RTT 样本|                  式中,b 是个小于 1 的系数,其推荐值是 1/4,即 0.25。

 

          4 往返时间的测量

             往返时间的测量相当复杂

             TCP 报文段 1 没有收到确认。重传(即报文段 2)后,收到了确认报文段 ACK。但如何判定此确认报文段是对原来的报文段 1 的确认,还是对重传的报文段 2 的确认? 

            下面这些算法提供了一下方法:

             Karn 算法 

                         在计算平均往返时间 RTT 时,只要报文段重传了,就不采用其往返时间样本。这样得出的加权平均平均往返时间 RTTS 和超时重传时间 RTO 就较准确。 

             修正Karn 算法 

                         报文段每重传一次,就把 RTO 增大一些,如下公式所示: 新的 RTO=y*(旧的 RTO)         式中,系数y的典型值是 2 。

 

             当不再发生报文段的重传时,才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值。实践证明,这种策略较为合理。 

 

        5  选择确认 SACK (Selective ACK) 

            当接收方收到了和前面的字节流不连续的两个字节块。如果这些字节的序号都在接收窗口之内,那么接收方就先收下这些数据,但要把这些信息准确地告诉发送方,使发送方不要再重复发送这些已收到的数据。 

 

            RFC 2018 的规定 

              (1) 如果要使用选择确认,那么在建立 TCP 连接时,就要在 TCP 首部的选项中加上“允许 SACK”的选项,而双方必须都事先商定好。

              (2) 如果使用选择确认,那么原来首部中的“确认号字段”的用法仍然不变。只是以后在 TCP 报文段的首部中都增加了 SACK 选项,以便报告收到的不连续的字节块的边界。

              (3) 由于首部选项的长度最多只有 40 字节,而指明一个边界就要用掉 4 字节,因此在选项中最多只能指明 4 个字节块的边界信息。