完美世界有声小说全集,遮天辰东小说,好看的小说君子以泽

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

Node.js是如何處理請求的

TCP 協(xié)議的核心概念

要了解服務器的工作原理首先需要了解 TCP 協(xié)議的工作原理。TCP 是一種面向連接的、可靠的、基于字節(jié)流的傳輸層全雙工通信協(xié)議，它有 4 個特點：面向連接、可靠、流式、全雙工。下面詳細講解這些特性。

面向連接

TCP 中的連接是一個虛擬的連接，本質(zhì)上是主機在內(nèi)存里記錄了對端的信息，我們可以將連接理解為一個通信的憑證。如下圖所示。

那么如何建立連接呢？TCP 的連接是通過三次握手建立的。

服務器首先需要監(jiān)聽一個端口。

客戶端主動往服務器監(jiān)聽的端口發(fā)起一個 syn 包（第一次握手）。

當服務器所在操作系統(tǒng)收到一個 syn 包時，會先根據(jù) syn 包里的目的 IP 和端口找到對應的監(jiān)聽 socket，如果找不到則回復 rst 包，如果找到則發(fā)送 ack 給客戶端（第二次握手），接著新建一個通信 socket 并插入到監(jiān)聽 socket 的連接中隊列（具體的細節(jié)會隨著不同版本的操作系統(tǒng)而變化。比如連接中隊列和連接完成隊列是一條隊列還是兩條隊列，再比如是否使用了 syn cookie 技術(shù)來防止 syn flood 攻擊，如果使用了，收到 syn 包的時候就不會創(chuàng)建 socket，而是收到第三次握手的包時再創(chuàng)建）。

客戶端收到服務器的 ack 后，再次發(fā)送 ack 給服務器，客戶端就完成三次握手進入連接建立狀態(tài)了。

當服務器所在操作系統(tǒng)收到客戶端的 ack 時（第三次握手），處于連接中隊列的 socket 就會被移到連接完成隊列中。

當操作系統(tǒng)完成了一個 TCP 連接，操作系統(tǒng)就會通知相應的進程，進程從連接完成隊列中摘下一個已完成連接的 socket 結(jié)點，然后生成一個新的 fd，后續(xù)就可以在該 fd 上和對端通信。具體的流程如下圖所示。

完成三次握手后，客戶端和服務器就可以進行數(shù)據(jù)通信了。操作系統(tǒng)收到數(shù)據(jù)包和收到 syn 包的流程不一樣，操作系統(tǒng)會根據(jù)報文中的 IP 和端口找到處理該報文的通信 socket（而不是監(jiān)聽 socket），然后把數(shù)據(jù)包（操作系統(tǒng)實現(xiàn)中是一個 skb 結(jié)構(gòu)體）掛到該通信 socket 的數(shù)據(jù)隊列中。

當應用層調(diào)用 read 讀取該 socket 的數(shù)據(jù)時，操作系統(tǒng)會根據(jù)應用層所需大小，從一個或多個 skb 中返回對應的字節(jié)數(shù)。同樣，寫也是類似的流程，當應用層往 socket 寫入數(shù)據(jù)時，操作系統(tǒng)不一定會立刻發(fā)送出去，而是會保存到寫緩沖區(qū)中，然后根據(jù)復雜的 TCP 算法發(fā)送。

當兩端完成通信后需要關閉連接，否則會浪費內(nèi)存。TCP 通過四次揮手實現(xiàn)連接的斷開，第一次揮手可以由任意一端發(fā)起。前面講過 TCP 是全雙工的，所以除了通過四次揮手完成整個 TCP 連接的斷開外，也可以實現(xiàn)半斷開，比如客戶端關閉寫端表示不會再發(fā)送數(shù)據(jù)，但是仍然可以讀取來自對端發(fā)送端數(shù)據(jù)。四次揮手的流程如下。

可靠

TCP 發(fā)送數(shù)據(jù)時會先緩存一份到已發(fā)送待確認隊列中，并啟動一個超時重傳計時器，如果一定時間內(nèi)沒有收到對端到確認 ack，則觸發(fā)重傳機制，直到收到 ack 或者重傳次數(shù)達到閾值才會結(jié)束流程。

流式

建立連接后，應用層就可以調(diào)用發(fā)送接口源源不斷地發(fā)送數(shù)據(jù)。通常情況下，并不是每次調(diào)用發(fā)送接口，操作系統(tǒng)就直接把數(shù)據(jù)發(fā)送出去，這些數(shù)據(jù)的發(fā)送是由操作系統(tǒng)按照一定的算法去發(fā)送的。對操作系統(tǒng)來說，它看到的是字節(jié)流，它會按照 TCP 算法打包出一個個包發(fā)送到對端，所以當對端收到數(shù)據(jù)后，需要處理好數(shù)據(jù)邊界的問題。

從上圖中可以看到，假設應用層發(fā)送了兩個 HTTP 請求，操作系統(tǒng)在打包數(shù)據(jù)發(fā)送時可能的場景是第一個包里包括了 HTTP 請求 1 的全部數(shù)據(jù)和部分請求 2 的數(shù)據(jù)，所以當對端收到數(shù)據(jù)并進行解析時，就需要根據(jù) HTTP 協(xié)議準確地解析出第一個 HTTP 請求對應的數(shù)據(jù)。

因為 TCP 的流式協(xié)議，所以基于 TCP 的應用層通常需要定義一個應用層協(xié)議，然后按照應用層協(xié)議實現(xiàn)對應的解析器，這樣才能完成有效的數(shù)據(jù)通信，比如常用的 HTTP 協(xié)議。對比來說 UDP 是面向數(shù)據(jù)包的協(xié)議，當應用層把數(shù)據(jù)傳遞給 UDP 時，操作系統(tǒng)會直接打包發(fā)送出去（如果數(shù)據(jù)字節(jié)大小超過閾值則會報錯）。

全雙工

剛才提到 TCP 是全雙工的，全雙工就是通信的兩端都有一個發(fā)送隊列和接收隊列，可以同時發(fā)送和接收，互不影響。另外也可以選擇關閉讀端或者寫端。

服務器的工作原理

介紹了 TCP 協(xié)議的概念后，接著看看如何創(chuàng)建一個 TCP 服務器（偽代碼）。

// 創(chuàng)建一個 socket，拿到一個文件描述符
int server_fd = socket();
// 綁定地址（IP + 端口）到該 socket 中
bind(server_fd, addressInfo);
// 修改 socket 為監(jiān)聽狀態(tài)，這樣就可以接收 TCP 連接了
listen(server_fd);

執(zhí)行完以上步驟，一個服務器就啟動了。服務器啟動的時候會監(jiān)聽一個端口，如果有連接到來，我們可以通過 accept 系統(tǒng)調(diào)用拿到這個新連接對應的 socket，那這個 socket 和監(jiān)聽的 socket 是不是同一個呢？

其實 socket 分為監(jiān)聽型和通信型。表面上服務器用一個端口實現(xiàn)了多個連接，但是這個端口是用于監(jiān)聽的，底層用于和客戶端通信的其實是另一個 socket。每當一個連接到來的時候，操作系統(tǒng)會根據(jù)請求包的目的地址信息找到對應的監(jiān)聽 socket，如果找不到就會回復 RST 包，如果找到就會生成一個新的 socket 與之通信（accept 的時候返回的那個）。監(jiān)聽 socket 里保存了監(jiān)聽的 IP 和端口，通信 socket 首先從監(jiān)聽 socket 中復制 IP 和端口，然后把客戶端的 IP 和端口也記錄下來。這樣一來，下次再收到一個數(shù)據(jù)包，操作系統(tǒng)就會根據(jù)四元組從 socket 池子里找到該 socket，完成數(shù)據(jù)的處理。因此理論上，一個服務器能接受多少連接取決于服務器的硬件配置，比如內(nèi)存大小。

接下來分析各種處理連接的方式。

串行模式

串行模式就是服務器逐個處理連接，處理完前面的連接后才能繼續(xù)處理后面的連接，邏輯如下。

while(1) {
    int client_fd  = accept(server_fd);
    read(client_fd);
    write(client_fd);
}

上面的處理方式是最樸素的模型，如果沒有連接，則服務器處于阻塞狀態(tài)，如果有連接服務器就會不斷地調(diào)用 accept 摘下完成三次握手的連接并處理。假設此時有 n 個請求到來，進程會從 accept 中被喚醒，然后拿到一個新的 socket 用于通信，結(jié)構(gòu)圖如下。

這種處理模式下，如果處理的過程中調(diào)用了阻塞 API，比如文件 IO，就會影響后面請求的處理，可想而知，效率是非常低的，而且，并發(fā)量比較大的時候，監(jiān)聽 socket 對應的隊列很快就會被占滿（已完成連接隊列有一個最大長度），導致后面的連接無法完成。這是最簡單的模式，雖然服務器的設計中肯定不會使用這種模式，但是它讓我們了解了一個服務器處理請求的整體過程。

多進程模式

串行模式中，所有請求都在一個進程中排隊被處理，效率非常低下。為了提高效率，我們可以把請求分給多個進程處理。因為在串行處理的模式中，如果有文件 IO 操作就會阻塞進程，繼而阻塞后續(xù)請求的處理。在多進程的模式中，即使一個請求阻塞了進程，操作系統(tǒng)還可以調(diào)度其它進程繼續(xù)執(zhí)行新的任務。多進程模式分為幾種。

按需 fork

按需 fork 模式是主進程監(jiān)聽端口，有連接到來時，主進程執(zhí)行 accept 摘取連接，然后通過 fork 創(chuàng)建子進程處理連接，邏輯如下。

while(1) {  
    int client_fd = accept(socket); 
    // 忽略出錯處理 
    if (fork() > 0) {  
        continue;
        // 父進程負責 accept  
    } else {  
        // 子進程負責處理連接
        handle(client_fd); 
        exit(); 
    }  
}

這種模式下，每次來一個請求，就會新建一個進程去處理，比串行模式稍微好了一點，每個請求都被獨立處理。假設 a 請求阻塞在文件 IO，不會影響 b 請求的處理，盡可能地做到了并發(fā)。它的缺點是

1. 進程數(shù)有限，如果有大量的請求，需要排隊處理。

2. 進程的開銷會很大，對于系統(tǒng)來說是一個負擔。

3. 創(chuàng)建進程需要時間，實時創(chuàng)建會增加處理請求的時間。

pre-fork 模式 + 主進程 accept

pre-fork 模式就是服務器啟動的時候，預先創(chuàng)建一定數(shù)量的進程，但是這些進程是 worker 進程，不負責接收連接，只負責處理請求。處理過程為主進程負責接收連接，然后把接收到的連接交給 worker 進程處理，流程如下。

邏輯如下：

let fds = [[], [], [], …進程個數(shù)];  
let process = [];  
for (let i = 0 ; i < 進程個數(shù); i++) {  
    // 創(chuàng)建管道用于傳遞文件描述符  
    socketpair(fds[i]);  
    let pid;  
    if (pid = fork() > 0) {  
        // 父進程  
        process.push({pid, 其它字段});  
    } else {  
        const index = i;  
        // 子進程處理請求  
        while(1) {  
            // 從管道中讀取文件描述符  
            var client_fd = read(fd[index][1]);  
            // 處理請求  
            handle(client_fd);  
        }  
    }  
}  
// 主進程 accept
for (;;) {  
    const clientFd = accept(socket);  
    // 找出處理該請求的子進程  
    const i = findProcess();  
    // 傳遞文件描述符  
    write(fds[i][0], clientFd);  
}

和 fork 模式相比，pre-fork 模式相對比較復雜，因為在前一種模式中，主進程收到一個請求就會實時 fork 一個子進程，這個子進程會繼承主進程中新請求對應的 fd，可以直接處理該 fd 對應的請求。但是在進程池的模式中，子進程是預先創(chuàng)建的，當主進程收到一個請求的時候，子進程中無法拿得到該請求對應的 fd 。這時候就需要主進程使用傳遞文件描述符的技術(shù)把這個請求對應的 fd 傳給子進程。

pre-fork 模式 + 子進程 accept

剛才介紹的模式中，是主進程接收連接，然后傳遞給子進程處理，這樣主進程就會成為系統(tǒng)的瓶頸，它可能來不及接收和分發(fā)請求給子進程，而子進程卻很空閑。子進程 accept 這種模式也是會預先創(chuàng)建多個進程，區(qū)別是多個子進程會調(diào)用 accept 共同處理請求，而不需要父進程參與，邏輯如下。

int server_fd = socket();
bind(server_fd);
for (let i = 0 ; i < 進程個數(shù); i++) {  
    if (fork() > 0) {  
        // 父進程負責監(jiān)控子進程  
    } else {  
        // 子進程處理請求  
        listen(server_fd);
        while(1) {  
            int client_fd = accept(socket);  
            handle(client_fd);  
        }  
    }  
}

這種模式下多個子進程都阻塞在 accept，如果這時候有一個請求到來，那么所有的子進程都會被喚醒，但是先被調(diào)度的子進程會摘下這個請求節(jié)點，后續(xù)的進程被喚醒后可能會遇到已經(jīng)沒有請求可以處理，而又進入睡眠，這種進程被無效喚醒的現(xiàn)象就是著名的驚群現(xiàn)象。這種模式的處理流程如下。

Nginx 中解決了驚群這個問題，它的處理方式是在 accpet 之前先加鎖，拿到鎖的進程才進行 accept，這樣就保證了只有一個進程會阻塞在 accept，不會引起驚群問題，但是新版操作系統(tǒng)已經(jīng)在內(nèi)核層面解決了這個問題，每次只會喚醒一個進程。

多線程模式

除了使用多進程外，也可以使用多線程技術(shù)處理連接，多線程模式和多進程模式類似，區(qū)別是在進程模式中，每個子進程都有自己的 task_struct，這就意味著在 fork 之后，每個進程負責維護自己的數(shù)據(jù)、資源。線程則不一樣，線程共享進程的數(shù)據(jù)和資源，所以連接可以在多個線程中共享，不需要通過文件描述符傳遞的方式進行處理，比如如下架構(gòu)。

上圖中，主線程負責 accept 請求，然后通過互斥的方式插入一個任務到共享隊列中，線程池中的子線程同樣是通過互斥的方式，從共享隊列中摘取節(jié)點進行處理。

事件驅(qū)動

從之前的處理模式中我們知道，為了應對大量的請求，服務器通常需要大量的進程 / 線程，這是個非常大的開銷。現(xiàn)在很多服務器（Nginx、Nodejs、Redis）都開始使用單進程 + 事件驅(qū)動模式去設計，這種模式可以在單個進程中輕松處理成千上萬的請求。

但也正因為單進程模式下，再多的請求也只在一個進程里處理，這樣一個任務會一直在占據(jù) CPU，后續(xù)的任務就無法執(zhí)行了。因此，事件驅(qū)動模式不適合 CPU 密集型的場景，更適合 IO 密集的場景（一般都會提供線程 / 線程池，負責處理 CPU 或者阻塞型的任務）。大部分操作系統(tǒng)都提供了事件驅(qū)動的 API，但是事件驅(qū)動在不同系統(tǒng)中實現(xiàn)不一樣，所以一般都會有一層抽象層抹平這個差異。這里以 Linux 的 epoll 為例子。

// 創(chuàng)建一個 epoll 實例
int epoll_fd = epoll_create();  
/* 
    在 epoll 給某個文件描述符注冊感興趣的事件，這里是監(jiān)聽的 socket，注冊可讀事件，即連接到來 
    event = { 
        event: 可讀 
        fd：監(jiān)聽 socket 
        // 一些上下文 
    } 
*/  
epoll_ctl(epoll_fd , EPOLL_CTL_ADD , socket, event);  
while(1) {  
    // 阻塞等待事件就緒，events 保存就緒事件的信息，total 是個數(shù)  
    int total= epoll_wait(epoll_fd , 保存就緒事件的結(jié)構(gòu)events, 事件個數(shù), timeout);  
    for (let i = 0; i < total; i++) {  
        if (events[fd] === 監(jiān)聽 socket) {  
            int client_fd = accpet(socket);  
            // 把新的 socket 也注冊到 epoll，等待可讀，即可讀取客戶端數(shù)據(jù)  
            epoll_ctl(epoll_fd , EPOLL_CTL_ADD , client_fd, event);  
        } else {  
            //  從events[i] 中拿到一些上下文，執(zhí)行相應的回調(diào)  
        }  
    }  
}

事件驅(qū)動模式的處理流程為服務器注冊文件描述符和事件到 epoll 中，然后 epoll 開始阻塞，當有事件觸發(fā)時 epoll 就會返回哪些 fd 的哪些事件觸發(fā)了，接著服務器遍歷就緒事件并執(zhí)行對應的回調(diào)，在回調(diào)里可以再次注冊 / 刪除事件，就這樣不斷驅(qū)動著進程的運行。epoll 的原理其實也類似事件驅(qū)動，它底層維護用戶注冊的事件和文件描述符，本身也會在文件描述符對應的文件 / socket / 管道處注冊一個回調(diào)，等被通知有事件發(fā)生的時候，就會把 fd 和事件返回給用戶，大致原理如下。

function epoll_wait() {  
    for 事件個數(shù)  
        // 調(diào)用文件系統(tǒng)的函數(shù)判斷  
        if (事件 [i] 中對應的文件描述符中有某個用戶感興趣的事件發(fā)生 ？) {  
            插入就緒事件隊列  
        } else {  
            /*
                在事件 [i] 中的文件描述符所對應的文件 / socke / 管道等資源中注冊回調(diào)。
                感興趣的事件觸發(fā)后回調(diào) epoll，回調(diào) epoll 后，epoll 把該 event[i] 插入
                就緒事件隊列返回給用戶  
            */
        }  
}

SO_REUSEPORT 端口復用

新版 Linux 支持 SO_REUSEPORT 特性后，使得服務器性能有了很大的提升。SO_REUSEPORT 之前，一個 socket 是無法綁定到同一個地址的，通常的做法是主進程接收連接然后傳遞給子進程處理，或者主進程 bind 后 fork 子進程，然后子進程執(zhí)行 listen，但底層是共享同一個 socket，所以連接到來時所有子進程都會被喚醒，但是只有一個連接可以處理這個請求，其他的進程被無效喚醒。SO_REUSEPORT 特性支持多個子進程對應多個監(jiān)聽 socket，多個 socket 綁定到同一個地址，當連接到來時，操作系統(tǒng)會根據(jù)地址信息找到一組 socket，然后根據(jù)策略選擇一個 socket 并喚醒阻塞在該 socket 的進程，被 socket 喚醒的進程處理自己的監(jiān)聽 socket 下的連接就行，架構(gòu)如下。

除了前面介紹的模式外，還有基于協(xié)程的模式，服務器技術(shù)繁多，就不一一介紹了。

IO 模型

IO 模型是服務器中非常重要的部分，操作系統(tǒng)通常會提供了多種 IO 模型，常見的如下。

阻塞 IO

當線程執(zhí)行一個 IO 操作時，如果不滿足條件，當前線程會被阻塞，然后操作系統(tǒng)會調(diào)度其他線程執(zhí)行。

非阻塞 IO

非阻塞 IO 在不滿足條件的情況下直接返回一個錯誤碼給線程，而不是阻塞線程。

那么這個阻塞是什么意思呢？直接看一段操作系統(tǒng)的代碼。

// 沒有空間可寫了
while(!(space = UN_BUF_SPACE(pupd))) 
{
    // 非阻塞模式，直接返回錯誤碼
    if (nonblock) 
        return(-EAGAIN);
    // 阻塞模式，進入阻塞狀態(tài)
    interruptible_sleep_on(sock->wait);
}

void interruptible_sleep_on(struct wait_queue **p)
{
    // 修改線程狀態(tài)為阻塞狀態(tài)
    __sleep_on(p,TASK_INTERRUPTIBLE);
}

static inline void __sleep_on(struct wait_queue **p, int state)
{
    unsigned long flags;
    // current 代表當前執(zhí)行的線程
    struct wait_queue wait = { current, NULL };
    // 修改線程狀態(tài)為阻塞狀態(tài)
    current->state = state;
    // 當前線程加入到資源的阻塞隊列，資源就緒后喚醒線程
    add_wait_queue(p, &wait);
    // 重新調(diào)度其他線程執(zhí)行，即從就緒的線程中選擇一個來執(zhí)行
    schedule();
}

通過這段代碼，我們就可以非常明確地了解到阻塞和非阻塞到底是指什么。

多路復用 IO

在阻塞式 IO 中，我們需要通過阻塞進程來感知 IO 是否就緒，在非阻塞式 IO 中，我們需要通過輪詢來感知 IO 是否就緒，這些都不是合適的方式。為了更好感知 IO 是否就緒，操作系統(tǒng)實現(xiàn)了訂閱發(fā)布機制，我們只需要注冊感興趣的 fd 和事件，當事件發(fā)生時我們就可以感知到。多路復用 IO 可以同時訂閱多個 fd 的多個事件，是現(xiàn)在高性能服務器的基石?？匆粋€例子。

#include 
#include 
#include 

int main(int argc, char **argv)
{   
    // 用于注冊事件到 kqueue
    struct  kevent event;
    // 用于接收從 kqueue 返回到事件，表示哪個 fd 觸發(fā)了哪些事件
    struct  kevent emit_event;
    int kqueue_fd, file_fd, result;
    // 打開需要監(jiān)控的文件，拿到一個 fd
    file_fd = open(argv[1], O_RDONLY);
    if (file_fd == -1) {
      printf("Fail to open %s", argv[1]);
      return 1;
    }
    // 創(chuàng)建 kqueue 實例
    kqueue_fd = kqueue();
    // 設置需要監(jiān)聽的事件，文件被寫入時觸發(fā)
    EV_SET(&event,file_fd, EVFILT_VNODE, EV_ADD | EV_CLEAR, NOTE_RENAME, 0, NULL);
    // 注冊到操作系統(tǒng)
    result = kevent(kqueue_fd, &event, 1, NULL, 0, NULL);
    // 不斷阻塞等待，直到文件被寫入
    while(1) {
        // result 返回觸發(fā)事件的 fd 個數(shù)，這里是一個
        result = kevent(kqueue_fd, NULL, 0, &emit_event,  1, NULL);
        if (result > 0) {
            printf("%s have been renamed\n", argv[1]);
        }
    }
}

異步 IO

前面介紹的幾種 IO 模型中，當 IO 就緒時需要自己執(zhí)行讀寫操作，而異步 IO 是 IO 就緒時，操作系統(tǒng)幫助線程完成 IO 操作，然后再通知線程操作完成了。下面以 io_uring（Linux 中的異步 IO 框架）為例了解下具體的情況。

uv_loop_t* loop;
napi_get_uv_event_loop(env, &loop);
struct io_uring_info *io_uring_data = (io_uring_info *)loop->data;
// 申請內(nèi)存
struct request *req = (struct request *)malloc(sizeof(*req) + (sizeof(struct iovec) * 1));
req->fd = fd;
req->offset = offset;
// 保存回調(diào)
napi_create_reference(env, args[2], 1, &req->func);
req->env = env;
req->nvecs = 1;
// 記錄buffer大小
req->iovecs[0].iov_len = bufferLength;
// 記錄內(nèi)存地址
req->iovecs[0].iov_base = bufferData;
// 提交給操作系統(tǒng)，操作系統(tǒng)讀完后通知線程，op 為 IORING_OP_READV 表示讀操作
submit_request(op, req, &io_uring_data->ring);

上面的代碼就是我們提交了一個讀請求給操作系統(tǒng)，然后操作系統(tǒng)在文件可讀并且讀完成后通知我們。

Libuv 雖然寫著是異步 IO 庫，但是它并不是真正的異步 IO。它的意思是，你提交一個 IO 請求時，可以注冊一個回調(diào)，然后就可以去做其他事情了，等操作完成后它會通知你，它的底層實現(xiàn)是線程池 + 多路復用 IO。

Node.js TCP 服務器的實現(xiàn)

Node.js 服務器的底層是 IO 多路復用 + 非阻塞 IO，所以可以輕松處理成千上萬的請求，但是因為 Node.js 是單線程的，所以更適合處理 IO 密集型的任務。下面看看 Node.js 中服務器是如何實現(xiàn)的。

啟動服務器

在 Node.js 中，我們通常使用以下方式創(chuàng)建一個服務器。

// 創(chuàng)建一個 TCP Server
const server = net.createServer((socket) => {
  // 處理連接
});

// 監(jiān)聽端口，啟動服務器
server.listen(8888);

使用 net.createServer 可以創(chuàng)建一個服務器，然后拿到一個 Server 對象，接著調(diào)用 Server 對象的 listen 函數(shù)就可以啟動一個 TCP 服務器了。下面來看一下具體的實現(xiàn)。

function createServer(options, connectionListener) {  
  return new Server(options, connectionListener);  
}  

function Server(options, connectionListener) {  
  EventEmitter.call(this);  
  // 服務器收到的連接數(shù)，可以通過 maxConnections 限制并發(fā)連接數(shù)  
  this._connections = 0;  
  // C++ 層的對象，真正實現(xiàn) TCP 功能的地方
  this._handle = null;  
  // 服務器下的連接是否允許半關閉 
  this.allowHalfOpen = options.allowHalfOpen || false;  
  // 有連接時是否注冊可讀事件，如果該 socket 是交給其他進程處理的話可以設置為 true 
  this.pauseOnConnect = !!options.pauseOnConnect;  
}

createServer 返回的是一個一般的 JS 對象，繼續(xù)看一下 listen 函數(shù)的邏輯，listen 函數(shù)邏輯很繁瑣，但是原理大致是一樣的，所以只講解常用的情況。

Server.prototype.listen = function(...args) {  
  /*
    處理入?yún)?，listen 可以接收很多種格式的參數(shù)，
    假設我們這里只傳了 8888 端口號
  */
    const normalized = normalizeArgs(args);  
    //  normalized = [{port: 8888}, null];  
    const options = normalized[0]; 
    // 監(jiān)聽成功后的回調(diào) 
    const cb = normalized[1];  

    // listen 成功后執(zhí)行的回調(diào)  
    if (cb !== null) {
        this.once('listening', cb);
    }
    listenIncluster(this, 
                    null, 
                    options.port | 0, 
                    4,      
                    ...); 
    return this;  
};

listen 處理了入?yún)⒑?，接著調(diào)用了 listenIncluster。

function listenIncluster(server, 
                         address, 
                         port, 
                         addressType,      
                         backlog, 
                         fd, 
                         exclusive) {  
  exclusive = !!exclusive;  
  if (cluster === null) cluster = require('cluster'); 
  if (cluster.isMaster || exclusive) {  
    server._listen2(address, port, addressType, backlog, fd);
    return;  
  }  
}

這里只分析在主進程創(chuàng)建服務器的情況，listenIncluster 中執(zhí)行了 _listen2，_listen2 對應的函數(shù)是 setupListenHandle。

function setupListenHandle(address, port, addressType, backlog, fd) {  
    // 通過 C++ 層導出的 API 創(chuàng)建一個對象，該對象關聯(lián)了 C++ 層的 TCPWrap 對象
    this._handle = new TCP(TCPConstants.SERVER);
    // 創(chuàng)建 socket 并綁定地址到 socket 中
    this._handle.bind(address, port); 
    // 有完成三次握手的連接時執(zhí)行的回調(diào)  
    this._handle.onconnection = onconnection;  
    // 互相關聯(lián)
    this._handle.owner = this;  
    // 執(zhí)行 C++ 層 listen  
    this._handle.listen(backlog || 511);  
    // 觸發(fā) listen 回調(diào)  
    nextTick(this[async_id_symbol], emitListeningNT, this);  
}

setupListenHandle 的邏輯如下。

1. 調(diào)用 new TCP 創(chuàng)建一個 handle（new TCP 對象關聯(lián)了 C++ 層的 TCPWrap 對象）。

2. 保存處理連接的函數(shù) onconnection，當有連接時被執(zhí)行。

3. 調(diào)用了 bind 綁定地址到 socket。

4. 調(diào)用 listen 函數(shù)修改 socket 狀態(tài)為監(jiān)聽狀態(tài)。首先看看 new TCP 做了什么。

void TCPWrap::New(const FunctionCallbackInfo& args) {
  new TCPWrap(env, args.This(), ...);
}

TCPWrap::TCPWrap(Environment* env, Local