nodejs处理tcp连接的核心流程

前几天和一个小伙伴交流了一下nodejs中epoll和处理请求的一些知识，今天简单来聊一下nodejs处理请求的逻辑。我们从listen函数开始。

我们看到，当我们createserver的时候，到libuv层就是传统的网络编程的逻辑。这时候我们的服务就启动了。在poll io阶段，我们的监听型的文件描述符和上下文（感兴趣的事件、回调等）就会注册到epoll中。正常来说就阻塞在epoll。那么这时候有一个tcp连接到来，会怎样呢？epoll首先遍历触发了事件的fd，然后执行fd上下文中的回调，即uvserver_io。我们看看uvserver_io。

从uv__server_io，我们知道libuv在一个循环中不断accept新的fd，然后执行回调，正常来说，回调会消费fd，如此循环，直到没有连接可处理了。接下来，我们重点看看回调里是如何消费fd的，大量的循环会不会消耗过多时间导致libuv的事件循环被阻塞一会。tcp的回调是c++层的onconnection。

代码看起来很复杂，我们只需要关注uv_accept。uv_accept的参数，第一个是服务器对应的handle，第二个是表示和客户端通信的对象。

uv_accept主要就是两个逻辑，把和客户端通信的fd设置到client中，并标记已经消费，从而驱动刚才讲的while循环继续执行。对于上层来说，就是拿到了一个和客户端的对象，在libuv层是结构体，在c++层是一个c++对象，在js层是一个js对象，他们三个是一层层封装且关联起来的，最核心的是libuv的client结构体中的fd，这是和客户端通信的底层门票。最后回调js层，那就是执行net.js的onconnection。onconnection又封装了一个socket对象用于表示和客户端通信，他持有c++层的对象，c++层对象又持有libuv的结构体，libuv结构体又持有fd。

到此这篇关于nodejs处理tcp连接的核心流程的文章就介绍到这了,更多相关nodejs处理tcp连接内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！