位元組跳動常考的基礎電腦網路面試題，快來看看！

這篇文章跟大家分享一些位元組跳動最愛考的，關於電腦網路的前端面試題。有一定的參考價值，有需要的朋友可以參考一下，希望對大家有幫助。

注意：每題前面出現的(xx) 數字代表這題出現的頻次，此電腦網路基礎是基於30 篇前端面經整理出的問題和對應的回答、參考連結等。文章內容為拿到 Offer 的本人整理。

（3）問：HTTP 快取

---

#HTTP 快取又分為強快取與協商快取：

• 首先透過Cache-Control 驗證強快取是否可用，如果強快取可用，那麼直接讀取快取

• 如果不可以，那麼就進入協商快取階段，發起HTTP 請求，伺服器透過請求頭中是否帶上If-Modified-Since 和If-None-Match 這些條件請求欄位檢查資源是否更新：

  • 若資源更新，那麼傳回資源和200狀態碼

  • 如果資源未更新，那麼告訴瀏覽器直接使用快取取得資源

##（ 5）問：HTTP 常用的狀態碼及使用情境？

---

• 1xx：表示目前是協定的中間狀態，還需要後續請求

• 2xx：表示請求成功

• 3xx：表示重定向狀態，需要重新要求

• 4xx：表示請求訊息錯誤

• 5xx：伺服器端錯誤

常用狀態碼：

• 101 切換請求協議，從HTTP 切換到WebSocket

• #200 請求成功，有回應體

• 301 永久重定向：會快取

• 302 暫時重定向：不會快取

• 304 協商快取命中

• #403 伺服器禁止存取

• 404 資源未找到

• 400 請求錯誤

• #500 伺服器端錯誤

• 503 伺服器忙線

你知道302 狀態碼是什麼嘛？你平常瀏覽網頁的過程中遇到過哪些 302 的場景？

---

而302 表示臨時重定向，這個資源只是暫時不能被訪問了，但是之後過一段時間還是可以繼續訪問，一般是訪問某個網站的資源需要權限時，會需要使用者去登錄，跳到登入頁面之後登入之後，還可以繼續造訪。

301 類似，都會跳到一個新的網站，但是301 代表訪問的地址的資源被永久移除了，以後都不應該訪問這個地址，搜索引擎抓取的時候也會用新的地址替換這個老的。可以在回傳的回應的 location 首部去取得到回傳的位址。 301 的場景如下：

• 例如從http://baidu.com，跳轉到https://baidu.com

##域名換了
（2）問：HTTP 常用的請求方式，區別和用途？

http/1.1 規定以下請求方法：

---

#GET：通用取得資料
HEAD：取得資源的元資訊
POST：提交資料
#PUT：修改資料

• ##DELETE：刪除資料

• CONNECT：建立連線隧道，用於代理伺服器

• #OPTIONS：列出可對資源實施的請求方法，常用於跨域

• TRACE：追蹤請求-回應的傳輸路徑
（）問：你對電腦網路的認知怎麼樣

應用程式層、表示層、會話層、傳輸層、網路層、資料鏈結層、實體層

---

（3 ）問：HTTPS 是什麼？具體流程

HTTPS 是在HTTP 和TCP 之間建立了一個安全層，HTTP 與TCP 通訊的時候，必須先進過一個安全層，對封包進行加密，然後將加密後的封包傳送給TCP，對應的TCP 必須將封包解密，才能傳給上面的HTTP。

---

瀏覽器傳輸一個client_random 和加密方法列表，伺服器收到後，傳給瀏覽器一個server_random、加密方法列表和數位憑證（包含了公鑰），然後瀏覽器對數位憑證進行合法驗證，如果驗證通過，則產生一個pre_random，然後用公鑰加密傳給伺服器，伺服器用client_random、server_random 和pre_random ，使用公鑰加密產生secret，然後之後的傳輸使用這個secret 作為秘鑰來進行資料的加解密。

（4）問：三次握手和四次揮手

#為什麼要進行三次握手：為了確認對方的發送和接收能力。

---

三次握手

三次握手主要流程：

• 一開始雙方處於CLOSED 狀態，然後服務端開始監聽某個連接埠進入LISTEN 狀態

• 然後客戶端主動發起連接，發送SYN，然後自己變成SYN-SENT，seq = x

• 服務端收到之後，回傳SYN seq = y 和ACK ack = x 1（對於客戶端發來的SYN），自己變成SYN-REVD

• 之後客戶端再發送ACK seq = x 1, ack = y 1給服務端，自己變成EASTABLISHED 狀態，服務端收到ACK，也進入ESTABLISHED

SYN 需要對端確認，所以ACK 的序列化要加一，凡是需要對端確認的，一點要消耗TCP 封包的序列化

為什麼不是兩次？

無法確認客戶端的接收能力。

如果首先客戶端發送了 SYN 封包，但是滯留在網路中，TCP 以為丟包了，然後重傳，兩次握手建立了連接。

等到客戶端關閉連線了。但是之後這個包如果到達了服務端，那麼服務端接收到了，然後發送相應的數據表，就建立了鏈接，但是此時客戶端已經關閉連接了，所以帶來了鏈接資源的浪費。

為什麼不是四次？

四次以上都可以，只不過三次就夠了

#四次揮手

• 一開始都處於ESTABLISH 狀態，然後客戶端發送FIN 封包，帶上seq = p，狀態變成FIN-WAIT-1

• 服務端收到之後，發送ACK 確認，ack = p 1，然後進入CLOSE-WAIT 狀態

• 客戶端收到之後進入FIN-WAIT-2  狀態

• #過了一會兒等資料處理完，再發送FIN、ACK，seq = q，ack = p 1，進入LAST-ACK 階段

• 客戶端收到FIN 之後，客戶端收到之後進入TIME_WAIT（等待2MSL），然後發送ACK 給服務端ack = 1 1

• 服務端收到之後進入CLOSED 狀態

客戶端這個時候還需要等待兩次MSL 之後，如果沒有收到服務端的重發請求，就表示ACK 成功到達，揮手結束，客戶端變成CLOSED 狀態，否則進行ACK 重發

為什麼需要等待2MSL（Maximum Segement Lifetime）：

因為如果不等待的話，如果服務端還有很多資料包要向客戶端發，且此時客戶端連接埠被新應用程式佔據，那麼就會接收到無用的資料包，造成資料包混亂，所以說最保險的方法就是等伺服器發來的資料包都死翹翹了再啟動新應用。

• 1個MSL 保證四次揮手中主動關閉方最後的ACK 封包能最終到達對端

• 1個MSL 保證對端沒有收到ACK 那麼進行重傳的FIN 封包能夠到達

為什麼是四次而不是三次？

**如果是三次的話，那麼服務端的ACK 和FIN 合成一個揮手，那麼長時間的延遲可能讓TCP 一位FIN 沒有達到伺服器端，然後讓客戶的不斷的重發FIN

參考資料

• #https://zhuanlan.zhihu.com/p/86426969

問：在互動過程中如果資料傳送完了，還不想斷開連線怎麼辦，怎麼維持？

---

在 HTTP 中回應體的 Connection 欄位指定為 keep-alive

你對 TCP 滑動視窗有了解嘛？

---

在TCP 連結中，對於發送端和接收端而言，TCP 需要把發送的資料放到發送快取區, 將接收的資料放到接收快取區。而常常會存在發送端發送過多，而接收端無法消化的情況，所以就需要流量控制，就是在透過接收快取區的大小，控制發送端的發送。如果對方的接收快取區滿了，就不能再繼續發送了。而這種流量控制的過程就需要在發送端維護一個發送窗口，在接收端維持一個接收窗口。

TCP 滑動視窗分為兩種: 發送視窗和接收視窗。

參考資料

• #https://juejin.im/post/5e527c58e51d4526c654bf41#heading-38

問：WebSocket與Ajax的差異

---

本質不同

Ajax 即非同步JavaScript 和XML，是一種創建互動式網頁的應用的網頁開發技術

websocket 是HTML5 的一種新協議，實現了瀏覽器和伺服器的即時通訊

生命週期不同：

#

• websocket 是長連接，會話一直保持

• ajax 發送接收之後就會斷開

適用範圍：

• websocket 用於前後端即時互動資料

• ajax 非即時

發起人：

• AJAX 用戶端發起

---

#WebSocket 伺服器端與客戶端互相推送

了解WebSocket 嘛？

長輪詢和短輪詢，WebSocket 是長輪詢。 具體例如在一個電商場景，商品的庫存可能會變化，所以需要及時反映給用戶，所以客戶端會不停的發請求，然後伺服器端會不停的去查變化，不管變不變，都返回，這個是短輪詢。

而長輪詢則表現為如果沒有變，就不返回，而是等待變或逾時（一般是十幾秒）才返回，如果沒有返回，客戶端也不需要一直發請求，所以減少了雙方的壓力。
參考連結

---

#https://www.jianshu.com/p/3fc3646fad80

• #HTTP 如何實現長連線？什麼時候會超時？

• 透過在頭部（請求和回應頭）設定Connection: keep-alive，HTTP1.0協定支持，但是預設關閉，從HTTP1.1協定以後，連線預設都是長連線

  • HTTP 一般會有httpd 守護進程，裡面可以設定keep-alive timeout，當tcp 連結閒置超過這個時間就會關閉，也可以在HTTP 的header 裡面設定逾時時間

  • TCP 的keep-alive 包含三個參數，支援在系統核心的net.ipv4 裡面設定：當TCP 連結之後，閒置了tcp_keepalive_time，則會發生偵測包，如果沒有收到對方的ACK，那麼會每隔tcp_keepalive_intvl 再發一次，直到發送了tcp_keepalive_probes，就會丟棄該連結。

  • tcp_keepalive_intvl = 15

tcp_keepalive_probes = 5

tcp_keepalive_time = 1800tcp_keepalive_time = 1800

• #實際上HTTP 沒有長短鏈接，只有TCP 有，TCP 長連接可以複用一個TCP 鏈接來發起多次HTTP 請求，這樣可以減少資源消耗，比如一次請求HTML ，可能還需要請求後續的JS/CSS/圖片等

參考連結

---

##https://blog .csdn.net/weixin_37672169/article/details/80283935

• https://www.jianshu.com/p/3fc3646fad80
##問：Fetch API與傳統Request的差異

fetch 符合關注點分離，使用Promise，API 更加豐富，支援Async/Await語意簡單，更語意化

• 可以使用isomorphic-fetch ，同構方便

---

##參考資源

• https://github.com/camsong/blog/issues/2

（2）問：POST一般可以發送什麼類型的文件，資料處理的問題

---

• #文字、圖片、影片、音訊等都可以

text/image/audio/ 或application/json 等

• #問：TCP 如何保證有效傳輸及擁塞控制原則。

tcp 是面向連線的、可靠的、傳輸層通訊協定

可靠體現在：有狀態、可控制有狀態是指TCP 會確認發送了哪些報文，接收方受到了哪些報文，哪些沒有收到，保證資料包按序到達，不允許有錯誤

可控制的是指，如果出現丟包或網路狀況不佳，則會跳轉自己的行為，減少發送的速度或重發

• 所以上面能保證資料包的有效傳輸。

• 擁塞控制原理

• 原因是有可能整個網路環境特別差，容易丟包，那麼發送端就應該注意了。

主要用三種方法：

慢啟動閾值擁塞避免

快速重傳

• #快速回覆

慢啟動閾值擁塞避免

對於擁塞控制來說，TCP主要維護兩個核心狀態：############擁塞視窗（cwnd）############慢啟動閾值（ssthresh）######### #######在傳送端使用擁塞視窗來控制傳送視窗的大小。 ###

然後採用一種比較保守的慢啟動演算法來慢慢適應這個網絡，在開始傳輸的一段時間，發送端和接收端會首先透過三次握手建立連接，確定各自接收視窗大小，然後初始化雙方的擁塞窗口，接著每經過一輪RTT（收發延遲），擁塞窗口大小會增加一倍，直到達到慢啟動閾值。

然後開始進行擁塞避免，擁塞避免具體的做法就是之前每一輪 RTT，擁塞窗口翻倍，現在每一輪就加一個。

快速重傳

在TCP 傳輸過程中，如果發生了丟包，接收端就會發送之前重複ACK，例如第5 個包丟了，6、7 達到，然後接收端會為5，6，7 都發送第四個包的ACK，這個時候發送端受到了3 個重複的ACK，意識到丟包了，就會馬上進行重傳，而不用等到RTO （超時重傳的時間）

選擇性重傳：報文首部可選性中加入SACK 屬性，透過left edge 和right edge 標誌那些包到了，然後重傳沒到的套件

快速恢復

#如果發送端收到了3 個重複的ACK，發現了丟包，覺得現在的網路狀況已經進入擁塞狀態了，那麼就會進入快速恢復階段：

• 會將擁塞閾值降低為擁塞視窗的一半

• 接著擁塞視窗大小變成壅塞閾值

• 接著擁塞視窗再進行線性增加，以適應網路狀況

##問： OPTION是乾啥的？舉個用到OPTION的例子？

---

旨在發送探測請求，以確定針對某個目標位址的請求必須具有怎麼樣的約束，然後根據約束發送真正的請求。

例如針對跨域資源的預檢，就是採用 HTTP 的 OPTIONS 方法先發送的。用來處理跨域請求

問：http知道嘛？哪一層的協定？ （應用層）

---

• 靈活可擴展，除了規定空格分隔單詞，換行分隔字段以外，其他都沒有限制，不僅可以傳輸文本，還可以傳輸圖片、視訊等任意資源

• 可靠傳輸，基於TCP/IP 所以繼承了這一特性

• 請求-應答，有來有回

• 無狀態，每次HTTP 請求都是獨立的，無關的、預設不需要儲存上下文資訊

##缺點：

明文傳輸不安全
複用一個TCP 鏈接，會發生對頭擁塞

• ##無狀態在長連接場景中，需要保存大量上下文，以避免傳輸大量重複的資訊
#問：OSI七層模型和TCP/IP四層模型

---

OSI七層模型

應用層

• 表示層

• 會話層

• 傳輸層

• #網路層

• 資料鏈結層

• #物理層

TCP/IP 四層概念：

#應用層：應用層、表示層、會話層：HTTP

• #傳輸層：傳輸層：TCP/UDP

• 網路層：網路層：IP

• 資料鏈結層：資料鏈結層、實體層
（3）問：TCP 協定怎麼保證可靠的，UDP 為什麼不可靠？

---

TCP 是連接導向的、可靠的、傳輸層通訊協定

• UDP 是無連線的傳輸層通訊協議，繼承IP 特性,基於資料封包

• 為什麼TCP 可靠？ TCP 的可靠性體現在有狀態和控制

會精確地記錄那些資料發送了，那些資料都被對方接收了，那些沒有被接收，而且保證資料包按序到達，不允許半點差錯，這就是有狀態

• 當意識到丟包了或網路環境不佳，TCP 會根據具體情況調整自己的行為，控制自己的發送速度或重發，這是可控制的

• 反之UDP 就是無狀態的和不可控制的

HTTP 2 改進

改進效能：

---

頭部壓縮

• #多路通道重複使用

---

• 
  

  # Server Push

參考資料

################https://juejin.im/post/5d032b77e51d45777a126183## #############更多程式相關知識，請造訪：###程式設計影片###！ ！ ###