在TCP中，当发送端的数据到达接收主机时，接收端主句会返回一个已收到消息的通知。这个消息叫做确认应答（ACK）。当发送端将数据发出之后会等待对端的确认应答。如果有确认应答，说明数据已经成功到达对端。反之，则数据丢失的可能性很大。
在一定时间内没有等待到确认应答，发送端就可以认为数据已经丢失，并进行重发。由此，即使产生了丢包，仍然能保证书能够到达对端，实现可靠传输。
为收到确认应答并不意味着数据一定丢失。也有可能是数据对方已经收到，只是返回的确认应答在途中丢失。这种情况也会导致发送端误以为数据没有到达目的地而重发数据。
此外，也有可能因为一些其他原因导致确认应答延迟到达，在源主句重发数据以后才到达的情况也屡见不鲜。此时，源主机只要按照机制重发数据即可。
对于目标主机来说，反复收到相同的数据是不可取的。为了对上层应用提供可靠的传输，目标主机必须放弃重复的数据包。位置我们引进了序列号。、
序列号是按照顺序给发送数据的每一个字节（8位字节）都标上号码的编号。接受端查询接收数据TCP首部中的序列号和数据的长度，将自己下一步应该接收的序列号作为确认应答返回。通过序列号和确认应答号，TCP能都识别是否已经接收数据，又能够判断是否需要接收，从而实现可靠传输。
发送方和接收方都会维护一个数据帧的序列，这个序列被称为窗口。发送方的窗口大小由接收方确认，目的是控制发送速度，一面接收方的缓存不够大导致溢出，同时控制流量也可以避免网络拥塞。
在TCP的可靠性的图中，我们可以看到，发送方每发送一个数据接收方就要给发送发一个ACK对这个数据进行确认。只有接受了这个确认数据以后发送发才能传输下个数据。
存在的问题：如果窗口过小，当传输比较大的数据的时候需要不停的对数据进行确认这个时候就会造成很大的延迟。
如果窗口过大。我们假设发送发一次发送100个数据，但是接收方只能处理50个数据，这样每次都只能处理50个数据进行确认。发送方下一次还是要发送100个数据，但是接收方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。
因此，我们引入了滑动窗口。滑动窗口通俗来讲就是一种流量控制技术。
它本质上市描述接收方的TCP数据缓冲区大小的数据，发送方根据这个数据来计算自己嘴都能发送多长的数据，如果发送方收到接收方的窗口大小为0的TCP数报，那么发送方就停止发送数据，等到接收方发送窗口大小不为0的数据报的到来。
首先是第一次发送数据，这个时候的窗口大小是根据链路宽带的大小来决定的。我们假设这个时候窗口的大小是3。这个时候接收方收到数据以后会对数据进行确认告诉发送方我下次希望收到的数据是多少。这里我们看到接收方发送的ACK=3（这是发送方发送序列2的回答确认，下一次接收方希望接受到的是3序列信号）。这个时候发送方收到这个数据以后就知道我第一次发送的3个数据对方只收到2个。就知道第3个数据对方没有收到。下次在发送的时候就从第3个数据开始发。
此时窗口大小变成2。
于是发送方发送2个数据。看到接收方发送的ACK 是5就表示它下一次希望收到的数据是5，发送方就知道我刚才发送的2个数据对方收了，这个时候发送第5个数据。
这就是滑动窗口的工作机制，当链路变好了或者变差了这个窗口还会发生变化，并不是第一次协商好以后就永远不变了。
所以滑动窗口协议，是TCP使用的一种流量控制方法。改协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每2发一个分组就停下来等待确认，因此该协议可以加速数据的传输。
只有在接受窗口向前滑动时（与此同时也发送确认），发送窗口才有可能向前滑动。
收发两端的窗口按照以上规律不断向前滑动，因此这种协议又称为滑动窗口协议。