大家知道，TCP采用的是全双工的工作模式，对每一个TCP的SOCKET来说，都有一个发送缓冲区和接收缓冲区与之对应，TCP的流量(拥塞)控制便是依赖于这两个独立的buffer滑动窗口协议之间。我们可以通过一个简单实验体会三者之间关系。
一、recv端
在监听套接字上准备accept，在accept结束以后不做什么操作，直接sleep很久，也就是在recv端并不做接收数据的操作，在sleep结束之后再recv数据。
二、send端
将套接字设置为阻塞，一次发送的buffer大于发送缓冲区所能容纳的数据量。
通过查看系统内核默认的支持的发送缓冲区大小，cat/proc/sys/net/ipv4/tcp_wmem，最后一个参数为发送缓冲区的最大值。接收缓冲区的配置文件在tcp_rmen中。
测试结果：
通过抓包可以发现：
阶段一：
接收端表现：在刚开始发送数据时，发送端处于慢启动状态，随着不断收到ack,拥塞窗口大小越来愈大，发送数据量又开始越来越小，但是不一会，由于接收端不处理接收缓冲区内的数据，其滑动窗口越来越小（因为接收端回应发送端中的win大小表示接收端还能够接收多少数据，发送端下次发送的数据大小不能超过回应中win的大小），发送数据量又开始越来越小，最后接收端回应给发送端的ACK中显示的win大小为0，表示接收端不能够再接收数据。发送停止。
发送端表现：发送端一直不能返回，如果接收端一直回应win为0的情况下，发送端的send就会一直不能返回。
原因分析：首先需要明白几个事实，阻塞式I/O会一直等待，直达这个操作完成；发送端完全接收到接收端的回应后才能将发送缓冲区中的数据进行清空。
在接收端不recv，那么接收端的接收缓冲区内会一直有数据，接收缓冲区满，导致滑动窗口为0，导致发送端不能发送数据。但是send操作为何不能返回呢？send操作只是将应用缓冲区的数据拷贝到发送缓冲区，但是发送缓冲区的数据并没有完全得到接收端的ACK回应，所以暂时不能将发送缓冲区中的数据丢弃，导致发送缓冲区的被填满，这样应用层中的数据也就不能拷贝到内核发送缓冲区内，也就会一直阻塞在这里，直到可以继续将应用层的数据拷贝到发送缓冲区中，何时触发这个操作呢？等到发送端回应win大于0时才有这样的操作。
阶段二;
接收端：在sleep结束以后，开始调用recv系统调用。这个时候接收端的滑动窗口又开始大于零。那么这样就唤醒了发送端继续发送数据。
发送端：发送端接收到接收端win大于0的回应，这个时候发送端又可以将应用层buffer中的数据拷贝到内核的发送缓冲区中。
原因分析：由于接收端调用recv将内核接收缓冲区的数据拷贝到应用层中，这样滑动窗口又大于0了，所以激发了发送端继续发送数据，由于发送端可以发送数据了，内核协议栈便将发送缓冲区中的数据发送给接收端，这样发送缓冲区又有空间了，那么send操作就可以将应用层的数据拷贝到发送缓冲区了！这样的操作一直保持到send操作返回，此时代表着将应用层的数据全部拷贝到发送缓冲区内，但不代表将数据已经发送给接收端。发送给对端成功的标志是接收到对端的ACK回应，这个时候发送端才可以将发送缓冲区的数据丢弃。不丢弃的原因是时刻准备重发丢失/出错的数据！
开发中的注意事项:
一个socket有两个滑动窗口(一个sendbuf、一个recvbuf)，两个窗口的大小是可以通过setsockopt函数设置的。
一、TCP的滑动窗口大小实际上就是socket的接收缓冲区大小的字节数
二、对于server端的socket一定要在listen之前设置缓冲区大小，因为，accept时新产生的socket会继承监听socket的缓冲区大 小。对于client端的socket则一定要在connet之前设置缓冲区大小，因为connet时需要进行三次握手过程，会通知对方自己的窗口大小。在 connet之后再设置缓冲区，已经没有什么意义。
原文地址：https://blog.csdn.net/smartfox80/article/details/22578735