这里最重要的一个调用sk->sk_prot->hash(sk),也就是inet_hash,其将当前sock链入全局的listen hash表,这样就可以在SYN包到来的时候寻找到对应的listen sock了 。如下图所示:
文章插图
如图中所示,如果开启了SO_REUSEPORT的话,可以让不同的Socket listen(监听)同一个端口,这样就能在内核进行创建连接的负载均衡 。在Nginx 1.9.1版本开启了之后,其压测性能达到3倍!
文章插图
半连接队列hash表和全连接队列在笔者一开始翻阅的资料里面,都提到 。tcp的连接队列有两个,一个是sync_queue,另一个accept_queue 。但笔者仔细阅读了一下源码,其实并非如此 。事实上,sync_queue其实是个hash表(syn_table) 。另一个队列是icsk_accept_queue 。
所以在本篇文章里面,将其称为reqsk_queue(request_socket_queue的简称) 。在这里,笔者先给出这两个queue在三次握手时候的出现时机 。如下图所示:
文章插图
当然了,除了上面提到的qlen和sk_ack_backlog这两个计数器之外,还有一个qlen_young,其作用如下:
qlen_young: 记录的是刚有SYN到达,没有被SYN_ACK重传定时器重传过SYN_ACK同时也没有完成过三次握手的sock数量
如下图所示:文章插图
至于SYN_ACK的重传定时器在内核中的代码为下面所示:
static void tcp_synack_timer(struct sock *sk){ inet_csk_reqsk_queue_prune(sk, TCP_SYNQ_INTERVAL,TCP_TIMEOUT_INIT, TCP_RTO_MAX);}
这个定时器在半连接队列不为空的情况下,以200ms(TCP_SYNQ_INTERVAL)为间隔运行一次 。限于篇幅,笔者就在这里不多讨论了 。为什么要存在半连接队列因为根据TCP协议的特点,会存在半连接这样的网络攻击存在,即不停的发SYN包,而从不回应SYN_ACK 。如果发一个SYN包就让Kernel建立一个消耗极大的sock,那么很容易就内存耗尽 。所以内核在三次握手成功之前,只分配一个占用内存极小的request_sock,以防止这种攻击的现象,再配合syn_cookie机制,尽量抵御这种半连接攻击的风险 。
半连接hash表和全连接队列的限制由于全连接队列里面保存的是占用内存很大的普通sock,所以Kernel给其加了一个最大长度的限制 。这个限制为:
下面三者中的最小值
1.listen系统调用中传进去的backlog
2./proc/sys/inet/ipv4/tcp_max_syn_backlog
3./proc/sys/net/core/somaxconn
即min(backlog,tcp_ma_syn_backlog,somaxcon)
如果超过这个somaxconn会被内核丢弃,如下图所示:
文章插图
这种情况的连接丢弃会发生比较诡异的现象 。在不设置tcp_abort_on_overflow的时候,client端无法感知,就会导致即在第一笔调用的时候才会知道对端连接丢弃了 。
文章插图
那么,怎么让client端在这种情况下感知呢,我们可以设置一下tcp_abort_on_overflow
echo '1' > tcp_abort_on_overflow
设置后,如下图所示:文章插图
当然了,最直接的还是调大backlog!
listen(fd,2048)echo '2048' > /proc/sys/inet/ipv4/tcp_max_syn_backlogecho '2048' > /proc/sys/net/core/somaxconn
backlog对半连接队列的影响这个backlog对半连接队列也有影响,如下代码所示: /* TW buckets are converted to open requests without* limitations, they conserve resources and peer is* evidently real one.*/ // 在开启SYN cookie的情况下,如果半连接队列长度超过backlog,则发送cookie // 否则丢弃 if (inet_csk_reqsk_queue_is_full(sk) && !isn) {want_cookie = tcp_syn_flood_action(sk, skb, "TCP");if (!want_cookie)goto drop; } /* 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.*/ // 在全连接队列满的情况下,如果有young_ack,那么直接丢弃 if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) {NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);goto drop; }
我们在dmesg里面经常看到的Possible SYN flooding on port 8080
就是由于半连接队列满以后,Kernel发送cookie校验而导致 。
推荐阅读
- linux网络编程常见API详解
- Spring Cloud微服务分布式物联网平台前后端分离源码
- 大学|国内3所“神秘”的大学,入学要签保密协议,毕业后就从事铁饭碗
- 怀表收藏如何挑选
- 茭白的种植第二年需不需要再从种 茭白需要每年种植吗
- Python爬虫遇到验证码的几种处理方式,文章末尾有源码
- 从生日看性格 出生日期隐藏的性格秘密
- 猫咪回家后一直在沙发下躲着 猫从沙发上摔下来
- 金毛从小什么时候可以养到大 金毛小的时候
- 现在ktv的发展如何 ktv行业现状