传输层 流量控制 使用滑动窗口实现流量控制

滑动窗口机制

---

流量缓冲：解决速度不匹配问题（客户端和服务器，这两端的速度是完全不一致的，机器性能不一致，这个时候处理的速度是不配的）

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。

TCP会话的双方都各自维护一个发送窗口和一个接收窗口。接收窗口大小取决于应用、系统、硬件的限制。发送窗口则取决于对端通告的接收窗口。

接收方发送的确认报文中的window字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。

将接收方的确认报文window字段设置为 0，则发送方不能发送数据。

TCP头包含window字段，16bit位，它代表的是窗口的字节容量，最大为65535。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。接收窗口的大小是约等于发送窗口的大小。

从之前可以了解到，发送窗口分为4个部分，接受窗口当中的数据分为3个部分。

发送和接受窗口都和操作系统的缓冲区是相关的，也和进程读取缓冲区的速度也有关系，为了方便理解这里也假设窗口不会发生变化。

窗口滑动示例：MSS 不产生影响，窗口不变。

这里有个客户端和服务器，客户端的发送窗口是360字节，所以服务器端的接受窗口也是360个字节，还有客户端的接受窗口是200字节，因此服务器的发送窗口是200字节。

初始的seq让客户端从1开始，服务器让其从241开始。

客户端要发送一个请求，比如http的一个get请求，这个请求是140个字节，因此它的send.next就要从1变为141，因为加了140个字节，发送到服务器，服务器第二步终于接收到，接收到以后就要返回一个响应，假设相应是有80字节的header，还有280字节的body，假设是一个文件，首先发送80个字节的头部，并且告诉客户端这140字节我已经收到了，我还要发一个ack，要完成这两件事，它的发送窗口和接受窗口都会发生变化，接受窗口当中的next从1变为141，因为收到了140个字节，但是我的接受窗口没变，依然是360，这个时候假定应用进程快速的从内核缓冲区把这140个字节读取出来了，所以360没有发生变化，然后又发送了80个字节的header，因此send next从241加上80等于等于321，发送窗口让人没有发生变化。

到了第三步的时候，客户端收到了80个字节，因此接受窗口从241变为321，它同时也收到了ack，那个ack说我收到了140个字节，所以它会告诉确认ack的seq为141。因此客户端的send next，也就是已发送，但是未确认的字节数变为141，

客户端消息发送

---

 客户端要发送消息，最初发送窗口是360个字节，可用窗口也是360个字节，但是发送了140字节请求之后呢？那么可用窗口就要减少为220个字节了，这样next就指向了141，当收到140个字节确认的ack之后，就将una往后移动140个字节，那么可用窗口又变为了360个字节了。

流量控制是指发送端给接收端发的太快了，接收端可以告诉它发慢点。（滑动窗口实现流量控制，流量控制是接收方控制发送方）

接收端设置窗口，发送端根据接收端的窗口来设置发送窗口，在整个通信过程当中窗口是可以调整的。

在上面建立连接的时候就有窗口字段64240个字节，最大的数据段为1460，网卡的最大传输单元MTU数据链路层的最大传输单元是1500个字节，网络层的首部为20个字节，传输层的首部是20个字节，那么数据就变为1460个字节。那么滑动窗口64240/1460就可以连续发44个数据包。

同时还可以支持选择性确认SACK_PERM=1。

在建立TCP连接的时候就可以协商这些参数，接收窗口是多大，MSS是多少，然后支持选择性确认。

确认里面数据的长度都是为0的，在给确认的时候就指定了窗口的大小，可以看到窗口是可以调整大小的。接受窗口变小那么发送窗口也随之变小，发送端发的就不那么快了。

 b告诉a，它的接受窗口是400，段最大为100个字节，在发的时候1 2到了 3丢了，给它确认，让它发送第三个数据包，然后窗口开始移动，然后发第4 5个再发第3个，收到之后给它确认。。。。。。。。

窗口变为0之后就不再发了，发送端就停止了，处理之后再发确认，窗口再调整为400。