TCP的滑动窗体攻克了端到端的流量控制问题，同意接受方对传输进行限制。直到它拥有足够的缓冲空间来容纳很多其他的数据。滑动窗体的大小由接收方确定，接收方在发送确认信号给发送方的同一时候告诉发送方自己的缓冲区大小（在TCP头部字段中），发送方依据此大小确定窗体大小，从而控制数据发送量。同一时候，滑动窗体协议同意发送方在停止并等待确认前能够连续发送多个分组，因为发送方不必每发一个分组就停下来等待确认，因此该协议能够加速数据的传输。
以下是一个样例：
在建立连接时。两方都告知了对方自己的MSS为1024，所以在传输过程中，每个报文段的大小都为1024.以下重点分析各个确认报文段，也就是从右边发往左边的报文段：
- 报文段7确认了报文段4和报文段5。因为包括两个分组的ACK，所以该报文段不是经受时延的确认。
滑动窗体大小为4096表示收到的两个报文段已经所有交付给了应用层。此时TCP的接收缓存为空。
- 报文段8确认了报文段6。此报文段在等待其他数据（这里为报文段9的确认）一起传送的过程中延时定时器溢出。所以此为经受时延的确认。滑动窗体大小为3072表示TCP接受缓存中还有1024字节数据未被应用程序读取。
- 报文段10确认了报文段9。它也是一个经受时延的确认。
- 报文段14确认了报文段11和报文段12，它不是一个经受时延的确认。
- 报文段16确认了报文段13和报文段15，它不是一个经受时延的确认。
通过上面的过程能够看出，报文段7、14、16的ACK确认了两个收到的报文段。这与开头的描写叙述是一致的。
以下来看看上述过程中的滑动窗体变化情况：
接收方每确认一个报文段，滑动窗体的左边沿就向右边沿靠拢。这里的确认是指接收方发送确认报文段，并不代表应用层已经读取了TCP接收缓存。当应用进程读取了已经确认的数据并释放TCP接受缓存后，滑动窗体的右边沿才会向右移动。
參考：
《TCP/IP具体解释》 P209-P214.