短链接的time_out的问题（我们组的人对线上业务的改进）
问题现象：
yp_fras前段时间经常会大量出现错误号为110的connection time out 错误
691: yp_wp075v.add.bjdt.qihoo.net [2016/06/12:14:52:03] access [xxx.xxx.xxx.xxx:9869] table: yp_fras catch exception in __construct: [BadaSocket: Could not connect to xxx.xxx.xxx.xxx:9869 (连接超时 [110])]
692: yp_wp023v.add.bjdt.qihoo.net [2016/06/12:14:52:03] access [xxx.xxx.xxx.xxx:9869] table: yp_fras catch exception in __construct: [BadaSocket: Could not connect to xxx.xxx.xxx.xxx:9869 (连接超时 [110])]
693: yp_wp089v.add.bjdt.qihoo.net [2016/06/12:14:52:03] access [xxx.xxx.xxx.xxx:9869] table: yp_fras catch exception in __construct: [BadaSocket: Could not connect to xxx.xxx.xxx.xxx:9869 (连接超时 [110])]
694: yp_wp080v.add.bjdt.qihoo.net [2016/06/12:14:52:07] access [xxx.xxx.xxx.xxx:9869] table: yp_fras catch exception in __construct: [BadaSocket: Could not connect to xxx.xxx.xxx.xxx:9869 (连接超时 [110])]
1: yp_wp054v.add.bjdt.qihoo.net [2016/0
问题结论
这个问题是由大量的短链接造成的，据初步统计，有近百台客户机上部署有访问bjdt机房yp_vrs的客户端，每个客户机上又有不少的客户端。当这些客户端在某个时刻以短链接的方式集中访问服务端时，TCP连接建立的压力是比较惊人的。
客户端大量的短连接请求，使得服务端的listen端口的ACCEPT队列产生溢出，从而不接受新的连接请求，连接失败，导致”[110][connection time out]”报错。
改进意见
提高客户端的链接超时限制。当前是300ms，比如可以提升到3s等；（治标不治本）
提高服务端的somaxconn限制，这也是个治标不治本的方法，只能是一定程度的缓解。（修改内核的其他的网络参数也是一样，只能是缓解，并不能解决根本问题）
在客户端使用连接缓冲池，将短链接转换成长链接来使用（个人认为这个才是更好的办法，一劳永逸）
问题分析
Linux的服务端从listen的端口建立的连接要经过两个队列的过渡，分别是SYN队列和ACCEPT队列。服务端接受到SYN请求后，会发送SYNACK，并把这个request sock存在SYN队列内；等到三次握手完成后，再存放到ACCEPT队列内；然后再由accept系统调用，从ACCEPT队列内拿出，交给用户使用。
SYN队列和ACCEPT队列都是有长度限制的，这个长度限制与以下三个参数有关：
- a. 调用listen接口，传递给back_log参数；
- b. 内核参数somaxconn; //与ACCEPT队列相关
- c.内核参数tcp_max_syn_backlog； //与SYN队列相关
我们线上的问题主要是ACCEPT队列出现溢出造成的，所以这里主要分析ACCEPT队列长度限制的情况
在调用listen接口的时候，内核会用系统的somaxconn参数去截断传递给listen的back_log参数，下面是linux2.6.32-70的相关代码片段
@sock.c
SYSCALL_DEFINE2(listen, int, fd, int, backlog)
{
......
if ((unsigned)backlog > somaxconn)
backlog = somaxconn; //被截断
......
err = sock->ops->listen(sock, backlog);//调用的就是下面的inet_listen函数
......
}
@af_inet.c
int inet_listen(struct socket *sock, int backlog)
{
......
sk->sk_max_ack_backlog = backlog;
......
}
上面的sk_max_ack_backlog就是listen端口的ACCEPT队列的最大长度
当短链接的量太大，accept系统调用接口处理来不及时，ACCEPT队列就可能会阻塞溢出，这个时候，Linux的TCP/IP协议栈的做法是把新来的SYN请求丢弃掉（ Accept backlog is full. If we have already queued enough of warm entries in syn queue, drop request. It is better than clogging syn queue with openreqs with exponentially increasing timeout.），这样当客户端设定的连接超时不够发送第二次SYN请求时，就会收不到服务端ack，连接建立失败，这个时候报的错误是ETIMEDOUT，也就是“[110][connection time out]“。下面是linux.2.6.32-70的相关代码片段
@tcp_ipv4.c
int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
......
if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) //inet_csk_reqsk_queue_young(sk) 表示SYN队列中还没有握手完成的请求数，也就是young request sock的数量
goto drop;//丢弃这个SYN请求
......
}
@sock.h
static inline int sk_acceptq_is_full(struct sock *sk)
{
return sk->sk_ack_backlog > sk->sk_max_ack_backlog;
}
在上面的代码段中，sk_acceptq_is_full(sk)是判断ACCEPT队列是否满了（队列长度限制已经在listen系统调用中被截断了，这也是为什么我们修改内核somaxconn内核参数，对当前应用程序的已经listen的端口的ACCEPT队列长度限制不产生影响的原因，需要重起，才能够使用新的内核参数），如果满了，而且SYN队列中又有新的没有完成握手的连接请求，则丢弃当前这个链接请求，这个时候的如果客户端设置的链接超时只够它发送一次SYN请求，则链接失败，发生“[110][connection time out]“报错。
验证:
- 按照线上情况，设置somaxconn为128,listen接口的back_log为8192 运行一定数量的客户端，频繁的向服务端建立TCP链接，然后释放，观察情况
- 设置somaxconn为8192, 同时设置listen的接口的back_log参数也为8192,重复1的步骤
<?php
while (true) {
$fp = fsockopen ( "10.138.79.205" , 8221 , $errno , $errstr , 0.5 );
fclose ( $fp );
}
?>
上面是单个客户端的代码逻辑，很简单。
somaxconn为128。
客户端大量报错
PHP Warning: fsockopen(): unable to connect to xxxxxxxxxxx:8221 (Connection refused) in /home/wxf/sample.php on line 3
PHP Warning: fsockopen(): unable to connect to xxxxxxxxxxx:8221 (Connection refused) in /home/wxy/sample.php on line 3
PHP Warning: fsockopen(): unable to connect to xxxxxxxxxxx:8221 (Connection refused) in /home/wxy/sample.php on line 3
....
服务端的现象
[wxf@host ~]$ for i in {1..6}; do netstat -s | grep -i listen; echo; sleep 1; done
2436905 times the listen queue of a socket overflowed
2436905 SYNs to LISTEN sockets ignored
2436927 times the listen queue of a socket overflowed
2436927 SYNs to LISTEN sockets ignored
2436950 times the listen queue of a socket overflowed
2436950 SYNs to LISTEN sockets ignored
2436985 times the listen queue of a socket overflowed
2436985 SYNs to LISTEN sockets ignored
2436999 times the listen queue of a socket overflowed
2436999 SYNs to LISTEN sockets ignored
2437018 times the listen queue of a socket overflowed
2437018 SYNs to LISTEN sockets ignored
从上面的结果可以看出，被丢弃的SYNs在不断的增加
somaxconn为8192
客户端没有报错
服务端
[wxy@host ~]$ for i in {1..6}; do netstat -s | grep -i listen; echo ;sleep 1; done
2439591 times the listen queue of a socket overflowed
2439591 SYNs to LISTEN sockets ignored
2439591 times the listen queue of a socket overflowed
2439591 SYNs to LISTEN sockets ignored
2439591 times the listen queue of a socket overflowed
2439591 SYNs to LISTEN sockets ignored
2439591 times the listen queue of a socket overflowed
2439591 SYNs to LISTEN sockets ignored
2439591 times the listen queue of a socket overflowed
2439591 SYNs to LISTEN sockets ignored
2439591 times the listen queue of a socket overflowed
2439591 SYNs to LISTEN sockets ignored
可以看出，这段时间内没有被丢弃的SYNs
验证的结果和内核代码以及我们的预想是吻合的
**˜˜
网友评论