socket的发送和接收缓冲区

 对于每个TCP的SOCKET来讲，都有一个发送缓冲区和接受缓冲区与之对应，下面举个例子说说发送缓冲区、接受缓冲区、滑动窗口协议之间的关系。

1、recv端

    在监听套接字上准备accept，在accept结束之后不作什么操做，直接sleep好久，也就是在recv端并不作接收数据的操做，在sleep结束以后再recv数据。

2、send端

    经过查看本系统内核支持的发送缓冲区大小，cat/proc/sys/net/ipv4/tcp_wmem，三个参数分别最小值、默认值和最大值。接收缓冲区的配置文件在tcp_rmen中。

    将套接字设置为阻塞，一次发送的buffer大于发送缓冲区所能容纳的数据量，一次send结束，在发送返回后接着打印发送的数据长度。

测试结果：

    阶段一：

    recv端表现：在刚开始发送数据时，接收端处于慢启动状态，滑动窗口值愈来愈大，可是因为接收端不处理接收缓冲区内的数据，其滑动窗口愈来愈小（由于接收端回应发送端中的win大小表示接受端还可以接受多少数据，发送端下次发送的数据大小不能超过回应中win的大小），最后发送端回应给接受端的ACK中显示的win大小为0，表示接收端不可以再接受数据。

    send端表现：发送端一直不能返回，若是接收端一直回应win为0的状况下，发送端的send就会一直不能返回，这种僵局一直持续到接收端的sleep结束。

    缘由分析：首先须要明白几个事实，阻塞式I/O会一直等待，直达这个操做完成；发送端接受到接收端的回应后才能将发送缓冲区中的数据进行清空。

    在接收端不recv，那么接收端的接收缓冲区内会一直有数据，接收缓冲区满，致使滑动窗口为0，发送端不能发送数据。可是send操做为什么不能返回呢？send操做只是将应用缓冲区的数据拷贝到发送缓冲区，可是发送缓冲区的数据并无彻底获得接收端的ACK回应，因此暂时不能将发送缓冲区中的数据丢弃，致使发送缓冲区的被填满，这样应用层中的数据也就不能拷贝到内核发送缓冲区内，也就会一直阻塞在这里，直到能够继续将应用层的数据拷贝到发送缓冲区中，什么时候触发这个操做呢？等到发送端回应win大于0时才有这样的操做。

    阶段二：

    recv端：在sleep结束之后，开始调用recv系统调用。这个时候接收端的滑动窗口又开始大于零，这样就唤醒了发送端继续发送数据。

    send端：发送端接收到接收端win大于0的回应，这个时候发送端又能够将应用层buffer中的数据拷贝到内核的发送缓冲区中。

    因为接收端调用recv将内核接收缓冲区的数据拷贝到应用层中，这样滑动窗口又大于0了，因此激发了发送端继续发送数据。因为发送端能够发送数据了，内核协议栈便将发送缓冲区中的数据发送给接收端，这样发送缓冲区又有空间了，那么send操做就能够将应用层的数据拷贝到发送缓冲区了！这样的操做一直保持到send操做返回，这样表明着将应用层的数据所有拷贝到发送缓冲区内，但不表明将数据发送给对端。发送给对端成功的标志是接收到对端的ACK回应，这个时候发送端才能够将发送缓冲区的数据丢弃。不丢弃的缘由是时刻准备重发丢失/出错的数据！

    Ps: TCP通讯为了保证可靠性，每次发送的数据都须要获得对方的ACK才确认对方收到了(仅保证对方TCP接收缓冲区收到数据了，但不保证对方应用程序取到数据了)，这时若是每次发送一次就要停下来等着对方的ACK消息，显然是一种极大的资源浪费和低下的效率，这时就有了滑动窗口的出现。

    发送方的滑动窗口维持着当前发送的帧序号，已发出去帧的计时器，接收方当前的窗口大小(由接收方ACK通知，大致等于接收缓冲大小-未处理的数据包)，接收方滑动窗口保存的有已接收的帧信息、期待的下一帧的帧号等，至于滑动窗口的具体工做原理这里就不说了。

    一 个socket有两个滑动窗口(一个sendbuf、一个recvbuf)，两个窗口的大小是经过setsockopt函数设置的，如今问题就出在这里， 经过抓包显示，设置的窗口大小没有生效，最后排查发现setsockopt函数是后来加上的，写到了listen函数的后面，这样每次accept出的 socket并无继承获得主socket设置的窗口大小，无语啊……

    解决办法：setsockopt函数提早到listen函数以前，这样在服务器程序启动监听前recvbuf就已经有了，accept后的连接获得的就是recvbuf了，启动程序运行，抓包显示窗口已是指定的大小了。

结论：

    1.TCP的滑动窗口大小实际上就是socket的接收缓冲区（SO_RCVBUF）大小的字节数

    2.对于server端的socket必定要在listen以前设置缓冲区大小，由于，accept时新产生的socket会继承监听socket的缓冲区大 小。对于client端的socket必定要在connet以前设置缓冲区大小，由于connet时须要进行三次握手过程，会通知对方本身的窗口大小。在 connet以后再设置缓冲区，已经没有什么意义。

    3.因为缓冲区大小在TCP头部只有16位来表示，因此它的最大值是65536，可是对于一些状况来讲须要使用更大的滑动窗口，这时候就要使用扩展的滑动窗口，如光纤高速通讯网络，或者是卫星长链接网络，须要窗口尽量的大。这时会使用扩展的32位的滑动窗口大小。

    这就是发送缓冲区、接受缓冲区、滑动窗口协议之间的关系，不知道你们明白了没有。因为优客的知识有限，可能描述不够恰当，但愿你们多多指教。

【我的补充】socket的发送缓冲区与滑动窗口关系    socket/send成功与否与滑动窗口没有任何关系，可是，存在逻辑上的前后做用关系，即    socket/send向缓冲区发送数据包时，要看发送缓冲区大小（SO_SNDBUF）--> tcp/send发送缓冲区中的数据包时，看滑动窗口win的值。