TCP的机制讨论:可靠传输、提高网络效率

通过序列号和确认应答提高可靠性

在TCP中,当发送端的数据到达接收主机时,接收端主机会返回一个已收到消息的通知。这个通知叫做确认应答(ACK)

通过序列号可以判断是否已经接收了该数据,并且能判断是否需要接收。

提高可靠性的具体做法:接收端要查询数据TCP首部中的序列号和数据的长度,将自己下一步应该接收的序号作为确认应答返送回去。

 超时重传机制

当消息发送方发送一条数据,就会开启一个重传计时器,用来计算数据发出去的时间,当数据发出去的时间大于RTO的时候,还没有收到确认报文,则进行重发。

RTO=2*RTT

RTO(超时重传时间)          RTT:报文往返时间(从发送报文开始,直到接收到确认应答所经历的时间)

RTO是动态计算的

预测下一次数据往返时间RTT=RTT(这次数据往返时间)* i + RTT(上一次数据往返时间) * (1 - i )

在TCP中,一般默认i = 0.9

不论是发送的数据丢失,还是确认报文丢失,对于消息发送方而言,都没有接收到确认报文,都会进行重发数据。

滑动窗口机制

窗口是已经被发送方发送到网络上,但是还没有收到确认报文的分组的集合

  对于TCP通信双方而言,都会维护一套窗口(发送窗口和接收窗口)

          发送窗口:保存没有收到确认应答的报文,是发送缓冲区的一部分

         接收窗口:算是等同于接收缓冲区

窗口大小就是指无需等待确认应答而继续发送数据的最大值。

    窗口的大小一般是15,TCP连接开始一般取值为8。(在三次握手期间进行协商的,双方窗口大小一致)

窗口大小是可以动态变化的,根据网络能力来决定

Win=Window size value * Window size scaling factor

网络良好时,窗口会变大,网络不好时,窗口会变小;

         窗口大小决定可以往网络上面发送多少字节数据,并不决定每次发送多少字节!

TCP在传送大量数据是,是以MSS(最大报文段长度)的大小将数据分割发送,进行重发的时候也是以MSS为单位

MSS是在三次握手的时候,在两端主机之间被计算得出:通过建立连接的SYN包相互通知对方网络接口的MSS值,在两者之间选一个较小的作为MSS的值,发送数据

MTU(数据链路层对数据帧限制的大小)=网络层头部+传输层TCP头部+MSS

注:

发送端主机在等到确认应答返回之前,必须在缓冲区中保留这部分数据。在滑动窗口以外的部分包括尚未发送的数据以及确认对端已收到的数据。当数据发出后若如期收到确认应答就可以不再进行重发,此时数据就可以从缓存区清除。收到确认应答的情况下,将窗口滑动到确认应答中的序列号的位置。

报文丢失情况:

数据丢失:一定会重传数据

针对消息接收方而言,如果没有收到消息发送方发送的数据,消息接收方即使接收到了更大序号的数据,也不会返回确认报文,需要一直发送丢失报文的起始序号。

确认应答丢失:不一定需要重传数据

如果发送方接收到比未确认序号更大的确认应答时,就可以认为没有收到的那个小的确认序号的所对应的数据已经被对端接收了。这时就不需要重传数据,可以忽略。

理解了上面我们定义一下滑动窗口机制

收到确认应答的情况下,将窗口滑动到确认应答中的序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制被称为滑动窗口机制。

拥塞控制机制

慢启动    拥塞避免  快重传   快恢复

慢启动:

核心思想是:当通信双方建立连接之后,刚开始不要发送大量的数据,而是先发送少量的数据,探测网络拥塞程度。在网络情况比较好的时候,逐渐增大发送的数据量。

 

为了在发送端调节所要发送数据的量,定义了一个“拥塞窗口”(cwnd)

  在发送方发送数据的时候,不单单要考虑发送窗口大小,还要考虑拥塞窗口。(拥塞窗口一般等于发送窗口,如果小于,按照拥塞窗口大小发送数据)

每次通信的时候,都会带有窗口大小(告诉对方,自己的接收能力)

慢开始门限(ssthresh):是一个阈值。

当拥塞窗口小于这个阈值时,执行慢开始算法,随着传输轮次,窗口大小进行指数增长。

当拥塞窗口大于这个阈值时,执行拥塞避免算法,随着传输轮次,窗口大小进行线性增长。

拥塞避免:

          当拥塞窗口大于慢开始门限的时候,拥塞窗口的大小随着传输轮次线性增长。

快重传:

  核心思想:当接收方接收到一个数据的报文段的时候,就会发出重复确认,意味着想让数据发送方提早的知道有一个数据没有到达接收方。

  具体做法:对于发送方而言,发送一个报文之后,就会开启一个重传计时器;但是当发送方接收到接收方的三个重复的确认应答,则不用等待设置的重传计时器完毕后在重传丢失数据,而是直接重传丢失的报文。

    注:快速重传依赖的接收方连续的确认数据报,不会等待接收方进行捎带应答确认。

快恢复:

     如果网络拥塞导致发送方某一个TCP报文丢失,接收方会依照快重传,一连串发送3个确认包。

针对发送方而言,如果能够一连串收到三个重复的确认包。针对于发送方而言,会认为网络拥塞的并不是很严重,完全没有从慢开始进行传输,而是设置新的慢开始门限(拥塞窗口/2),将拥塞窗口等于新的慢开始门限,从而执行拥塞避免算法。

   


提高网络利用率:

捎带应答机制:

   为了减少网络当中的数据量,当接收方接收到一个数据之后,发出确认的时候,是随着接收方发送给发送方的数据一起,发送给发送方

延时应答机制:

接收数据的主机如果每次都立刻回复确认应答的话,可能会返回一个较小的窗口,这是因为刚接收完数据,缓冲区已满。当发送端收到这个小窗口通知以后,会以它为上限发送数据,从而又降低了网络的利用率。

延时应答机制:收到数据以后并不立即返回确认应答,而是延迟一段时间再回复的机制。

好处:当接收方接收到数据之后,等待一段时间,等待应用层程序将接收缓冲区当中的数据读走,从而扩大接收缓冲区接收数据的能力;在回复的时候,就可以告诉发送方自己接收能力比较大的情况,

注:延时应答机制不是不进行确认应答恢复,而是不立即回复,等待一段时间后再回复。

 

当接收方接收缓冲区满了之后,就被迫暂停接收数据。应用程序从接收缓冲区将数据读走之后,回想发送方发送一个发送窗口,发送方在收到发送窗口更新通知后通信会得以继续进行。

  如果这个窗口的更新通知(发送窗口)在传送途中丢失,可能会导致无法继续通信。为了避免此问题的发生,发送端主机会在等待RTO后发送一个窗口他侧的数据段,此数据段仅含一个字节以获取最新窗口的大小信息。


保活计时器:

作用:保证TCP连接是正常的。

当一个TCP连接双方在2个小时内没有发送数据,则保活计时器超时的一方,每隔75s发送保活探测包,连续发送10次,如果10次都没有收到响应报文,则认为该连接异常,需要断开连接。只要收到响应报文,计时器就会被重置,从0开始。

 

你们的 【三连】 是给Qyuan最大的肯定!

↓          ↓           ↓

注:如果本篇博客有任何错误和建议,欢迎伙伴们留言,你快说句话啊

 

 

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值