LinuxEye - Linux系统教程

LinuxEye - Linux系统教程

当前位置: 主页 > Linux教程 >

TCP滑动窗口和流控

时间:2015-02-26 10:19来源:firefoxbug.com 编辑:firefoxbug 点击:
TCP的滑动窗口是一个很重要的概念,也是很晦涩的一个知识点。下面就大概介绍下TCP滑动窗口为什么出现?它是怎么工作的的? 什么是TCP窗口 首先,要理解,client和server各自协议栈都

TCP的滑动窗口是一个很重要的概念,也是很晦涩的一个知识点。下面就大概介绍下TCP滑动窗口为什么出现?它是怎么工作的的?

什么是TCP窗口

首先,要理解,client和server各自协议栈都有自己的buffer,应用层读写数据的源都是协议栈buffer里。以接收端为例,应用程 序调用read()时,会从buffer里移走数据到用户空间,应用程序读的速度越快(read(1024)必然比read(1)要快),那么 buffer里的内容消费的越快,buffer也会越空。那么TCP就可以告诉client,我现在很闲,你可以发送更多的数据来。"更多"是多少?这就 说窗口,窗口就是量化接收端和服务端当前能处理数据的能力。

TCP窗口是如何工作的

client和server端建立连接后,client会告诉server,自己的"接收窗口"大小(自己能接收多少的数据,受上面所说的 buffer影响),server端接收到client的"接收窗口"大小,就会变成server端自己的"发送窗口"大小。同样的,server端告诉 client自己的"接收窗口"大小,就会变成客户端的"发送窗口"大小。

为了理解TCP的窗口大小是怎么样变化的,我们先需要理解它的含义。最简单的方式就是认为窗口大小"意味着接收方能接收数据的大小",这也是说接收 端设备再应用程序读取buffer中数据之前,能从对端连接处理多少数据。比如说server端窗口大小是360,那么就意味着server端一次只能从 客户端接收不超过360bytes的数据。当server端收到数据,它会将数据放到buffer里,然后server端必须对这份数据做两件事

1. server端必须发送一个 ACK 到client端来确认数据已经收到
2. server端必须处理这份数据,把它交给对应的应用程序

要区分上面两件事对理解窗口很重要,接收方收到数据后会确认,但是数据并不一定是里面就是从buffer里取出的,这是受应用层逻辑控制的。所以很 有可能如果接收数据过快,而取出数据更慢,就会导致buffer满。一旦这种情况发生,窗口大小就开始调整来防止接收方负载过高。

正是因为窗口大小的调整可以用来调节数据传输的速率,所以就可以实现TCP的流控,在传输层的流控就是典型的例子,流控对于TCP的通信是很重要的,通过增大或者减小窗口的大小,client和server各自确保彼此设备发数据和收数据平衡。

通过TCP窗口实现流控

下面举一个例子,来看TCP窗口大小变化怎样实现流控。client端和server端已经三次握手建立TCP连接,总窗口大小是TCP建立连接时 候确定的。黑色框代表client和server总的窗口大小,红色框代表实际可用的窗口大小。初始化的时候默认client和server总窗口和可用 端口分别都是360。另外,假设Client总共只发送360bytes数据,所以总窗口大小不会往前移动。

  1. client 发送140bytes到server端,Seq=1,Length=140;可用窗口大小往前移动,变成260bytes,总窗口大小不变,依然是360。这中间的120是已发送,等待确认;
  2. server端收到140bytes,放入buffer中,但是应用程序很繁忙,只取出100个字节。这时候可用窗口大小: 260(360-100)。接着server端要给client发确认,Ack=141,Window=260。黑框左边缘向前移动,表示140字节已经 确认收到,但是应用程序太慢,处理很忙导致我现在只能处理260bytes(回顾下上面server端收到数据要做的两件事);
  3. client收到来自server端的ack回应,首先总窗口左边缘向前移动,表示第一步的140bytes server已经收到,剩下260数据。接着被告知server的可接收窗口是260,client就调整自己的发送窗口是260,表示一次发数据不能超 过260;
  4. client发送180bytes,可用窗口变成80(260-180),等待确认发送的180bytes;
  5. server收到180bytes,放入buffer中,应用程序依然很繁忙,这次一个字节都不处理。此时可用窗口大小:80(260-180),然后发180 ack给client,并告知窗口大小80;
  6. client收到ack,确认之前发送的180已经到达,剩余数据还有80字节。被告知server端接收窗口大小是80,调整自己的发送窗口大小为80
  7. client发送80bytes,可用窗口变成0(80-80),等待确认发送的80bytes;
  8. server收到180bytes,放入buffer中,应用程序依然很繁忙,一个字节都不处理。此时可用窗口大小:80(80-80),然后发80 ack给client,并告知窗口大小0;
  9. client收到ack,确认之前发送的80已经到达。被告知server端接收窗口大小是0,调整自己的发送窗口大小为0,此时无论client是否还有数据要发送,都不能再发了。

总结

窗口就是量化接收端和服务端当前能处理数据的能力。个人理解,如发现接收端的窗口越来越小,或者越来越大,都可能会有问题。

1. 接收端的窗口越来越小,那么就是接收端处理不过来(1.发的程序太快,太多;2.收的程序太慢,太少;3.发端带宽比收端带宽更大),会导致接收端发送给发送端的窗口变小,从而发送端调整发送窗口大小,降低发送速度,网络流量就会下降。
2. 接收端的窗口越来越大,那么就是发送端处理不过来(1.收的程序太快,太多;2.发的程序太慢,太少;3.发端带宽比收端带宽更小),会导致接收端发送给发送端的窗口变大,从而发送端调整发送窗口大小,增加发送速度,网络流量就会升高。

转载请保留固定链接: https://linuxeye.com/Linux/2210.html

------分隔线----------------------------
标签:TCP
栏目列表
推荐内容