《面試八股文》之網絡十九卷
一.TCP/IP 網絡模型有幾層?分別有什么用?

TCP/IP網絡模型總共有五層
1.應用層:我們能接觸到的就是應用層了,手機,電腦這些這些設備都屬于應用層。
2.傳輸層:就是為應用層提供網絡支持的,當設備作為接收⽅時,傳輸層則要負責把數據包傳給應⽤,但是⼀臺設備上可能會有很多應⽤在接收或者傳輸數據,因此需要⽤⼀個編號將應⽤區分開來,這個編號就是端⼝。所以 TCP 和 UDP 協議就是在這一層的
3.網絡層:是負責傳輸數據的,最常使用的 ip 協議就在該層,⽹絡層負責將數據從⼀個設備傳輸到另⼀個設備,世界上有很多設備,⽹絡層需要有區分設備的編號。我們⼀般⽤ IP 地址給設備進⾏編號
4.數據鏈路層:每⼀臺設備的⽹卡都會有⼀個 MAC 地址,它就是⽤來唯⼀標識設備的。路由器計算出了下⼀個⽬的地 IP 地址,再通過 ARP 協議找到該⽬的地的 MAC 地址,這樣就知道這個 IP 地址是哪個設備的了。路由器就是通過數據鏈路層來知道這個 ip 地址是屬于哪個設備的,它主要為⽹絡層提供鏈路級別傳輸的服務。
5.物理層:當數據準備要從設備發送到⽹絡的時候,需要把數據包轉換成電信號,讓其可以在物理介質中傳輸,它主要是為數據鏈路層提供⼆進制傳輸的服務。
二.介紹一下 HTTP 協議吧
HTTP 協議是基于 TCP 協議實現的,它是一個超文本傳輸協議,其實就是一個簡單的請求-響應協議,它指定了客戶端可能發送給服務器什么樣的消息以及得到什么樣的響應。
它主要是負責點對點之間通信的。
超文本就是用超鏈接的方法,將各種不同空間的文字信息組織在一起的網狀文本。比如說html,內部定義了很多圖片視頻的鏈接,放在瀏覽器上就呈現出了畫面。
協議就是約定俗稱的東西,比如說 moon 要給讀者送一本書,讀者那里只接受順豐快遞,那么 moon 覺得可以,發快遞的時候選擇的順豐,那么我們彼此之間共同約定好的就叫做協議。
傳輸這個就很好理解了,比如剛才舉的例子,將書發給讀者,要通過騎車或者飛機的方式,傳遞的這個過程就是運輸。
三.GET 和 POST有什么區別?
GET 和 POST 本質上就是 TCP 鏈接,并無差別。
但是由于 HTTP 的規定和瀏覽器/服務器的限制,導致他們在應用過程中體現出一些不同。
四.PING 的作用?
PING 主要的作用就是測試在兩臺主機之間能否建立連接,如果 PING 不通就無法建立連接。
它其實就是向目的主機發送多個 ICMP 回送請求報文
- 如果沒有響應則無法建立連接
- 如果有響應就可以根據目的主機返回的回送報文的時間和成功響應的次數估算出數據包往返時間及丟包率
五.常見的 HTTP 狀態碼有哪些
六.HTTP1.1 和 HTTP1.0 的區別有哪些?
1.長鏈接
早期 HTTP1.0 的每一次請求都伴隨著一次三次握手的過程,并且是串行的請求,增加了不必要的性能開銷
HTTP1.1 新增了長鏈接的通訊方式,減少了性能損耗
2.管道
HTTP1.0 只有串行發送,沒有管道
HTTP1.1 增加了管道的概念,使得在同一個 TCP 鏈接當中可以同時發出多個請求
3.斷點續傳
HTTP1.0 不支持斷點續傳
HTTP1.1 新增了 range 字段,用來指定數據字節位置,開啟了斷點續傳的時代
4.Host頭處理
HTTP1.0 任務主機只有一個節點,所以并沒有傳 HOST
HTTP1.1 時代,虛擬機技術越來越發達,一臺機器上也有可能有很多節點,故增加了 HOST 信息
5.緩存處理
在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準
HTTP1.1則引入了更多的緩存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
6.錯誤狀態響應碼
在HTTP1.1中新增了24個錯誤狀態響應碼,如410(Gone)表示服務器上的某個資源被永久性的刪除等。
七.HTTPS 和 HTTP 的區別是什么?
1.SSL安全協議
HTTP 是超⽂本傳輸協議,信息是明⽂傳輸,存在安全⻛險的問題。
HTTPS 則解決 HTTP 不安全的缺陷,在TCP 和 HTTP ⽹絡層之間加⼊了 SSL/TLS 安全協議,使得報⽂能夠加密傳輸。
2.建立連接
HTTP 連接建⽴相對簡單, TCP 三次握⼿之后便可進⾏ HTTP 的報⽂傳輸。
HTTPS 在 TCP 三次握⼿之后,還需進⾏ SSL/TLS 的握⼿過程,才可進⼊加密報⽂傳輸。
3.端口號
HTTP 的端⼝號是 80。
HTTPS 的端⼝號是 443。
4.CA證書
HTTPS 協議需要向 CA(證書權威。機構)申請數字證書來保證服務器的身份是可信的。
八.HTTP2 和 HTTP1.1 的區別是什么?
1.頭部壓縮
在 HTTP2 當中,如果你發出了多個請求,并且它們的頭部(header)是相同的,那么 HTTP2 協議會幫你消除同樣的部分。(其實就是在客戶端和服務端維護一張索引表來實現)
2.二進制格式
HTTP1.1 采用明文的形式
HTTP/2 全⾯采⽤了⼆進制格式,頭信息和數據體都是⼆進制
3.數據流
HTTP/2 的數據包不是按順序發送的,同⼀個連接⾥⾯連續的數據包,可能屬于不同的回應。(對數據包做了標記,標志其屬于哪一個請求,其中規定客戶端發出的數據流編號為奇數,服務器發出的數據流編號為偶數。客戶端還可以指定數據流的優先級,優先級⾼的請求,服務器就先響應該請求)
4.IO多路復用
如:在⼀個連接中,服務器收到了客戶端 A 和 B 的兩個請求,但是發現在處理 A 的過程中⾮常耗時,索性就先回應 A 已經處理好的部分,再接著回應 B 請求,最后再回應 A 請求剩下的部分。
HTTP/2 可以在⼀個連接中并發多個請求或回應。
5.服務器推送
服務器可以主動向客戶端發送請求
九.HTTP3 和 HTTP2 的區別是什么?
1.協議不同
HTTP2 是基于 TCP 協議實現的
HTTP3 是基于 UDP 協議實現的
2.QUIC
HTTP3 新增了 QUIC 協議來實現可靠性的傳輸
3.握手次數
HTTP2 是基于 HTTPS 實現的,建立連接需要先進行 TCP 3次握手,然后再進行 TLS 3次握手,總共6次握手
HTTP3 只需要 QUIC 的3次握手
十.TCP 建立連接的過程是怎樣的?
第一次握手:A 的 TCP 進程創建一個 傳輸控制塊 TCB ,然后向 B 發出連接請求報文段。之后將同步位 SYN 設置為 1,同時選擇一個初始序列號 seq=x,這時客戶端 A 進入到 SYN-SENT(同步已發送)狀態。
第二次握手:B 收到連接請求報文段,如果同意建立連接,則向 A 發送確認。在確認報文段中 同步位 SYN=1、確認位 ACK=1、確認號 ack=x+1,同時也為自己選擇一個初始序列號 seq=y,這時服務器 B 進入 SYN-RCVID 狀態。
第三次握手:A 收到 B 的確認以后,再向 B 發出確認。確認報文 ACK=1、確認號ack=y+1。這時A進入到 ESTAB-LISHED 狀態。當B接收到A的確認后,也進入 ESTAB-LISHED 狀態。連接建立完成
十一.為什么是三次握手???
1.為了防止已經失效的連接請求報文段突然又傳到服務端,因而產生錯誤
如果客戶端連續發送多次 SYN 建⽴連接的報⽂,如果出現了網絡擁堵,可能會有舊連接先于新連接到達的情況,就可能會出現連接覆蓋,要避免這種情況,最少需要三次握手
2.三次握⼿正好避免資源浪費
三次握⼿就已經是理論上建立可靠連接的最小次數了,所以不需要更多的連接
3.同步雙⽅初始序列號
同步序列號(可以鑒別重復數序,按序接受等)其實并不要三次握手,只要一來一回兩次就可以了
十二.TCP 斷開連接的過程是怎樣的?
第一次揮手:A 先發送連接釋放報文段,段首部的終止控制位 FIN=1,序號seq=u(等于A前面發送數據的最后一個序號加1);然后 A 進入 FIN-WAIT-1(終止等待1)狀態,等待 B 的確認。
第二次揮手:B 收到 A 的連接釋放報文段后,立刻發出確認報文段,確認號 ack=u+1,序號 seq=v(等于 B 前面發送數據的最后一個序號加1);然后 B 進入 CLOSE-WAIT(關閉等待)狀態。
第三次揮手:A 收到 B 的確認報文段后進入到 FIN-WAIT-2(終止等待2)狀態,繼續等待 B 發出連接釋放報文段;
若 B 已經沒有數據要發送,B 就會向 A 發送連接釋放報文段,段首部的終止控制位 FIN=1,序號 seq=w(半關閉狀態可能又發送了一些數據),確認號 ack=u+1,這時B進入 LAST-ACK(最后確認)狀態,等待A的確認。
第四次揮手:A收到B的連接釋放報文段并發出確認,確認段中 確認位 ACK=1,確認號 ack=w+1,序號 seq=u+1;然后 A 進入到TIME-WAIT(時間等待)狀態。當 B 再接收到該確認段后,B 就進入 CLOSED 狀態。
十三.第四次揮手為什么要等待2MSL(60s)
首先 2MSL 的時間是從客戶端(A)接收到 FIN 后發送 ACK 開始計時的。如果在 TIME-WAIT 時間內,因為客戶端(A)的 ACK 沒有傳輸到服務端(B),客戶端(A)又接收到了服務端(B)重發的 FIN 報文,那么 2MSL 時間會被重置。等待 2MSL 原因如下
1.得原來連接的數據包消失
1)如果B沒有收到自己的ACK,會超時重傳FiN那么A再次接到重傳的FIN,會再次發送ACK
2)如果B收到自己的ACK,也不會再發任何消息,
在最后一次揮手后 A 并不知道 B 是否接到自己的 信息
包括 ACK 是以上哪兩種情況,A 都需要等待,要取這兩種情況等待時間的最大值,以應對最壞的情況發生,這個最壞情況是:去向ACK消息最大存活時間(MSL) + 來向FIN消息的最大存活時間(MSL)。這剛好是2MSL,這個時間,足以使得原來連接的數據包在網絡中消失。
2.保證 ACK 能被服務端接收到從而正確關閉鏈接
因為這個 ACK 是有可能丟失的,會導致服務器收不到對 FIN-ACK 確認報文。假設客戶端不等待 2MSL ,而是在發送完 ACK 之后直接釋放關閉,一但這個 ACK 丟失的話,服務器就無法正常的進入關閉連接狀態。
十四.為什么是四次揮手?
因為 tcp 可以在發送數據的同時也能接受數據,要實現可靠的連接關閉,A 發出結束報文 FIN,收到 B 確認后 A 知道自己沒有數據需要發送了,B 知道 A 不再發送數據了,自己也不會接收數據了,但是此時 A 還是可以接收數據,B 也可以發送數據;當 B 發出 FIN 報文的時候此時兩邊才會真正的斷開連接,讀寫分開。
十五.TCP 滑動窗⼝是什么?
TCP 是每發送⼀個數據,都要進⾏⼀次確認應答。只有上一個收到了回應才發送下一個,這樣效率會非常低,因此引進了滑動窗口的概念.
其實就是在發送方設立一個緩存區間,將已發送但未收到確認的消息緩存起來,假如一個窗口可以發送 5 個 TCP 段,那么發送方就可以連續發送 5 個 TCP 段,然后就會將這 5 個 TCP 段的數據緩存起來,這 5 個 TCP 段是有序的,只要后面的消息收到了 ACK ,那么不管前面的是否有收到 ACK,都代表成功,窗⼝⼤⼩是由接收方決定的。
窗⼝⼤⼩就是指不需要等待應答,還可以發送數據的大小。
十六.發送方一直發送數據,但是接收方處理不過來怎么辦?(流量控制)
如果接收方處理不過來,發送方就會觸發重試機制再次發送數據,然而這個是有性能損耗的,為了解決這個問題,TCP 就提出了流量控制,為的就是讓發送方知道接受方的處理能力。
也就是說,每次接收方接受到數據后會將剩余可處理數據的大小告訴發送方。
比如接受方滑動窗口可用大小為400字節,發送方發送過來100字節的數據,那么接收方剩余可用滑動窗口大小就為300字節,這是發送方就知道下次返送數據的大小范圍了。
但是這里有一個問題,數據會存放在緩沖區,但是這個緩沖區是操作系統控制的,當系統繁忙的時候,會縮減緩沖區減小,可能就會造成丟包的問題。
如: 發送方接收方窗口大小各為200字節,發送方發送100字節的給接收方,此時雙方各剩100字節,但是此時操作系統非常忙,將接收方的緩存區減少了50字節,這時接收方就會告訴發送方,我還有50字節可用,但是在接收方發送到達之前,發送方是不知道的,只會看到自己還有100字節可用,那么就繼續發送數據,如果發送了80字節數據,那么接收方緩存區大小為50字節,就會丟失30字節的數據,也就是會發生丟包現象。
我們會發現,這個問題發生的原因就是減少了緩存,又收縮了窗口大小,所以 TCP 是不允許同時減少緩存⼜收縮窗⼝的。
十七.TCP 半連接隊列和全連接隊列是什么?
服務端收到客戶端發出的 SYN 請求后,會把這個連接信息存儲到半鏈接隊列(SYN 隊列)。
服務端收到第三次握⼿的 ACK 后,內核會把連接從半連接隊列移除,然后創建新的完全的連接,并將其添加到全連接隊列(accept 隊列),等待進程調⽤ accept 函數時把連接取出來。
這兩個隊列都是有大小限制的,當超過容量后就會將鏈接丟棄,或者返回 RST 包。
十八.粘包/拆包是怎么發生的?怎么解決這個問題?
TCP 發送數據時會根據 TCP 緩沖區的實際情況進行包的劃分,一個完整的包可能會被 TCP 拆分成多個包進行發送,也有可能把多個小的包封裝成一個大的數據包發送,這就是 TCP 粘包和拆包問題。
發生 TCP 粘包的原因:
1.發送的數據小于 TCP 緩沖區大小,TCP將緩沖區中的數據(數據屬于多條業務內容)一次發送出去可能就會發生粘包。
2.接收數據端的應用層沒有及時讀取接收緩沖區中的數據,將發生粘包。
發生 TCP 拆包的原因:
1.待發送數據大于最大報文長度,TCP 在傳輸前將進行拆包。
2.發送的數據大于 TCP 發送緩沖區剩余空間大小,將會發生拆包。
解決方案:
1.發送端給每個數據包添加包首部,首部中包含數據包的長度,這樣接收端在接收到數據后,通過該字段就可以知道每個數據包的實際長度了。
2.發送端將每個數據包設置固定長度,這樣接收端每次從讀取固定長度的數據把每個數據包拆分開。
3.可以在數據包之間設置邊界,如添加特殊符號,接收端可以通過這個特殊符號來拆分包。
十九.瀏覽器地址欄輸入網站按回車后發生了什么?
1:解析網址,生成 HTTP 請求信息
2:根據 DNS 服務器查詢真實請求的 IP 地址,如果本地服務器有緩存則直接返回
3:得到了 IP 以后,向服務器發送 TCP 連接,TCP 連接經過三次握手。
4:接受 TCP 報文后,對連接進行處理,對 HTTP 協議解析
5:服務器返回響應
6:瀏覽器接受響應,顯示頁面,渲染頁面
本文轉載自微信公眾號「moon聊技術」