「面試題」那些年與面試官交手過的HTTP問題

「觀感度：🌟🌟🌟🌟🌟」

「口味：剁椒魚頭」

「烹飪時間：20min」

本文已收錄在Github github.com/Geekhyt，感謝Star。

從淡黃的長裙和蓬鬆的頭髮我察覺到，面前坐着的這位女面試官屬實是有點東西。個人自我介紹也變得聲情並茂起來。Skr~~~ 在此期間，小姐姐面無改色的看着個人簡歷。不過無所謂，這些都不重要。

仍是我們的原定計劃，把面試官引到了我們最擅長的領域。

你以爲本身最擅長的是什麼？

HTTP 協議吧，我還算比較瞭解。

0.那你說一下OSI 網絡分層模型是怎樣分層的？

應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層、物理層

application layer、presentation layer、session layer、transport layer、network layer、data link layer、physical layer

1.TCP/IP 網絡分層模型是怎樣分層的？

應用層、傳輸層、網際層、連接層

application layer、transport layer、internet layer、link layer

2.TCP 和 UDP 區別？

TCP 和 UDP 都是傳輸層的協議，但兩者有着大相徑庭的基因。

TCP：

• 面向鏈接
• 面向字節流
• 有狀態
• 保證可靠交付
• 具有擁塞控制
• 點對點傳播
• 有序

UDP：

• 無鏈接
• 面向數據報
• 無狀態
• 不保證可靠交付
• 不具有擁塞控制
• 廣播、多播
• 無序

3.TCP 的三次握手和四次揮手簡單說一下

三次握手

• 1.客戶端主動發起 SYN

• 2.服務端收到並返回 SYN 以及 ACK 客戶端的 SYN

• 3.客戶端收到服務端的 SYN 和 ACK 後，發送 ACK 的 ACK 給服務端，服務端收到後鏈接創建

• Client -> SYN -> Server

• Server -> SYN/ACK -> Client

• Client -> ACK -> Server

四次揮手

• 1.客戶端發送 FIN 給服務端

• 2.服務端收到後發送 ACK 給客戶端

• 3.服務端發送 FIN 給客戶端

• 4.客戶端收到後，發送 ACK 的 ACK 給服務端，服務端關閉，客戶端等待 2MSL 後關閉

• Client -> FIN -> Server

• Server -> ACK -> Client

• Server -> FIN -> Client

• Client -> ACK -> Server -> CLOSED

• Client -> 2MSL 的時間 -> CLOSED

4.什麼是HTTP協議？

(小白回答版)

HTTP 就是超文本傳輸協議呀，它的英文是 HyperText Transfer Protocol。

敲黑板！

(羅劍鋒老師的完美回答版)

HTTP 是一個在計算機世界裏專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規範。

(面試官：理解的不錯)

5.你知道哪些 HTTP 的請求方法？

• GET 獲取資源 (冪等)
• POST 新增資源
• HEAD 獲取HEAD元數據 (冪等)
• PUT 更新資源 (帶條件時冪等)
• DELETE 刪除資源 (冪等)
• CONNECT 創建 Tunnel 隧道
• OPTIONS 獲取服務器支持訪問資源的方法 (冪等)
• TRACE 回顯服務器收到的請求，能夠定位問題。 (有安全風險)

6.說一下HTTP/0.九、HTTP/1.0、HTTP/1.一、HTTP/二、HTTP/3各版本之間的區別？

請移步個人另外一篇專欄

7.說一下你對HTTPS的瞭解

HTTPS 就是在 HTTP 和 TCP 協議中間加入了 SSL/TLS 安全套接層。

結合非對稱加密和對稱加密的各自優勢，配合證書。既保證了安全性，也保證了傳輸效率。

目前應用最普遍的是TLS1.2，實現原理以下：

• 1.Client 發送 random1+對稱加密套件列表+非對稱加密套件列表
• 2.Server 收到信息， 選擇 對稱加密套件+非對稱加密套件 並和 random2+證書(公鑰在證書中) 一塊兒返回
• 3.Client 驗證證書有效性，並用 random1+random2 生成 pre-master 經過服務器公鑰加密+瀏覽器確認 發送給 Server
• 4.Server 收到 pre-master，根據約定的加密算法對 random1+random2+pre-master（解密）生成 master-secret，而後發送服務器確認
• 5.Client 收到生成一樣的 master-secert，對稱加密祕鑰傳輸完畢

TLS1.3 則簡化了握手過程，徹底握手只須要一個消息往返，提高了性能。不只如此，還對部分不安全的加密算法進行了刪減。

8.你所謂的約定的加密算法應該是 ECDHE 橢圓算法吧？HTTP 傳輸消息都是明文的，黑客徹底能夠做爲中間人劫持消息，再利用 ECDHE 算法，這樣不就能破解密鑰了嗎？

ECDHE 算法利用了橢圓曲線和離散對數等思想，按照當下的計算機算力，很難在短期進行破解。且每次握手時生成的都是一對臨時的公鑰和私鑰，這樣就保證每次的密鑰對也不一樣。

即便大費力氣破解了一次的密鑰，以前的歷史消息也不會受到影響，保證了前向安全。

固然，TLS 協議的安全性受限於當下最快的計算機運行速度，理論上絕對安全的是量子通信傳遞密鑰。

(面試官：小夥子有點東西)

(基操，勿6)

9.說一說你對DNS的理解？

DNS (Domain Name System)是互聯網中的重要基礎設施，負責對域名的解析工做，爲了保證高可用、高併發和分佈式，它設計成了樹狀的層次結構。

由根DNS服務器、頂級域 DNS 服務器和權威 DNS 服務器組成。

解析順序是首先從瀏覽器緩存、操做系統緩存以及本地 DNS 緩存 (/etc/hosts) 逐級查找，而後從本地 DNS 服務器、根 DNS、頂級 DNS 以及權威 DNS層層遞歸查詢。

還能夠基於域名在內網、外網進行負載均衡。

不過傳統的 DNS 有不少問題(解析慢、更新不及時)，HTTPDNS 經過客戶端 SDK 和服務端配合，直接經過 HTTP 調用解析 DNS 的方式，能夠繞過傳統 DNS 這些缺點，實現智能調度。

(面試官：小夥子理解的挺細啊)

10.說一說你對 CDN 的理解？

CDN（Content Delivery Network）就是內容分發網絡。

爲了突破現實生活中的光速、傳輸距離等物理限制，CDN 投入了大量資金，在全球範圍內各大樞紐城市創建機房，部署大量高存儲高帶寬的節點，構建跨運營商、跨地域的專用高速傳輸網絡。

其中分爲中心節點、區域節點、邊緣節點等，在用戶接入網絡後，首先經過全局負載均衡 (Global Sever Load Balance)，簡稱 GSLB 算法負責調度，找到離用戶最合適的節點。而後經過 HTTP 緩存代理技術進行緩存，緩存命中就返回給用戶，不然就回源站去取。CDN 擅長緩存靜態資源(圖片、音頻等)，固然也支持動態內容的緩存。

11.說一說你對 WebSocket 的理解？

WebSocket 是一種基於 TCP 的輕量級網絡通訊協議。和 HTTP/2 同樣，都是爲了解決 HTTP 某些方面的缺陷而誕生的。不過解決方式略有不一樣，HTTP/2 針對的是「隊頭阻塞 」，WebSocket 針對的是「請求-應答」的通訊模式。

咱們知道「請求-應答」是半雙工的通訊模式，不具有服務器推送能力。這就限制了 HTTP 在實時通訊領域的發展。雖然可使用輪詢來不停的向服務器發送 HTTP 請求，可是缺點也很大，反覆的無效請求佔用了大量的帶寬和 CPU 資源。因此，WebSocket 應運而生。

WebSocket 是一個全雙工通訊協議，具有服務端主動推送的能力。本質上是對 TCP 作了一層包裝，讓它能夠運行在瀏覽器環境裏。

看過我這篇專欄的同窗們必定知道，Webpack 的熱更新中就利用了這種協議。固然，在即時通信、遊戲以及可視化大屏展現等領域中也都有着 WebSocket 的身影。

(關於 WebSocket 的過多細節這裏再也不展開，後續有機會在專欄中詳細介紹，感興趣的同窗們能夠先自行學習）

12.HTTP 的緩存策略知道嗎？

強緩存

服務器使用 Cache-Control 來設置緩存策略，經常使用 max-age 來表示資源的有效期。

(這裏的 max-age 的時間計算起點是響應報文的建立時刻，而不是客戶端收到報文的時刻。)

(瀏覽器也能夠發送 Cache-Control 字段，使用 max-age=0 或 no-cache 來刷新數據)

若是想更精確的控制緩存策略，還可使用 Cache-Control 的其餘屬性：

• no-store：不容許緩存 (用於秒殺頁面等變化頻率很是高的場景)
• no-cache：能夠緩存，使用前必需要去服務端驗證是否過時，是不是最新版本
• must-revalidate：若是緩存不過時就能夠繼續使用，過時了就必須去服務端驗證

協商緩存

驗證資源是否失效就須要使用條件請求。經常使用的是 If-Modified-Since 和 If-None-Match，收到 304 狀態碼就能夠複用緩存裏的資源。

(If-None-Match 比 If-Modified-Since 優先級更高)

驗證資源是否被修改的條件有兩個 Last-modified 和 ETag (ETag 比 Last-modified 的精確度更高)，須要預先在服務端的響應報文裏設置，配合條件請求使用。

13.HTTP 如何進行內容協商？

內容協商就是每一個 URI 指向的資源能夠是任何事物，能夠有不少不一樣的表述。對於文檔來講，能夠有不一樣的語言、不一樣的媒體格式，並針對不一樣的瀏覽器提供不一樣的壓縮編碼。

• 主動式內容協商

  • 客戶端在請求頭部中提出須要的表述形式，服務器根據其來進行特定表述
• 響應式內容協商

  • 服務端返回 300 或者 406，由客戶端選擇一種表述

協商要素

• 質量因子q：內容的質量、可接受類型的優先級
• 媒體資源的 MIME 類型
• 字符編碼 (UTF-8)
• 內容編碼 (Accept-Encoding:gzip,deflate,br)
• 表述語言 (Accept-Language:zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7)
• 國際化與本地化 (i18n,l10n)

14.說一說 HTTP 的重定向

重定向是服務器發起的跳轉，要求客戶端使用新的 URI 從新發送請求。在響應頭字段 Location 中指示了要跳轉的 URI。使用 Refresh 字段，還能夠實現延時重定向。

301 / 302 是經常使用的重定向狀態碼。分別表明永久性重定向和臨時性重定向。

除此以外還有：

• 303：相似於 302，重定向後的請求方法改成 GET 方法
• 307：相似於 302，含義比 302 更明確，重定向後請求的方法和實體不容許變更
• 308：相似於 301，表明永久重定向，重定向後請求的方法和實體不容許變更
• 300：是一個特殊的重定向狀態碼，會返回一個有多個連接選項的頁面，由用戶自行選擇
• 304：是一個特殊的重定向狀態碼，服務端驗證過時緩存有效後，要求客戶端使用該緩存

15.你知道哪些 HTTP 的經常使用的首部字段？

(上文中提到過一些，這裏只列舉一些經常使用的)

(開始報菜名)

通用首部字段

• Cache-Control 控制緩存
• Connection 鏈接管理
• Transfor-Encoding 報文主體的傳輸編碼格式
• Date 建立報文的時間
• Upgrade 升級爲其餘協議

請求首部字段

• Host 請求資源所在的服務器 (惟一一個HTTP/1.1規範裏要求必須出現的字段)
• Accept 客戶端或者代理可以處理的媒體類型
• If-Match 比較實體標記 (ETag)
• If-None-Match 比較實體標記 (ETag)，與 If-Match 相反
• If-Modified-Since 比較資源更新時間 (Last-Modified)
• If-Unmodified-Since 比較資源更新時間 (Last-Modified)， 與 If-Modified-Since 相反
• Range 實體的字節範圍請求
• User-Agent 客戶端信息

響應首部字段

• Accept-Ranges 能接受的字節範圍
• Location 命令客戶端重定向的 URI
• ETag 可以表示資源惟一資源的字符串
• Server 服務器的信息

實體首部字段

• Allow 資源可支持 HTTP 請求方法
• Last-Modified 資源最後修改時間
• Expires 實體主體過時時間
• Content-Language 實體資源語言
• Content-Encoding 實體編碼格式
• Content-Length 實體大小
• Content-Type 實體媒體類型

16.你知道哪些 HTTP 狀態碼？

(上文中提到過一些，這裏只列舉一些經常使用的)

(開始報菜名)

1xx

• 1xx：請求已經接收到，須要進一步處理才能完成，HTTP/1.0 不支持
• 100 Continue：上傳大文件前使用
• 101 Switch Protocols：協議升級使用
• 102 Processing：服務器已經收到並正在處理請求，但無響應可用

2xx

• 2xx：成功處理請求
• 200 OK：成功返回響應
• 201 Created：有新資源在服務器端被成功建立
• 202 Accepted：服務器接受並開始處理請求，但請求未處理完成
• 206 Partial Content：使用range協議時返回部分響應內容時的響應碼

3xx

請查閱上文重定向部分，這裏再也不贅述。

4xx

• 4xx：客戶端出現錯誤
• 400 Bad Request：服務器認爲客戶端出現了錯誤，但不明確，通常是 HTTP 請求格式錯誤
• 401 Unauthorized：用戶認證信息確實或者不正確
• 403 Forbidden：服務器理解請求的含義，但沒有權限執行
• 407 Proxy Authentication Required：對須要經由代理的請求，認證信息未經過代理服務器的驗證
• 404 Not Found：服務器沒有找到對應的資源
• 408 Request Timeout：服務器接收請求超時

5xx

• 5xx：服務器端出現錯誤
• 500 Internal Server Error：服務器內部錯誤，且不屬於如下錯誤類型
• 502 Bad Gateway：代理服務器沒法獲取到合法響應
• 503 Service Unavailable：服務器資源還沒有準備好處理當前請求
• 505 HTTP Version Not Supported：請求使用的 HTTP 協議版本不支持

小姐姐拿起桌旁已經涼透的芋泥波波奶茶，喝了一口。

(精神小夥啊)

參考

• 透視 HTTP 協議 (羅劍鋒)
• 趣談網絡協議 (劉超)
• Web 協議詳解與抓包實戰 (陶輝)

❤️愛心三連擊

1.看到這裏了就點個贊支持下吧，你的「贊」是我創做的動力。

2.關注公衆號前端食堂，「你的前端食堂，記得按時吃飯」!

3.本文已收錄在前端食堂Github github.com/Geekhyt，求個小星星，感謝Star。