传输层 --------- TCP( 二 )

最新推荐文章于 2024-07-19 16:09:28 发布

GSX_M

最新推荐文章于 2024-07-19 16:09:28 发布

阅读量781

点赞数 3

分类专栏：计算机网络文章标签：网络 tcp/ip 网络协议服务器

本文链接：https://blog.csdn.net/m0_52169086/article/details/125825300

版权

计算机网络专栏收录该内容

15 篇文章 2 订阅

订阅专栏

9.流量控制 (通信双方控制)

(1)TCP支持根据接收端的接收数据的能力来决定发送端发送数据的速度，这个机制叫做流量控制（Flow Control）。

(2)接收端处理数据的速度是有限的，如果发送端发的太快，导致接收端的缓冲区被打满，此时发送端继续发送数据，就会造成丢包，进而引起丢包重传等一系列连锁反应。因此接收端可以将自己接收数据的能力告知发送端，让发送端控制自己发送数据的速度。

接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK通知发送端。
窗口大小字段越大，说明网络的吞吐量越高。
接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端。
发送端接收到这个窗口之后，就会减慢自己发送的速度。(如何减慢？滑动窗口)
如果接收端缓冲区满了，就会将窗口值设置为0，这时发送方不再发送数据，但需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

(3)当发送端得知接收端接收数据的能力为0时会停止发送数据，此时发送端会通过以下两种方式来得知何时可以继续发送数据。

等待告知。接收端上层将接收缓冲区当中的数据读走后，接收端向发送端发送一个TCP报文，主动将自己的窗口大小告知发送端，发送端得知接收端的接收缓冲区有空间后就可以继续发送数据了。
主动询问。发送端每隔一段时间向接收端发送报文，该报文不携带有效数据，只是为了询问发送端的窗口大小，直到接收端的接收缓冲区有空间后发送端就可以继续发送数据了。

(4)16为数字最大表示65535，那TCP窗口最大就是65535吗

理论上确实是这样的，但实际上TCP报头当中40字节的选项字段中包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位得到的。

(5)第一次向对方发送数据时如何得知对方的窗口大小

双方在进行TCP通信之前需要先进行三次握手建立连接，而双方在握手时除了验证双方通信信道是否通畅以外，还进行了其他信息的交互，其中就包括告知对方自己的接收能力，因此在双方还没有正式开始通信之前就已经知道了对方接收数据能力，所以双方在发送数据时是不会出现缓冲区溢出的问题的。

10.滑动窗口

连续发送数据

双方在进行TCP通信时可以一次向对方发送多条数据，这样可以将等待多个响应的时间重叠起来，进而提高数据通信的效率
虽然双方在进行TCP通信时可以一次向对方发送大量的报文，但不能将自己发送缓冲区当中的数据全部打包发送给对端，在发送数据时还要考虑对方的接收能力

滑动窗口

(1)为什么主机不一次把数据全部发送过去?

虽然一次可以发送很多但是要考虑接收方的接受能力，即接受缓冲区的大小。建立连接的时候会交换双方的窗口(接受缓冲区)大小。

(2)发送方可以一次发送多个报文给对方，此时也就意味着发送出去的这部分报文当中有相当一部分数据是暂时没有收到应答的。

其实可以将发送缓冲区当中的数据分为三部分，这里发送缓冲区的第二部分就叫做滑动窗口。（也有人把这三部分整体称之为滑动窗口，而将其中的第二部分称之为窗口大小)

(3)窗口协商

TCP 头里有一个字段叫Window，也就是窗口大小。
这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。
通常窗口的大小是由接收方的窗口大小来决定的。
发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。

(4)发送数据示例

A根据B给出的窗口值，构造出自己的发送窗口。
发送窗口表示:在没有收到B的确认时，A可连续把窗口内的数据都发送出去。
发送窗口里面的序号表示允许发送的序号。
接收窗口:只允许接收落入窗口内的数据。
窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。

①现在假定A发送了序号为31 - 41的数据

②描述发送窗口的状态需要三个指针p1,p2,p3 ; 指针都指向字节的序号

P1=后沿，P2=当前，P3=前沿。
p1之前的数据是已发送并受到确认
p3之后的数据是不允许发送的部分
P3 - P1=A的发送窗口（又称为通知窗口) = 20
P2 - P1=已发送但尚未收到确认的字节数 (可以理解为滑动窗口)
P3 - P2=允许发送但尚未发送的字节数（又称为可用窗口)

③ B收到了序号为32和33的数据，但未收到序号为31的数据。因此发送的确认报文段中的确认号是31（即期望收到的序号)。

④假定B受到序号为31的数据，把序号为31-33的数据交付给上层应用, 删除这些数据，把接收窗口向前移动3个序号，同时给A发送确认 , 窗口值仍为20，但是确认号为34. 表明B已经收到序号34之前的数据。B还收到了序号37,38,40 的数据，但是没有按序到达，只能暂存在接收窗口中。A 收到B的确认后可以把发送窗口向前滑动3个序号，但是指针P2不动 , 此时A的可用窗口增大.

⑤如果A的发送窗口已满，可用窗口减小到0，必须停止发送.

A未收到确认的原因有:① B未发送; ②B已发送，但还未到达A。
为保证可靠传输，A只能认为B还没有收到这些数据。A经过一段时间后(由超时计时器控制）就重传这部分数据，重新设置超时计时器，直到收到B的确认为止。
若A按序收到落在发送窗口内的确认号，就使发送窗口向前滑动，并发送新的数据。

(5)缓存和窗口

(6)强调两点

虽然A的发送窗口是根据B的接收窗口设置的，但是在同一时刻，A,B的窗口大小并不一样. 因为通过网络传输是有一定的滞后。另外，发送方A还可能根据网络当时的拥塞情况适当减小自己的发送数值.
对于不按序到达的数据TCP标准并未明确规定. 如果把这些数据丢弃，那么接收窗口的管理将会比较简单，但是对网络资源的利用不高。因此TCP通常把不按序到达的数据先临时存放在接收窗口中，等到字节流中缺少的字节收到后，再按序交付给上层应用.

(7)快重传

①丢ACK

在发送端连续发送多个报文数据时，部分ACK丢包并不要紧，此时可以通过后续的ACK进行确认。

②丢数据包

当1001-2000的数据包丢失后，发送端会一直收到确认序号为1001的响应报文，就是在提醒发送端“下一次应该从序号为1001的字节数据开始发送”。
如果发送端连续收到三次确认序号为1001的响应报文，此时就会将1001-2000的数据包重新进行发送。
此时当接收端收到1001-2000的数据包后，就会直接发送确认序号为6001的响应报文，因为2001-6000的数据接收端其实在之前就已经收到了。

③这种机制被称为“高速重发控制”，也叫做“快重传”。

需要注意的是，快重传需要在大量的数据重传和个别的数据重传之间做平衡，实际这个例子当中发送端并不知道是1001-2000这个数据包丢了，当发送端重复收到确认序号为1001的响应报文时，理论上发送端应该将1001-7000的数据全部进行重传，但这样可能会导致大量数据被重复传送，所以发送端可以尝试先把1001-2000的数据包进行重发，然后根据重发后的得到的确认序号继续决定是否需要重发其它数据包。

④既然有了快重传，为什么还有超时重传

快重传是用来解决大量数据发送时，某一块数据未收到的问题，当滑动窗口 < 3时接收的ACK不足3个，就无法触发块重传只能使用超时重传，超时重传是一个兜底的。他俩相互补充

(8)允许发送但是尚未发送是什么意思

数据报文发送是一个个发的,
滑动窗口的大小受拥塞窗口的影响，即网络的状况，如果网络状态差一下子发送太多使网络更差.

11.拥塞控制(多方控制)

(1)为什么会有拥塞控制？

①两个主机在进行TCP通信的过程中，出现个别数据包丢包的情况是很正常的，此时可以通过快重传或超时重发对数据包进行补发。但如果双方在通信时出现了大量丢包，此时就不能认为是正常现象了。

②TCP不仅考虑了通信双端主机的问题，同时也考虑了网络的问题。

流量控制：考虑的是对端接收缓冲区的接收能力，进而控制发送方发送数据的速度，避免对端接收缓冲区溢出。
滑动窗口：考虑的是发送端不用等待ACK一次所能发送的数据最大量，进而提高发送端发送数据的效率。
拥塞窗口：考虑的是双方通信时网络的问题，如果发送的数据超过了拥塞窗口的大小就可能会引起网络拥塞。

③双方网络通信时出现少量的丢包TCP是允许的，但一旦出现大量的丢包，此时量变引起质变，这件事情的性质就变了，此时TCP就不再推测是双方接收和发送数据的问题，而判断是双方通信信道网络出现了拥塞问题。

(2)如何解决网络拥塞问题？

网络出现大面积瘫痪时，通信双方作为网络当中两台小小的主机，看似并不能为此做些什么，但“雪崩的时候没有一片雪花是无辜的”，网络出现问题一定是网络中大部分主机共同作用的结果。
大家遵守的协议是—样的，当网络情况很差收不到数据会进行超时重传，大家都重传，这时会有大量数据进入网络，会进一步加重网络拥堵。
当网络出现拥塞问题时，通信双方虽然不能提出特别有效的解决方案，但双方主机可以做到不加重网络的负担。
双方通信时如果出现大量丢包，不应该立即将这些报文进行重传，而应该少发数据甚至不发数据，等待网络状况恢复后双方再慢慢恢复数据的传输速率。
需要注意的是，网络拥塞时影响的不只是一台主机，而几乎是该网络当中的所有主机，此时所有使用TCP传输控制协议的主机都会执行拥塞避免算法。
因此拥塞控制看似只是谈论的一台主机上的通信策略，实际这个策略是所有主机在网络崩溃后都会遵守的策略。一旦出现网络拥塞，该网络当中的所有主机都会受到影响，此时所有主机都要执行拥塞避免，这样才能有效缓解网络拥塞问题。通过这样的方式就能保证雪崩不会发生，或雪崩发生后可以尽快恢复。

(3)慢启动和拥塞窗口

①虽然滑动窗口能够高效可靠的发送大量的数据，但如果在刚开始阶段就发送大量的数据，就可能会引发某些问题。因为网络上有很多的计算机，有可能当前的网络状态就已经比较拥塞了，因此在不清楚当前网络状态的情况下，贸然发送大量的数据，就可能会引起网络拥塞问题。

②因此TCP引入了慢启动机制，在刚开始通信时先发少量的数据探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。

③拥塞窗口

TCP除了有窗口大小和滑动窗口的概念以外，还有一个窗口叫做拥塞窗口。拥塞窗口是可能引起网络拥塞的阈值，如果一次发送的数据超过了拥塞窗口的大小就可能会引起网络拥塞。
刚开始发送数据的时候拥塞窗口大小定义以为1，每收到一个ACK应答拥塞窗口的值就+1(单位是 MSS，最大单个报文段长度）)
每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小做比较，取较小的值作为实际发送数据的窗口大小，即滑动窗口的大小。
滑动窗口 = min(对方接收能力(对方主机)，自己拥塞窗口大小(网络))

④每收到一个ACK应答拥塞窗口的值就加一，此时拥塞窗口就是以指数级别进行增长的 但指数级增长是非常快的，因此“慢启动”实际只是初始时比较慢，但越往后增长的越快。如果拥塞窗口的值一直以指数的方式进行增长，此时就可能在短时间内再次导致网络出现拥塞。

先要确认网络是否通畅，会不会在少量数据的情况下，依旧会丢包
慢慢考虑尽快恢复我们的通信速度
最后在网络条件良好情况下正常，快速通信.

⑤为了避免短时间内再次导致网络拥塞，因此不能一直让拥塞窗口按指数级的方式进行增长。此时就引入了慢启动的阈值，当拥塞窗口的大小超过这个阈值时，就不再按指数的方式增长，而按线性的方式增长。

当TCP刚开始启动的时候，慢启动阈值设置为对方窗口大小的最大值。
在每次超时重发的时候，慢启动阈值会变成当前拥塞窗口的一半，同时拥塞窗口的值被重新置为1，如此循环下去。

⑥图示说明：

指数增长。刚开始进行TCP通信时拥塞窗口的值为1，并不断按指数的方式进行增长。
加法增大。慢启动的阈值初始时为对方窗口大小的最大值，图中慢启动阈值的初始值为16，因此当拥塞窗口的值增大到16时就不再按指数形式增长了，而变成了的线性增长。
乘法减小。拥塞窗口在线性增长的过程中，在增大到24时如果发生了网络拥塞，此时慢启动的阈值将变为当前拥塞窗口的一半，也就是12，并且拥塞窗口的值被重新设置为1，所以下一次拥塞窗口由指数增长变为线性增长时拥塞窗口的值应该是12。

⑦每台主机拥塞窗口的大小不一定是一样的，即便是同区域的两台主机在同一时刻认为拥塞窗口的大小也不一定是完全相同的。因此在同一时刻，可能一部分主机正在进行正常通信，而另一部分主机可能已经发生网络拥塞了。

⑧示例

当 TCP连接已建立后，把拥塞窗口 cwnd 置为1。在本例中，慢开始门限的初始值设置为16个报文段，即ssthresh = 16。在执行慢开始算法阶段，每经过一个往返时间 RTT，拥塞窗口cwnd就加倍。当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh时（图中的点①，此时拥塞窗口cwnd = 16），就改为执行拥塞避免算法，拥塞窗口按线性规律增长。但请注意，“拥塞避免”并非完全避免拥塞，而是让拥塞窗口增长得缓慢些，使网络不容易出现拥塞。
当拥塞窗口cwnd =24 时，网络出现了超时（图中的点②），这就是网络发生拥塞的标志。于是调整门限值 ssthresh=cwnd/2=12，同时设置拥塞窗口 cwnd=1，执行慢开始算法。
按照慢开始算法，发送方每收到一个对新报文段的确认 ACK，就把拥塞窗口值加 1。当拥塞窗口 cwnd = ssthresh = 12时（图中的点③，这是 ssthresh 第 1 次调整后的数值），改为执行拥塞避免算法，拥塞窗口按线性规律增大。
有时，个别报文段会在网络中意外丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，并误认为网络发生了拥塞。这就导致发送方错误地启动慢开始，把拥塞窗口 cwnd 又设置为1，因而不必要地降低了传输效率。
当拥塞窗口cwnd=16时（图中的点④），出现了一个新的情况，就是发送方一连收到3个对同一个报文段的重复确认（图中记为3-ACK）。关于这个问题要解释如下。)
采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
因此，在图中的点④，发送方现在只是丢失了个别报文段。于是不启动慢开始，而是执行快恢复算法。这时发送方第二次调整门限值, 使ssthresh = cwnd / 2 = 8 ，同时设置拥塞窗口cwnd = ssthresh = 8 , 开始执行拥塞避免算法.

⑨TCP拥塞控制流程图

(7)小结

①为什么叫慢启动，指数级增长是很快的?

指数级增长刚开始是慢的。让网络中的数据消散一下。

②为什么到了中间部分不能再指数级增长而是线性增长?

指数级增长到了后半段它的增长幅度特别大，你这样做，所有人都这样做,到时网络短期之内涌满了大量的数据。

③即便是线性增长那也不能一直增长吧?

不会一直增长下去，因为当你的拥塞窗口再增长 >= 流量控制对方的接收能力时，你的拥塞窗口就没有意义了，这时我们看的是对方的接收能力。

12.延迟应答

(1)如果接收数据的主机收到数据后立即进行ACK应答，此时返回的窗口可能比较小。

假设对方接收端缓冲区剩余空间大小为1M，对方一次收到500K的数据后，如果立即进行ACK应答，此时返回的窗口就是500K。
但实际接收端处理数据的速度很快，10ms之内就将接收缓冲区中500K的数据消费掉了。
在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来。
如果接收端稍微等一会再进行ACK应答，比如等待200ms再应答，那么这时返回的窗口大小就是1M。

(2)需要注意的是，延迟应答的目的不是为了保证可靠性，而是留出一点时间让接收缓冲区中的数据尽可能被上层应用层消费掉，此时在进行ACK响应的时候报告的窗口大小就可以更大，从而增大网络吞吐量，进而提高数据的传输效率。

(3)此外，不是所有的数据包都可以延迟应答。

数量限制：每个N个包就应答一次。
时间限制：超过最大延迟时间就应答一次（这个时间不会导致误超时重传）。

延迟应答具体的数量和超时时间，依操作系统不同也有差异，一般N取2，超时时间取200ms。

13.捎带应答

(1) 捎带应答其实是TCP通信时最常规的一种方式，就好比主机A给主机B发送了一条消息，当主机B收到这条消息后需要对其进行ACK应答，但如果主机B此时正好也要给主机A发生消息，此时这个ACK就可以搭顺风车，而不用单独发送一个ACK应答，此时主机B发送的这个报文既发送了数据，又完成了对收到数据的响应，这就叫做捎带应答。

(2)捎带应答最直观的角度实际也是发送数据的效率，此时双方通信时就可以不用再发送单纯的确认报文了。

(3)此外，由于捎带应答的报文携带了有效数据，因此对方收到该报文后会对其进行响应，当收到这个响应报文时不仅能够确保发送的数据被对方可靠的收到了，同时也能确保捎带的ACK应答也被对方可靠的收到了。

14.面向字节流

(1)当创建一个TCP的socket时，同时在内核中会创建一个发送缓冲区和一个接收缓冲区。

调用write函数就可以将数据写入发送缓冲区中，此时write函数就可以进行返回了，接下来发送缓冲区当中的数据就是由TCP自行进行发送的。
如果发送的字节数太长，TCP会将其拆分成多个数据包发出。如果发送的字节数太短，TCP可能会先将其留在发送缓冲区当中，等到合适的时机再进行发送。
接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区，可以通过调用read函数来读取接收缓冲区当中的数据。
而调用read函数读取接收缓冲区中的数据时，也可以按任意字节数进行读取。

(2)由于缓冲区的存在，TCP程序的读和写不需要一一匹配，例如：

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

(3)实际对于TCP来说，它并不关心发送缓冲区当中的是什么数据，在TCP看来这些只是一个个的字节数据，它的任务就是将这些数据准确无误的发送到对方的接收缓冲区当中就行了，而至于如何解释这些数据完全由上层应用来决定，这就叫做面向字节流。

15.粘包问题

(1)什么是粘包？

首先要明确，粘包问题中的“包”，是指的应用层的数据包。
在TCP的协议头中，没有如同UDP一样的“报文长度”这样的字段。
站在传输层的角度，TCP是一个一个报文过来的，按照序号排好序放在缓冲区中。
但站在应用层的角度，看到的只是一串连续的字节数据。
那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包。

(2)如何解决粘包问题

要解决粘包问题，本质就是要明确报文和报文之间的边界(应用层）。
对于定长的包，保证每次都按固定大小读取即可。
对于变长的包，可以在报头的位置，约定一个包总长度的字段，从而就知道了包的结束位置。比如HTTP报头当中就包含Content-Length属性，表示正文的长度。
对于变长的包，还可以在包和包之间使用明确的分隔符。因为应用层协议是程序员自己来定的，只要保证分隔符不和正文冲突即可。

(3)UDP是否存在粘包问题？

对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在，同时，UDP是一个一个把数据交付给应用层的，有很明确的数据边界。
站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收，不会出现“半个”的情况。
因此UDP是不存在粘包问题的，根本原因就是UDP报头当中的16位UDP长度记录的UDP报文的长度，因此UDP在底层的时候就把报文和报文之间的边界明确了，而TCP存在粘包问题就是因为TCP是面向字节流的，TCP报文之间没有明确的边界。

16.TCP异常问题

(1)进程终止

当客户端正常访问服务器时，如果客户端进程突然崩溃了，此时建立好的连接会怎么样？
当一个进程退出时，该进程曾经打开的文件描述符都会自动关闭，因此当客户端进程退出时，相当于自动调用了close函数关闭了对应的文件描述符，此时双方操作系统在底层会正常完成四次挥手，然后释放对应的连接资源。也就是说，进程终止时会释放文件描述符，TCP底层仍然可以发送FIN，和进程正常退出没有区别。

(2)机器重启

当客户端正常访问服务器时，如果将客户端主机重启，此时建立好的连接会怎么样？
当我们选择重启主机时，操作系统会先杀掉所有进程然后再进行关机重启，因此机器重启和进程终止的情况是一样的，此时双方操作系统也会正常完成四次挥手，然后释放对应的连接资源。

(3)机器掉电/网线断开

当客户端正常访问服务器时，如果将客户端突然掉线了，此时建立好的连接会怎么样？
当客户端掉线后，服务器端在短时间内无法知道客户端掉线了，因此在服务器端会维持与客户端建立的连接，但这个连接也不会一直维持，因为TCP是有保活策略的。
服务器会定期询问客户端的存在状况，检查对方是否在线，如果连续多次都没有收到ACK应答，此时服务器就会关闭这条连接。
此外，客户端也可能会定期向服务器“报平安”，如果服务器长时间没有收到客户端的消息，此时服务器也会将对应的连接关闭。
其中服务器定期询问客户端的存在状态的做法，叫做基于保活定时器的一种心跳机制，是由TCP实现的。此外，应用层的某些协议，也有一些类似的检测机制，例如基于长连接的HTTP，也会定期检测对方的存在状态。

17.TCP小结

(1)保证可靠性机制：

检验和。
序列号。
确认应答。
超时重传。
连接管理。
流量控制。
拥塞控制。

(2)提高性能机制：

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

(3)TCP的这些机制有些能够通过TCP报头体现出来的，但还有一些是通过代码逻辑体现出来的。

(4)TCP定时器

重传定时器：为了控制丢失的报文段或丢弃的报文段，也就是对报文段确认的等待时间。
坚持定时器：专门为对方零窗口通知而设立的，也就是向对方发送窗口探测的时间间隔。
保活定时器：为了检查空闲连接的存在状态，也就是向对方发送探查报文的时间间隔。
TIME_WAIT定时器：双方在四次挥手后，主动断开连接的一方需要等待的时长。

(5)理解传输控制协议

TCP的各种机制实际都没有谈及数据真正的发送，这些都叫做传输数据的策略。TCP协议是在网络数据传输当中做决策的，它提供的是理论支持，比如TCP要求当发出的报文在一段时间内收不到ACK应答就应该进行超时重传，而数据真正的发送实际是由底层的IP和MAC帧完成的。
TCP做决策和IP+MAC做执行，我们将它们统称为通信细节，它们最终的目的就是为了将数据传输到对端主机。而传输数据的目的是什么则是由应用层决定的。因此应用层决定的是通信的意义，而传输层及其往下的各层决定的是通信的方式。

(6)用UDP实现可靠传输(经典面试题)

现在的直播平台使用的使用UDP和TCP混用，规避各自的缺点

参考TCP的可靠性机制, 在应用层实现类似的逻辑; 问一下具体的场景

例如: