【你问我答】TCP怎么做流量控制？

TCP流量控制(滑动窗口协议) TCP报文头有个窗口(windows)字段，接收方在返回ACK报文之前会根据自己的空间大小动态调整接收窗口大小，并改写windows的字段，用于控制对方发送窗口大小； 发送窗口的上限为接受窗口和拥塞窗口中的较小值。接受窗口表明了接收方的接收能力，拥塞窗口表明了网络的传送能力。 (零窗口：发送方停止发送数据，只能发送探测数据包)

TCP是一种可靠的，面向连接的传输层协议。 存在的问题：TCP能够传输的数据越快越好。但如果发送方数据发送的非常快，而且接收方耗尽自己的资源也根本来不及接收，那这些多余的数据就会被丢弃，这就违背了TCP可靠的宗旨了。 方案的提出：引入一种流量控制的手段：让发送方不要发送太快，既让接收方能够顺利接收数据，而且也不会造成网络链路的阻塞。 一、滑动窗口的方式 接收方控制发送方的数据大小，每次应答时通知发送方自己还剩下多少可接受数据的空间。窗口标记了接受方缓冲区的大小，窗口的大小决定了一次能发送多少数据量，该窗口可以滑动。 二、延迟ACK 如果TCP对每个数据包都发送一个ACK确认，那么会造成性能上的损失，所以TCP会延迟一段时间，如果这段时间内有数据发送到对端，则稍带发送ACK，如果在延迟ACK定时器触发时候，发现ACK尚未发送，则单独发送。该方式可以避免糊涂窗口和减少流量消耗。

我们都知道TCP是一种可靠的，面向连接的传输层协议。我们总是希望TCP能够传输的数据越快越好。如果存在这样一种情况，发送方数据发送的非常快，而且接收方耗尽自己的资源也根本来不及接收，那这些多余的数据就会被丢弃，这就违背了TCP可靠的宗旨了。 所以就需要引入一种流量控制的手段：让发送方不要发送太快，既让接收方能够顺利接收数据，而且也不会造成网络链路的阻塞。 思路 沿着这个思路：让发送方不要发送的太快。那就让接收方控制发送方的数据大小，每次应答的时候通知发送方自己还剩多少空间可以接收数据。当然实际交互没有这么的简单，只是提供了一种思路。利用这种思路，诞生了滑动窗口的方式。 滑动窗口 滑动窗口类似一个窗口，是用来告诉发送方可以发送数据的大小。也可以说是窗口标记了接收方缓冲区的大小。窗口大小也就表示一次能发送多少数据量，而且这个窗口可以滑动，滑动窗口因此得名。 怎样告知发送方窗口大小? 怎样通知发送方窗口大小呢?难道要重新发送一包数据告诉对方吗，这显然是不合理的。可以巧妙的使用确认应答包。有了确认应答包还是不够，如果是***次交互呢?所以还需要在三次握手时候，就需要告知对方。(rwnd表示接收窗口) https://s3.51cto.com/oss/201907/02/ea266ab5a8cf75410275e5787944fa14.jpg-wh_600x-s_628978497.jpg 在原来的确认应答策略中，每一次发送数据，都需要Ack应答，在接收到Ack之后才会发送下一个数据段，发送方没有接收到Ack应答呢?这样做的方式效率实在太低。使用了滑动窗口，可以多次发送数据，只要不要超过对方窗口大小。这样就大大提高了效率。

TCP流量控制，简单来说就是让数据传输端传输的速率不要太快，让数据接收端来得及接收，利用滑动窗口机制可以很方便的在TCP连接上实现对数据传输端的流量控制。TCP的窗口单位是字节，不是报文段，数据传输端的发送窗口不能超过接收端给出的接收窗口的数值，流量控制的机制是控制丢包率，主要目的：让数据传输端了解数据接收端当前的接收能力，可灵活调整传输速率。 滑动窗口：TCP采用大小可变的滑动窗口进行流量控制，窗口大小的单位是字节。数据传输窗口在连接建立时由双方商定。但在通信的过程中，数据接收端可根据自己的资源情况，随时动态地调整对方的传输窗口大小。 滑动窗口引进原由：把窗口理解为缓冲区（但是有些窗口和缓冲区又不太一样）。如果没有这些“窗口”，那么TCP每发送一段数据后都必须等到数据接收端确认后才能发送下一段数据，这样做的话TCP传输的效率实在是太低了。解决的办法就是在发送端等待确认的时候继续发送数据，假设发送到第X个数据段是收到数据接收端的确认信息，如果X在可接受的范围内那么这样做也是可接受的。 滑动窗口： A、数据接收端窗口 X 接收端缓冲区大小。接收端将此窗口值放在 TCP 报文的首部中的窗口字段，传送给发送端。 B、拥塞窗口 Y 发送端缓冲区大小 C、数据传输窗口 Z 发送窗口的上限值 = Min [X, Y] ① 当 X < Y 时，是接收端的接收能力限制数据传输窗口的最大值。 ② 当 Y < X 时，则是网络的拥塞限制数据传输窗口的最大值。