[系统运维]TCP异常连接

目录

connect

第一次握手

第三次握手

调优

端口不足

握手情况下

全队列和半队列查询

全连接队列

半连接队列

????????TCP异常连接分为connect，第一次握手，第三次握手源码逻辑介绍，给出优化方案以及查看全连接与半连接的方法。

connect

在连接失败后，大量的端口范围查找，会调用自旋锁等操作与hash查找，引起系统态CPU开销上涨。

第一次握手

客户端

• 1）半队列满，且tcp_syncookies为0

2）全队列满，且有未完成的半连接请求；

3）没有收到synack客户端发起重试，时间要1s以后，对系统有影响；

4）重传时间 1 2 4 8 16 32 翻倍；次数是tcp_syn_retries

int tcp_conn_request(struct request_sock_ops *rsk_ops,
? ? ? ? ? ? ?const struct tcp_request_sock_ops *af_ops,
? ? ? ? ? ? ?struct sock *sk, struct sk_buff *skb)
{

? ? //查看半连接队列是否满

? ? if ((net->ipv4.sysctl_tcp_syncookies == 2 ||
? ? ? ? ?inet_csk_reqsk_queue_is_full(sk)) && !isn) {
? ? ? ? //检查是否开启内核参数tcp_syncookies，一般打开，半连接队列满了仍然可以保证正常握手
? ? ? ? want_cookie = tcp_syn_flood_action(sk, rsk_ops->slab_name);//syn攻击 耗光服务端的半连接队列使用户请求无法响应

? ? ? ? if (!want_cookie)
? ? ? ? ? ? goto drop;
? ? }

? ? //查看全连接队列是否满
? ? if (sk_acceptq_is_full(sk)) {
? ? ? ? NET_INC_STATS(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
? ? ? ? goto drop;
? ? }
}

第三次握手

服务端

1）全连接队列满了则丢弃，客户端不知道，服务器发起syn+ack

2）次数由tcp_synack_retries 控制

（现象制造，不进行accept,让客户端占满连接队列资源）

调优

端口不足

1）调整端口?Ip_local_port_range增大端口范围

2）使用复用连接

3）使用长链接

4）开启tcp_tw_reuse和tcp_tw_recycle

握手情况下

1）打开syncookies

????? 防止过多的请求打满半连接队列；SYN攻击；解决服务端因为半连接队列满而发生的丢包。

2）增加全连接队列长度

????? 全队列：Min(backlog,net.core.somaxconn)

3）尽快调用accept

????? 从全队列中取出连接

4）减少TCP连接次数，尽早拒绝；

????????内核参数tcp_abort_on_overflow发现满了直接发送rst给客户端，客户端收到的是 connection reset by peer

????????用长链接代替短连接；

????????重试的次数不宜加大；

全队列和半队列查询

全连接队列

#netstat -s | grep overflowed

前面数字有变化代表有溢出

半连接队列

?????? netstat –s | grep SYNs 这种方法是不对的，无法说明问题因为全连接溢出也会增加。

? ? ? ? 1）want_cookie参数是不是1，如果是真，则不会发生半连接溢出丢包。

????????2）want_cookie，没有打开，除了netstat –antp，建议查看listen端口上的SYN_RECV的数量

#watch 'netstat -s | grep "SYNs"'

#netstat –antp | grep SYN_RECV | wc -l

?参考
https://course.0voice.com/v1/course/intro?courseId=2&agentId=0