日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

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

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

面向連接

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

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

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

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

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

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

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

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

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

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

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

可靠

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

流式

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

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

因為 TCP 的流式協(xié)議，所以基于 TCP 的應用層通常需要定義一個應用層協(xié)議，然后按照應用層協(xié)議實現(xiàn)對應的解析器，這樣才能完成有效的數(shù)據通信，比如常用的 HTTP 協(xié)議。對比來說 UDP 是面向數(shù)據包的協(xié)議，當應用層把數(shù)據傳遞給 UDP 時，操作系統(tǒng)會直接打包發(fā)送出去（如果數(shù)據字節(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)調用拿到這個新連接對應的 socket，那這個 socket 和監(jiān)聽的 socket 是不是同一個呢？

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

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

串行模式

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

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

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

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

多進程模式

串行模式中，所有請求都在一個進程中排隊被處理，效率非常低下。為了提高效率，我們可以把請求分給多個進程處理。因為在串行處理的模式中，如果有文件 IO 操作就會阻塞進程，繼而阻塞后續(xù)請求的處理。在多進程的模式中，即使一個請求阻塞了進程，操作系統(tǒng)還可以調度其它進程繼續(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 。這時候就需要主進程使用傳遞文件描述符的技術把這個請求對應的 fd 傳給子進程。

pre-fork 模式 + 子進程 accept

剛才介紹的模式中，是主進程接收連接，然后傳遞給子進程處理，這樣主進程就會成為系統(tǒng)的瓶頸，它可能來不及接收和分發(fā)請求給子進程，而子進程卻很空閑。子進程 accept 這種模式也是會預先創(chuàng)建多個進程，區(qū)別是多個子進程會調用 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，如果這時候有一個請求到來，那么所有的子進程都會被喚醒，但是先被調度的子進程會摘下這個請求節(jié)點，后續(xù)的進程被喚醒后可能會遇到已經沒有請求可以處理，而又進入睡眠，這種進程被無效喚醒的現(xiàn)象就是著名的驚群現(xiàn)象。這種模式的處理流程如下。

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

多線程模式

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

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

事件驅動

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

但也正因為單進程模式下，再多的請求也只在一個進程里處理，這樣一個任務會一直在占據 CPU，后續(xù)的任務就無法執(zhí)行了。因此，事件驅動模式不適合 CPU 密集型的場景，更適合 IO 密集的場景（一般都會提供線程 / 線程池，負責處理 CPU 或者阻塞型的任務）。大部分操作系統(tǒng)都提供了事件驅動的 API，但是事件驅動在不同系統(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 , 保存就緒事件的結構events, 事件個數(shù), timeout);  
    for (let i = 0; i < total; i++) {  
        if (events[fd] === 監(jiān)聽 socket) {  
            int client_fd = accpet(socket);  
            // 把新的 socket 也注冊到 epoll，等待可讀，即可讀取客戶端數(shù)據  
            epoll_ctl(epoll_fd , EPOLL_CTL_ADD , client_fd, event);  
        } else {  
            //  從events[i] 中拿到一些上下文，執(zhí)行相應的回調  
        }  
    }  
}

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

function epoll_wait() {  
    for 事件個數(shù)  
        // 調用文件系統(tǒng)的函數(shù)判斷  
        if (事件 [i] 中對應的文件描述符中有某個用戶感興趣的事件發(fā)生 ？) {  
            插入就緒事件隊列  
        } else {  
            /*
                在事件 [i] 中的文件描述符所對應的文件 / socke / 管道等資源中注冊回調。
                感興趣的事件觸發(fā)后回調 epoll，回調 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)會根據地址信息找到一組 socket，然后根據策略選擇一個 socket 并喚醒阻塞在該 socket 的進程，被 socket 喚醒的進程處理自己的監(jiān)聽 socket 下的連接就行，架構如下。

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

IO 模型

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

阻塞 IO

當線程執(zhí)行一個 IO 操作時，如果不滿足條件，當前線程會被阻塞，然后操作系統(tǒng)會調度其他線程執(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);
    // 重新調度其他線程執(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;
// 申請內存
struct request *req = (struct request *)malloc(sizeof(*req) + (sizeof(struct iovec) * 1));
req->fd = fd;
req->offset = offset;
// 保存回調
napi_create_reference(env, args[2], 1, &req->func);
req->env = env;
req->nvecs = 1;
// 記錄buffer大小
req->iovecs[0].iov_len = bufferLength;
// 記錄內存地址
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 請求時，可以注冊一個回調，然后就可以去做其他事情了，等操作完成后它會通知你，它的底層實現(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 對象，接著調用 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) {  
  /*
    處理入參，listen 可以接收很多種格式的參數(shù)，
    假設我們這里只傳了 8888 端口號
  */
    const normalized = normalizeArgs(args);  
    //  normalized = [{port: 8888}, null];  
    const options = normalized[0]; 
    // 監(jiān)聽成功后的回調 
    const cb = normalized[1];  

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

listen 處理了入參后，接著調用了 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í)行的回調  
    this._handle.onconnection = onconnection;  
    // 互相關聯(lián)
    this._handle.owner = this;  
    // 執(zhí)行 C++ 層 listen  
    this._handle.listen(backlog || 511);  
    // 觸發(fā) listen 回調  
    nextTick(this[async_id_symbol], emitListeningNT, this);  
}

setupListenHandle 的邏輯如下。

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

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

3. 調用了 bind 綁定地址到 socket。

4. 調用 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