最近用netty写了一套代理服务发现网速超级慢下载只有200k左右，代理服务器的实际网速在100Mbit/s 左右。找了好久终于找到原因了。原来是netty tcp 参数SO_SNDBUF和SO_RCVBUF设置太小了（原来为32K，现在设置为2M后网速恢复正常）。
源码地址（可支持CDN，求Star）: https://github.com/zhining-lu/netty-websocket-proxy
含义
- SO_SNDBUF：TCP发送缓冲区的容量上限；
- SO_RCVBUF：TCP接受缓冲区的容量上限；
注意：缓冲区的上限不能无限大，如果超过内核设置的上限值，则以内核设置值为准（sysctl -a命令查看）。
net.ipv4.tcp_rmem = 8192 87380 16777216
net.ipv4.tcp_wmem = 8192 65536 16777216
net.ipv4.tcp_mem = 8388608 12582912 16777216与实际使用内存的关系？
- SO_SNDBUF和SO_RCVBUF只是规定了读写缓冲区大小的上限，在实际使用未达到上限前，SO_SNDBUF和SO_RCVBUF是不起作用的。
- 一个TCP连接占用的内存相当于读写缓冲区实际占用内存大小之和。
与滑动窗口的关系？
接收缓存区和接受滑动窗口关系
接收缓存区包含了滑动窗口，即接收缓存区大小>= 滑动窗口大小。接受缓冲区的数据主要分为两部分：
- 接受滑动窗口内的无序的TCP报文；
- 有序的，应用还未读取的数据（占用比例：1/(2^tcp_adv_win_scale)，默认tcp_adv_win_scale配置为2）；
因此，当接受缓冲区上限固定后，如果应用程序读取数据的速率过慢，接收滑动窗口会缩小，从而通知连接的对端降低发送速度，避免无谓的网络传输。
发送缓存区和发送滑动窗口关系
发送缓存区包含了发送滑动窗口，即发送缓存区大小>= 发送滑动窗口大小。发送缓冲区的数据主要分为两部分：
- 发送窗口内的数据：已发送还未确认的数据；
- 应用写入的数据；
缓冲区大小预估
####估算最大接受窗口大小
一般以BDP来设置最大接收窗口，BDP叫做带宽时延积，也就是带宽与网络时延的乘积。因为BDP就表示了网络承载能力，最大接收窗口就表示了网络承载能力内可以不经确认发出的报文。如下图所示：
####计算接受缓冲区大小
根据接受窗口大小的占比1-1/(2^tcp_adv_win_scale)，计算出缓冲区大小上限；
举例：例如若我们的带宽为2Gbps，时延为10ms，那么带宽时延积BDP则为2G/8*0.01=2.5MB，所以这样的网络中可以设最大接收窗口为2.5MB，当tcp_adv_win_scale=2时最大读缓存可以设为4/3*2.5MB=3.3MB。