[[422375]]

一.TCP/IP 網(wǎng)絡模型有幾層?分別有什么用?

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

1.應用層:我們能接觸到的就是應用層了，手機，電腦這些這些設備都屬于應用層。

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

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

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

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

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

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

它主要是負責點對點之間通信的。

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

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

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

三.GET 和 POST有什么區(qū)別?

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

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

四.PING 的作用?

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

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

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

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

六.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 任務主機只有一個節(jié)點，所以并沒有傳 HOST

HTTP1.1 時代，虛擬機技術越來越發(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)響應碼

在HTTP1.1中新增了24個錯誤狀態(tài)響應碼，如410(Gone)表示服務器上的某個資源被永久性的刪除等。

七.HTTPS 和 HTTP 的區(qū)別是什么?

1.SSL安全協(xié)議

HTTP 是超⽂本傳輸協(xié)議，信息是明⽂傳輸，存在安全⻛險的問題。

HTTPS 則解決 HTTP 不安全的缺陷，在TCP 和 HTTP ⽹絡層之間加⼊了 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ù)字證書來保證服務器的身份是可信的。

八.HTTP2 和 HTTP1.1 的區(qū)別是什么?

1.頭部壓縮

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

2.二進制格式

HTTP1.1 采用明文的形式

HTTP/2 全⾯采⽤了⼆進制格式，頭信息和數(shù)據(jù)體都是⼆進制

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

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

4.IO多路復用

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

HTTP/2 可以在⼀個連接中并發(fā)多個請求或回應。

5.服務器推送

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

九.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次握手

十.TCP 建立連接的過程是怎樣的?

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

第二次握手:B 收到連接請求報文段，如果同意建立連接，則向 A 發(fā)送確認。在確認報文段中 同步位 SYN=1、確認位 ACK=1、確認號 ack=x+1，同時也為自己選擇一個初始序列號 seq=y，這時服務器 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)。連接建立完成

十一.為什么是三次握手???

1.為了防止已經(jīng)失效的連接請求報文段突然又傳到服務端，因而產(chǎn)生錯誤

如果客戶端連續(xù)發(fā)送多次 SYN 建⽴連接的報⽂，如果出現(xiàn)了網(wǎng)絡擁堵，可能會有舊連接先于新連接到達的情況，就可能會出現(xiàn)連接覆蓋，要避免這種情況，最少需要三次握手

2.三次握⼿正好避免資源浪費

三次握⼿就已經(jīng)是理論上建立可靠連接的最小次數(shù)了，所以不需要更多的連接

3.同步雙⽅初始序列號

同步序列號(可以鑒別重復數(shù)序，按序接受等)其實并不要三次握手，只要一來一回兩次就可以了

十二.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(關閉等待)狀態(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(半關閉狀態(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)。

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

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

1.得原來連接的數(shù)據(jù)包消失

1)如果B沒有收到自己的ACK，會超時重傳FiN那么A再次接到重傳的FIN，會再次發(fā)送ACK

2)如果B收到自己的ACK，也不會再發(fā)任何消息，

在最后一次揮手后 A 并不知道 B 是否接到自己的 信息

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

2.保證 ACK 能被服務端接收到從而正確關閉鏈接

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

十四.為什么是四次揮手?

 

因為 tcp 可以在發(fā)送數(shù)據(jù)的同時也能接受數(shù)據(jù)，要實現(xià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 報文的時候此時兩邊才會真正的斷開連接，讀寫分開。

十五.TCP 滑動窗⼝是什么?

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

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

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

十六.發(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 是不允許同時減少緩存⼜收縮窗⼝的。

十七.TCP 半連接隊列和全連接隊列是什么?

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

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

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

十八.粘包/拆包是怎么發(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è)務內(nèi)容)一次發(fā)送出去可能就會發(fā)生粘包。

2.接收數(shù)據(jù)端的應用層沒有及時讀取接收緩沖區(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ù)據(jù)把每個數(shù)據(jù)包拆分開。

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

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

1:解析網(wǎng)址,生成 HTTP 請求信息

2:根據(jù) DNS 服務器查詢真實請求的 IP 地址，如果本地服務器有緩存則直接返回

3:得到了 IP 以后，向服務器發(fā)送 TCP 連接，TCP 連接經(jīng)過三次握手。

4:接受 TCP 報文后，對連接進行處理，對 HTTP 協(xié)議解析

5:服務器返回響應

6:瀏覽器接受響應，顯示頁面，渲染頁面

本文轉(zhuǎn)載自微信公眾號「moon聊技術」