昨天和同事奋战几个小时，解决了一个linger造成的bug。

现象是这样的，这是一个我从原型接手，扩充了各种功能成为可用代码的epoll实现的非阻塞socket server程序，接收大量的短连接，测试发现性能有问题，用gperftools的cpu profiler也没看出问题。就在一些可疑调用的地方前后加时间，耗时较长的就打出来。一开始发现是epoll处理某些fd的时间有时很长，最后发现是close(fd)耗时达一秒。我才想起来，上周为了解决短连接丢数据问题，把原来linger的超时从0改为了1，改回去现象就消失了，最后彻底去掉就解决了。

原来，在linux下，只要开启了linger并设置了非0的超时，那么close时，如果有数据待发送，就会阻塞最多达指定的时间，不管socket是不是阻塞的。看了一下内核代码，也确认是这样处理的，有点出乎意料。

// net/ipv4/tcp.cvoid tcp_close(struct sock *sk, long timeout){        // ...	sk_stream_wait_close(sk, timeout);        // ...}

// net/ipv4/af_inet.cint inet_release(struct socket *sock){	struct sock *sk = sock->sk;	if (sk) {		long timeout;                // ...		timeout = 0;		if (sock_flag(sk, SOCK_LINGER) &&		    !(current->flags & PF_EXITING))			timeout = sk->sk_lingertime;		sock->sk = NULL;		sk->sk_prot->close(sk, timeout);	}	return 0;}

回想当初是这个错误的原因是，因为manpage里没找到，我查一些文章却说close一个这样的socket时，会返回EWOULDBLOCK，大意了。至于代码当初为什么会开启linger，估计是为了消除TIME_WAIT，但是这种做法是得不偿失的。

查阅MSDN closesocket的文档，发现winsock下的行为不一样，会返回EWOULDBLOCK，这可能就是误导我的文章的说法的出处吧。

结论：对于使用非阻塞socket的程序，linger基本就是个无用且有害的选项，开启并设置0超时会丢数据，设置非0超时又会阻塞，因此千万不要用它。

TCP Linger的坑