网站建设是不是无形资产微信开发小程序开发网站建设

当前位置： 首页 > news >正文

网站建设是不是无形资产,微信开发小程序开发网站建设,OA网站建设分析,北京微信小程序开发今天就从Linux源码的角度看下Server端的Socket在进行listen的时候到底做了哪些事情(基于Linux 3.10内核)#xff0c;当然由于listen的backlog参数和半连接hash表以及全连接队列都相关#xff0c;在这里也一块讲了。 Server端Socket需要Listen 众所周知#xff0c;一个Serv…今天就从Linux源码的角度看下Server端的Socket在进行listen的时候到底做了哪些事情(基于Linux 3.10内核)当然由于listen的backlog参数和半连接hash表以及全连接队列都相关在这里也一块讲了。 Server端Socket需要Listen 众所周知一个Server端Socket的建立需要socket、bind、listen、accept四个步骤。 今天笔者就聚焦于Listen这个步骤。 代码如下: void start_server(){// server fdint sockfd_server;// accept fd int sockfd;int call_err;struct sockaddr_in sock_addr;……call_errbind(sockfd_server,(struct sockaddr)(sock_addr),sizeof(sock_addr));if(call_err -1){fprintf(stdout,bind error!\n);exit(1);}// 这边就是我们今天的聚焦点listencall_errlisten(sockfd_server,MAX_BACK_LOG);if(call_err -1){fprintf(stdout,listen error!\n);exit(1);} }首先我们通过socket系统调用创建了一个socket其中指定了SOCK_STREAM,而且最后一个参数为0也就是建立了一个通常所有的TCP Socket。在这里我们直接给出TCP Socket所对应的ops也就是操作函数。 资料直通车最新Linux内核源码资料文档视频资料 内核学习地址Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈 Listen系统调用 好了现在我们直接进入Listen系统调用吧。 #include sys/socket.h // 成功返回0,错误返回-1,同时错误码设置在errno int listen(int sockfd, int backlog);注意这边的listen调用是被glibc的INLINE_SYSCALL装过一层其将返回值修正为只有0和-1这两个选择同时将错误码的绝对值设置在errno内。 这里面的backlog是个非常重要的参数如果设置不好是个很隐蔽的坑。 对于java开发者而言基本用的现成的框架而java本身默认的backlog设置大小只有50。这就会引起一些微妙的现象这个在本文中会进行讲解。 接下来我们就进入Linux内核源码栈吧 listen|-INLINE_SYSCALL(listen……)|-SYSCALL_DEFINE2(listen, int, fd, int, backlog)/ 检测对应的描述符fd是否存在不存在返回-BADF|-sockfd_lookup_light/* 限定传过来的backlog最大值不超出 /proc/sys/net/core/somaxconn|-if ((unsigned int)backlog somaxconn) backlog somaxconn|-sock-ops-listen(sock, backlog) inet_listen值得注意的是Kernel对于我们传进来的backlog值做了一次调整让其无法内核参数设置中的somaxconn。 inet_listen 接下来就是核心调用程序inet_listen了。 int inet_listen(struct socket sock, int backlog) {/ Really, if the socket is already in listen state* we can only allow the backlog to be adjusted.*if ((sysctl_tcp_fastopen TFO_SERVER_ENABLE) ! 0 inet_csk(sk)-icsk_accept_queue.fastopenq NULL) {fastopen的逻辑if ((sysctl_tcp_fastopen TFO_SERVER_WO_SOCKOPT1) ! 0)err fastopen_init_queue(sk, backlog);else if ((sysctl_tcp_fastopen TFO_SERVER_WO_SOCKOPT2) ! 0)err fastopen_init_queue(sk,((uint)sysctl_tcp_fastopen) 16);elseerr 0;if (err)goto out;}if(old_state ! TCP_LISTEN) {err inet_csk_listen_start(sk, backlog);}sk-sk_max_ack_backlog backlog;…… }从这段代码中第一个有意思的地方就是,listen这个系统调用可以重复调用第二次调用的时候仅仅只能修改其backlog队列长度(虽然感觉没啥必要)。 首先我们看下除fastopen之外的逻辑(fastopen以后开单章详细讨论)。也就是最后的inet_csk_listen_start调用。 int inet_csk_listen_start(struct sock *sk, const int nr_table_entries) {……// 这里的nr_table_entries即为调整过后的backlog// 但是在此函数内部会进一步将nr_table_entries min(backlog,sysctl_max_syn_backlog)这个逻辑int rc reqsk_queue_alloc(icsk-icsk_accept_queue, nr_table_entries);……inet_csk_delack_init(sk);// 设置socket为listen状态sk-sk_state TCP_LISTEN;// 检查端口号if (!sk-sk_prot-get_port(sk, inet-inet_num)){// 清除掉dst cachesk_dst_reset(sk);// 将当前sock链入listening_hash// 这样当SYN到来的时候就能通过inet_lookup_listen函数找到这个listen中的socksk-sk_prot-hash(sk);}sk-sk_state TCP_CLOSE;reqsk_queue_destroy(icsk-icsk_accept_queue);// 端口已经被占用返回错误码-EADDRINUSEreturn -EADDRINUSE; }这里最重要的一个调用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_backlog echo 2048 /proc/sys/net/core/somaxconnbacklog对半连接队列的影响 这个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校验而导致。