TCP的选项SO_LINGER设置延时关闭

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，都需要大量耐心的测试来确保你的服务器程序确实是按照你的意愿在跑，因为这个选项对服务器处理小量请求的行为影响非常细微，简单的功能测试很难验证它的行为，上线后量大的情况下可能会出问题，让你的服务器马上下线，大并发量的模拟实际场景压测才能保证其正确性:)

1               慎用TCP的选项SO_LINGER

最近有一次性能测试，通讯程序出现错误，表现为服务器处理速度明显降低，检查发现服务器的很多句柄出于TIME_WAIT状态，Justin这个流氓的自己承认测试用例写的有问题，在recv函数返回0后，没有close句柄。

我很郁闷google了一下如何处理这类错误，发现了SO_LINGER这个选项，发现这个选项可以避免端口的状态进入TIME_WAIT状态，大胆的进行了一下测试。发现在性能测试中，服务器的表现好了不少，暗爽。

//使用SO_LINGER，close后不进入TIME_WAIT状态

struct linger linger;

linger.l_onoff = 1;

linger.l_linger = 0;

setsockopt(serverSocket,

  SOL_SOCKET, SO_LINGER,

  (const char *) &linger,

  sizeof(linger));

周3发版本，突然发现很多同事的都报告出现了一些错误，从客户端的日志反馈看，客户端在最后阶段往往没有收到几个我们的服务器的返回命令，于是立即想到了可能是这个选项导致了麻烦。注释这个选项后，果然大家的程序都正常了。

回头仔细读了一下《UNIX网络编程》卷1，才慢慢回想起来，TIME_WAIT的作用是保证在主动关闭端口后，保证数据让对端收到，Richard.Steven的原话是”TIME_WAIT是我们的朋友。”

由于我们客户端要和多个游戏服务器通讯，而且之间还有一些时序关系，所以我们不能使用这种让用户丢弃一部分数据的方式。对于TCP的细节感觉还是不熟悉，呵呵。

不能丢弃TIME_WAIT状态，但是让他缩短一些也是可以的。我们可以在l_linger参数上动点手脚，当l_onoff非0是。l_linge也非0的时候，套接口在TIME_WAIT上将拖延一段时间，l_linger秒，而不再是2MSL的超时[注]。我也打算继续试验一下。

 

【注】，根据《UNIX网络编程》卷1，需要注意的是，l_linger非0的解释在不同的平台可能不一样，BSD平台的实现是0.01s。