SO_LINGER这个选项在我以前带队改造haproxy的时候引出过一个reset（RST）客户端连接的bug。
SO_LINGER作用
设置函数close()关闭TCP连接时的行为。缺省close()的行为是，如果有数据残留在socket发送缓冲区中则系统将继续发送这些数据给对方，等待被确认，然后返回。
利用此选项，可以将此缺省行为设置为以下两种
a.立即关闭该连接，通过发送RST分组(而不是用正常的FIN|ACK|FIN|ACK四个分组)来关闭该连接。至于发送缓冲区中如果有未发送完的数据，则丢弃。主动关闭一方的TCP状态则跳过TIMEWAIT，直接进入CLOSED。网上很多人想利用这一点来解决服务器上出现大量的TIMEWAIT状态的socket的问题，但是，这并不是一个好主意，这种关闭方式的用途并不在这儿，实际用途在于服务器在应用层的需求。
b.将连接的关闭设置一个超时。如果socket发送缓冲区中仍残留数据，进程进入睡眠，内核进入定时状态去尽量去发送这些数据。
在超时之前，如果所有数据都发送完且被对方确认，内核用正常的FIN|ACK|FIN|ACK四个分组来关闭该连接，close()成功返回。
如果超时之时，数据仍然未能成功发送及被确认，用上述a方式来关闭此连接。close()返回EWOULDBLOCK。
SO_LINGER选项使用如下结构：
struct linger {
int l_onoff;
int l_linger;
};
l_onoff为0，则该选项关闭，l_linger的值被忽略，close()用上述缺省方式关闭连接。
l_onoff非0，l_linger为0，close()用上述a方式关闭连接。
l_onoff非0，l_linger非0，close()用上述b方式关闭连接。
值得一说的是，不管你用什么方式使用SO_LINGER，都需要大量耐心的测试来确保你的服务器程序确实是按照你的意愿在跑，因为这个选项对服务器处理小量请求的行为影响非常细微，简单的功能测试很难验证它的行为，上线后量大的情况下可能会出问题，让你的服务器马上下线，大并发量的模拟实际场景压测才能保证其正确性:)
