TCP Linger的坑
昨天和同事奋战几个小时,解决了一个linger造成的bug。
现象是这样的,这是一个我从原型接手,扩充了各种功能成为可用代码的epoll实现的非阻塞socket server程序,接收大量的短连接,测试发现性能有问题,用gperftools的cpu profiler也没看出问题。就在一些可疑调用的地方前后加时间,耗时较长的就打出来。一开始发现是epoll处理某些fd的时间有时很长,最后发现是close(fd)耗时达一秒。我才想起来,上周为了解决短连接丢数据问题,把原来linger的超时从0改为了1,改回去现象就消失了,最后彻底去掉就解决了。
原来,在linux下,只要开启了linger并设置了非0的超时,那么close时,如果有数据待发送,就会阻塞最多达指定的时间,不管socket是不是阻塞的。看了一下内核代码,也确认是这样处理的,有点出乎意料。
// net/ipv4/tcp.c void tcp_close(struct sock *sk, long timeout) { // ... sk_stream_wait_close(sk, timeout); // ... }
// net/ipv4/af_inet.c int 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超时又会阻塞,因此千万不要用它。
posted on 2014-11-19 21:33 chen3feng 阅读(1089) 评论(0) 编辑 收藏 举报