Nginx源代码分析之accept细节（十九）

梦里梦外; 2022-09-25 12:16 241阅读 0赞

现在单独说说accept中与一些具体I/O模型相关的细节。

其实前面已经提过这个问题，这一系列I/O模型中最大差别是iocp，我们前面也说了，linux的几个模型,不管是select,epoll,kqueue，其实都是基于异步通知的，也就是说系统只关心哪个socket有接受和发送完成的消息，然后设置一定的标志，当某个work线程调用select,epoll\_wait,kevent这样的函数发现这个标志后，再调用i/o函数来收发数据。

而iocp不同，他是直接基于异步I/O的，而windows后来增加了多个扩展函数，包括acceptex,connectex，就是为了实现完整的异步功能。并且，异步I/O是按照先来先调用的原则，也就是在同一个socket先投递的I/O请求必然先触发。

根据以上信息，在nginx中iocp是不会引起群惊问题的，因为即使多个线程向同1个监听端口投递了多个acceptext请求，每次客户端的connect只会触发其中一个acceptex。

再看看nginx的源码，在epoll模型中有这样一段代码：

if ((revents & EPOLLIN) && rev->active) \{  
  
  
\#if (NGX\_HAVE\_EPOLLRDHUP)  
if (revents & EPOLLRDHUP) \{  
rev->pending\_eof = 1;  
\}  
\#endif  
  
  
rev->ready = 1;  
  
  
if (flags & NGX\_POST\_EVENTS) \{  
queue = rev->accept ? &ngx\_posted\_accept\_events  
: &ngx\_posted\_events;  
  
  
ngx\_post\_event(rev, queue);  
  
  
\} else \{  
rev->handler(rev);  
\}  
\}

前面章节已经提过，在防群惊模式下，会给flags增加NGX\_POST\_EVENTS标志，执行到这里会根据这个标志把可读请求放到2个缓存队列中，以便尽快释放accept锁。而在iocp的模型中，没有看到这方面的代码，因此我猜测，如果在配置中选择iocp的话，必须关闭群惊锁，,否则整个代码是有一定问题的。

在来看看在ngx\_event\_process\_init里面，iocp与其他模型在初始化过程中的差异，异步消息通知模型，只需要注册rev->handler = ngx\_event\_accept,然后调用gnx\_add\_event即可。而iocp则完全不同，我们看1.97的代码：

if (ngx\_event\_flags & NGX\_USE\_IOCP\_EVENT) \{  
ngx\_iocp\_conf\_t \*iocpcf;  
  
  
rev->handler = ngx\_event\_acceptex;  
  
  
if (ngx\_use\_accept\_mutex) \{  
continue;  
\}  
  
  
if (ngx\_add\_event(rev, 0, NGX\_IOCP\_ACCEPT) == NGX\_ERROR) \{  
return NGX\_ERROR;  
\}  
  
  
ls\[i\].log.handler = ngx\_acceptex\_log\_error;  
  
  
iocpcf = ngx\_event\_get\_conf(cycle->conf\_ctx, ngx\_iocp\_module);  
if (ngx\_event\_post\_acceptex(&ls\[i\], iocpcf->post\_acceptex)  
== NGX\_ERROR)  
\{  
return NGX\_ERROR;  
\}  
  
  
\} else \{  
rev->handler = ngx\_event\_accept;  
  
  
if (ngx\_use\_accept\_mutex) \{  
continue;  
\}  
  
  
if (ngx\_add\_event(rev, NGX\_READ\_EVENT, 0) == NGX\_ERROR) \{  
return NGX\_ERROR;  
\}  
\}

其中对群惊锁的判断其实是没有意义的，抛开这个问题，看看其中的细节，首先仍然是注册ngx\_event\_acceptex，然后执行ngx\_add\_event(rev, 0, NGX\_IOCP\_ACCEPT)，将listen socket加入完成端口的通知对象，伺候调用ngx\_event\_post\_acceptex，此函数会根据文件中的配置生成多个client socket，然后调用ngx\_acceptex，这就同时发起了多个accept异步调用，每个client socket会生成一个对应ngx\_connect,以及相应的rev,wev 事件对象。rev->handler则注册为ngx\_event\_acceptex，ngx\_connect还会记录listen socket，

这其中有一点跟通常iocp模型有差别，一般来说会首先调用ngx\_acceptex，然后在回调函数中再调用ngx\_add\_event(rev, 0, NGX\_IOCP\_IO)来把client socket加入完成端口的通知对象集合，但这里却在刚创建client socket之后就将其加入。

再看ngx\_event\_acceptex，到这里系统已经生成真正的client socket，因此首先调用setsockopt并设置SO\_UPDATE\_ACCEPT\_CONTEXT以复制listen socket的特性，再调用ngx\_getacceptexsockaddrs获取client socket的本地和对端地址然后保存在ngx\_connection里面，接着再次调用ngx\_event\_post\_acceptex，但这次数量限定为1，保持整个进程投递的异步accept总量不变，最后再调用listen socket对象的handler，即ngx\_http\_init\_connection。

再看看ngx\_http\_init\_connection里面的一些细节，到这里首先会注册rev的回调函数ngx\_http\_wait\_request\_handler，然后在352行，则有一段专门针对iocp的代码，首先判断rev->ready是否为1，如果是的话则会直接调用rev->handler即ngx\_http\_wait\_request\_handler。在ngx\_http\_wait\_request\_handler里面，可能已经有附带数据跟accept一起到达，因此需要进行简单的判断：

b = c->buffer;  
  
  
if (b == NULL) \{  
b = ngx\_create\_temp\_buf(c->pool, size);  
if (b == NULL) \{  
ngx\_http\_close\_connection(c);  
return;  
\}  
  
  
c->buffer = b;  
  
  
\} else if (b->start == NULL) \{  
  
  
b->start = ngx\_palloc(c->pool, size);  
if (b->start == NULL) \{  
ngx\_http\_close\_connection(c);  
return;  
\}  
  
  
b->pos = b->start;  
b->last = b->start;  
b->end = b->last + size;  
\}

随后调用n = c->recv(c, b->last, size);也就是iocp版本的ngx\_overlapped\_wsarecv