问题产生：
在进行客户端向服务端发送数据时，每次发送一定数量数据后发送端就等不到send函数的返回，导致程序一直卡死在send函数。
通过抓包发现：发送端发送过快而接收端处理速度过慢，导致快速发送一定量数据后wireshark显示发送端发送数据有window full提醒，几次之后接收端会发送zero window消息，发送缓冲区数据无法发出导致堆积满发送缓冲区，从而导致send无法将数据拷贝进发送缓冲区，进而形成send函数无法返回，程序阻塞无法运行。
分析：
recv端表现：在刚开始发送数据时，接收端处于慢启动状态，滑动窗口值越来越大，但是由于接收端不处理接收缓冲区内的数据，其滑动窗口越来越小（因为接收端回应发送端中的win大小表示接受端还能够接受多少数据，发送端下次发送的数据大小不能超过回应中win的大小），最后发送端回应给接受端的ACK中显示的win大小为0，表示接收端不能够再接受数据。
send端表现：发送端一直不能返回，如果接收端一直回应win为0的情况下，发送端的send就会一直不能返回，这种僵局一直持续到接收端的缓冲区数据被处理完成空出足够接收一定量数据的空间。
原因分析：首先需要明白几个事实，阻塞式I/O会一直等待，直达这个操作完成；发送端接受到接收端的回应后才能将发送缓冲区中的数据进行清空。
那么接收端的接收缓冲区满，导致滑动窗口为0，发送端不能发送数据。但是send操作为何不能返回呢？send操作只是将应用缓冲区的数据拷贝到发送缓冲区，但是发送缓冲区的数据并没有完全得到接收端的ACK回应，所以暂时不能将发送缓冲区中的数据丢弃，导致发送缓冲区的被填满，这样应用层中的数据也就不能拷贝到内核发送缓冲区内，也就会一直阻塞在这里，直到可以继续将应用层的数据拷贝到发送缓冲区中，何时触发这个操作呢？等到发送端回应win大于0时才有这样的操作。
遗留问题：
接收端一直在接收数据，将缓冲区数据处理写入本地文件，但是问题产生后程序将会一直阻塞基本未见好转情况。同时抓包数据显示recv端一直有zero window消息，send端一直发送心跳包检测。为什么程序一直卡死，并且接收端缓冲区不见减小？
-->>解答：
接收端使用ET模式，而且每次接收数据buff设置小于发送的buff，导致每次收到ET消息后只会处理部分缓冲区内数据，导致缓冲区数据持续增长直至窗口缩小为0。
至此，发送端不能再发送数据，接收端将不会收到ET信号。从而缓冲区数据将不会减少，窗口一直保持为0的状态。程序死锁，一直hang住。