【计算机网络】TCP协议——3. 可靠性策略&效率策略

发布时间:2023年12月19日

?前言

TCP是一种可靠的协议,提供了多种策略来确保数据的可靠性传输。

可靠并不是保证每次发送的数据,对方都一定收到;而是尽最大可能让数据送达目的主机,即使丢包也可以知道丢包。

目录

一. 确认应答和捎带应答机制

二. 超时重传

超时时间

三. 滑动窗口

1. 滑动窗口的实现

2. 滑动窗口的相关问题(快重传)?

3. 延迟应答

四. 流量控制

五. 拥塞控制

六. 面向字节流&粘包问题

TCP小结

结束语


一. 确认应答和捎带应答机制

在上篇博客说到,TCP将每个字节的数据都进行了编号,即为序列号。

序列号,既是TCP面向字节流的体现,也对发送的数据进行了排序,即编号小的,一定是先发送的。接收方在收到TCP报文后,根据报头中的序列号,将TCP报文按照序号顺序放入接收缓冲区

TCP协议规定,接收方接收数据,必须发送确认报文。这就是确认应答

序列号和确认号就是TCP缓冲区的编号(下标)

  • 序列号:表示本报文第一个字节的编号(在缓冲区的下标)。在TCP连接中,所传输的字节流的每一个字节都会按顺序编号
  • 确认号:在客户服务器模式中,当发送方给接收方发送数据,接收方只要接收到数据,必须给发送方发送确认报文。此时报文中的确认号,表示接收方期望收到发送方下一个报文的第一个字节的编号,相当于告诉发送方,这个序号之前的报文我都收到了。接收方收到数据后,根据序号给出确认序号,发送给发送方,发送方就知道接收方收到了哪些数据。确认号通常和序列号搭配使用。如下图

确认应答是一种特殊的报文(ACK),所谓应答报文,本质是ACK标志位字段为1的报文,此时“确认序号”字段才生效

初始序号是随机的,为了防止网络攻击;如果发送多个数据,每个数据都会带着一个序号。

和确认应答搭配使用的是捎带应答,即一方返回确认应答ACK报文时,也可以携带要发送给对方的数据。

比如客户端给服务器发送“How are you?”,接收方收到数据后,发送ACK确认报文,同时可以在报文中附上有效载荷(数据):“Fine,thank you”。


确认应答不仅让发送方知晓哪些报文收到了,还可以提高双方通信的效率

上图线性的通信效率较低,确认应答可以让双方一次性发送多个报文

发送方一次发送多个报文,接收方一次性接收并发送多个确认应答

即使中间的确认应答丢失:比如2001的确认应答丢失,但发送方只要接收到4001的确认应答,就代表4001前的报文,接收方都收到了;若1001~2000的报文丢失,那么接收方即使收到了后面的额2001~3000的报文,也只会给发送方返回1001的确认应答,如此发送方也能知晓1001~2000的报文丢失,进而使用接下来的策略——超时重传

二. 超时重传

确认应答是比较理想的情况,数据在网络传输中,是可能会丢包的。

报文如果成功送达接收方,接收方会发送确认报文,发送方就知道报文成功送达。但也可能出现如下两种情况:

  • 发送方的报文丢失
  • 接受方的确认报文丢失

这两种情况,发送方都不会收到接收方的确认报文。

TCP规定,在报文发送后的一个时间间隔后,如果还没收到确认报文,发送方一律认为报文丢失,重新发送该报文,这就是超时重传。

也有可能报文或确认报文因为网络拥塞而延迟送达对方主机,此时发送方也会超时重传,因此主机B会收到很多重复数据,那么TCP协议需要能够识别出哪些报文是重复的,并把重复的报文丢弃——根据报文的序列号就可以知道哪些报文是重复的

超时时间

超时时间如何确定呢?

  • 最理想的情况下,找到一个最小的时间,保证“确认应答一定能在这个时间内返回”
  • 但是这个时间的长短,随着网络环境的不同,是有差异的。
  • 如果超时时间设置太长,会影响整体的重传效率
  • 如果超时时间设置太短,可能会频繁发送重复的报文

TCP为了保证在任何环境下都能有比较高性能的通信,因此会动态计算这个最大超时时间

  • Linux中(BSD Unix和Windows也是如此),超时以500ms为一个单位进行控制,每次判定超时重传的超时时间都是500ms的整数倍
  • 如果重发一次之后,仍得不到应答,等待2*500ms后再进行重传
  • 如果仍得不到应答,等待4*500ms进行重传,以此类推,以指数形式递增
  • 累计到一定的重传次数,TCP认为网络或者对端主机出现异常,强制关闭连接

三. 滑动窗口

上述我们了解到,发送方可以一次性发送多个报文,那么报文数量是如何确定的呢?

在TCP报文中,有一个16位窗口大小,该字段反应了发送该报文的主机进程的接收缓冲区剩余大小,即接收能力。

在通信双方建立连接,进行三次握手时,就会通报对方自己的窗口大小——即接收能力,双方基于每次通信报文中的窗口大小,动态的调整自己将要发送给对方的报文数量。这就是滑动窗口的原理


1. 滑动窗口的实现

在发送缓冲区中,有编号,即序列号的存在。滑动窗口是根据对端发送的窗口大小,将发送缓冲区划分成三部分。

?滑动窗口就是可发送,未收到应答的部分。

  • 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值,上图的窗口大小就是4000字节(四个段)
  • 发送滑动窗口内的四个分段时,不需要等待任何ACK,直接发送。原先发送1~1000,要等待1001的确认报文,才能发送1001~2000。但在滑动窗口范围内的报文,可以不用收到ACK,直接发送。
  • 收到一个ACK后,滑动窗口向后移动,继续发送第五个段的数据,以此类推

  • 操作系统内核为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有哪些数据没有应答;只有确认应答过的数据,才能从缓冲区删掉(被后续数据覆盖)
  • 窗口越大,则网络的吞吐率越高

代码实现上

操作系统可以维护两个变量——win_start和win_end,表示滑动窗口开始的序号和结束的序号

在收到一个确认报文后,确认报文中的seq确认序号,指示发送方下一次发送的序号,窗口大小(win)指示滑动窗口的大小(目前)

2. 滑动窗口的相关问题(快重传)?

问题1:滑动窗口只能向右滑动吗?向左可以吗?

回答:只能向右。因为滑动窗口将发送缓冲区划分为三个部分,左边部分是已经发送的数据且受到应答,不应该再发送。


问题2:滑动窗口能变大吗?能变小吗?能变0吗,表示什么意思?

回答:滑动窗口的大小取决于对方通告的win大小,即窗口大小(目前),当然可以变大或变小。变0表示对方暂时不能接受数据,可能是接收缓冲区已满


问题3:滑动窗口能一直向右滑动吗?不会越界?

回答:发送缓冲区被设计成环形队列,所以可以一直向右滑动,滑动窗口左边的部分,也会在后续被新的数据覆盖


问题4:出现丢包问题,如何进行重传?

这里分两种情况讨论:

情况一:数据包到达对方数据,ACK确认报文丢失

此时,部分ACK丢失不要紧,因为可以通过后续的ACK进行确认。

即使ACK=2001的确认报文丢失,但发送方收到ACK=5001的确认报文,这就代表接收方5001前的报文都已收到

情况二:数据包丢失

?

  • 当某一段报文丢失后,发送方会一直收到1001这样的ACK。
  • 如果发送端主机连续三次收到同样一个“ACK=1001”这样的确认报文,就会立刻将1001~2000的报文重新发送
  • 此时,接收端收到1001~2000的报文后,再次返回的确认报文ACK=7001(7001前的报文全部收到)

这种机制被称为“高速重发机制”,也叫快重传

3. 延迟应答

如果接收数据的主机立刻返回ACK,此时返回的窗口可能比较小

  • 假设接收方缓冲区为1M,一次收到500K的数据,如果立刻应答,返回的窗口大小就是500K
  • 但实际上上层可能处理速度很快,10ms之内就把500K的数据从缓冲区消费掉了
  • 在这种情况,接收端还远远没有达到自己的极限,即使发送数据再多些也能处理过来
  • 所以如果接收端能稍等一会应答,可能可以返回更大的窗口大小

窗口越大,网络吞吐量越大,传输效率越高。

延迟应答一般有如下限制:

  • 数量限制:每隔N个包就应答一次
  • 时间限制:超过最大延迟时间就应答一次

具体数量和超时时间,不同操作系统各有不同,一般N取2,超时时间为200ms

四. 流量控制

接收端处理数据的速度是有限的,如果发送端发的太快,导致接收端的缓冲区被打满,此时如果发送端继续发送,就会造成丢包,继而引起丢包重传等等一系列连锁反应

因此TCP支持根据接收端的接受能力,来决定发送端的发送速度,这个机制就叫做“流量控制(Flow Control)”

  • 接收端将自己可以接受的缓冲区大小放入TCP首部中的“窗口大小”字段,通过ACK端通知发送端;
  • 窗口大小字段越大,网络的吞吐率越高
  • 接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端
  • 发送端接收这个窗口大小后,减慢自己的发送速度
  • 如果接收缓冲区满了,就会将窗口设置为0;此时发送方不再发送数据,但是需要定期发送一个窗口探测报文,知晓接收方的窗口大小

窗口字段为16位,最大表示65535字节,但其实窗口大小还可以更大

在TCP首部的选项字段,有一个窗口扩大因子M,实际窗口大小是,窗口字段的值左移M位,即2^(16+M)?字节

详细可参看:【计算机网络】TCP协议报头详解

五. 拥塞控制

滑动窗口既体现了TCP的可靠性,又提高了性能。但网络通信还需要考虑网络拥塞情况,所以TCP还需要拥塞控制。

网络中有很多主机,如果当前网络状态比较拥堵,在不清楚当前网络状态下,盲目根据接收方窗口大小发送数据,可能导致网络更为拥堵。

TCP引入慢启动机制——先发送少量数据,探测网络信道状态,了解当前网络拥堵情况,再决定按照多大的速度传输数据

此处引入一个概念——拥塞窗口,其大小为swnd

慢开始的思路是

  • 刚开始将cwnd设置成为一个MSS的数值,每经过一个传输轮次cwnd就加倍传输轮次:拥塞窗口所允许的发送的报文都连续发出去,且收到了对已发送的最后一个字节的确认
  • 因为是加倍(指数)增长,为了防止增长过度,引起网络阻塞,还设置一个慢开始门限(阈值)ssthresh。当cwnd超过ssthresh时,就改为拥塞避免算法,也就是线性缓慢增长
  • 当TCP开始启动时,慢启动阈值等于窗口最大值
  • 在每次超时重传后,慢启动阈值会变成检测到网络拥塞时的窗口大小的一半,同时将拥塞窗口cwnd设置为1

少量的丢包,触发超时重传;大量的丢包,认为是网络拥塞。当TCP通信开始后,网络吞吐量会逐渐上升,随着网络发生拥堵,吞吐量会立刻下降


注意:发送方的发送窗口,会根据接收方反馈的接收窗口和自身维护的拥塞窗口,取较小值作为实际发送的窗口大小

六. 面向字节流&粘包问题

面向字节流

创建一个TCP的socket,同时在内核中创建一个发送缓冲区和接收缓冲区

  • 调用write,数据会先写入发送缓冲区
  • 如果发送的数据太长,会被拆分成多个TCP数据包
  • 如果发送的字节数太短,就会先在缓冲区里等待,等到缓冲区长度差不多,或者其他合适的时机发出
  • 接收数据时,数据也是从网卡驱动程序到达内核的接收缓冲区
  • 然后应用程序可以调用read从接收缓冲区拿数据
  • 另一方面,TCP的一个连接,既有发送缓冲区,也有接收缓冲区。可以同时读写数据,这个概念叫做全双工

由于缓冲区的存在,TCP程序的读和写不需要一一匹配。

  • 写100个字节数据时,可以调用一次write写100个字节,也可以调用100次write,每次写一个字节;
  • 读100个字节数据时,也完全不需要考虑写的时候是怎么写的,既可以一次read 100个字节,也可以一次read一个字节,重复100次;

粘包问题

粘包问题中的"包" ,指的是应用层的数据包。在TCP的协议头中,没有如同UDP一样的"报文长度"这样的字段,但是有一个序号这样的字段。

  • 站在传输层的角度, TCP是一个一个报文过来的.按照序号排好序放在缓冲区中。
  • 站在应用层的角度,看到的只是一串连续的字节数据。那么应用程序看到了这么一连串的字节数据,就不知道从哪个部分开始到哪个部分,是一个完整的应用层数据包。

不同数据粘连,就是粘包问题

明确两个包之间的边界,是避免粘包问题的根本:

  • 对于定长的包,保证每次都按固定大小读取即可;
  • 对于变长的包,可以在包头的位置,约定一个包总长度的字段,从而就知道了包的结束位置;
  • 对于变长的包,还可以在包和包之间使用明确的分隔符(应用层协议,是程序猿自己来定的,只要保证分隔符不和正文冲突即可);

注意:对于UDP协议,不存在粘包问题,因为UDP报头中有总长度,并且UDP是面向数据报的,有明确的数据边界。站在应用层的角度,使用UDP时,要么收到完整的UDP报文,要么不收,不会出现“半个报文”的情况

TCP小结

TCP协议可靠性机制有:

  • 校验和
  • 序列号(按序到达)
  • 确认应答
  • 超时重传
  • 连接管理
  • 流量控制
  • 拥塞控制

提高性能:

  • 滑动窗口
  • 快重传
  • 延迟应答
  • 捎带应答

其他:

定时器(超时重传定时器,保活定时器(连接),TIME_WAIT定时器等)

保活计时器和TIME_WAIT计时器可参看:【计算机网络】连接管理(三次握手,四次挥手)


基于TCP的应用层协议:HTTP,HTTPS,SSH,Telnet,FTP,SMTP。

结束语

本篇博客到此结束,感谢看到此处。
欢迎大家纠错和补充
如果觉得本篇文章对你有所帮助的话,不妨点个赞支持一下博主,拜托啦,这对我真的很重要。

文章来源:https://blog.csdn.net/m0_72563041/article/details/135006494
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。