詳細剖析分布式微服務架構下網絡通信的底層實現原理（圖解）

在分布式架構中，網絡通信是底層基礎，沒有網絡，也就沒有所謂的分布式架構。只有通過網絡才能使得一大片機器互相協作，共同完成一件事情。

同樣，在大規模的系統架構中，應用吞吐量上不去、網絡存在通信延遲、我們首先考慮的都是網絡問題，因此網絡的重要性不言而喻。

作為現代化應用型程序員，要開發一個網絡通信的應用，是非常簡單的。不僅僅有成熟的api，還有非常方便的通信框架。

可能大家已經忘記了網絡通信的重要性，本篇文章會詳細分析網絡通信的底層原理！！

1.1 理解通信的本質

如圖1-1所示，當我們通過瀏覽器訪問一個網址時，一段時間后該網址會渲染出訪問的內容，這個過程是怎么實現的呢？

圖1-1

我想站在今天，在做的同學都知道，它是基於http協議來實現數據通信的，這里有兩個字很重要，就是“協議”。

兩個計算機之間要實現數據通信，必須遵循同一種協議，否則，就像一個中國人和一個外國人交流時，一個講英語另一個講解中文，肯定是無法正常交流。在計算機中，協議非常常見。

1.1.1 協議的組成

我們寫的Java代碼，計算機能夠理解並且執行，原因是人和計算機之間遵循了同一種語言，那就是Java，如圖1-2所示，.java文件最終編譯成.class文件這個過程，也同樣涉及到協議。

圖1-2 java編譯過程

所以，在計算機中，協議是指大家需要共同遵循的規則，只有實現統一規則之后，才能實現不同節點之間的數據通信，從而讓計算機的應用更加強大。

組成一個協議，需要具備三個要素：

• 語法，就是這一段內容要符合一定的規則和格式。例如，括號要成對，結束要使用分號等。
• 語義，就是這一段內容要代表某種意義。例如數字減去數字是有意義的，數字減去文本一般來說就沒有意義。
• 時序，就是先干啥，后干啥。例如，可以先加上某個數值，然后再減去某個數值。

1.1.2 http協議

理解了協議的作用，那協議是長什么樣的呢？

那么再來看圖1-3的場景，人們通過瀏覽器訪問網站，用到了http協議。

圖1-3 http協議

http協議包含包含幾個部分：

• http請求組成
  • 狀態行
  • 請求頭
  • 消息主體
• http響應組成
  • 狀態行
  • 響應頭
  • 響應正文

Http響應報文如圖1-4所示，那么這個協議的三要素分別是：

• 語法： http協議的消息體由狀態、頭部、內容組成。
• 語義： 比如狀態，200表示成功，404表示請求路徑不存在等，通信雙方必須遵循該語義。
• 時序： 組成消息體的三部分的排列順序，必須要有request，才會產生response。

而瀏覽器按照http協議做好了相關的處理后，才能讓大家通過網址訪問網絡上的各種信息。

圖1-4

1.1.3 常用的網絡協議

DNS協議、Http協議、SSH協議、TCP協議、FTP協議等，這些都是大家比較常用的協議類型。無論哪種協議，本質上仍然是由協議的三要素組成，只是應用場景不同。

DNS、HTTP、HTTPS 所在的層我們稱為應用層。經過應用層封裝后，瀏覽器會將應用層的包交給下一層去完成，通過 socket 編程來實現。下一層是傳輸層。傳輸層有兩種協議，一種是無連接的協議 UDP，一種是面向連接的協議 TCP。對於通信可靠性要求的場景來說，往往使用 TCP 協議。所謂的面向連接就是，TCP 會保證這個包能夠到達目的地。如果不能到達，就會重新發送，直至到達。

1.3 TCP/IP通信原理分析

一次網絡通信到底是怎么完成的呢？

涉及到網絡通信，那我們一定會提到一個網絡模型的概念，如圖1-5所示。表示TCP/IP的四層概念模型和OSI七層網絡模型，它是一種概念模型，由國際標准化組織提出來的，試圖讓全世界范圍內的計算機能基於該網絡標准實現互聯。

圖1-5

網絡模型為什么要分層呢？其實從我們現在的業務分層架構中就不難發現，任何系統一旦變得復雜，就都會采用分層設計。它的主要好處是

• 實現高內聚低耦合
• 每一層有自己單一的職責
• 提高可復用性和降低維護成本

1.2.1 http通信過程的發送數據包

由於我們的課程並不是專門來講網絡，所以只是提及一下網絡分層模型，為了讓大家更簡單的理解網絡分層模型的工作原理，我們仍然以一次網絡通信的數據包傳輸為例進行分析，如圖1-6所示。

圖1-6

圖1-6的工作流程描述如下：

• 假設我們要登錄某一個網站，此時基於Http協議會構建一個http協議報文，這個報文中按照http協議的規范組裝，其中包括要傳輸的用戶名和密碼。這個是屬於應用層協議。

• 經過應用層封裝后，瀏覽器會把應用層的包交給TCP/IP四層模型中的下一層，也就是傳輸層來完成，傳輸層有兩種協議：

  • TCP協議，可靠的通信協議，該協議會確保數據包能達到目的地
  • UDP協議，不可靠通信協議，可能會存在數據丟失

  在http通信中使用了TCP協議，TCP協議會有兩個端口，一個是瀏覽器監聽的端口，一個是目標服務器進程的端口。操作系統會根據端口來判斷這個數據包應該分發給那個進程。

• 傳輸層封裝完成后，該數據包會技術交給網絡層來處理，網絡層協議是IP協議，IP協議中會包含源IP地址（也就是客戶端及其的IP）和目標服務器的IP地址。

• 操作系統知道了目標IP地址后，就開始根據這個IP來尋找目標機器，而目標服務器一定是部署在不同的地方，這種跨網絡節點的訪問，需要經過網關（所謂網關就是一個網絡到另外一個網絡的關口）。

  所以數據包首先需要先通過自己當前所在網絡的網關出去，然后訪問到目標服務器，但是在數據包傳輸到目標服務器之前，需要再組裝MAC頭信息。

  Mac頭包含本地的Mac地址和目標服務器的Mac地址，這個MAC地址怎么獲得的呢？

  • 獲取本機MAC地址的方法是，操作系統會發送一個廣播消息詢問網關地址（192.168.1.1）是誰？收到該廣播消息的網關會回應一個MAC地址。這個廣播消息是基於ARP協議實現的（這個協議簡單來說就是已知目標機器的ip，需要獲得目標機器的mac地址。(發送一個廣播消息，這個ip是誰的，請來認領。認領ip的機器會發送一個mac地址的響應)）。

    為了避免每次都用 ARP 請求，機器本地也會進行 ARP 緩存。當然機器會不斷地上線下線，IP 也可能會變，所以 ARP 的 MAC 地址緩存過一段時間就會過期。

  • 獲取遠程機器的MAC地址的方法也同樣是基於ARP協議實現的。

完成MAC地址組裝后，一個完整的數據包就構成了。這個時候會把這個數據包給到網卡，網卡再把這個數據包發出去，由於這個數據包中包含MAC地址，因此它能夠到達網關進行傳輸。網關收到包之后，會根據路由信息，判斷下一步應該怎么走。網關往往是一個路由器，到某個 IP 地址應該怎么走，這個叫作路由表。

1.2.2 http通信過程中的接收數據包

當數據包發送到網關后，會根據網關的路由信息判斷該數據包要傳輸到那個網段上。數據從客戶端發送到目標服務器，可能會經過多個網關，所以數據包根據網關路由進入到下一個網關后，繼續根據下一個網關的MAC地址尋找下下一個網關，直到到達目標網絡服務器上。

這個時候服務器收到包之后，最后一個網關知道這個網絡包就是要去當前局域網的，於是拿着目標IP通過ARP協議大喊一聲這是誰？ 目標服務器就會給網關回復一個MAC地址。 然后網絡包在最后那個網關修改目標的MAC地址，通過這個MAC地址，網絡包找到了目標服務器。

當目標服務器和MAC地址對上后，開始取出MAC頭信息，接着把數據包發送給操作系統的網絡層。網絡層會取出IP頭信息，IP頭里面會寫上一層封裝的是TCP協議，於是交給傳輸層來處理，實現過程如圖1-7所示。

在這一層中，對於收到的每個數據包都會有一個回復，表示服務器端已經收到了該數據包。如果過一段時間客戶端沒有收到該確認包，發送端的 TCP 層會重新發送這個包，還是上面的過程，直到最終收到回復。

這個重試是TCP協議層來實現的，不需要我們應用來主動發起。

圖1-7

為什么有了MAC層還要走IP層呢？

之前我們提到，mac地址是唯一的，那理論上，在任何兩個設備之間，我應該都可以通過mac地址發送數據，為什么還需要ip地址？

mac地址就好像個人的身份證號，人的身份證號和人戶口所在的城市，出生的日期有關，但是和人所在的位置沒有關系，人是會移動的，知道一個人的身份證號，並不能找到它這個人，mac地址類似，它是和設備的生產者，批次，日期之類的關聯起來，知道一個設備的mac，並不能在網絡中將數據發送給它，除非它和發送方的在同一個網絡內。

所以要實現機器之間的通信，我們還需要有ip地址的概念，ip地址表達的是當前機器在網絡中的位置，類似於城市名+道路號+門牌號的概念。通過ip層的尋址，我們能知道按何種路徑在全世界任意兩台Internet上的的機器間傳輸數據。

1.4 詳解TCP可靠性通信特性

我們知道，TCP協議是屬於可靠性通信協議，它能夠確保數據包不被丟失。首先我們先了解一下TCP的三次握手和四次揮手。

1.4.1 TCP的三次握手

兩個節點需要進行數據通信，首先得先建立連接。而在建立連接時，TCP采用了三次握手來實現連接建立。如圖1-8所示。

圖1-8

第一次握手(SYN=1, seq=x)

客戶端發送一個 TCP的 SYN 標志位置1的包，指明客戶端打算連接的服務器的端口，以及初始序號 X,保存在包頭的序列號(Sequence Number)字段里。發送完畢后，客戶端進入 SYN_SEND 狀態。

第二次握手(SYN=1, ACK=1, seq=y, ACK num=x+1):

服務器發回確認包(ACK)應答。即 SYN 標志位和 ACK 標志位均為1。服務器端選擇自己 ISN 序列號，放到Seq 域里，同時將確認序號(Acknowledgement Number)設置為客戶的 ISN 加1，即X+1。 發送完畢后，服務器端進入 SYN_RCVD 狀態。

第三次握手(ACK=1，ACK num=y+1)

客戶端再次發送確認包(ACK)，SYN標志位為0，ACK標志位為1，並且把服務器發來 ACK的序號字段+1，放在確定字段中發送給對方，並且在數據段放寫ISN發完畢后，客戶端進入 ESTABLISHED 狀態，當服務器端接收到這個包時，也進入 ESTABLISHED 狀態，TCP握手結束。

1.4.2 TCP為什么是三次握手？

TCP是全雙工，如果沒有第三次的握手，服務端不能確認客戶端是否ready，不知道什么時候可以往客戶端發數據包。三次的握手剛好兩邊都互相確認對方已經ready。

我們假設網絡的不可靠性，

A發起一個連接，當發起一個請求沒有得到反饋的時候，會有很多可能性，比如請求包丟失，或者超時，或者B沒有響應

由於A不能確認結果，於是再發，當有一個請求包到了B之后，A並不知道這個數據包已經到了B，所以可能還會重試。

所以B收到請求之后，知道了A的存在並且要和我建立連接，這個時候B會發送ack給到A，告訴A我收到了請求包。

對於B來說，這個應答包也是一個網絡通信，我怎么知道能不能到達A呢？所以這個時候B不能很主觀的認為連接已經建立好了，還需要等到A再次發送應答包來確認。

1.4.3 TCP的四次揮手

如圖1-9所示，TCP的連接斷開，會通過所謂的四次揮手完成。

四次揮手表示TCP斷開連接的時候,需要客戶端和服務端總共發送4個包以確認連接的斷開；客戶端或服務器均可主動發起揮手動作(因為TCP是一個全雙工協議)，在 socket 編程中，任何一方執行 close() 操作即可產生揮手操作。

圖1-9

上述交互過程如下：

• 斷開的時候，我們可以看到，當A客戶端說說“我要斷開連接”，就進入 FIN_WAIT_1 的狀態。

• B 服務端收到“我要斷開連接”的消息后，發送"知道了"給到A客戶端，就進入 CLOSE_WAIT 的狀態。

• A 收到“B 說知道了”，就進入 FIN_WAIT_2 的狀態，如果這個時候 B 服務器掛掉了，則 A 將永遠在這個狀態。TCP 協議里面並沒有對這個狀態的處理，但是 Linux 有，可以調整 tcp_fin_timeout 這個參數，設置一個超時時間。

• 如果 B 服務器正常，則發送了“B 要關閉連接”的請求到達 A 時，A 發送“知道 B 也要關閉連接”的 ACK 后，從 FIN_WAIT_2 狀態結束。

• 按說這個時候 A 可以退出了，但是最后的這個 ACK 萬一 B 收不到呢？則 B 會重新發一個“B 要關閉連接”，這個時候 A 已經跑路了的話，B 就再也收不到 ACK 了，因而 TCP 協議要求 A 最后等待一段時間 TIME_WAIT，這個時間要足夠長，長到如果 B 沒收到 ACK 的話，“B 說不玩了”會重發的，A 會重新發一個 ACK 並且足夠時間到達 B。

這個等待實現是2MSL，MSL 是 Maximum Segment Lifetime，報文最大生存時間，它是任何報文在網絡上存在的最長時間，超過這個時間報文將被丟棄（此時A直接進入CLOSE狀態）。協議規定 MSL 為 2 分鍾，實際應用中常用的是 30 秒，1 分鍾和 2 分鍾等。

第一次揮手(FIN=1，seq=x)

假設客戶端想要關閉連接，客戶端發送一個 FIN 標志位置為1的包，表示自己已經沒有數據可以發送了，但是仍然可以接受數據。發送完畢后，客戶端進入 FIN_WAIT_1 狀態。

第二次揮手(ACK=1，ACKnum=x+1)

服務器端確認客戶端的 FIN包，發送一個確認包，表明自己接受到了客戶端關閉連接的請求，但還沒有准備好關閉連接。發送完畢后，服務器端進入 CLOSE_WAIT 狀態，客戶端接收到這個確認包之后，進入 FIN_WAIT_2 狀態，等待服務器端關閉連接。

第三次揮手(FIN=1，seq=w)

服務器端准備好關閉連接時，向客戶端發送結束連接請求，FIN置為1。發送完畢后，服務器端進入 LAST_ACK 狀態，等待來自客戶端的最后一個ACK。

第四次揮手(ACK=1，ACKnum=w+1)

客戶端接收到來自服務器端的關閉請求，發送一個確認包，並進入 TIME_WAIT狀態，等待可能出現的要求重傳的 ACK包。服務器端接收到這個確認包之后，關閉連接，進入 CLOSED 狀態。

【問題1】為什么連接的時候是三次握手，關閉的時候卻是四次握手？

答：三次握手是因為因為當Server端收到Client端的SYN連接請求報文后，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET（因為可能還有消息沒處理完），所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。

【問題2】為什么TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可以最后一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

1.4.4 TCP協議的報文傳輸

連接建立好之后，就開始進行數據包的傳輸了。那TCP作為一個可靠的通信協議，如何保證消息傳輸的可靠性呢？

TCP采用了消息確認的方式來保證數據報文傳輸的安全性，也就是說客戶端發送了數據包到服務端后，服務端會返回一個確認消息給到客戶端，如果客戶端沒有收到確認包，則會重新再發送。

為了保證順序性，每一個包都有一個 ID。在建立連接的時候，會商定起始的 ID 是什么，然后按照 ID 一個個發送。為了保證不丟包，對於發送的包都要進行應答，但是這個應答也不是一個一個來的，而是會應答某個之前的 ID，表示都收到了，這種模式稱為累計確認或者累計應答（cumulative acknowledgment）

如圖1-10所示，為了記錄所有發送的包和接收的包，TCP協議在發送端和接收端分別拿會有發送緩沖區和接收緩沖區，TCP的全雙工的工作模式及TCP的滑動窗口就是依賴於這兩個獨立的Buffer和該Buffer的填充狀態。

接收緩沖區把數據緩存到內核，若應用進程一直沒有調用Socket的read方法進行讀取，那么該數據會一直被緩存在接收緩沖區內。不管進程是否讀取Socket，對端發來的數據都會經過內核接收並緩存到Socket的內核接收緩沖區。

read所要做的工作，就是把內核接收緩沖區中的數據復制到應用層用戶的Buffer里。進程調用Socket的send發送數據的時候，一般情況下是將數據從應用層用戶的Buffer里復制到Socket的內核發送緩沖區，然后send就會在上層返回。換句話說，send返回時，數據不一定會被發送到對端。

圖1-10

發送端/接收端的緩沖區中是按照包的 ID 一個個排列，根據處理的情況分成四個部分。

• 第一部分：發送了並且已經確認的。
• 第二部分：發送了並且尚未確認的。需要等待確認后，才能移除。
• 第三部分：沒有發送，但是已經等待發送的。
• 第四部分：沒有發送，並且暫時還不會發送的。

這里的第三部分和第四部分之所以做一個區分，其實是因為TCP采用做了流量控制，這里采用了滑動窗口的方式來實現流量整形，避免出現數據擁堵的情況。

圖1-11

為了更好的理解數據包的通信過程，我們通過下面這個網址來演示一下

https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations/selective-repeat-protocol/index.html

1.4.5 滑動窗口協議

上述地址中動畫演示的部分，其實就是數據包發送和確認機制，同時還涉及到互動窗口協議。

滑動窗口（Sliding window）是一種流量控制技術。早期的網絡通信中，通信雙方不會考慮網絡的擁擠情況直接發送數據。由於大家不知道網絡擁塞狀況，同時發送數據，導致中間節點阻塞掉包，誰也發不了數據，所以就有了滑動窗口機制來解決此問題；發送和接受方都會維護一個數據幀的序列，這個序列被稱作窗口

發送窗口

就是發送端允許連續發送的幀的序號表。

發送端可以不等待應答而連續發送的最大幀數稱為發送窗口的尺寸。

接收窗口

接收方允許接收的幀的序號表，凡落在 接收窗口內的幀，接收方都必須處理，落在接收窗口外的幀被丟棄。

接收方每次允許接收的幀數稱為接收窗口的尺寸。

1.5 理解阻塞通信的本質

理解了TCP通信的原理后，在Java中我們會采用Socket套接字來實現網絡通信，下面這段代碼演示了Socket通信的案例。

public class ServerSocketExample {

    public static void main(String[] args) throws IOException {
        final int DEFAULT_PORT = 8080;
        ServerSocket serverSocket = null;
        serverSocket = new ServerSocket(DEFAULT_PORT);
        System.out.println("啟動服務，監聽端口：" + DEFAULT_PORT);
        while (true) {
            Socket socket = serverSocket.accept();
            System.out.println("客戶端：" + socket.getPort() + "已連接");
            new Thread(new Runnable() {
                Socket socket;
                public Runnable setSocket(Socket s){
                    this.socket=s;
                    return this;
                }
                @Override
                public void run() {
                    try {
                        BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(socket.getInputStream()));
                        String clientStr = null; //讀取一行信息
                        clientStr = bufferedReader.readLine();
                        System.out.println("客戶端發了一段消息：" + clientStr);
                        BufferedWriter bufferedWriter = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
                        bufferedWriter.write("我已經收到你的消息了");
                        bufferedWriter.flush(); //清空緩沖區觸發消息發送
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                }
            }.setSocket(socket)).start();

        }
    }
}

在我們講Redis的專題中詳細講到過，上述通信是BIO模型，也就是阻塞通信模型，阻塞主要體現的點是

• accept，阻塞等待客戶端連接
• io阻塞，阻塞等待客戶端的數據傳輸。

相信大家和我一樣有一些以后，這個阻塞和喚醒到底是怎么回事，下面我們簡單來了解一下。

1.5.1 阻塞操作的本質

阻塞是指進程在等待某個事件發生之前的等待狀態，它是屬於操作系統層面的調度，我們通過下面操作來追蹤Java程序中有多少程序，每一個線程對內核產生了哪些操作。

strace，Linux操作系統中的指令

1. 把ServerSocketExample.java，去掉package導入頭，拷貝到linux服務器的 /data/app目錄下。

2. 使用javac ServerSocketExample.java進行編譯，得到.class文件

3. 使用下面這個命令來追蹤（打開一個新窗口）

   按照strace官網的描述, strace是一個可用於診斷、調試和教學的Linux用戶空間跟蹤器。我們用它來監控用戶空間進程和內核的交互，比如系統調用、信號傳遞、進程狀態變更等。

   strace -ff -o out java ServerSocketExample
   

   • -f 跟蹤目標進程，以及目標進程創建的所有子進程
   • -o 把strace的輸出單獨寫到指定的文件

4. 上述指令執行完成后，會在/data/app目錄下得到很多out.*的文件，每個文件代表一個線程。因為Java本身是多線程的。

   [root@localhost app]# ll
   total 748
   -rw-r--r--. 1 root root  14808 Aug 23 12:51 out.33320 //最小的表示主線程
   -rw-r--r--. 1 root root 186893 Aug 23 12:51 out.33321
   -rw-r--r--. 1 root root    961 Aug 23 12:51 out.33322
   -rw-r--r--. 1 root root    917 Aug 23 12:51 out.33323
   -rw-r--r--. 1 root root    833 Aug 23 12:51 out.33324
   -rw-r--r--. 1 root root    819 Aug 23 12:51 out.33325
   -rw-r--r--. 1 root root  23627 Aug 23 12:53 out.33326
   -rw-r--r--. 1 root root   1326 Aug 23 12:51 out.33327
   -rw-r--r--. 1 root root   1144 Aug 23 12:51 out.33328
   -rw-r--r--. 1 root root   1270 Aug 23 12:51 out.33329
   -rw-r--r--. 1 root root   8136 Aug 23 12:53 out.33330
   -rw-r--r--. 1 root root   8158 Aug 23 12:53 out.33331
   -rw-r--r--. 1 root root   6966 Aug 23 12:53 out.33332
   -rw-r--r--. 1 root root   1040 Aug 23 12:51 out.33333
   -rw-r--r--. 1 root root 445489 Aug 23 12:53 out.33334
   

5. 打開out.33321這個文件（主線程后面的一個文件），shift+g到該文件的尾部，可以看到如下內容。

   下面這些方法，都是屬於系統調用，也就是調用操作系統提供的內核指令觸發相關的操作。

   # 創建socket fd 
   socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 5 
   ....
   # 綁定8888端口
   bind(5, {sa_family=AF_INET6, sin6_port=htons(8888), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
   # 創建一個socket並監聽申請的連接, 5表示sockfd，50表示等待隊列的最大長度
   listen(5, 50)                           = 0
   mprotect(0x7f21d00df000, 4096, PROT_READ|PROT_WRITE) = 0
   write(1, "\345\220\257\345\212\250\346\234\215\345\212\241\357\274\214\347\233\221\345\220\254\347\253\257\345\217\243\357\274\23288"..., 34) = 34
   write(1, "\n", 1)                       = 1
   lseek(3, 58916778, SEEK_SET)            = 58916778
   read(3, "PK\3\4\n\0\0\10\0\0U\23\213O\336\274\205\24X8\0\0X8\0\0\25\0\0\0", 30) = 30
   lseek(3, 58916829, SEEK_SET)            = 58916829
   read(3, "\312\376\272\276\0\0\0004\1\367\n\0\6\1\37\t\0\237\1 \t\0\237\1!\t\0\237\1\"\t\0"..., 14424) = 14424
   # poll, 把當前的文件指針掛到等待隊列，文件指針指的是fd=5，簡單來說就是讓當前進程阻塞，直到有事件觸發喚醒
   * events: 表示請求事件，POLLIN（普通或優先級帶數據可讀）、POLLERR，發生錯誤。
   poll([{fd=5, events=POLLIN|POLLERR}], 1, -1
   

從這個代碼中可以看到，Socket的accept方法最終是調用系統的poll函數來實現線程阻塞的。

通過在linux服務器輸入 man 2 poll

man: 幫助手冊

2： 表示系統調用相關的函數

DESCRIPTION
       poll()  performs  a  similar  task  to  select(2): it waits for one of a set of file
       descriptors to become ready to perform I/O.

poll類似於select函數，它可以等待一組文件描述符中的IO就緒事件

6. 通過下面命令訪問socket server。

   telnet 192.168.221.128 8888
   

   這個時候通過tail -f out.33321這個文件，發現被阻塞的poll()方法，被POLLIN事件喚醒了，表示監聽到了一次連接。

   poll([{fd=5, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
   accept(5, {sa_family=AF_INET6, sin6_port=htons(53778), inet_pton(AF_INET6, "::ffff:192.168.221.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 6
   

1.5.2 阻塞被喚醒的過程

如圖1-12所示，網絡數據包通過網線傳輸到目標服務器的網卡，再通過2所示的硬件電路傳輸，最終把數據寫入到內存中的某個地址上，接着網卡通過中斷信號通知CPU有數據到達，操作系統就知道當前有新的數據包傳遞過來，於是CPU開始執行中斷程序，中斷程序的主要邏輯是

• 先把網卡接收到的數據寫入到對應的Socket接收緩沖區中
• 再喚醒被阻塞在poll()方法上的線程

圖1-12

1.5.3 阻塞的整體原理分析

操作系統為了支持多任務處理，所以實現了進程調度功能，運行中的進程表示獲得了CPU的使用權，當進程(線程)因為某些操作導致阻塞時，就會釋放CPU使用權，使得操作系統能夠多任務的執行。

當多個進程是運行狀態等待CPU調度時，這些進程會保存到一個可運行隊列中，如圖1-13所示。

圖1-13 當進程A執行創建Socket語句時，在Linux操作系統中會創建一個由文件系統管理的Socket對象，這個Socket對象包含發送緩沖區、接收緩沖區、等待隊列等，其中等待隊列是非常重要的結構，它指向所有需要等待當前Socket事件的進程，如圖1-14所示。

當進程A調用poll()方法阻塞時，操作系統會把當前進程A從工作隊列移動到Socket的等待隊列中（將進程A的指針指向等待隊列，后續需要進行喚醒），此時A被阻塞，CPU繼續執行下一個進程。

圖1-14

當Socket收到數據時，等待該Socket FD的進程會收到被喚醒，如圖1-15所示，計算機通過網卡接收到客戶端傳過來的數據，網卡會把這個數據寫入到內存，然后再通過中斷信號通知CPU有數據到達，於是CPU開始執行中斷程序。

當發生了中斷，就意味着需要操作系統的介入，開展管理工作。由於操作系統的管理工作（如進程切換、分配IO設備）需要使用特權指令，因此CPU要從用戶態轉換為核心態。中斷就可以使CPU從用戶態轉換為核心態，使操作系統獲得計算機的控制權。因此，有了中斷，才能實現多道程序並發執行。

此處的中斷程序主要有兩項功能，先將網絡數據寫入到對應 Socket 的接收緩沖區里面(步驟 ④)，再喚醒進程 A(步驟 ⑤)，重新將進程 A 放入工作隊列中。

圖1-15

1.5 Linux中的select/poll模型本質

前面在1.4節中講的其實是Recv()方法，它只能監視單個Socket。而在實際應用中，這種單Socket監聽很明顯會影響到客戶端連接數，所以我們需要尋找一種能夠同時監聽多個Socket的方法，而select/poll就是在這個背景下產生的，其中poll方法在前面的案例中就講過，默認情況下使用poll模型。

先來了解一下select模型，由於在前面的分析中我們知道Recv()只能實現對單個socket的監聽，當客戶端連接數較多的時候，會導致吞吐量非常低，所以我們想，能不能實現同時監聽多個socket，只要任何一個socket連接存在IO就緒事件，就觸發進程的喚醒。

如圖1-16所示，假設程序同時監聽socket1和socket2這兩個socket連接，那么當應用程序調用select方法后，操作系統會把進程A分別指向這連個個socket的等待隊列中。當任何一個Socket收到數據后，中斷程序會喚醒對應的進程。

當進程 A 被喚醒后，它知道至少有一個 Socket 接收了數據。程序只需遍歷一遍 Socket 列表，就可以得到就緒的 Socket。

圖1-16

select模式有二個問題，

• 就是每次調用select都需要將進程加入到所有監視器socket的等待隊列，每次喚醒都需要從等待隊列中移除，這里涉及到兩次遍歷，有一定的性能開銷。
• 進程被喚醒后，並不知道哪些socket收到了數據，所以還需要遍歷一次所有的socket，得到就緒的socket列表

由於這兩個問題產生的性能影響，所以select默認規定只能監視1024個socket，雖然可以通過修改監視的文件描述符數量，但是這樣會降低效率。而poll模式和select基本是一樣，最大的區別是poll沒有最大文件描述符限制。

1.6 Linux中的epoll模型

有沒有更加高效的方法，能夠減少遍歷也能達到同時監聽多個fd的目的呢？epoll模型就可以解決這個問題。

epoll 其實是event poll的組合，它和select最大的區別在於，epoll會把哪個socket發生了什么樣的IO事件通知給應用程序，所以epoll實際上就是事件驅動，具體原理如圖1-17所示。

在epoll中提供了三個方法分別是epoll_create、epoll_ctl、epoll_wait。具體執行流程如下

• 首先調用epoll_create方法，在內核創建一個eventpoll對象，這個對象會維護一個epitem集合，它是一個紅黑樹結構。這個集合簡單理解成fd集合。
• 接着調用epoll_ctl函數將當前fd封裝成epitem加入到eventpoll對象中，並給這個epitem加入一個回調函數注冊到內核。當這個fd收到網絡IO事件時，會把該fd對應的epitem加入到eventpoll中的就緒列表rdlist（雙向鏈表）中。同時再喚醒被阻塞的進程A。
• 進程A繼續調用epoll_wait方法，直接讀取epoll中就緒隊列rdlist中的epitem，如果rdlist隊列為空，則阻塞等待或者等待超時。

從epoll的原理中可以得知，由於rdlist的存在，使得進程A被喚醒后知道哪些Socket(fd)發生了IO事件，從而在不需要遍歷的情況下獲取所有就緒的socket連接。

圖1-17

版權聲明：本博客所有文章除特別聲明外，均采用 CC BY-NC-SA 4.0 許可協議。轉載請注明來自 Mic帶你學架構！
如果本篇文章對您有幫助，還請幫忙點個關注和贊，您的堅持是我不斷創作的動力。歡迎關注「跟着Mic學架構」公眾號公眾號獲取更多技術干貨！