唯快不破：TCP/IP中的SO_REUSEADDR和SO_KEEPALIVE

SO_REUSEADDR

据《UNIX网络编程》卷一所说，此选项用于4种用途

我本人在TCP服务器上只处理过两种，其他情况如有需要，请参考《UNIX网络编程》卷一

1.引自《UNIX网络编程》卷一

多进程绑定同一对IP和PORT，按时序举个多进程模式tcp服务器的例子

a.父进程进行监听；

b.来syn包，请求连接；

c.派生子进程处理用户长连接请求；

d.父进程挂掉；

e.重启父进程。

此时，子进程复制继承父进程的监听socket，并且子进程并没有消亡，如果在监听前没有对监听socket设置此选项，重启父进程时，会导致bind调用失败。

2.先明确一个概念：socket是系统级的对象，并非属于某个进程自己的资源。
言归正传，不考虑多进程方式的tcp服务器，举个最简单的单进程+epoll方式的TCP服务器的例子

服务器进程挂掉（内核自动关闭所有此进程打开的文件，其中包括socket），监听socket进入TIME_WAIT状态（此时socket仍存在于系统中），重新启动服务器，如果在监听前没有对监听socket设置此选项，此时会导致bind调用失败。

KEEPALIVE机制，是TCP协议规定的TCP层（非应用层业务代码实现的）检测TCP本端到对方主机的TCP连接的连通性的行为。避免服务器在客户端出现各种不良状况时无法感知，而永远等在这条TCP连接上。

该选项可以设置这个检测行为的细节，如下代码所示：

int keepAlive =1; // 非0值，开启keepalive属性

intkeepIdle =60; // 如该连接在60秒内没有任何数据往来,则进行此TCP层的探测

intkeepInterval =5; // 探测发包间隔为5秒

int keepCount = 3; //尝试探测的次数.如果第1次探测包就收到响应了,则后2次的不再发
setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, (void*)&keepAlive,sizeof(keepAlive));
setsockopt(sockfd, SOL_TCP, TCP_KEEPIDLE,(void*)&keepIdle,sizeof(keepIdle));
setsockopt(sockfd, SOL_TCP, TCP_KEEPINTVL, (void*)&keepInterval,sizeof(keepInterval));
setsockopt(sockfd, SOL_TCP, TCP_KEEPCNT, (void*)&keepCount,sizeof(keepCount));

设置该选项后，如果60秒内在此套接口所对应连接的任一方向都没有数据交换，TCP层就自动给对方发一个保活探测分节(keepaliveprobe)。这是一个对方必须响应的TCP分节。它会导致以下三种情况：

对方接收一切正常：以期望的ACK响应。60秒后，TCP将重新开始下一轮探测。

对方已崩溃且已重新启动：以RST响应。套接口的待处理错误被置为ECONNRESET。

对方无任何响应：比如客户端那边已经断网，或者客户端直接死机。以设定的时间间隔尝试3次，无响应就放弃。套接口的待处理错误被置为ETIMEOUT。

全局设置可更改/etc/sysctl.conf,加上:

net.ipv4.tcp_keepalive_intvl= 5
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_time = 60

在程序中表现为：

阻塞模型下，当TCP层检测到对端socket不再可用时，内核无法主动通知应用层出错，只有应用层主动调用read()或者write()这样的IO系统调用时，内核才会利用出错来通知应用层。

非阻塞模型下，select或者epoll会返回sockfd可读,应用层对其进行读取时，read()会报错。

一点经验：
实际上我们在做服务器程序的时候，对客户端的保活探测基本上不依赖于这个TCP层的keepalive探测机制。
而是我们自己做一套应用层的请求应答消息，在应用层实现这样一个功能。

http://blog.csdn.net/yusiguyuan/article/details/21457811