自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

面試題系列:網(wǎng)絡(luò)篇奪命連環(huán)12問

網(wǎng)絡(luò) 通信技術(shù)
為了增強(qiáng)通用性和兼容性,計算機(jī)網(wǎng)絡(luò)都被設(shè)計成層次機(jī)構(gòu),每一層都遵守一定的規(guī)則。因此有了OSI這樣一個抽象的網(wǎng)絡(luò)通信參考模型,按照這個標(biāo)準(zhǔn)使計算機(jī)網(wǎng)絡(luò)系統(tǒng)可以互相連接。

一、談一談你對 TCP/IP 四層模型,OSI 七層模型的理解?

為了增強(qiáng)通用性和兼容性,計算機(jī)網(wǎng)絡(luò)都被設(shè)計成層次機(jī)構(gòu),每一層都遵守一定的規(guī)則。

[[403728]]

因此有了OSI這樣一個抽象的網(wǎng)絡(luò)通信參考模型,按照這個標(biāo)準(zhǔn)使計算機(jī)網(wǎng)絡(luò)系統(tǒng)可以互相連接。

  • 物理層:通過網(wǎng)線、光纜等這種物理方式將電腦連接起來。傳遞的數(shù)據(jù)是比特流,0101010100。
  • 數(shù)據(jù)鏈路層:首先,把比特流封裝成數(shù)據(jù)幀的格式,對0、1進(jìn)行分組。電腦連接起來之后,數(shù)據(jù)都經(jīng)過網(wǎng)卡來傳輸,而網(wǎng)卡上定義了全世界唯一的MAC地址。然后再通過廣播的形式向局域網(wǎng)內(nèi)所有電腦發(fā)送數(shù)據(jù),再根據(jù)數(shù)據(jù)中MAC地址和自身對比判斷是否是發(fā)給自己的。
  • 網(wǎng)絡(luò)層:廣播的形式太低效,為了區(qū)分哪些MAC地址屬于同一個子網(wǎng),網(wǎng)絡(luò)層定義了IP和子網(wǎng)掩碼,通過對IP和子網(wǎng)掩碼進(jìn)行與運(yùn)算就知道是否是同一個子網(wǎng),再通過路由器和交換機(jī)進(jìn)行傳輸。IP協(xié)議屬于網(wǎng)絡(luò)層的協(xié)議。
  • 傳輸層:有了網(wǎng)絡(luò)層的MAC+IP地址之后,為了確定數(shù)據(jù)包是從哪個進(jìn)程發(fā)送過來的,就需要端口號,通過端口來建立通信,比如TCP和UDP屬于這一層的協(xié)議。
  • 會話層:負(fù)責(zé)建立和斷開連接
  • 表示層:為了使得數(shù)據(jù)能夠被其他的計算機(jī)理解,再次將數(shù)據(jù)轉(zhuǎn)換成另外一種格式,比如文字、視頻、圖片等。
  • 應(yīng)用層:最高層,面對用戶,提供計算機(jī)網(wǎng)絡(luò)與最終呈現(xiàn)給用戶的界面

TCP/IP則是四層的結(jié)構(gòu),相當(dāng)于是對OSI模型的簡化。

  • 數(shù)據(jù)鏈路層,也有稱作網(wǎng)絡(luò)訪問層、網(wǎng)絡(luò)接口層。他包含了OSI模型的物理層和數(shù)據(jù)鏈路層,把電腦連接起來。
  • 網(wǎng)絡(luò)層,也叫做IP層,處理IP數(shù)據(jù)包的傳輸、路由,建立主機(jī)間的通信。
  • 傳輸層,就是為兩臺主機(jī)設(shè)備提供端到端的通信。
  • 應(yīng)用層,包含OSI的會話層、表示層和應(yīng)用層,提供了一些常用的協(xié)議規(guī)范,比如FTP、SMPT、HTTP等。

總結(jié)下來,就是物理層通過物理手段把電腦連接起來,數(shù)據(jù)鏈路層則對比特流的數(shù)據(jù)進(jìn)行分組,網(wǎng)絡(luò)層來建立主機(jī)到主機(jī)的通信,傳輸層建立端口到端口的通信,應(yīng)用層最終負(fù)責(zé)建立連接,數(shù)據(jù)格式轉(zhuǎn)換,最終呈現(xiàn)給用戶。

二、說說 TCP 3次握手的過程?

建立連接前server端需要監(jiān)聽端口,所以初始狀態(tài)是LISTEN。

  • client端建立連接,發(fā)送一個SYN同步包,發(fā)送之后狀態(tài)變成SYN_SENT
  • server端收到SYN之后,同意建立連接,返回一個ACK響應(yīng),同時也會給client發(fā)送一個SYN包,發(fā)送完成之后狀態(tài)變?yōu)镾YN_RCVD
  • client端收到server的ACK之后,狀態(tài)變?yōu)镋STABLISHED,返回ACK給server端。server收到之后狀態(tài)也變?yōu)镋STABLISHED,連接建立完成。

三、為什么要3次?2次,4次不行嗎?

因為TCP是雙工傳輸模式,不區(qū)分客戶端和服務(wù)端,連接的建立是雙向的過程。

如果只有兩次,無法做到雙向連接的建立,從建立連接server回復(fù)的SYN和ACK合并成一次可以看出來,他也不需要4次。

揮手為什么要四次?因為揮手的ACK和FIN不能同時發(fā)送,因為數(shù)據(jù)發(fā)送的截止時間不同。

四、那么四次揮手的過程呢?

  1. client端向server發(fā)送FIN包,進(jìn)入FIN_WAIT_1狀態(tài),這代表client端已經(jīng)沒有數(shù)據(jù)要發(fā)送了
  2. server端收到之后,返回一個ACK,進(jìn)入CLOSE_WAIT等待關(guān)閉的狀態(tài),因為server端可能還有沒有發(fā)送完成的數(shù)據(jù)
  3. 等到server端數(shù)據(jù)都發(fā)送完畢之后,server端就向client發(fā)送FIN,進(jìn)入LAST_ACK狀態(tài)
  4. client收到ACK之后,進(jìn)入TIME_WAIT的狀態(tài),同時回復(fù)ACK,server收到之后直接進(jìn)入CLOSED狀態(tài),連接關(guān)閉。但是client要等待2MSL(報文最大生存時間)的時間,才會進(jìn)入CLOSED狀態(tài)。

五、為什么要等待2MSL 的時間才關(guān)閉?

  • 為了保證連接的可靠關(guān)閉。如果server沒有收到最后一個ACK,那么就會重發(fā)FIN。
  • 為了避免端口重用帶來的數(shù)據(jù)混淆。如果client直接進(jìn)入CLOSED狀態(tài),又用相同端口號向server建立一個連接,上一次連接的部分?jǐn)?shù)據(jù)在網(wǎng)絡(luò)中延遲到達(dá)server,數(shù)據(jù)就可能發(fā)生混淆了。

六、TCP 怎么保證傳輸過程的可靠性?

校驗和:發(fā)送方在發(fā)送數(shù)據(jù)之前計算校驗和,接收方收到數(shù)據(jù)后同樣計算,如果不一致,那么傳輸有誤。

確認(rèn)應(yīng)答,序列號:TCP進(jìn)行傳輸時數(shù)據(jù)都進(jìn)行了編號,每次接收方返回ACK都有確認(rèn)序列號。

超時重傳:如果發(fā)送方發(fā)送數(shù)據(jù)一段時間后沒有收到ACK,那么就重發(fā)數(shù)據(jù)。

連接管理:三次握手和四次揮手的過程。

流量控制:TCP協(xié)議報頭包含16位的窗口大小,接收方會在返回ACK時同時把自己的即時窗口填入,發(fā)送方就根據(jù)報文中窗口的大小控制發(fā)送速度。

擁塞控制:剛開始發(fā)送數(shù)據(jù)的時候,擁塞窗口是1,以后每次收到ACK,則擁塞窗口+1,然后將擁塞窗口和收到的窗口取較小值作為實際發(fā)送的窗口,如果發(fā)生超時重傳,擁塞窗口重置為1。這樣做的目的就是為了保證傳輸過程的高效性和可靠性。

七、說下瀏覽器請求一個網(wǎng)址的過程?

  • 首先通過DNS服務(wù)器把域名解析成IP地址,通過IP和子網(wǎng)掩碼判斷是否屬于同一個子網(wǎng)
  • 構(gòu)造應(yīng)用層請求http報文,傳輸層添加TCP/UDP頭部,網(wǎng)絡(luò)層添加IP頭部,數(shù)據(jù)鏈路層添加以太網(wǎng)協(xié)議頭部
  • 數(shù)據(jù)經(jīng)過路由器、交換機(jī)轉(zhuǎn)發(fā),最終達(dá)到目標(biāo)服務(wù)器,目標(biāo)服務(wù)器同樣解析數(shù)據(jù),最終拿到http報文,按照對應(yīng)的程序的邏輯響應(yīng)回去。

八、知道HTTPS的工作原理嗎?

  • 用戶通過瀏覽器請求https網(wǎng)站,服務(wù)器收到請求,選擇瀏覽器支持的加密和hash算法,同時返回數(shù)字證書給瀏覽器,包含頒發(fā)機(jī)構(gòu)、網(wǎng)址、公鑰、證書有效期等信息。
  • 瀏覽器對證書的內(nèi)容進(jìn)行校驗,如果有問題,則會有一個提示警告。否則,就生成一個隨機(jī)數(shù)X,同時使用證書中的公鑰進(jìn)行加密,并且發(fā)送給服務(wù)器。
  • 服務(wù)器收到之后,使用私鑰解密,得到隨機(jī)數(shù)X,然后使用X對網(wǎng)頁內(nèi)容進(jìn)行加密,返回給瀏覽器
  • 瀏覽器則使用X和之前約定的加密算法進(jìn)行解密,得到最終的網(wǎng)頁內(nèi)容

九、負(fù)載均衡有哪些實現(xiàn)方式?

DNS:這是最簡單的負(fù)載均衡的方式,一般用于實現(xiàn)地理級別的負(fù)載均衡,不同地域的用戶通過DNS的解析可以返回不同的IP地址,這種方式的負(fù)載均衡簡單,但是擴(kuò)展性太差,控制權(quán)在域名服務(wù)商。

Http重定向:通過修改Http響應(yīng)頭的Location達(dá)到負(fù)載均衡的目的,Http的302重定向。這種方式對性能有影響,而且增加請求耗時。

反向代理:作用于應(yīng)用層的模式,也被稱作為七層負(fù)載均衡,比如常見的Nginx,性能一般可以達(dá)到萬級。這種方式部署簡單,成本低,而且容易擴(kuò)展。

IP:作用于網(wǎng)絡(luò)層的和傳輸層的模式,也被稱作四層負(fù)載均衡,通過對數(shù)據(jù)包的IP地址和端口進(jìn)行修改來達(dá)到負(fù)載均衡的效果。常見的有LVS(Linux Virtual Server),通常性能可以支持10萬級并發(fā)。

按照類型來劃分的話,還可以分成DNS負(fù)載均衡、硬件負(fù)載均衡、軟件負(fù)載均衡。

其中硬件負(fù)載均衡價格昂貴,性能最好,能達(dá)到百萬級,軟件負(fù)載均衡包括Nginx、LVS這種。

十、說說 BIO/NIO/AIO 的區(qū)別?

BIO:同步阻塞IO,每一個客戶端連接,服務(wù)端都會對應(yīng)一個處理線程,對于沒有分配到處理線程的連接就會被阻塞或者拒絕。相當(dāng)于是一個連接一個線程。

NIO:同步非阻塞IO,基于Reactor模型,客戶端和channel進(jìn)行通信,channel可以進(jìn)行讀寫操作,通過多路復(fù)用器selector來輪詢注冊在其上的channel,而后再進(jìn)行IO操作。這樣的話,在進(jìn)行IO操作的時候再用一個線程去處理就可以了,也就是一個請求一個線程。

AIO:異步非阻塞IO,相比NIO更進(jìn)一步,完全由操作系統(tǒng)來完成請求的處理,然后通知服務(wù)端開啟線程去進(jìn)行處理,因此是一個有效請求一個線程。

十一、那么你怎么理解同步和阻塞?

首先,可以認(rèn)為一個IO操作包含兩個部分:

  • 發(fā)起IO請求
  • 實際的IO讀寫操作

同步和異步在于第二個,實際的IO讀寫操作,如果操作系統(tǒng)幫你完成了再通知你,那就是異步,否則都叫做同步。

阻塞和非阻塞在于第一個,發(fā)起IO請求,對于NIO來說通過channel發(fā)起IO操作請求后,其實就返回了,所以是非阻塞。

十二、談一下你對Reactor模型的理解?

Reactor模型包含兩個組件:

  1. Reactor:負(fù)責(zé)查詢、響應(yīng)IO事件,當(dāng)檢測到IO事件時,分發(fā)給Handlers處理。
  2. Handler:與IO事件綁定,負(fù)責(zé)IO事件的處理。

它包含幾種實現(xiàn)方式:

單線程 Reactor

這個模式reactor和handler在一個線程中,如果某個handler阻塞的話,會導(dǎo)致其他所有的handler無法執(zhí)行,而且無法充分利用多核的性能。

 

單 Reactor 多線程

由于decode、compute、encode的操作并非IO的操作,多線程Reactor的思路就是充分發(fā)揮多核的特性,同時把非IO的操作剝離開。

但是,單個Reactor承擔(dān)了所有的事件監(jiān)聽、響應(yīng)工作,如果連接過多,還是可能存在性能問題。

 

多 Reactor 多線程

為了解決單Reactor的性能問題,就產(chǎn)生了多Reactor的模式。其中mainReactor建立連接,多個subReactor則負(fù)責(zé)數(shù)據(jù)讀寫。

 

 

責(zé)任編輯:未麗燕 來源: 阿里云云棲號
相關(guān)推薦

2021-10-26 15:56:57

kafka數(shù)據(jù)平臺,

2023-02-26 02:00:36

OpenFeign接口實現(xiàn)類

2024-03-13 13:56:11

openFeignHttp服務(wù)調(diào)用

2023-03-08 09:03:55

2023-04-26 09:16:17

2021-07-21 09:15:27

MySQL數(shù)據(jù)庫面試

2021-07-30 16:16:54

網(wǎng)絡(luò)面試TCP

2018-07-10 16:50:28

數(shù)據(jù)庫MySQL面試題

2022-03-25 09:01:36

Spring循環(huán)依賴面試

2010-12-29 10:33:51

Oracle

2021-01-19 05:24:36

ThreadLocal線程編程

2021-11-08 14:10:37

分布式Spring鏈路

2019-05-29 15:17:43

TCPHTTPSSL

2022-05-14 21:19:22

ThreadLocaJDKsynchroniz

2020-06-04 14:40:40

面試題Vue前端

2020-08-06 10:45:30

JavaSpring面試題

2022-05-08 19:58:10

JSONPJavaScript

2023-11-13 07:37:36

JS面試題線程

2011-03-24 13:27:37

SQL

2021-01-14 10:24:33

嵌入式筆試面試
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號