TCP 核心工作机制

TCP 的核心知识:如何保证传输可靠 + 如何提高传输效率

如何保证传输可靠:确认应答机制 + 超时重传机制

如何提高传输效率:滑动窗口机制、快速重传机制、流量控制机制、延时应答机制、捎带应答机制、拥塞控制机制

一、如何保证传输可靠

        TCP的可靠性主要是通过 确认应答 + 超时重传 来实现的。

1 确认应答机制

TCP 核心工作机制_第1张图片

        先看发送发:在没有滑动窗口机制之前,发送方一次只能发送一段报文,且每次发送完后要等待接收方的ACK确认,只有在收到接收方的ACK确认应答后,才能将发送缓冲区里对应的数据释放掉,并开始发送第二段报文。如果在规定时间内未收到ACK确认,则尝试重传这段报文(超时重传机制)。

        再看接收方:接收方每次接收到报文后,都要给发送方返回一个确认应答报文ACK,告知对方已正确接收数据,期望下次收到报文段的起始序列号是ack。

        确认应答机制本质上是接收方对发送方报文中的seq进行确认,TCP是字节流传输协议,seq就代表数据,seq被确认就意味着数据被确认。只有确认应答机制 + 超时重传机制才能保证数据传输的可靠性,但数据传输效率比较低(RTT时间越长,传输效率越低)

2 超时重传机制

        TCP超时重传机制是针对确认应答阶段数据丢包的情况,TCP传输过程中,发送方发出的报文可能会丢失,接收方返回给对端的ACK报文也有可能丢失。无论是哪种丢包,发送方在发送完报文后如果在指定时间内(RTO,Retransmission Timeout 超时重传时间)未收到对端返回的ACK报文,就会重传这段报文。重传次数达到一定量时,如果还是无法收到ACK报文,发送方就会发送RST报文,要求重置连接,如果重置连接都失败那就彻底断开连接。

RTO随RTT动态变化。RTT越小,网络环境越好,RTO也随之变小。

如果超时重传的数据,因再次超时而重传时,超时重传时间将是先前值的两倍。

        接收方收到重复的报文怎么办?TCP接收数据时都先将数据写入到接收缓冲区(Receive Buffer),再根据seq对缓冲区数据进行排序,方便应用程序正确有序地读取数据。新接收到的数据在写入缓冲区后,自然也要根据seq排序,这时就很容易判断出这段数据是否重复,如果重复就直接丢弃,这种机制确保了应用层读取到的数据是有序且不重复的。

        超时重传存在的问题是,超时周期相对较长。

 3 连接管理机制

        通过三次握手建立连接,再通过四次挥手断开连接。

        参考文章 TCP三次握手、四次挥手及状态转换详解

二、如何提高传输效率

        TCP为了能最大限度的提高传输效率,分别从三方面对传输过程进行优化

  • 提高发送方的发送量(发送速率),如滑动窗口机制;
  • 提高接收方的接收能力(对方是否能承受大的数据量),如流量控制机制、延时应答机制;
  • 提高网络的转发能力(网络是否能转发大的数据量),如拥塞控制机制。

4 滑动窗口机制

4.1 为何要引入窗口概念?

        在没有引入窗口概念之前,确认应答机制中一次只能发送一条报文段,只有等被ACK确认应答后才能发送另一段报文。这传输效率着实有点慢,当网络环境不佳时,效率还会更慢。如何提高传输效率呢?有没有可能提高TCP的发送量呢,能否允许它先一次发送多条报文,然后再等ACK确认应答,先把发送量提起来再说。TCP这才引入了窗口概念,数据发送量以窗口大小来衡量。即使在RTT较长的情况下,也不会降低传输效率。

        在学习窗口之前,我们先简单了解下什么是缓冲区。

4.2 什么是缓冲区?

  • 缓冲区是TCP在操作系统中开辟的一块缓存空间,用于缓存将要发送和接收的数据;
  • TCP有两个缓冲区,分别是发送缓冲区接收缓冲区
  • 发送缓冲区和接收缓冲区都是环形队列
  • 应用层调用send函数将数据写入发送缓冲区,TCP从发送缓冲区获取数据并发送;
  • 网络层递交给TCP的数据最终被存放到接收缓冲区,应用层调用recv函数将数据从接收缓冲区读出。

4.3 什么是窗口?

        窗口分“发送窗口”和“接收窗口”,首先它俩针对的缓冲区有所不同,发送窗口针对的是发送缓冲区,而接收窗口针对的是接收缓冲区。其次,发送方发送窗口的大小由接收方接收窗口的大小决定,但并不意味着两者就完全相等,因为有网络延迟,所以接收窗口大小一般约等于或稍大于发送窗口大小。还需注意的是,窗口大小并不代表缓冲区的大小

        接收窗口(大小)就是我们通常讲的窗口(大小),如:“A端窗口还是1M,让B端发送慢点”,这里的窗口指的就是A端的接收窗口大小,接收窗口对应TCP报头中的Window字段,表示接收方还剩多少接收缓冲区可用于接收数据。

        发送窗口(大小)指的是发送缓冲区中“已发送但未收到ACK确认”和“可以发送但还未发送”两块缓冲区的组成部分。这两部分的数据无需TCP确认就可直接推送给网络层。

        “已发送但未收到ACK确认”很好理解,就是已发送的报文在未等到确认应答ACK返回之前,必须保留在发送缓冲区中,如果在规定时间(RTO)内收到了ACK报文,就将数据从缓存区清除,否则重传报文。

        “可以发送但还未发送”指的是“可以发送但还没来得及发送,且总大小在接收方窗口大小范围之内”。

        注意:窗口是会动态变化的,可大可小,并不是下图中画的那样只有20字节;

TCP 核心工作机制_第2张图片

TCP 核心工作机制_第3张图片

4.4 引入滑动窗口机制 

        下面图中,如果32 ~ 45字节的数据状态不变,46 ~ 51字节的数据也已成功发送且未收到ACK确认,那么此时发送方的可用窗口就是0,在未收到新的ACK确认应答前无法继续发送数据。 

TCP 核心工作机制_第4张图片

        如果32 ~ 45 字节中前一部分数据收到了ACK确认应答以后怎么办呢?总不能等这个窗口中的所有数据都被ACK确认应答后才换另一个窗口吧?这不是换汤不换药吗,TCP发送方还是要会花很长时间等待确认。然后,TCP就又引入了滑动窗口机制,让窗口动态滑动起来不就好了吗,前面已被ACK确认的数据我就释放掉,将窗口向右滑动,新进入窗口的数据开始发送,就这样边确认边滑动边发送,这不就提高了传输效率嘛。

        滑动窗口允许窗口内的报文数据,不需要等前一个报文段被ACK确认应答,就可以直接交给网络层进行传输,已被确认的数据会被窗口释放掉(还在缓冲区中,只是不在窗口内),窗口也随之向右移动,这样可大大提高TCP发送方的数据发送量。

4.5 发送方滑动窗口(四部分)

        如下图,当32 ~ 36字节的数据收到ACK确认应答后,如果发送窗口大小不变,则将窗口往右滑动5个字节,此时发送窗口就变成了由37 ~ 56字节组成的缓冲区了,后续就可以继续发送52 ~ 56字节之间的数据了。

TCP 核心工作机制_第5张图片

发送方滑动窗口由以下四部分组成:

TCP 核心工作机制_第6张图片

  • SND.WND:发送窗口大小(由接收窗口Window大小决定);
  • SND.UNA:是一个绝对指针,指向的是#2已发送但未收到ACK确认应答内容的第一个字节数据所对应的序列号;
  • SND.NXT:是一个绝对指针,指向的是#3可以发送但未发送内容的第一个字节数据所对应的序列号;
  • 是一个相对指针,SND.UNA + SND.WND,指向的是#4未发送且不能发送内容的第一个字节数据对应的序列号。

可用窗口大小 = SND.WND -(SND.NXT - SND.UNA)

4.6 接收方滑动窗口(三部分)

TCP 核心工作机制_第7张图片

  • RCV.WND:接收窗口大小,会赋值给Window并发送给发送方
  • RCV.NXT:是一个绝对指针,指向的是期望发送方下次发送来的数据的起始序列号,即ack值
  • 是一个相对指针,RCV.NXT + RCV.WND,指向的是#4未收到且不可以接收的第一个字节数据对应的序列号。

5 快重传

5.1 快速重传机制

        引入滑动窗口机制后,发送方一次可发送多条报文,但又会面临一个新的问题,如果发出的多条报文中丢失了好几条怎么办,干等着超时重传吗?一个重传完继续判断另一个丢失数据?再重传?这种重传效率比较低,所以TCP就引入了快速重传机制,可大大提高重传速率。

        快速重传(Fast Retransmit)机制,本质还是为了提高传输效率,它不以时间为驱动,而是以数据驱动重传,在没有触发超时重传前,就已经触发发送方重传数据了。

        发送方利用滑动窗口机制一次发出了5条报文,如下图

TCP 核心工作机制_第8张图片

  • 接收方收到seq1报文,返回ack2;
  • 接收方收到seq3报文,未收到seq2,还是返回ack2;
  • 接收方收到seq4和seq5报文,但还未收到seq2,最终还是返回ack2;
  • 发送方收到了3次重复的ack2,表明seq2丢失了,便立即重传丢失的seq2;
  • 接收方收到seq2报文,返回ack6。

        快速重传的工作方式是当发送方收到三次冗余的(不含第一次)重复的 ACK 报文时,在RTO生效前,立即重传丢失的报文段,这样就可以有效缩短重传时间。但这里面还存在效率的问题,如果发送方发出了6条或更多条报文,假设 seq2 和 seq3 都丢失了,发送方在收到3次冗余的ack2报文后,此时它首先能肯定的是seq2丢失了,但不确定seq2之后的数据有没有丢失,怎么办呢?只能先把seq2发出去再说,等收到后面的ack后再判读有没有其它数据丢失。假设当前通信网络环境不佳,发送方发送了很多条报文出去,丢包率为10%,发送方如果还是按照上面这种方式重传报文的话,其实效率也没提高多少。为了解决快重传的效率问题,于是就有了选择性确认SACK(Selective Acknowledgment),该参数位于TCP报头的Options,发送方可通过SACK值来判断哪部分数据丢失,有针对性地进行快重传,大大提高了重传效率。

5.2 SACK

        选择性确认(SACK,Selective Acknowledgment)用于数据重传机制,位于TCP报头的Options。接收方可通过SACK参数告知发送方我方收到了不连续的数据块(ack=200,SACK=300-400),发送方可根据此信息检查哪部分数据丢失(对方收到200字节数据,接收到了300-400段,说明200-299段丢失了)并重传丢失的数据。

TCP 核心工作机制_第9张图片

        TCP三次握手过程中,双方会通过“SACK Permitted”来互相声明自己是否支持SACK,只有双方都支持SACK时,TCP才会使用SACK。Linux开启SACK的方法如下

#linux系统中可通过修改net.ipv4.tcp_sack来决定是否开启SACK,Linux 2.4后默认开启
[root@reader ~]# sysctl -a | grep net.ipv4.tcp_sack
net.ipv4.tcp_sack = 1
[root@reader ~]# find / -name *tcp_sack*
/proc/sys/net/ipv4/tcp_sack
[root@reader ~]# cat /proc/sys/net/ipv4/tcp_sack
1
[root@reader ~]# 

可以用echo或sysctl -w 来临时修改tcp_sack
也可以在系统配置文件 /etc/sysctl.conf 中,添加如下一行代码,永久修改 tcp_sack
net.ipv4.tcp_sack = 

5.3 D-SACK

        Duplicate SACK 又称D-SACK,主要是通过SACK来告知发送方有哪些数据被重复接收了。通过D-SACK可让发送方知道是我方发出的报文丢失还是对端返回的ACK报文丢失。如,发送方收到ack= 500,SACK=300-400这样的报文,意味着500之前的数据都接收到了,且重复收到了300-400的数据。

#linux系统中可通过修改net.ipv4.tcp_dsack来决定是否开启SACK,Linux 2.4后默认开启
[root@reader ~]# sysctl -a | grep net.ipv4.tcp_dsack
net.ipv4.tcp_dsack = 1
[root@reader ~]# find / -name *tcp_dsack*
/proc/sys/net/ipv4/tcp_dsack
[root@reader ~]# cat /proc/sys/net/ipv4/tcp_dsack
1
[root@reader ~]# 

可以用echo或sysctl -w 来临时修改tcp_dsack
也可以在系统配置文件 /etc/sysctl.conf 中,添加如下一行代码,永久修改 tcp_dsack
net.ipv4.tcp_dsack= 

6 流量控制机制

        通过滑动窗口机制有效提高了发送方的数据量和发送速率,但光提高发送方的发送速率也无法彻底解决问题,因为我们未考虑到接收方的数据处理能力,如果发送方的发送速率过高,而接收方的处理速率较低,就会出现接收方无法及时确认应答,发送方触发超时重传的情况,这样的话传输效率还是无法提高。所以,只有在发送方的发送速率与接收方的处理速率同步时,传输效率才能真正提高。

        流量控制机制:发送方根据接收方的实际接收能力来控制自己的发送速率。

        无论是发送方还是接收方,都有一个接收缓冲区,而接收窗口代表了当前可用于接收数据的缓冲区大小,接收方每次进行ACK确认应答时,都会把接收窗口大小放入到报头中的Window字段,发送方收到这条ACK报文后,可根据Window字段获知接收方的接收能力,并通过调整发送窗口大小来调整自己的发送速率,从而适应接收方的接收能力。

        发送方发送窗口的大小由接收方接收窗口的大小决定,但并不意味着两者就完全相等,因为有网络延迟,所以接收窗口大小一般约等于或稍大于发送窗口大小。

6.1 窗口关闭了怎么办?

        当窗口大小Window为0,也就是可用于接收数据的缓冲区大小为0,发送方将停止给接收方发送数据,直到窗口大小变为非 0 为止,这就是窗口关闭

6.2 如何结束窗口关闭状态?

  • 接收方主动结束窗口关闭状态。当接收缓冲区中的部分数据可以被确认时,这部分缓冲空间将被释放,可用于接收新的数据,同时接收方也会给发送方发送ACK报文,并声明Window大小,发送方收到这条ACK报文后会根据Window大小继续发送新的数据。
  • 发送方主动探测窗口关闭状态。只要发送方收到Window=0的ACK报文,就会启动一个定时器,等计时器超时后,发送方会主动发送窗口探测(Window probe)报文,而对方在确认这个探测报文时,会给出自己现在的接收窗口大小。如果接收窗口仍然是0,那就重新启动计时器。如果接收窗口不是0,那就继续发送新的数据。

6 延时应答机制

        延时应答机制建立在滑动窗口机制基础之上,其实就是接收方在接收到报文数据后,并不会立即给发送方返回ACK报文,而是稍等片刻再返回,这样做不仅可以将多次ACK应答合并成一次ACK应答(累计应答),有效减少了ACK应答次数,而且接收方在等待的这段时间内还能处理更多的数据,释放出更多的缓冲空间,接收缓冲区也因此变大,此时再给发送方返回的ACK报文中的Window也会比立即返回报文时的要大。所以,延时应答机制既能减少应答次数,还能变相的增大窗口大小,从而提高传输效率。

7 捎带应答机制

        捎带应答机制建立在延时应答机制基础之上,具体是指当一方要给对方发送非ACK报文时,此时刚好有ACK报文需要返回给对方,那么就将ACK应答内容合并到本报文中捎带着一起发送过去,这样的话可以有效减少应答次数,提高传输效率。

8 拥塞控制机制

        通过不同的策略,不断的探测网络的转发能力,调整发送方的发送数据量

  • 慢启动
  • 拥塞避免
  • 快恢复

粘包处理

异常处理


参考文章:4.2 TCP 重传、滑动窗口、流量控制、拥塞控制 | 小林coding

你可能感兴趣的:(#,TCP协议,tcp/ip,网络,服务器,工作机制,滑动窗口,流量控制)