TCP选项之SO_RCVBUF和SO_SNDBUF

每个TCP socket在内核中都有一个发送缓冲区和一个接收缓冲区，TCP的全双工的工作模式以及TCP的滑动窗口便是依赖于这两个独立的buffer以及此buffer的填充状态。接收缓冲区把数据缓存入内核，应用进程一直没有调用read进行读取的话，此数据会一直缓存在相应socket的接收缓冲区内。再啰嗦一点，不管进程是否读取socket，对端发来的数据都会经由内核接收并且缓存到socket的内核接收缓冲区之中。read所做的工作，就是把内核缓冲区中的数据拷贝到应用层用户的buffer里面，仅此而已。进程调用send发送的数据的时候，最简单情况（也是一般情况），将数据拷贝进入socket的内核发送缓冲区之中，然后send便会在上层返回。换句话说，send返回之时，数据不一定会发送到对端去（和write写文件有点类似），send仅仅是把应用层buffer的数据拷贝进socket的内核发送buffer中。

每个UDP socket都有一个接收缓冲区，没有发送缓冲区，从概念上来说就是只要有数据就发，不管对方是否可以正确接收，所以不缓冲，不需要发送缓冲区。

接收缓冲区被TCP和UDP用来缓存网络上来的数据，一直保存到应用进程读走为止。对于TCP，如果应用进程一直没有读取，buffer满了之后，发生的动作是：通知对端TCP协议中的窗口关闭。这个便是滑动窗口的实现。保证TCP套接口接收缓冲区不会溢出，从而保证了TCP是可靠传输。因为对方不允许发出超过所通告窗口大小的数据。 这就是TCP的流量控制，如果对方无视窗口大小而发出了超过窗口大小的数据，则接收方TCP将丢弃它。 UDP：当套接口接收缓冲区满时，新来的数据报无法进入接收缓冲区，此数据报就被丢弃。UDP是没有流量控制的；快的发送者可以很容易地就淹没慢的接收者，导致接收方的UDP丢弃数据报。
以上便是TCP可靠，UDP不可靠的实现。
这两个选项就是来设置TCP连接的两个buffer尺寸的。

来自：http://blog.chinaunix.net/uid-20726500-id-4949695.html

为了达到最大网络吞吐，socket send buffer size(SO_SNDBUF)不应该小于带宽和延迟的乘积。
之前我遇到2个性能问题，都和SO_SNDBUF设置得太小有关。
但是，写程序的时候可能并不知道把SO_SNDBUF设多大合适，而且SO_SNDBUF也不宜设得太大，浪费内存啊。
于是，有OS提供了动态调整缓冲大小的功能，这样应用程序就不用再对SO_SNDBUF调优了。
(接受缓冲SO_RCVBUF也是类似的问题，不应该小于带宽和延迟的乘积)。

On Linux：
Linux从2.4开始支持接收缓冲和发送缓冲的动态调整。
http://www.man7.org/linux/man-pages/man7/tcp.7.html
------------------------------------------------------------
       tcp_rmem (since Linux 2.4)
              This is a vector of 3 integers: [min, default, max].  These
              parameters are used by TCP to regulate receive buffer sizes.
              TCP dynamically adjusts the size of the receive buffer from
              the defaults listed below, in the range of these values,
              depending on memory available in the system.
...
       tcp_wmem (since Linux 2.4)
              This is a vector of 3 integers: [min, default, max].  These
              parameters are used by TCP to regulate send buffer sizes.  TCP
              dynamically adjusts the size of the send buffer from the
              default values listed below, in the range of these values,
              depending on memory available.
------------------------------------------------------------

On Windows:
Windows上其实有类似的机能，但是Windows的文档太糟糕了，我废了不少劲才找到一些旁证。
从Vista开始Windows引入接受窗口的自动调整
http://blogs.msdn.com/b/wndp/archive/2007/07/05/receive-window-auto-tuning-on-vista.aspx


从Win7和Win2008R2开始Windows引入送信缓冲的自动调整
https://technet.microsoft.com/zh-cn/subscriptions/ms740642.aspx
------------------------------------------------------------ 
Updated for Windows 7 and Windows Server 2008 R2
...
Dynamic send buffering for TCP was added on Windows 7 and Windows Server 2008 R2. As a result, the use of the SIO_IDEAL_SEND_BACKLOG_CHANGE andSIO_IDEAL_SEND_BACKLOG_QUERY IOCTLs are needed only in special circumstances. For more information, see SIO_IDEAL_SEND_BACKLOG_QUERY.
------------------------------------------------------------

需要注意的是，如果应用设置了SO_SNDBUF，Dynamic send buffering会失效 。
https://msdn.microsoft.com/en-us/library/windows/desktop/bb736549(v=vs.85).aspx
------------------------------------------------------------
Dynamic send buffering for TCP was added on Windows 7 and Windows Server 2008 R2. By default, dynamic send buffering for TCP is enabled unless an application sets the SO_SNDBUF socket option on the stream socket.
------------------------------------------------------------

我在MSDN上没有找到正式介绍这个功能的页面（也许就没有这样的页面），所以也不知道它的自动调整是怎么个调法，范围是多少。而且，通过对Win7和Windows Server 2008 R2的测试我也没看到送信缓冲自动调整的效果，这个效果我只在Windows 2012上看到了。

测试：
下面是我的测试，主要针对送信缓冲的。
以下是各OS中送信缓冲的缺省值
OS                      送信缓冲的缺省值(通过getsockopt(SO_SNDBUF)获取) 
Window7:            8k 
Windows2003:     8k 
Windows2008:     8k 
Windows8:          64k 
Windows2012:     64k

测试方法:
1)机器A(Windows)通过TCP socket向机器B发送100MB数据。
2)机器A每次send()向socket写入8K字节。
3)机器A的程序设置不同的SO_SNDBUF，查看总送信时间的变化。

测试环境1:
Host A: Windows 2012(x64)
Host B: RHEL6(x64)
Network:1Gbit LAN

Result(execute time):
default(64K),                  1.118s(送信缓冲的自动调整生效) 
set SO_SNDBUF to 32K,   3.295s 
set SO_SNDBUF to 64K,   2.048s 
set SO_SNDBUF to 128K, 1.404s 
set SO_SNDBUF to 256K, 1.290s

从上面可以看出， Windows 2012中送信缓冲的自动调整还是很有效果的。
注)如果使用Windows而不是Linux作为客户端，效果也是一样的


测试环境2:
Host A: Windows 2008 R2(x64)
Host B: RHEL6(x64)
Network:1Gbit LAN

Result(execute time):
default(8K),                   7.370s 
set SO_SNDBUF to 32K,  4.159s 
set SO_SNDBUF to 64K,  2.875s 
set SO_SNDBUF to 128K, 1.593s 
set SO_SNDBUF to 256K, 1.324s 

对Windows 2008 R2，不知道送信缓冲的自动调整没有生效("netsh winsock show autotuning"是生效了的)，还是8K初始值的起点太低，反正性能不如人意。


结论：
较新的OS都支持socket buffer的自动调整，不需要应用程序去调优。但对Windows 2012(和Win8)以前的Windows，为了达到最大网络吞吐，还是要应用程序操心一下SO_SNDBUF的设置。