《面試八股文》之網(wǎng)絡(luò)19卷

微信公眾號：moon聊技術(shù)
關(guān)注選擇“ 星標 ”， 重磅干貨，第一 時間送達！
[如果你覺得文章對你有幫助，歡迎關(guān)注，在看，點贊，轉(zhuǎn)發(fā)]

其他《面試八股文》系列請關(guān)注公號moon聊技術(shù)獲取~

• 1.TCP/IP 網(wǎng)絡(luò)模型有幾層？分別有什么用？

• 2.介紹一下 HTTP 協(xié)議吧

• 3.GET 和 POST有什么區(qū)別？

• 4.PING 的作用？

• 5.常見的 HTTP 狀態(tài)碼有哪些

• 6.HTTP1.1 和 HTTP1.0 的區(qū)別有哪些？

• 7.HTTPS 和 HTTP 的區(qū)別是什么？

• 8.HTTP2 和 HTTP1.1 的區(qū)別是什么？

• 9.HTTP3 和 HTTP2 的區(qū)別是什么？

• 10.TCP 建立連接的過程是怎樣的？

• 11.為什么是三次握手？？？

• 12.TCP 斷開連接的過程是怎樣的？

• 13.第四次揮手為什么要等待2MSL(60s)

• 14.為什么是四次揮手？

• 15.TCP 滑動窗?是什么？

• 16.發(fā)送方一直發(fā)送數(shù)據(jù)，但是接收方處理不過來怎么辦？（流量控制）

• 17.TCP 半連接隊列和全連接隊列是什么？

• 18.粘包/拆包是怎么發(fā)生的？怎么解決這個問題？

• 19.瀏覽器地址欄輸入網(wǎng)站按回車后發(fā)生了什么？

1.TCP/IP 網(wǎng)絡(luò)模型有幾層？分別有什么用？

TCP/IP網(wǎng)絡(luò)模型總共有五層

• 1.應(yīng)用層:我們能接觸到的就是應(yīng)用層了，手機，電腦這些這些設(shè)備都屬于應(yīng)用層。

• 2.傳輸層:就是為應(yīng)用層提供網(wǎng)絡(luò)支持的，當設(shè)備作為接收?時，傳輸層則要負責(zé)把數(shù)據(jù)包傳給應(yīng)?，但是?臺設(shè)備上可能會有很多應(yīng)?在接收或者傳輸數(shù)據(jù)，因此需要??個編號將應(yīng)?區(qū)分開來，這個編號就是端?。所以 TCP 和 UDP 協(xié)議就是在這一層的

• 3.網(wǎng)絡(luò)層:是負責(zé)傳輸數(shù)據(jù)的，最常使用的 ip 協(xié)議就在該層，?絡(luò)層負責(zé)將數(shù)據(jù)從?個設(shè)備傳輸?shù)搅?個設(shè)備，世界上有很多設(shè)備，?絡(luò)層需要有區(qū)分設(shè)備的編號。我們?般? IP 地址給設(shè)備進?編號

• 4.數(shù)據(jù)鏈路層:每?臺設(shè)備的?卡都會有?個 MAC 地址，它就是?來唯?標識設(shè)備的。路由器計算出了下?個?的地 IP 地址，再通過 ARP 協(xié)議找到該?的地的 MAC 地址，這樣就知道這個 IP 地址是哪個設(shè)備的了。路由器就是通過數(shù)據(jù)鏈路層來知道這個 ip 地址是屬于哪個設(shè)備的，它主要為?絡(luò)層提供鏈路級別傳輸?shù)姆?wù)。

• 5.物理層:當數(shù)據(jù)準備要從設(shè)備發(fā)送到?絡(luò)的時候，需要把數(shù)據(jù)包轉(zhuǎn)換成電信號，讓其可以在物理介質(zhì)中傳輸，它主要是為數(shù)據(jù)鏈路層提供?進制傳輸?shù)姆?wù)。

2.介紹一下 HTTP 協(xié)議吧

HTTP 協(xié)議是基于 TCP 協(xié)議實現(xiàn)的，它是一個超文本傳輸協(xié)議，其實就是一個簡單的請求-響應(yīng)協(xié)議，它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)。

它主要是負責(zé)點對點之間通信的。

超文本就是用超鏈接的方法，將各種不同空間的文字信息組織在一起的網(wǎng)狀文本。比如說html，內(nèi)部定義了很多圖片視頻的鏈接，放在瀏覽器上就呈現(xiàn)出了畫面。

協(xié)議就是約定俗稱的東西，比如說 moon 要給讀者送一本書，讀者那里只接受順豐快遞，那么 moon 覺得可以，發(fā)快遞的時候選擇的順豐，那么我們彼此之間共同約定好的就叫做協(xié)議。

傳輸這個就很好理解了，比如剛才舉的例子，將書發(fā)給讀者，要通過騎車或者飛機的方式，傳遞的這個過程就是運輸。

3.GET 和 POST有什么區(qū)別？

GET 和 POST 本質(zhì)上就是 TCP 鏈接，并無差別。

但是由于 HTTP 的規(guī)定和瀏覽器/服務(wù)器的限制，導(dǎo)致他們在應(yīng)用過程中體現(xiàn)出一些不同。

4.PING 的作用？

PING 主要的作用就是測試在兩臺主機之間能否建立連接，如果 PING 不通就無法建立連接。

它其實就是向目的主機發(fā)送多個 ICMP 回送請求報文

• 如果沒有響應(yīng)則無法建立連接
• 如果有響應(yīng)就可以根據(jù)目的主機返回的回送報文的時間和成功響應(yīng)的次數(shù)估算出數(shù)據(jù)包往返時間及丟包率

5.常見的 HTTP 狀態(tài)碼有哪些

6.HTTP1.1 和 HTTP1.0 的區(qū)別有哪些？

• 1.長鏈接
• 早期 HTTP1.0 的每一次請求都伴隨著一次三次握手的過程，并且是串行的請求，增加了不必要的性能開銷
• HTTP1.1 新增了長鏈接的通訊方式，減少了性能損耗
• 2.管道
• HTTP1.0 只有串行發(fā)送，沒有管道
• HTTP1.1 增加了管道的概念，使得在同一個 TCP 鏈接當中可以同時發(fā)出多個請求
• 3.斷點續(xù)傳
• HTTP1.0 不支持斷點續(xù)傳
• HTTP1.1 新增了 range 字段，用來指定數(shù)據(jù)字節(jié)位置，開啟了斷點續(xù)傳的時代
• 4.Host頭處理
• HTTP1.0 任務(wù)主機只有一個節(jié)點，所以并沒有傳 HOST
• HTTP1.1 時代，虛擬機技術(shù)越來越發(fā)達，一臺機器上也有可能有很多節(jié)點，故增加了 HOST 信息
• 5.緩存處理
• 在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準
• HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
• 6.錯誤狀態(tài)響應(yīng)碼
• 在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼，如410（Gone）表示服務(wù)器上的某個資源被永久性的刪除等。

7.HTTPS 和 HTTP 的區(qū)別是什么？

• 1.SSL安全協(xié)議
• HTTP 是超?本傳輸協(xié)議，信息是明?傳輸，存在安全?險的問題。
• HTTPS 則解決 HTTP 不安全的缺陷，在TCP 和 HTTP ?絡(luò)層之間加?了 SSL/TLS 安全協(xié)議，使得報?能夠加密傳輸。
• 2.建立連接
• HTTP 連接建?相對簡單， TCP 三次握?之后便可進? HTTP 的報?傳輸。
• HTTPS 在 TCP 三次握?之后，還需進? SSL/TLS 的握?過程，才可進?加密報?傳輸。
• 3.端口號
• HTTP 的端?號是 80。
• HTTPS 的端?號是 443。
• 4.CA證書
• HTTPS 協(xié)議需要向 CA（證書權(quán)威。機構(gòu)）申請數(shù)字證書來保證服務(wù)器的身份是可信的。

8.HTTP2 和 HTTP1.1 的區(qū)別是什么？

• 1.頭部壓縮

• 在 HTTP2 當中，如果你發(fā)出了多個請求，并且它們的頭部(header)是相同的，那么 HTTP2 協(xié)議會幫你消除同樣的部分。(其實就是在客戶端和服務(wù)端維護一張索引表來實現(xiàn))

• 2.二進制格式

• HTTP1.1 采用明文的形式
• HTTP/2 全?采?了?進制格式，頭信息和數(shù)據(jù)體都是?進制

• 3.數(shù)據(jù)流

• HTTP/2 的數(shù)據(jù)包不是按順序發(fā)送的，同?個連接??連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)。(對數(shù)據(jù)包做了標記，標志其屬于哪一個請求，其中規(guī)定客戶端發(fā)出的數(shù)據(jù)流編號為奇數(shù)，服務(wù)器發(fā)出的數(shù)據(jù)流編號為偶數(shù)。客戶端還可以指定數(shù)據(jù)流的優(yōu)先級，優(yōu)先級?的請求，服務(wù)器就先響應(yīng)該請求)

• 4.IO多路復(fù)用

• 如:在?個連接中，服務(wù)器收到了客戶端 A 和 B 的兩個請求，但是發(fā)現(xiàn)在處理 A 的過程中?常耗時，索性就先回應(yīng) A 已經(jīng)處理好的部分，再接著回應(yīng) B 請求，最后再回應(yīng) A 請求剩下的部分。
• HTTP/2 可以在?個連接中并發(fā)多個請求或回應(yīng)。

• 5.服務(wù)器推送

• 服務(wù)器可以主動向客戶端發(fā)送請求

9.HTTP3 和 HTTP2 的區(qū)別是什么？

• 1.協(xié)議不同
• HTTP2 是基于 TCP 協(xié)議實現(xiàn)的
• HTTP3 是基于 UDP 協(xié)議實現(xiàn)的
• 2.QUIC
• HTTP3 新增了 QUIC 協(xié)議來實現(xiàn)可靠性的傳輸
• 3.握手次數(shù)
• HTTP2 是基于 HTTPS 實現(xiàn)的，建立連接需要先進行 TCP 3次握手，然后再進行 TLS 3次握手，總共6次握手
• HTTP3 只需要 QUIC 的3次握手

10.TCP 建立連接的過程是怎樣的？

• 第一次握手:A 的 TCP 進程創(chuàng)建一個 傳輸控制塊 TCB ，然后向 B 發(fā)出連接請求報文段。之后將同步位 SYN 設(shè)置為 1，同時選擇一個初始序列號 seq=x，這時客戶端 A 進入到 SYN-SENT（同步已發(fā)送）狀態(tài)。

• 第二次握手:B 收到連接請求報文段，如果同意建立連接，則向 A 發(fā)送確認。在確認報文段中 同步位 SYN=1、確認位 ACK=1、確認號 ack=x+1，同時也為自己選擇一個初始序列號 seq=y，這時服務(wù)器 B 進入 SYN-RCVID 狀態(tài)。

• 第三次握手:A 收到 B 的確認以后，再向 B 發(fā)出確認。確認報文 ACK=1、確認號ack=y+1。這時A進入到 ESTAB-LISHED 狀態(tài)。當B接收到A的確認后，也進入 ESTAB-LISHED 狀態(tài)。連接建立完成

11.為什么是三次握手？？？

• 1.為了防止已經(jīng)失效的連接請求報文段突然又傳到服務(wù)端，因而產(chǎn)生錯誤
• 如果客戶端連續(xù)發(fā)送多次 SYN 建?連接的報?，如果出現(xiàn)了網(wǎng)絡(luò)擁堵，可能會有舊連接先于新連接到達的情況，就可能會出現(xiàn)連接覆蓋，要避免這種情況，最少需要三次握手
• 2.三次握?正好避免資源浪費
• 三次握?就已經(jīng)是理論上建立可靠連接的最小次數(shù)了，所以不需要更多的連接
• 3.同步雙?初始序列號
• 同步序列號(可以鑒別重復(fù)數(shù)序，按序接受等)其實并不要三次握手，只要一來一回兩次就可以了

12.TCP 斷開連接的過程是怎樣的？

• 第一次揮手:A 先發(fā)送連接釋放報文段，段首部的終止控制位 FIN=1，序號seq=u（等于A前面發(fā)送數(shù)據(jù)的最后一個序號加1）；然后 A 進入 FIN-WAIT-1（終止等待1）狀態(tài)，等待 B 的確認。

• 第二次揮手:B 收到 A 的連接釋放報文段后，立刻發(fā)出確認報文段，確認號 ack=u+1，序號 seq=v（等于 B 前面發(fā)送數(shù)據(jù)的最后一個序號加1）；然后 B 進入 CLOSE-WAIT（關(guān)閉等待）狀態(tài)。

• 第三次揮手:A 收到 B 的確認報文段后進入到 FIN-WAIT-2（終止等待2）狀態(tài)，繼續(xù)等待 B 發(fā)出連接釋放報文段；

• 若 B 已經(jīng)沒有數(shù)據(jù)要發(fā)送，B 就會向 A 發(fā)送連接釋放報文段，段首部的終止控制位 FIN=1，序號 seq=w（半關(guān)閉狀態(tài)可能又發(fā)送了一些數(shù)據(jù)），確認號 ack=u+1，這時B進入 LAST-ACK（最后確認）狀態(tài)，等待A的確認。

• 第四次揮手:A收到B的連接釋放報文段并發(fā)出確認，確認段中 確認位 ACK=1，確認號 ack=w+1，序號 seq=u+1；然后 A 進入到TIME-WAIT（時間等待）狀態(tài)。當 B 再接收到該確認段后，B 就進入 CLOSED 狀態(tài)。

13.第四次揮手為什么要等待2MSL(60s)

首先 2MSL 的時間是從客戶端(A)接收到 FIN 后發(fā)送 ACK 開始計時的。如果在 TIME-WAIT 時間內(nèi)，因為客戶端(A)的 ACK 沒有傳輸到服務(wù)端(B)，客戶端(A)又接收到了服務(wù)端(B)重發(fā)的 FIN 報文，那么 2MSL 時間會被重置。等待 2MSL 原因如下

• 1.得原來連接的數(shù)據(jù)包消失
• 1）如果B沒有收到自己的ACK，會超時重傳FiN那么A再次接到重傳的FIN，會再次發(fā)送ACK
• 2）如果B收到自己的ACK，也不會再發(fā)任何消息，
• 在最后一次揮手后 A 并不知道 B 是否接到自己的 信息

包括 ACK 是以上哪兩種情況，A 都需要等待，要取這兩種情況等待時間的最大值，以應(yīng)對最壞的情況發(fā)生，這個最壞情況是：去向ACK消息最大存活時間（MSL) + 來向FIN消息的最大存活時間(MSL)。這剛好是2MSL，這個時間，足以使得原來連接的數(shù)據(jù)包在網(wǎng)絡(luò)中消失。

• 2.保證 ACK 能被服務(wù)端接收到從而正確關(guān)閉鏈接
• 因為這個 ACK 是有可能丟失的，會導(dǎo)致服務(wù)器收不到對 FIN-ACK 確認報文。假設(shè)客戶端不等待 2MSL ，而是在發(fā)送完 ACK 之后直接釋放關(guān)閉，一但這個 ACK 丟失的話，服務(wù)器就無法正常的進入關(guān)閉連接狀態(tài)。

14.為什么是四次揮手？

因為 tcp 可以在發(fā)送數(shù)據(jù)的同時也能接受數(shù)據(jù)，要實現(xiàn)可靠的連接關(guān)閉，A 發(fā)出結(jié)束報文 FIN，收到 B 確認后 A 知道自己沒有數(shù)據(jù)需要發(fā)送了，B 知道 A 不再發(fā)送數(shù)據(jù)了，自己也不會接收數(shù)據(jù)了，但是此時 A 還是可以接收數(shù)據(jù)，B 也可以發(fā)送數(shù)據(jù)；當 B 發(fā)出 FIN 報文的時候此時兩邊才會真正的斷開連接，讀寫分開。

15.TCP 滑動窗?是什么？

TCP 是每發(fā)送?個數(shù)據(jù)，都要進??次確認應(yīng)答。只有上一個收到了回應(yīng)才發(fā)送下一個，這樣效率會非常低，因此引進了滑動窗口的概念.

其實就是在發(fā)送方設(shè)立一個緩存區(qū)間，將已發(fā)送但未收到確認的消息緩存起來，假如一個窗口可以發(fā)送 5 個 TCP 段，那么發(fā)送方就可以連續(xù)發(fā)送 5 個 TCP 段，然后就會將這 5 個 TCP 段的數(shù)據(jù)緩存起來，這 5 個 TCP 段是有序的，只要后面的消息收到了 ACK ，那么不管前面的是否有收到 ACK,都代表成功，窗???是由接收方?jīng)Q定的。

窗???就是指不需要等待應(yīng)答，還可以發(fā)送數(shù)據(jù)的大小。

16.發(fā)送方一直發(fā)送數(shù)據(jù)，但是接收方處理不過來怎么辦？（流量控制）

如果接收方處理不過來，發(fā)送方就會觸發(fā)重試機制再次發(fā)送數(shù)據(jù)，然而這個是有性能損耗的，為了解決這個問題，TCP 就提出了流量控制，為的就是讓發(fā)送方知道接受方的處理能力。

也就是說，每次接收方接受到數(shù)據(jù)后會將剩余可處理數(shù)據(jù)的大小告訴發(fā)送方。

比如接受方滑動窗口可用大小為400字節(jié)，發(fā)送方發(fā)送過來100字節(jié)的數(shù)據(jù)，那么接收方剩余可用滑動窗口大小就為300字節(jié)，這是發(fā)送方就知道下次返送數(shù)據(jù)的大小范圍了。

但是這里有一個問題，數(shù)據(jù)會存放在緩沖區(qū)，但是這個緩沖區(qū)是操作系統(tǒng)控制的，當系統(tǒng)繁忙的時候，會縮減緩沖區(qū)減小，可能就會造成丟包的問題。

如: 發(fā)送方接收方窗口大小各為200字節(jié)，發(fā)送方發(fā)送100字節(jié)的給接收方，此時雙方各剩100字節(jié)，但是此時操作系統(tǒng)非常忙，將接收方的緩存區(qū)減少了50字節(jié)，這時接收方就會告訴發(fā)送方，我還有50字節(jié)可用，但是在接收方發(fā)送到達之前，發(fā)送方是不知道的，只會看到自己還有100字節(jié)可用，那么就繼續(xù)發(fā)送數(shù)據(jù)，如果發(fā)送了80字節(jié)數(shù)據(jù)，那么接收方緩存區(qū)大小為50字節(jié)，就會丟失30字節(jié)的數(shù)據(jù)，也就是會發(fā)生丟包現(xiàn)象。

我們會發(fā)現(xiàn)，這個問題發(fā)生的原因就是減少了緩存，又收縮了窗口大小，所以 TCP 是不允許同時減少緩存?收縮窗?的。

17.TCP 半連接隊列和全連接隊列是什么？

服務(wù)端收到客戶端發(fā)出的 SYN 請求后，會把這個連接信息存儲到半鏈接隊列(SYN 隊列)。

服務(wù)端收到第三次握?的 ACK 后，內(nèi)核會把連接從半連接隊列移除，然后創(chuàng)建新的完全的連接，并將其添加到全連接隊列(accept 隊列)，等待進程調(diào)? accept 函數(shù)時把連接取出來。

這兩個隊列都是有大小限制的，當超過容量后就會將鏈接丟棄，或者返回 RST 包。

18.粘包/拆包是怎么發(fā)生的？怎么解決這個問題？

TCP 發(fā)送數(shù)據(jù)時會根據(jù) TCP 緩沖區(qū)的實際情況進行包的劃分，一個完整的包可能會被 TCP 拆分成多個包進行發(fā)送，也有可能把多個小的包封裝成一個大的數(shù)據(jù)包發(fā)送，這就是 TCP 粘包和拆包問題。

發(fā)生 TCP 粘包的原因:

• 1.發(fā)送的數(shù)據(jù)小于 TCP 緩沖區(qū)大小，TCP將緩沖區(qū)中的數(shù)據(jù)(數(shù)據(jù)屬于多條業(yè)務(wù)內(nèi)容)一次發(fā)送出去可能就會發(fā)生粘包。
• 2.接收數(shù)據(jù)端的應(yīng)用層沒有及時讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包。

發(fā)生 TCP 拆包的原因:

• 1.待發(fā)送數(shù)據(jù)大于最大報文長度，TCP 在傳輸前將進行拆包。
• 2.發(fā)送的數(shù)據(jù)大于 TCP 發(fā)送緩沖區(qū)剩余空間大小，將會發(fā)生拆包。

解決方案:

• 1.發(fā)送端給每個數(shù)據(jù)包添加包首部，首部中包含數(shù)據(jù)包的長度，這樣接收端在接收到數(shù)據(jù)后，通過該字段就可以知道每個數(shù)據(jù)包的實際長度了。

• 2.發(fā)送端將每個數(shù)據(jù)包設(shè)置固定長度，這樣接收端每次從讀取固定長度的數(shù)據(jù)把每個數(shù)據(jù)包拆分開。

• 3.可以在數(shù)據(jù)包之間設(shè)置邊界，如添加特殊符號，接收端可以通過這個特殊符號來拆分包。

19.瀏覽器地址欄輸入網(wǎng)站按回車后發(fā)生了什么？

• 1:解析網(wǎng)址,生成 HTTP 請求信息
• 2:根據(jù) DNS 服務(wù)器查詢真實請求的 IP 地址，如果本地服務(wù)器有緩存則直接返回
• 3:得到了 IP 以后，向服務(wù)器發(fā)送 TCP 連接，TCP 連接經(jīng)過三次握手。
• 4:接受 TCP 報文后，對連接進行處理，對 HTTP 協(xié)議解析
• 5:服務(wù)器返回響應(yīng)
• 6:瀏覽器接受響應(yīng)，顯示頁面，渲染頁面

  ---