TCP的滑动窗口协议是；以字节为单位的。现假设A收到B发来的确认报文段，其中窗口是20，而确认号是31，这个信息表明，接收方希望接受的数据是31号数据，所以也就代表我们31号之前的数据都已经正确接收了，我们也不必在发送缓存中为它们保留了，窗口可以向前滑动，我们根据这些确认报文里的信息可以构造我们的滑动窗口。
我们发送窗口里的数据都是可以发送出去的，但是发送窗口里没有收到确认的数据还必须保留下来，防止需要重传。
根据观察，我们也不难发现，我们的滑动窗口越大，在没有收到确认的情况下，可以发送的数据就越多，这个窗口的大小不仅仅和接收方的接收能力有关，还和网络的状况有关，可能网络情况不太好的话，我们还有考虑拥塞窗口。
发送窗口是由前沿和后沿共同决定的。发送窗口后沿可以不动或者前移。不动，是因为发出去的数据，一直没有收到确认，向前移动是发送的数据收到了确认，就不需要再为他继续保存了。而发送窗口的后沿可以前移，可以不动，也可以后退。前移是，可能我们的窗口没变，然后收到了确认的数据，窗口整理向前移动了，也有可能是我们虽然没有收到确认数据，但是我们接收方的所给报文段里窗口增大了。而前沿不动有可能有两种情况，是窗口大小不变，但是我们未收到任何确认，还有一种情况是收到了确认，但是窗口变小了，所以没动。前沿也有可能后退，就是对方通知窗口变小了，这一般强烈不建议这样，因为可能在调整之前，要把原来可以发送的值发送了，但是这时候窗口又变小了，可能会有错误发生。
这幅图中我们可以看到，管理我们的发送窗口需要三个指针。我们可以看一看它们划定部分的意义。
P3-p1=A的发送窗口；
P2-p1=已发送但是未收到确认的字节数；、
P3-p2=允许发送但是尚未发送的字节数；
观察上图我们可以发现，我们的A中，有31-41的数据已经发送但是没有收到确认，而我们的可用窗口在减小。而在我们的B中，32、33没有按序到达，所以，B只能给按序到达数据的最高序号给出确认，因此B发确认号的时候，它还是只能发31号。假设我们已经按序到达了，31-33，然后发出了34的确认，我们的发送窗口会向前移动3个，因为我们收到确认就不必为它保留了。
A这时可以继续发送的范围是42到53。A继续发送完42-53后，指针p2和p3重合。发送窗口内的序号都已用完，但还没有收到确认。所以A的可用窗口已经减小到0，因此必须停止发送。
我们网络可能存在这种情况，A的数据全部正确到达了，但是B的确认滞留在了网络中。在没有手打B的确认的时候，A不能猜测：“或许B收到了把！”为了确保可靠传输，A只能认为B还没有收到这些数据。于是，A在经过一段时间后就重传这些数据，重新设置超时计时器，知道收到B的确认位置。如果A收到确认号落在发送窗口内，那么A就可以使发送窗口继续向前滑动，并发送新的数据。
可以发现，发送方的引用进程把字节流写入TCP的发送缓存，接收方的应用进程从TCP的接收缓存中读取字节流。我们可以讨论一下窗口和缓存的关系。
发送缓存用来暂时存放：
1）发送应用程序传送给发送方TCP准备发送的数据；
2）TCP已发送出单尚未收到确认的数据；
发送窗口通常只是发送缓存的一部分。已被确认的数据应当从发送缓存中删除，因此发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送缓存中的被写入的字节数。发送应用程序必须控制写入缓存的速率 ，不能太快，否则发送缓存就会没有存放数据的空间。
再看一下b图的接收方的情况
1）按序到达的，单尚未被接收方应用程序读取的数据；
2）未按序到达的数据；
如果收到的分组别检测出有差错，则样丢弃。如果接受应用程序来不及读取收到的数据，接受缓存就会被填满，使接受窗口减小到0.泛指，如果接受应用程序能够及时从接受缓存中读取收到的数据，接收窗口就可以增大，但最大不能超过接收缓存的大小。