从Linux源码看Socket(TCP)的accept

从Linux源码看Socket(TCP)的accept

前言

笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件Exciting的事情。今天笔者就从Linux源码的角度看下Server端的Socket在进行Accept的时候到底做了哪些事情(基于Linux 3.10内核)。

一个最简单的Server端例子

void start_server(){
    // server fd
    int sockfd_server;
    // accept fd 
    int sockfd;
    int call_err;
    struct sockaddr_in sock_addr;
     ......
    call_err=bind(sockfd_server,(struct sockaddr*)(&sock_addr),sizeof(sock_addr));
      ......
    call_err=listen(sockfd_server,MAX_BACK_LOG);
     ......
    while(1){
        struct sockaddr_in* s_addr_client = mem_alloc(sizeof(struct sockaddr_in));
              int client_length = sizeof(*s_addr_client);
         // 这边就是我们今天的聚焦点accept
        sockfd = accept(sockfd_server,(struct sockaddr_ *)(s_addr_client),(socklen_t *)&(client_length));
        if(sockfd == -1){
            printf("Accept error!\n");
            continue;
        }
        process_connection(sockfd,(struct sockaddr_in*)(&s_addr_client));
    }
}

accept系统调用

好了，我们直接进入accept系统调用吧。

#include <sys/socket.h>
// 成功，返回代表新连接的描述符，错误返回-1,同时错误码设置在errno
int accept(int sockfd,struct sockaddr* addr,socklen_t *addrlen);
// 注意,实际上Linux还有个accept扩展accept4:
// 额外添加的flags参数可以为新连接描述符设置O_NONBLOCK|O_CLOEXEC(执行exec后关闭)这两个标记
int accept4(int sockfd, struct sockaddr *addr,socklen_t *addrlen, int flags);

注意，这边的accept调用是被glibc用SYSCALL_CANCEL包了一层，其将返回值修正为只有0和-1这两个选择，同时将错误码的绝对值设置在errno内。由于glibc对于系统调用的封装过于复杂，就不在这里细讲了。如果要寻找具体的逻辑，用

// 注意accept和(之间要有空格，不然搜索不到
accept (int

accept
 |->SYSCALL_CANCEL(accept......)
   ......
    |->SYSCALL_DEFINE3(accept
     // 最终调用了sys_accept4
     |->sys_accept4    
      /* 检测监听描述符fd是否存在，不存在，返回-BADF
      |->sockfd_lookup_light
       |->sock_alloc /*新建Socket*/
         |->get_unused_fd_flags /*获取一个未用的fd*/
          |->sock->ops->accept(sock...) /*调用核心*/

sock->ops->accept
        |->inet_steam_ops->accept(inet_accept)
            /* 由一开始的sock图可知sk_prot=tcp_prot
            |->sk1->sk_prot->accept
                |->inet_csk_accept

好了，穿过了层层包装，终于到具体逻辑部分了。上代码:

struct sock *inet_csk_accept(struct sock *sk, int flags, int *err)
{
    struct inet_connection_sock *icsk = inet_csk(sk);
    /* 获取当前监听sock的accept队列*/
    struct request_sock_queue *queue = &icsk->icsk_accept_queue;
    ......
    /* 如果监听Socket状态非TCP_LISEN,返回错误 */
    if (sk->sk_state != TCP_LISTEN)
        goto out_err
    /* 如果当前accept队列为空 */
    if (reqsk_queue_empty(queue)) {
        long timeo = sock_rcvtimeo(sk, flags & O_NONBLOCK);
        /* 如果是非阻塞模式，直接返回-EAGAIN */
        error = -EAGAIN;
        if (!timeo)
            goto out_err;
        /* 如果是阻塞模式，切超时时间不为0,则等待新连接进入队列 */
        error = inet_csk_wait_for_connect(sk, timeo);
        if (error)
            goto out_err;
    }    
    /* 到这里accept queue不为空,从queue中获取一个连接 */
    req = reqsk_queue_remove(queue);
    newsk = req->sk;
    /* fastopen 判断逻辑 */
    ......
    /* 返回新的sock,也就是accept派生出的和client端对等的那个sock */
    return newsk
}

static int inet_csk_wait_for_connect(struct sock *sk, long timeo)
{
    for (;;) {
        /* 通过增加EXCLUSIVE标志使得在BIO中调用accept中不会产生惊群效应 */
        prepare_to_wait_exclusive(sk_sleep(sk), &wait,
                      TASK_INTERRUPTIBLE);
        if (reqsk_queue_empty(&icsk->icsk_accept_queue))
            timeo = schedule_timeout(timeo);
        .......
        err = -EAGAIN;
        /* 这边accept超时，返回的是-EAGAIN */
        if (!timeo)
            break;
    }
    finish_wait(sk_sleep(sk), &wait);
    return err;                        
}

通过exclusice标志使得我们在BIO中调用accept(不用epoll/select等)时，不会惊群。

由代码得知在accept超时时候返回(errno)的是EAGAIN而不是ETIMEOUT。

EPOLL(在accept时候)”惊群”

由于在EPOLL LT(水平触发模式下),一次accept事件，可能会唤醒多个等待在此listen fd上的(epoll_wait)线程,而最终可能只有一个能成功的获取到新连接(newfd),其它的都是-EGAIN，也即有一些不必要的线程被唤醒了，做了无用功。关于epoll的原理可以看下笔者之前的博客《从linux源码看epoll》:

https://my.oschina.net/alchemystar/blog/3008840

// 通过f_op->poll判定
epi->ffd.file->f_op->poll
    |->tcp_poll
        /* 如果sock是listen状态，则由下面函数负责 */
        |->inet_csk_listen_poll

/* 通过accept_queue队列是否为空判断监听sock是否有未处理事件*/
static inline unsigned int inet_csk_listen_poll(const struct sock *sk)
{
    return !reqsk_queue_empty(&inet_csk(sk)->icsk_accept_queue) ?
            (POLLIN | POLLRDNORM) : 0;
}

其实不仅仅是accept,要是多线程epoll_wait同一个fd的read/write也是同样的惊群，只不过应该不会有人这么做吧。

正是由于这种”惊群”效应的存在，所以我们经常采用单开一个线程去专门accept的形式，例如reactor模式即是如此。但是，如果一瞬间有大量连接涌进来，单线程处理还是有瓶颈的,无法充分利用多核的优势,在海量短连接场景下就显得稍显无力了。这也是有解决方式的！

采用so_reuseport解决惊群

accept_queue全连接队列

https://my.oschina.net/alchemystar/blog/3098219

另外，对于accept_queue具体的填充机制以及源码，可以见笔者另一篇博客的详细分析

《从Linux源码看Socket(TCP)的listen及连接队列》：

https://my.oschina.net/alchemystar/blog/4672630

总结