網路篇面試題

1. 打開瀏覽器訪問www.baidu.com 發生了什么事情

當我們在瀏覽器地址欄中輸入baidu.com訪問后會自動跳轉到百度首頁展現頁面,發生了以下這些事情

1. 瀏覽器查找該域名的 IP 地址
2. 瀏覽器和對應的IP建立TCP連接
3. 瀏覽器根據決議得到的IP地址向 web 服務器發送一個 HTTP 請求
4. 服務器收到請求并進行處理
5. 服務器回傳一個回應
6. 瀏覽器對該回應進行解碼，渲染顯示，
7. 頁面顯示完成后，瀏覽器發送異步請求，

1.1 域名決議的流程

瀏覽器是如何查找域名對應的IP地址的呢？

1. IP地址是指互聯網協議地址，每個處于互聯網中的設備都有IP 地址，形如 192.168.0.1 局域網 IP和公網 IP 是有差別的，每個主機在網路中都是IP為標識的，IP才是主機在網路中的位置，域名只是為了方便用戶記憶而已，這就要求瀏覽器能夠識別域名并且將其轉化為對應的IP地址，
2. 所以瀏覽器會有一個DNS快取，其中記錄了一些域名與IP的對應關系，供瀏覽器快速查找需要的IP，但是這個DNS快取不可能存下所有的域名-IP地址，何況IP地址有時候還會變化，因此當在瀏覽器DNS快取中沒有找到的時候，就要先向DNS服務器請求域名決議，DNS域名決議時用的是UDP協議，

1.2 http使用了tcp協議嗎

http使用了tcp協議嗎，http協議的特點是什么

1. TCP協議對應于傳輸層，而HTTP協議對應于應用層，從本質上來說，二者沒有可比性，
2. Http協議是建立在TCP協議基礎之上的，當瀏覽器需要從服務器獲取網頁資料的時候，會發出一次Http請求
3. Http會通過TCP建立起一個到服務器的連接通道，當本次請求需要的資料完畢后，Http會立即將TCP連接斷開，這個程序是很短的，所以Http連接是一種短連接，是一種無狀態的連接，
4. 所謂的無狀態，是指瀏覽器每次向服務器發起請求的時候，不是通過一個連接，而是每次都建立一個新的連接，如果是一個連接的話，服務器行程中就能保持住這個連接并且在記憶體中記住一些資訊狀態，而每次請求結束后，連接就關閉，相關的內容就釋放了，所以記不住任何狀態，成為無狀態連接，

1.3 三次握手

TCP三次握手：

1.3.1 第一次握手

客戶端向服務端發送連接請求報文段，該報文段的頭部中SYN=1，ACK=0，seq=x，請求發送后，客戶端便進入SYN-SENT狀態，

1. 向目的主機發送TCP連接請求報文
2. 該TCP報文中SYN標志位為1，產生一個亂數x，表示連接請求,x為本次TCP通信的位元組流的初始
   序號，
3. 該TCP報文通過獲取的ip（DNS）找到服務器主機，然后獲得MAC地址（ARP），通過網關，最終
   到達目的主機，
   TCP規定：SYN=1的報文段不能有資料部分，但要消耗掉一個序號，

1.3.2 第二次握手

服務端收到連接請求報文段后，如果同意連接，則會發送一個應答：SYN=1，ACK=1，seq=y，ack=x+1
該應答發送完成后便進入SYN-RCVD狀態，

1. 目的主機收到資料幀后，通過ip協議傳輸幀，再到TCP協議，封裝成請求應答報文；
2. 該報文中SYN標志為1，產生一個亂數y，ack標志位x+1，表示連接請求應答
3. 該請求應答報文通過接收到的源ip->Mac（arp）->網關，發送到我的主機；

1.3.3 第三次握手

當客戶端收到連接同意的應答后，還要向服務端發送一個確認報文段，表示：服務端發來的連接同意應答已經成功收到，
該報文段的頭部為：ACK=1，seq=x+1，ack=y+1， 客戶端發完這個報文段后便進入ESTABLISHED狀態，服務端收到這個應答后也進入ESTABLISHED狀態，此時連接的建立完成

1. 我的主機收到資料幀，通過ip協議傳輸幀，再到TCP協議，封裝成請求確認報文
2. 該請求確認報文通過目標ip->Mac（arp）->網關，發送到目的主機
3. 請求確認報文的ack為y +1，表示請求確認；
4. 目的主機接收到資料幀，連接建立完成

1.4 為什么必須是三次

為什么要三次握手

1. 防止失效的連接請求報文段被服務端接收，從而產生錯誤，
2. 若建立連接只需兩次握手，客戶端并沒有太大的變化，仍然需要獲得服務端的應答后才進入ESTABLISHED狀態，而服務端在收到連接請求后就進入ESTABLISHED狀態，
3. 此時如果網路擁塞，客戶端發送的連接請求遲遲到不了服務端，客戶端便超時重發請求，如果服務端正確接收并確認應答，雙方便開始通信，通信結束后釋放連接，
4. 此時，如果那個失效的連接請求抵達了服務端，由于只有兩次握手，服務端收到請求就會進入ESTABLISHED狀態，等待發送資料或主動發送資料，但此時的客戶端早已進入CLOSED狀態，服務端將會一直等待下去，這樣浪費服務端連接資源，

三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是資料的發送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的，

第一次握手：Client 什么都不能確認；Server 確認了對方發送正常，自己接收正常

第二次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：對方發送正常，自己接收正常

第三次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己發送、接收正常，對方發送、接收正常（server確認了自己發送也正常）

所以三次握手就能確認雙發收發功能都正常，缺一不可，

1.5 四次揮手

能說下四次揮手的流程嗎
資料傳輸結束之后需要斷開連接，與建立連接不同，斷開連接需要多一次手，四次揮手

1.5.1 第一次揮手

若A認為資料發送完成，則它需要向B發送連接釋放請求，該請求只有報文頭，頭中攜帶的主要引數為：FIN=1，seq=u，此時，A將進入FIN-WAIT-1狀態

1. 瀏覽器向目的主機發出連接結束報文，此時進入FIN WAIT狀態；
2. 連接結束報文標志位FIN=1，并且產生序號 u
3. TCP連接結束請求報文通過ip->Mac（arp）->網關->目的主機

1.5.2 第二次揮手

B收到連接釋放請求后，會通知相應的應用程式，告訴它A向B這個方向的連接已經釋放，此時B進入CLOSE-WAIT狀態，并向A發送連接釋放的應答，其報文頭包含：ACK=1，seq=v，ack=u+1

1. 目的主機接收到資料幀，通過ip->tcp，通過tcp協議單元回應結束應答報文
2. 結束應答報文中ack = u + 1，表示收到結束請求，當前只是進行回應，因為目的主機可能還有資料
   要傳，并不急著斷開連接，
   第二次揮手完成后，A到B方向的連接已經釋放，B不會再接收資料，A也不會再發送資料，但B到A方向
   的連接仍然存在，B可以繼續向A發送資料，

1.5.3 第三次揮手

當B向A發完所有資料后，向A發送連接釋放請求，請求頭：FIN=1，ACK=1，seq=w，ack=u+1， B便進入LAST-ACK狀態，

1. 等到瀏覽器發送完所有資料后，目的主機向我的主機發出tcp連接結束請求報文；
2. 該報文FIN標志位1，并且產生亂數w，表示結束請求
3. tcp結束請求報文通過ip->Mac（arp）->網關->我的主機

1.5.4 第四次揮手

A收到釋放請求后，向B發送確認應答，此時A進入TIME-WAIT狀態，該狀態會持續2MSL時間，若該時間段內沒有B的重發請求的話，就進入CLOSED狀態，撤銷TCB，當B收到確認應答后，也便進入CLOSED狀態，撤銷TCB，

1. 我的主機收到資料幀，通過ip->tcp，tcp協議單元回應結束應答報文，此時進入TIME WAIT狀態，因為不相信網路是可靠的，如果目的主機沒收到，還能夠重發結束應答報文
2. 該回應結束應答報文中的FIN標志為1，ack=N+1；表示結束應答，該tcp報文通過ip->Mac（arp）->網關->目的主機；目的主機關閉連接，如果TIME WAIT等待結束后，沒有收到回復，說明目的主機連接正常關閉了，我的主機也關閉連接

1.6 為什么是四次揮手

為什么斷開連接需要四次揮手而不是兩次

因為建立連接時，目的主機可以直接發送SYN+ACK應答報文，而當目的主機收到FIN后，可能還有資料
要發，并不一定直接斷開，所以先發送一次應答，告知我的主機收到了連接結束請求，等確認所有資料
都發完了，在發送FIN，同時等待我的主機應答，這里的FIN和ACK不能一起發送，因為可能還有資料要
傳輸，所以需要四次

1.7 為什么關閉連接需要等待2MSL

為什么從TIME_WAIT到CLOSE需要等待2MSL

1. 在Client發送出最后的ACK回復，但該ACK可能丟失，Server如果沒有收到ACK，將不斷重復發送FIN片段，所以Client不能立即關閉，它必須確認Server接收到了該ACK，
2. Client會在發送出ACK之后進入到TIME_WAIT狀態，Client會設定一個計時器，等待2MSL的時間，
   如果在該時間內再次收到FIN，那么Client會重發ACK并再次等待2MSL，
3. 所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)，MSL指一個片段在網路中最大的存活時間，2MSL就是一個發送和一個回復所需的最大時間，如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經被成功接收，則結束TCP連接，

1.8 說下TCP粘包半包

說一下 TCP 粘包半包產生的原因以及解決方案

1.8.1 粘包原因

發送方產生粘包
采用TCP協議傳輸資料的客戶端與服務器經常是保持一個長連接的狀態（一次連接發一次資料不存在粘
包），雙方在連接不斷開的情況下，可以一直傳輸資料；但當發送的資料包過于的小時，那么TCP協議
默認的會啟用Nagle演算法，將這些較小的資料包進行合并發送（緩沖區資料發送是一個堆壓的程序）；
這個合并程序就是在發送緩沖區中進行的，也就是說資料發送出來它已經是粘包的狀態了；
接收方產生粘包
接收方采用TCP協議接收資料時的程序是這樣的：資料到底接收方，從網路模型的下方傳遞至傳輸層，
傳輸層的TCP協議處理是將其放置接識訓沖區，然后由應用層來主動獲取（C語言用recv、read等函
數）；這時會出現一個問題，就是我們在程式中呼叫的讀取資料函式不能及時的把緩沖區中的資料拿出
來，而下一個資料又到來并有一部分放入的緩沖區末尾，等我們讀取資料時就是一個粘包；（放資料的
速度 > 應用層拿資料速度）

1.8.2 半包原因

可能是IP分片傳輸導致的，也可能是傳輸程序中丟失部分包導致出現的半包，還有可能就是一個包可能被分成了兩次傳輸，在取資料的時候，先取到了一部分（還可能與接收的緩沖區大小有關系），總之就
是一個資料包被分成了多次接收，

1.8.3 解決粘包半包問題

由于底層的TCP無法理解上層的業務資料，所以在底層是無法保證資料包不被拆分和重組的，這個問題只能通過上層的應用協議堆疊設計來解決，根據業界的主流協議的解決方案，可以歸納如下，
客戶端解決粘包半包

1. 發送產生是因為Nagle演算法合并小資料包，那么可以禁用掉該演算法；
2. TCP提供了強制資料立即傳送的操作指令push，當填入資料后呼叫操作指令就可以立即將資料發送，而不必等待發送緩沖區填充自動發送；
3. 資料包中加頭，頭部資訊為整個資料的長度（最廣泛最常用）
   服務端解決粘包半包
4. 決議資料包頭部資訊，根據長度來接收；
5. 自定義資料格式：在資料中放入開始、結束標識；決議時根據格式抓取資料，缺點是資料內不能含
   有開始或結束標識；

2. http和https的區別

HTTP：是互聯網上應用最為廣泛的一種網路協議，是一個客戶端和服務器端請求和應答的標準（TCP），用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網路傳輸減少，
HTTPS：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全
基礎是SSL，因此加密的詳細內容就需要SSL，
HTTPS協議的主要作用可以分為兩種：一種是建立一個資訊安全通道，來保證資料傳輸的安全；另一種
就是確認網站的真實性，

2.1 https的通訊流程嗎

能說下https的通訊以及加密流程嗎
HTTPS能夠加密資訊，以免敏感資訊被第三方獲取，所以很多銀行網站或電子郵箱等等安全級別較高的
服務都會采用HTTPS協議，

客戶端在使用HTTPS方式與Web服務器通信時有以下幾個步驟，如圖所示，

1. 客戶使用https的URL訪問Web服務器，要求與Web服務器建立SSL連接，
2. Web服務器收到客戶端請求后，會將網站的證書資訊（證書中包含公鑰）傳送一份給客戶端，
3. 客戶端的瀏覽器與Web服務器開始協商SSL連接的安全等級，也就是資訊加密的等級，
4. 客戶端的瀏覽器根據雙方同意的安全等級，建立會話密鑰，然后利用網站的公鑰將會話密鑰加密，
   并傳送給網站，
5. Web服務器利用自己的私鑰解密出會話密鑰，
6. Web服務器利用會話密鑰加密與客戶端之間的通信，

4. 什么是RPC通訊

RPC（Remote Promote Call） 一種行程間通信方式，允許像呼叫本地服務一樣呼叫遠程服務，RPC框架的主要目標就是讓遠程服務呼叫更簡單、透明
RPC框架負責屏蔽底層的傳輸方式（TCP或者UDP）、序列化方式（XML/JSON/二進制）和通信細節，
開發人員在使用的時候只需要了解誰在什么位置提供了什么樣的遠程服務介面即可，并不需要關心底層
通信細節和呼叫程序，

4.1 RPC和HTTP的區別

RPC和HTTTP不是一個并行的概念，RPC是遠程程序呼叫，針對于業務應用來說的，而Http只是一
個網路協議，RPC可以采用http協議來實作，也可以通過更底層的TCP或者socket來實作，
RPC，是遠程方法呼叫，只要是調外部的方法，都算， 至于怎么呼叫，有很多實作，HTTP+json和
dubbo只是實作方式的兩種而已，

4.2 RPC和RMI的區別

RMI:Java遠程方法呼叫，即Java RMI（Java Remote Method Invocation）是Java編程語言里， 一種用
于實作遠程程序呼叫的應用程式編程介面，它使客戶機上運行的程式可以呼叫遠程服務器上的物件，
RMI 只能在 Java 語言中使用， 可以把 RMI 看作面向物件的 Java RPC ，

RPC（Remote Procedure Call Protocol）遠程程序呼叫協議，通過網路從遠程計算機上請求呼叫某種服務，

兩者區別如下：

• RPC 跨語言，而 RMI只支持Java
• RMI 呼叫遠程物件方法，允許方法回傳 Java 物件以及基本資料型別，而RPC 不支持物件的概念

4.3 自己設計一個RPC

能夠描述下如何設計一個RPC框架，并描述下每一個組件的作用

服務層
服務層Service，其中主要部分就是動態代理，主要用于將服務提供者的介面通過動態代理將我們的直接方法呼叫變為網路請求呼叫
過濾器層
主要完成過濾器鏈的嵌入，在動態代理階段做一些事情，比如限流，負載均衡，失敗通知，服務監控等等
RPC層
RPC層主要用來屏蔽遠程呼叫的細節，對上層呼叫透明，也是 RPC 框架的核心部分，包括通信框
架，序列化框架，還有用于屏蔽底層通信框架和序列化框架的抽象介面，
其他組件
服務注冊中心
負責服務的發布和通知，通常支持對等集群部署，某個節點宕機不會影響整個集群不可用，即使全部宕
機，只影響新的節點注冊和發布，不影響現有的，因為客戶端需要快取服務路由資訊，
服務治理中心
服務治理中心通常包括服務治理介面和服務治理 Portal，架構師，測驗人員和系統運維人員通過服務治理 Portal 對服務的運行狀態，歷史資料，健康度和呼叫關系等進行可視化的分析和維護，目標是要持續優化服務，防止服務架構腐化，保證服務高質量運行

4.3.5 說一下RPC請求程序

1. 首先服務的提供方和呼叫方啟動的時候會將服務地址注冊到注冊中心中，然后服務也會拉取對應的
   注冊中心的注冊資訊
2. 我們呼叫介面的時候，服務會將呼叫方的介面通過動態代理從代理到遠程介面，
3. 通過過濾器鏈從本地存根或者注冊中心中獲取到呼叫的服務器串列，然后進行負載均衡篩選出來一
   個呼叫地址
4. 然后通過統一的遠程呼叫介面進行網路呼叫
5. 先對請求的引數進行序列化
6. 通過netty或者http對遠程地址進行呼叫，引數是序列化后的地址
7. 服務提供方收到請求后，對引數進行反序列化然后根據呼叫地址找到需要呼叫的目標方法
8. 呼叫目標方法將引數傳入后呼叫方法回傳介面再將回傳的結果進行序列化
9. 通過網路請求將結果回傳給呼叫發起方，然后將引數進行反序列化
10. 最終將結束輸出

5. Linux IO模型有幾種分別是什么

說說常見的IO模型有幾種，以及他們之間的區別
阻塞IO、非阻塞IO、多路復用IO、信號驅動IO以及異步IO

5.1 常見的IO模型

5.1.1 阻塞IO

我們釣魚的時候，有一種方式比較愜意，比較輕松，那就是我們坐在魚竿面前，這個程序中我們什么也不做，雙手一直把著魚竿，就靜靜的等著魚兒咬鉤，一旦手上感受到魚的力道，就把魚釣起來放入魚簍中，然后再釣下一條魚，

最傳統的一種IO模型，即在讀寫資料程序中會發生阻塞現象，

當用戶執行緒發出IO請求之后，內核會去查看資料是否就緒，如果沒有就緒就會等待資料就緒，而用戶線
程就會處于阻塞狀態，用戶執行緒交出CPU，當資料就緒之后，內核會將資料拷貝到用戶執行緒，并回傳結
果給用戶執行緒，用戶執行緒才解除block狀態，

data = socket.read();

如果資料沒有就緒，就會一直阻塞在read方法，
優點：程式簡單，在阻塞等待資料期間行程/執行緒掛起，基本不會占用 CPU 資源，
缺點：每個連接需要獨立的行程/執行緒單獨處理，當并發請求量大時為了維護程式，記憶體、執行緒切換開
銷較大，這種模型在實際生產中很少使用，

5.1.2 非阻塞IO（輪詢）

我們釣魚的時候，在等待魚兒咬鉤的程序中，我們可以做點別的事情，比如玩一把王者榮耀、看一集《延禧攻略》等等，但是，我們要時不時的去看一下魚竿，一旦發現有魚兒上鉤了，就把魚釣上來，

當用戶執行緒發起一個read操作后，并不需要等待，而是馬上就得到了一個結果，

如果結果是一個error時，它就知道資料還沒有準備好，于是它可以再次發送read操作，一旦內核中的資料準備好了，并且又再次收到了用戶執行緒的請求，那么它馬上就將資料拷貝到了用戶執行緒，然后回傳，
所以事實上，在非阻塞IO模型中，用戶執行緒需要不斷地詢問內核資料是否就緒，也就說非阻塞IO不會交出CPU，而會一直占用CPU，

while(true){ 
   data = socket.read(); 
   if(data!= error){ 
       處理資料 
       break; 
    } 
}

但是對于非阻塞IO就有一個非常嚴重的問題，在while回圈中需要不斷地去詢問內核資料是否就緒，這樣會導致CPU占用率非常高，因此一般情況下很少使用while回圈這種方式來讀取資料，
優點：不會阻塞在內核的等待資料程序，每次發起的 I/O 請求可以立即回傳，不用阻塞等待，實時性較
好，
缺點：輪詢將會不斷地詢問內核，這將占用大量的 CPU 時間，系統資源利用率較低，所以一般 Web 服
務器不使用這種 I/O 模型，

5.1.3 多路復用IO模型

我們釣魚的時候，為了保證可以最短的時間釣到最多的魚，我們同一時間擺放多個魚竿，同時釣魚，然后哪個魚竿有魚兒咬鉤了，我們就把哪個魚竿上面的魚釣起來，

多路復用IO模型是目前使用得比較多的模型，Java NIO實際上就是多路復用IO，

在多路復用IO模型中，會有一個執行緒不斷去輪詢多個socket的狀態，只有當socket真正有讀寫事件時，才真正呼叫實際的IO讀寫操作，因為在多路復用IO模型中，只需要使用一個執行緒就可以管理多個socket，系統不需要建立新的行程或者執行緒，也不必維護這些執行緒和行程，并且只有在真正有socket讀寫事件進行時，才會使用IO資源，所以它大大減少了資源占用，
在Java NIO中，是通過selector.select()去查詢每個通道是否有到達事件，如果沒有事件，則一直阻塞在
那里，因此這種方式會導致用戶執行緒的阻塞，
優點：可以基于一個阻塞物件，同時在多個描述符上等待就緒，而不是使用多個執行緒(每個檔案描述符一
個執行緒)，這樣可以大大節省系統資源，
缺點：當連接數較少時效率相比多執行緒+阻塞 I/O 模型效率較低，可能延遲更大，因為單個連接處理需
要 2 次系統呼叫，占用時間會有增加，

5.1.4 信號驅動IO模型

我們釣魚的時候，為了避免自己一遍一遍的去查看魚竿，我們可以給魚竿安裝一個報警器，當有魚兒咬鉤的時候立刻報警，然后我們再收到報警后，去把魚釣起來，

在信號驅動IO模型中，當用戶執行緒發起一個IO請求操作，會給對應的socket注冊一個信號函式，然后用戶執行緒會繼續執行，當內核資料就緒時會發送一個信號給用戶執行緒，用戶執行緒接收到信號之后，便在信號函式中呼叫IO讀寫操作來進行實際的IO請求操作，

優點：執行緒并沒有在等待資料時被阻塞，可以提高資源的利用率，
缺點：信號 I/O 在大量 IO 操作時可能會因為信號佇列溢位導致沒法通知，

實際在呼叫io讀取資料的的時候還是阻塞的

我們把釣魚程序，可以拆分為兩個步驟：1、魚咬鉤（資料準備），2、把魚釣起來放進魚簍里（資料拷貝），無論以上提到的哪種釣魚方式，在第二步，都是需要人主動去做的，并不是魚竿自己完成的，所以，這個釣魚程序其實還是同步進行的，

5.1.5 異步IO模型

我們釣魚的時候，采用一種高科技釣魚竿，即全自動釣魚竿，可以自動感應魚上鉤，自動收竿，更厲害的可以自動把魚放進魚簍里，然后，通知我們魚已經釣到了，他就繼續去釣下一條魚去了，

異步IO模型才是最理想的IO模型，在異步IO模型中，當用戶執行緒發起read操作之后，立刻就可以開始去做其它的事，而另一方面，從內核的角度，當它收到一個asynchronous read之后，它會立刻回傳，說明read請求已經成功發起了，因此不會對用戶執行緒產生任何block，然后，內核會等待資料準備完成，然后將資料拷貝到用戶執行緒，當這一切都完成之后，內核會給用戶執行緒發送一個信號，告訴它read操作完成了，也就說用戶執行緒完全不需要知道實際的整個IO操作是如何進行的，只需要先發起一個請求，當接收內核回傳的成功信號時表示IO操作已經完成，可以直接去使用資料了，
也就說在異步IO模型中，IO操作的兩個階段都不會阻塞用戶執行緒，這兩個階段都是由內核自動完成，然后發送一個信號告知用戶執行緒操作已完成，用戶執行緒中不需要再次呼叫IO函式進行具體的讀寫，這點是和信號驅動模型有所不同的，在信號驅動模型中，當用戶執行緒接收到信號表示資料已經就緒，然后需要用戶執行緒呼叫IO函式進行實際的讀寫操作；而在異步IO模型中，收到信號表示IO操作已經完成，不需要再在用戶執行緒中呼叫iO函式進行實際的讀寫操作，
優點：異步 I/O 能夠充分利用 DMA 特性，讓 I/O 操作與計算重疊，
缺點：要實作真正的異步 I/O，作業系統需要做大量的作業，目前 Windows 下通過 IOCP 實作了真正的
異步 I/O，

參考

5.2 什么是同步？什么是異步

主要關注的是結果訊息的通信機制
同步：同步的意思就是呼叫方需要主動等待結果的回傳
異步：異步的意思就是不需要主動等待結果的回傳，而是通過其他手段比如，狀態通知，回呼函式等
重點看是否是同一個執行緒回傳

5.3 什么是阻塞？什么是非阻塞？

主要關注的是等待結果回傳呼叫方的狀態
阻塞:是指結果回傳之前，當前執行緒被掛起，不做任何事
非阻塞:是指結果在回傳之前，執行緒可以做一些其他事，不會被掛起