一. read/write的语义：为什么会阻塞？
先从write说起：
#include <unistd.h>
ssize_t write(int fd, const void *buf, size_t count);首先，write成功返回，只是buf中的数据被复制到了kernel中的TCP发送缓冲区。至于数据什么时候被发往网络，什么时候被对方主机接收，什么时候被对方进程读取，系统调用层面不会给予任何保证和通知。
write在什么情况下会阻塞？当kernel的该socket的发送缓冲区已满时。对于每个socket，拥有自己的send buffer和receive buffer。从Linux 2.6开始，两个缓冲区大小都由系统来自动调节（autotuning），但一般在default和max之间浮动。
# 获取socket的发送/接受缓冲区的大小：（后面的值是在我在Linux 2.6.38 x86_64上测试的结果）
sysctl net.core.wmem_default #126976
sysctl net.core.wmem_max #131071
sysctl net.core.wmem_default #126976
sysctl net.core.wmem_max #131071已经发送到网络的数据依然需要暂存在send buffer中，只有收到对方的ack后，kernel才从buffer中清除这一部分数据，为后续发送数据腾出空间。接收端将收到的数据暂存在receive buffer中，自动进行确认。但如果socket所在的进程不及时将数据从receive buffer中取出，最终导致receive buffer填满，由于TCP的滑动窗口和拥塞控制，接收端会阻止发送端向其发送数据。这些控制皆发生在TCP/IP栈中，对应用程序是透明的，应用程序继续发送数据，最终导致send buffer填满，write调用阻塞。
一般来说，由于接收端进程从socket读数据的速度跟不上发送端进程向socket写数据的速度，最终导致发送端write调用阻塞。
而read调用的行为相对容易理解，从socket的receive buffer中拷贝数据到应用程序的buffer中。read调用阻塞，通常是发送端的数据没有到达。
二. blocking（默认）和nonblock模式下read/write行为的区别：
将socket fd设置为nonblock（非阻塞）是在服务器编程中常见的做法，采用blocking IO并为每一个client创建一个线程的模式开销巨大且可扩展性不佳（带来大量的切换开销），更为通用的做法是采用线程池+Nonblock I/O+Multiplexing（select/poll，以及Linux上特有的epoll）。
// 设置一个文件描述符为nonblock
int set_nonblocking(int fd)
{
int flags;
if ((flags = fcntl(fd, F_GETFL, 0)) == -1)
flags = 0;
return fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}
几个重要的结论：
1. read总是在接收缓冲区有数据时立即返回，而不是等到给定的read buffer填满时返回。
只有当receive buffer为空时，blocking模式才会等待，而nonblock模式下会立即返回-1（errno = EAGAIN或EWOULDBLOCK）
2. blocking的write只有在缓冲区足以放下整个buffer时才返回（与blocking read并不相同）
nonblock write则是返回能够放下的字节数，之后调用则返回-1（errno = EAGAIN或EWOULDBLOCK）
对于blocking的write有个特例：当write正阻塞等待时对面关闭了socket，则write则会立即将剩余缓冲区填满并返回所写的字节数，再次调用则write失败（connection reset by peer），这正是下个小节要提到的：
三. read/write对连接异常的反馈行为：
对应用程序来说，与另一进程的TCP通信其实是完全异步的过程：
1. 我并不知道对面什么时候、能否收到我的数据
2. 我不知道什么时候能够收到对面的数据
3. 我不知道什么时候通信结束（主动退出或是异常退出、机器故障、网络故障等等）
对于1和2，采用write() -> read() -> write() -> read() ->...的序列，通过blocking read或者nonblock read+轮询的方式，应用程序基于可以保证正确的处理流程。
对于3，kernel将这些事件的“通知”通过read/write的结果返回给应用层。
假设A机器上的一个进程a正在和B机器上的进程b通信：某一时刻a正阻塞在socket的read调用上（或者在nonblock下轮询socket）
当b进程终止时，无论应用程序是否显式关闭了socket（OS会负责在进程结束时关闭所有的文件描述符，对于socket，则会发送一个FIN包到对面）。
”同步通知“：进程a对已经收到FIN的socket调用read，如果已经读完了receive buffer的剩余字节，则会返回EOF:0
”异步通知“：如果进程a正阻塞在read调用上（前面已经提到，此时receive buffer一定为空，因为read在receive buffer有内容时就会返回），则read调用立即返回EOF，进程a被唤醒。
socket在收到FIN后，虽然调用read会返回EOF，但进程a依然可以其调用write，因为根据TCP协议，收到对方的FIN包只意味着对方不会再发送任何消息。 在一个双方正常关闭的流程中，收到FIN包的一端将剩余数据发送给对面（通过一次或多次write），然后关闭socket。
但是事情远远没有想象中简单。优雅地（gracefully)关闭一个TCP连接，不仅仅需要双方的应用程序遵守约定，中间还不能出任何差错。
假如b进程是异常终止的，发送FIN包是OS代劳的，b进程已经不复存在，当机器再次收到该socket的消息时，会回应RST（因为拥有该socket的进程已经终止）。a进程对收到RST的socket调用write时，操作系统会给a进程发送SIGPIPE，默认处理动作是终止进程，知道你的进程为什么毫无征兆地死亡了吧：）
from 《Unix Network programming, vol1》 3rd Edition：
"It is okay to write to a socket that has received a FIN, but it is an error to write to a socket that has received an RST."通过以上的叙述，内核通过socket的read/write将双方的连接异常通知到应用层，虽然很不直观，似乎也够用。
这里说一句题外话：
不知道有没有同学会和我有一样的感慨：在写TCP/IP通信时，似乎没怎么考虑连接的终止或错误，只是在read/write错误返回时关闭socket，程序似乎也能正常运行，但某些情况下总是会出奇怪的问题。想完美处理各种错误，却发现怎么也做不对。
原因之一是：socket（或者说TCP/IP栈本身）对错误的反馈能力是有限的。
考虑这样的错误情况：
不同于b进程退出（此时OS会负责为所有打开的socket发送FIN包），当B机器的OS崩溃（注意不同于人为关机，因为关机时所有进程的退出动作依然能够得到保证）/主机断电/网络不可达时，a进程根本不会收到FIN包作为连接终止的提示。
如果a进程阻塞在read上，那么结果只能是永远的等待。
如果a进程先write然后阻塞在read，由于收不到B机器TCP/IP栈的ack，TCP会持续重传12次（时间跨度大约为9分钟），然后在阻塞的read调用上返回错误：ETIMEDOUT/EHOSTUNREACH/ENETUNREACH
假如B机器恰好在某个时候恢复和A机器的通路，并收到a某个重传的pack，因为不能识别所以会返回一个RST，此时a进程上阻塞的read调用会返回错误ECONNREST
恩，socket对这些错误还是有一定的反馈能力的，前提是在对面不可达时你依然做了一次write调用，而不是轮询或是阻塞在read上，那么总是会在重传的周期内检测出错误。如果没有那次write调用，应用层永远不会收到连接错误的通知。
write的错误最终通过read来通知应用层，有点阴差阳错？
---------------设置非阻塞连接超-----------------------------
复制代码
//首先改成非阻塞套接字
unsigned long ul=1;
int rm=ioctl(sConnect,FIONBIO,(unsigned long*)&ul);
if(rm==-1)
{
printf("ioctl noblock error!\n");
close(sConnect);
return -3;
}//向服务器发出连接请求
int err = connect(sConnect, (struct sockaddr*)&addrServer, sizeof(addrServer));//正常返回EINPROGRESS
if(err && errno!=EINPROGRESS)
{
printf("cannot connect:%s\n",severAgent);
return -4;
}//有可能返回0
if (err==0)
{
printf("connect suceess!");
}else
{
struct timeval tv;
fd_set /*r,*/w;
// FD_ZERO(&r);
FD_ZERO(&w);
// FD_SET(sConnect,&r);
FD_SET(sConnect,&w);
tv.tv_sec=m_conTimeout;
tv.tv_usec=0;
int retval = select(sConnect+1,0,&w,0,&tv);
if(retval==-1)
{
printf("select error\n");
return -5;
}
else if(retval == 0)
{
printf("connect timeout\n");
return -6;
}
else
{
int er;
socklen_t len = sizeof(er);
if (getsockopt(sConnect, SOL_SOCKET, SO_ERROR, (char *)&er, &len) < 0) {
//getsockopt()失败，进行错处理
printf("getsockopt error\n");
return -8;
}
if (er != 0) {
//connect()失败，进行错处理
printf("connect error\n");
return -9;
}
}
}
//改为阻塞
ul=0;
rm=ioctl(sConnect,FIONBIO,(unsigned long*)&ul);
if(rm==-1)
{
printf("ioctl block error!\n");
close(sConnect);
return -7;
} 值得注意的是：linux中，如果服务器的地址无效，则以上超时过程正常。如果服务器地址有效，但是服务程序未开启，则直接返回错误，也就是说超时过程不起作用，说明是已经做了目标网络检测了。
但是window中，同样是以上的代码，如果服务器的地址无效，则以上超时过程正常。如果服务器地址有效，但是服务程序未开，以上超时过程也是正常的。二者还是有点区别的。
---------------------------------------------------------设置socket缓冲区原理-----------------------------
1 设置socket tcp缓冲区大小的疑惑
疑惑1：通过setsockopt设置SO_SNDBUF、SO_RCVBUF这连个默认缓冲区的值，再用getsockopt获取设置的值，发现返回值是设置值的两倍。为什么？
通过网上查找，看到linux的内核代码/usr/src/linux-2.6.13.2/net/core/sock.c，找到sock_setsockopt这个函数的这段代码：
case SO_SNDBUF:
/* Don't error on this BSD doesn't and if you think
about it this is right. Otherwise apps have to
play 'guess the biggest size' games. RCVBUF/SNDBUF
are treated in BSD as hints */
if (val > sysctl_wmem_max)//val是我们想设置的缓冲区大小的值
val = sysctl_wmem_max;//大于最大值，则val值设置成最大值
sk->sk_userlocks |= SOCK_SNDBUF_LOCK;
if ((val * 2) < SOCK_MIN_SNDBUF)//val的两倍小于最小值，则设置成最小值
sk->sk_sndbuf = SOCK_MIN_SNDBUF;
else
sk->sk_sndbuf = val * 2;//val的两倍大于最小值，则设置成val值的两倍
/*
* Wake up sending tasks if we
* upped the value.
*/
sk->sk_write_space(sk);
break;
case SO_RCVBUF:
/* Don't error on this BSD doesn't and if you think
about it this is right. Otherwise apps have to
play 'guess the biggest size' games. RCVBUF/SNDBUF
are treated in BSD as hints */
if (val > sysctl_rmem_max)
val = sysctl_rmem_max;
sk->sk_userlocks |= SOCK_RCVBUF_LOCK;
/* FIXME: is this lower bound the right one? */
if ((val * 2) < SOCK_MIN_RCVBUF)
sk->sk_rcvbuf = SOCK_MIN_RCVBUF;
else
sk->sk_rcvbuf = val * 2;
break;从上述代码可以看出：（1）当设置的值val > 最大值sysctl_wmem_max，则设置为最大值的2倍：2*sysctl_wmem_max；
（2）当设置的值的两倍val*2 > 最小值，则设置成最小值：SOCK_MIN_SNDBUF；
（3）当设置的值val < 最大值sysctl_wmem_max，且 val*2 > SOCK_MIN_SNDBUF， 则设置成2*val。
查看linux 手册：
SO_RCVBUF：
Sets or gets the maximum socket receive buffer in bytes.
The kernel doubles this value (to allow space for bookkeeping overhead) when it is set using setsockopt(2),
and this doubled value is returned by getsockopt(2).
The default value is set by the /proc/sys/net/core/rmem_default file,
and the maximum allowed value is set by the /proc/sys/net/core/rmem_max file.
The minimum (doubled) value for this option is 256. 查看我的主机Linux 2.6.6 ：/proc/sys/net/core/rmem_max：
4194304 //4M
查看/proc/sys/net/core/wmem_max：
8388608 //8M
所以，能设置的接收缓冲区的最大值是8M，发送缓冲区的最大值是16M。
疑惑2：为什么要有2倍这样的一个内核设置呢？我的理解是，用户在设置这个值的时候，可能只考虑到数据的大小，没有考虑数据封包的字节开销。所以将这个值设置成两倍。
注：overhead，在计算机网络的帧结构中，除了有用数据以外，还有很多控制信息，这些控制信息用来保证通信的完成。这些控制信息被称作系统开销。
2 tcp缓冲区大小的默认值
建立一个socket，通过getsockopt获取缓冲区的值如下：
发送缓冲区大小：SNDBufSize = 16384
接收缓冲区大小：RCVBufSize = 87380
疑惑3：linux手册中，接收缓冲区的默认值保存在/proc/sys/net/core/rmem_default，发送缓冲区保存在/proc/sys/net/core/wmem_default。
[root@cfs_netstorage core]# cat /proc/sys/net/core/rmem_default
1048576
[root@cfs_netstorage core]# cat /proc/sys/net/core/wmem_default
512488
可知，接收缓冲区的默认值是：1048576，1M。发送缓冲区的默认值是：512488，512K。为什么建立一个socket时得到的默认值是87380、16384？？？
进一步查阅资料发现， linux下socket缓冲区大小的默认值在/proc虚拟文件系统中有配置。分别在一下两个文件中：
/proc/sys/net/ipv4/tcp_wmem
[root@cfs_netstorage core]# cat /proc/sys/net/ipv4/tcp_wmem4096 16384 131072 //第一个表示最小值，第二个表示默认值，第三个表示最大值。
/proc/sys/net/ipv4/tcp_rmem
[root@cfs_netstorage core]# cat /proc/sys/net/ipv4/tcp_rmem
4096 87380 174760
由此可见，新建socket，选取的默认值都是从这两个文件中读取的。可以通过更改这两个文件中的值进行调优，但是最可靠的方法还是在程序中调用setsockopt进行设置。通过setsockopt的设置，能设置的接收缓冲区的最大值是8M，发送缓冲区的最大值是16M（Linux 2.6.6中）。
--------------------------------缓冲区值查看-------------------------------------
1. tcp 收发缓冲区默认值
[root@ www.linuxidc.com]# cat /proc/sys/net/ipv4/tcp_rmem
4096 87380 4161536
87380 ：tcp接收缓冲区的默认值
[root@ www.linuxidc.com]# cat /proc/sys/net/ipv4/tcp_wmem
4096 16384 4161536
16384 ： tcp 发送缓冲区的默认值
2. tcp 或udp收发缓冲区最大值
[root@ www.linuxidc.com]# cat /proc/sys/net/core/rmem_max
131071
131071：tcp 或 udp 接收缓冲区最大可设置值的一半。
也就是说调用 setsockopt(s, SOL_SOCKET, SO_RCVBUF, &rcv_size, &optlen); 时rcv_size 如果超过 131071，那么
getsockopt(s, SOL_SOCKET, SO_RCVBUF, &rcv_size, &optlen); 去到的值就等于 131071 * 2 = 262142
[root@ www.linuxidc.com]# cat /proc/sys/net/core/wmem_max
131071
131071：tcp 或 udp 发送缓冲区最大可设置值得一半。
跟上面同一个道理
3. udp收发缓冲区默认值
[root@ www.linuxidc.com]# cat /proc/sys/net/core/rmem_default
111616：udp接收缓冲区的默认值
[root@ www.linuxidc.com]# cat /proc/sys/net/core/wmem_default
111616
111616：udp发送缓冲区的默认值
4. tcp 或udp收发缓冲区最小值
tcp 或udp接收缓冲区的最小值为 256 bytes，由内核的宏决定；
tcp 或udp发送缓冲区的最小值为 2048 bytes，由内核的宏决定
---------------------------------------修改系统缓冲区方法-----------------------------------
在linux下可以修改协议栈改变tcp缓冲相关参数：
修改系统套接字缓冲区
echo 65536 > /proc/sys/net/core/rmem_max
echo 256960 > /proc/sys/net/core/wmem_max
echo 65536 > /proc/sys/net/core/wmen_default修改tcp接收/发送缓冲区
echo "4096 32768 65536" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 65536 256960" > /proc/sys/net/ipv4/tcp_wmem修改网络设备接收队列
echo 500 > /proc/sys/net/core/netdev_max_backlog重传次数
echo 5 > /proc/sys/net/ipv4/tcp_retries2
