前言：TCP的可靠性大致通过3类方法来保障：1.确认和重传。2.流量控制。3.拥塞避免。其中的流量控制中使用的滑动窗口，使得TCP的发送方和接收方速度得以匹配，从而为传输提供了可靠性支撑。本篇就介绍一下滑动窗口在Linux的大致代码，对于滑动窗口的基本知识已经有无数优秀的文章，更有TCP/IP卷一可参考，本篇不再赘述。代码基于 Linux 2.6.32。

我们知道TCP是有确认机制的，就是对于发送方发送的每个字节，接收方都会显式的进行确认（连续确认实际也是确认了每个字节）。那么仔细想象一下，该如何处理这个确认过程呢？比如，sender发送完一定数据后，停下来等待receiver的确认，然后再继续发送，再继续等待... 因此这里存在一个传输效率的问题。

接着再想另外一个问题，如果发送端的发送速度快，而接收端的接收速度慢，此时，如果不能协调收发速度，将会导致接收不及时丢包，进而加重重传，丢更多的包，引发网络雪崩。

上面两个问题基本就是滑动窗口诞生要解决的问题，即提高传输效率和流量控制的功能。

TCP的流量控制主要是协调收发的速度，在发送端维护着发送和接收窗口，同样的，在接收端，也同样如此。在说具体的操作之前，先说几个相关的概念：发送队列，接收队列，重传队列，滑动窗口，发送窗口，拥塞窗口，通告窗口。

TCP接收报文的函数为tcp_v4_do_rcv()，当建立连接后，接收处理的函数为tcp_rcv_established()，进来后，会进行fast path和slow path的区分处理，快通道和慢通道是由首部预测来确认的，首部预测用于提高TCP的处理速度。通常网络上大多数报文都会走fast path，看处理细节

那么就进行ack报文的处理tcp_ack()，在这个函数中，会更新发送窗口，使窗口右移，这样就会有新的报文可以被发送，tcp_data_snd_check(sk);就把这些报文发送出去。
最后调用tcp_write_xmit(),其函数说明如下：

可以看出，这个确实是用于发送窗口扩大后的报文。从这里可以看出TCP报文的发送在窗口机制下是由接收的ack来

然后就把报文从内核态拷贝到用户态，如果拷贝成功，标志成eaten = 1;接下来就是计算RTT以及更新接收的序列号。

如果没有拷贝成功，那么就把报文放在接收队列中，同时更新RTT，失败的原因比如用户报文数据长度比用户空间缓存的剩余量大等。

最后检查一下是否需要发送ack报文或者是sack报文。

另外一个是如果出现乱序等，快速路径没有满足条件，则走慢速路径，在慢速路径中会有把报文放入乱序队列等操作，具体不表了。

之后，用户进程通过recv读操作，把报文从接收队列中读取报文,在tcp_recvmsg可以看其过程：

TCP的滑动窗口的流量控制是通过协调发送方和接收方的速度来实现的，具体来说，就是发送方窗口是由接收方回的ack驱动的，也就是说发送方要能持续发送包需要持续接收ack。另一个方面，接收方在读取报文后，发送ack进行响应，循环进行接收。这个过程通过驱动窗口的可持续滑动，进而实现了流量控制和提高传输效率。