來自公眾號：前端食堂
作者霍語佳

本文已收錄在Github周拐，https://github.com/Geekhyt/front-end-canteen吃嘿，感謝Star塞关。

從淡黃的長裙和蓬松的頭發(fā)我察覺到晕讲，面前坐著的這位女面試官屬實是有點東西贵白。我的自我介紹也變得聲情并茂起來抚芦。Skr~~~ 在此期間倍谜，小姐姐面無改色的看著我的簡歷。不過無所謂叉抡，這些都不重要尔崔。

還是咱們的原定計劃，把面試官引到了咱們最擅長的領(lǐng)域褥民。

你覺得自己最擅長的是什么季春？

HTTP 協(xié)議吧，我還算比較了解消返。

0.那你說一下OSI 網(wǎng)絡(luò)分層模型是怎樣分層的载弄？

應(yīng)用層耘拇、表示層、會話層宇攻、傳輸層惫叛、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層逞刷、物理層

application layer嘉涌、presentation layer、session layer夸浅、transport layer仑最、network layer、data link layer帆喇、physical layer

1.TCP/IP 網(wǎng)絡(luò)分層模型是怎樣分層的词身？

應(yīng)用層、傳輸層番枚、網(wǎng)際層、鏈接層

application layer损敷、transport layer葫笼、internet layer、link layer

2.TCP 和 UDP 區(qū)別拗馒？

TCP 和 UDP 都是傳輸層的協(xié)議路星，但二者有著截然不同的基因。

TCP：

• 面向連接
• 面向字節(jié)流
• 有狀態(tài)
• 保證可靠交付
• 具備擁塞控制
• 點對點傳播
• 有序

UDP：

• 無連接
• 面向數(shù)據(jù)報
• 無狀態(tài)
• 不保證可靠交付
• 不具備擁塞控制
• 廣播诱桂、多播
• 無序

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

三次握手

• 1.客戶端主動發(fā)起 SYN

• 2.服務(wù)端收到并返回 SYN 以及 ACK 客戶端的 SYN

• 3.客戶端收到服務(wù)端的 SYN 和 ACK 后洋丐，發(fā)送 ACK 的 ACK 給服務(wù)端，服務(wù)端收到后連接建立

• Client -> SYN -> Server

• Server -> SYN/ACK -> Client

• Client -> ACK -> Server

四次揮手

• 1.客戶端發(fā)送 FIN 給服務(wù)端

• 2.服務(wù)端收到后發(fā)送 ACK 給客戶端

• 3.服務(wù)端發(fā)送 FIN 給客戶端

• 4.客戶端收到后挥等，發(fā)送 ACK 的 ACK 給服務(wù)端友绝，服務(wù)端關(guān)閉，客戶端等待 2MSL 后關(guān)閉

• Client -> FIN -> Server

• Server -> ACK -> Client

• Server -> FIN -> Client

• Client -> ACK -> Server -> CLOSED

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

4.什么是HTTP協(xié)議肝劲？

(小白回答版)

HTTP 就是超文本傳輸協(xié)議呀迁客，它的英文是 HyperText Transfer Protocol。

敲黑板辞槐！

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

HTTP 是一個在計算機世界里專門在兩點之間傳輸文字掷漱、圖片、音頻榄檬、視頻等超文本數(shù)據(jù)的約定和規(guī)范卜范。

(面試官：理解的不錯)

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

• GET 獲取資源 (冪等)
• POST 新增資源
• HEAD 獲取HEAD元數(shù)據(jù) (冪等)
• PUT 更新資源 (帶條件時冪等)
• DELETE 刪除資源 (冪等)
• CONNECT 建立 Tunnel 隧道
• OPTIONS 獲取服務(wù)器支持訪問資源的方法 (冪等)
• TRACE 回顯服務(wù)器收到的請求鹿榜，可以定位問題海雪。(有安全風(fēng)險)

6.說一下HTTP/0.9锦爵、HTTP/1.0、HTTP/1.1喳魏、HTTP/2棉浸、HTTP/3各版本之間的區(qū)別？

請移步我的另一篇專欄刺彩。

HTTP的世界觀

7.說一下你對HTTPS的了解

HTTPS 就是在 HTTP 和 TCP 協(xié)議中間加入了 SSL/TLS 安全套接層迷郑。

結(jié)合非對稱加密和對稱加密的各自優(yōu)點，配合證書创倔。既保證了安全性嗡害，也保證了傳輸效率。

目前應(yīng)用最廣泛的是TLS1.2畦攘，實現(xiàn)原理如下：

• 1.Client 發(fā)送 random1+對稱加密套件列表+非對稱加密套件列表
• 2.Server 收到信息霸妹， 選擇 對稱加密套件+非對稱加密套件 并和 random2+證書(公鑰在證書中) 一起返回
• 3.Client 驗證證書有效性，并用 random1+random2 生成 pre-master 通過服務(wù)器公鑰加密+瀏覽器確認(rèn) 發(fā)送給 Server
• 4.Server 收到 pre-master知押，根據(jù)約定的加密算法對 random1+random2+pre-master（解密）生成 master-secret叹螟，然后發(fā)送服務(wù)器確認(rèn)
• 5.Client 收到生成同樣的 master-secert，對稱加密秘鑰傳輸完畢

TLS1.3 則簡化了握手過程台盯，完全握手只需要一個消息往返罢绽，提升了性能。不僅如此静盅，還對部分不安全的加密算法進行了刪減良价。

8.你所謂的約定的加密算法應(yīng)該是 ECDHE 橢圓算法吧？HTTP 傳輸消息都是明文的蒿叠，黑客完全可以作為中間人劫持消息明垢，再利用 ECDHE 算法，這樣不就能破解密鑰了嗎市咽？

ECDHE 算法利用了橢圓曲線和離散對數(shù)等思想痊银，按照當(dāng)下的計算機算力，很難在短時間進行破解施绎。且每次握手時生成的都是一對臨時的公鑰和私鑰曼验，這樣就保證每次的密鑰對也不同。

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

當(dāng)然孤紧，TLS 協(xié)議的安全性受限于當(dāng)下最快的計算機運行速度豺裆，理論上絕對安全的是量子通訊傳遞密鑰。

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

(基操，勿6)

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

DNS (Domain Name System)是互聯(lián)網(wǎng)中的重要基礎(chǔ)設(shè)施躺酒，負責(zé)對域名的解析工作，為了保證高可用蔑歌、高并發(fā)和分布式羹应，它設(shè)計成了樹狀的層次結(jié)構(gòu)。

由根DNS服務(wù)器次屠、頂級域 DNS 服務(wù)器和權(quán)威 DNS 服務(wù)器組成园匹。

解析順序是首先從瀏覽器緩存、操作系統(tǒng)緩存以及本地 DNS 緩存 (/etc/hosts) 逐級查找劫灶，然后從本地 DNS 服務(wù)器裸违、根 DNS、頂級 DNS 以及權(quán)威 DNS層層遞歸查詢本昏。

還可以基于域名在內(nèi)網(wǎng)供汛、外網(wǎng)進行負載均衡。

不過傳統(tǒng)的 DNS 有很多問題(解析慢涌穆、更新不及時)怔昨，HTTPDNS 通過客戶端 SDK 和服務(wù)端配合，直接通過 HTTP 調(diào)用解析 DNS 的方式宿稀，可以繞過傳統(tǒng) DNS 這些缺點趁舀，實現(xiàn)智能調(diào)度。

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

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

CDN（Content Delivery Network）就是內(nèi)容分發(fā)網(wǎng)絡(luò)。

為了突破現(xiàn)實生活中的光速巡蘸、傳輸距離等物理限制奋隶，CDN 投入了大量資金，在全球范圍內(nèi)各大樞紐城市建立機房悦荒，部署大量高存儲高帶寬的節(jié)點唯欣，構(gòu)建跨運營商、跨地域的專用高速傳輸網(wǎng)絡(luò)搬味。

其中分為中心節(jié)點境氢、區(qū)域節(jié)點、邊緣節(jié)點等碰纬，在用戶接入網(wǎng)絡(luò)后萍聊，首先通過全局負載均衡 (Global Sever Load Balance)，簡稱 GSLB 算法負責(zé)調(diào)度悦析，找到離用戶最合適的節(jié)點寿桨。然后通過 HTTP 緩存代理技術(shù)進行緩存，緩存命中就返回給用戶强戴，否則就回源站去取亭螟。CDN 擅長緩存靜態(tài)資源(圖片挡鞍、音頻等)，當(dāng)然也支持動態(tài)內(nèi)容的緩存预烙。

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

WebSocket 是一種基于 TCP 的輕量級網(wǎng)絡(luò)通信協(xié)議。和 HTTP/2 一樣扁掸，都是為了解決 HTTP 某些方面的缺陷而誕生的翘县。不過解決方式略有不同，HTTP/2 針對的是“隊頭阻塞 ”也糊，WebSocket 針對的是“請求-應(yīng)答”的通信模式炼蹦。

我們知道“請求-應(yīng)答”是半雙工的通信模式，不具備服務(wù)器推送能力狸剃。這就限制了 HTTP 在實時通信領(lǐng)域的發(fā)展掐隐。雖然可以使用輪詢來不停的向服務(wù)器發(fā)送 HTTP 請求，但是缺點也很大钞馁，反復(fù)的無效請求占用了大量的帶寬和 CPU 資源虑省。所以，WebSocket 應(yīng)運而生僧凰。

WebSocket 是一個全雙工通信協(xié)議探颈，具備服務(wù)端主動推送的能力。本質(zhì)上是對 TCP 做了一層包裝训措，讓它可以運行在瀏覽器環(huán)境里伪节。

看過我這篇專欄「吐血整理」再來一打Webpack面試題 的同學(xué)們一定知道，Webpack 的熱更新中就利用了這種協(xié)議绩鸣。當(dāng)然怀大，在即時通訊、游戲以及可視化大屏展示等領(lǐng)域中也都有著 WebSocket 的身影呀闻。

(關(guān)于 WebSocket 的過多細節(jié)這里不再展開化借，后續(xù)有機會在專欄中詳細介紹，感興趣的同學(xué)們可以先自行學(xué)習(xí)）

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

強緩存

服務(wù)器使用 Cache-Control 來設(shè)置緩存策略蓖康，常用 max-age 來表示資源的有效期。

(這里的 max-age 的時間計算起點是響應(yīng)報文的創(chuàng)建時刻垒手，而不是客戶端收到報文的時刻蒜焊。)

(瀏覽器也可以發(fā)送 Cache-Control 字段，使用 max-age=0 或 no-cache 來刷新數(shù)據(jù))

如果想更精確的控制緩存策略科贬，還可以使用 Cache-Control 的其他屬性：

• no-store：不允許緩存 (用于秒殺頁面等變化頻率非常高的場景)
• no-cache：可以緩存山涡，使用前必須要去服務(wù)端驗證是否過期，是否是最新版本
• must-revalidate：如果緩存不過期就可以繼續(xù)使用，過期了就必須去服務(wù)端驗證

協(xié)商緩存

驗證資源是否失效就需要使用條件請求鸭丛。常用的是 If-Modified-Since 和 If-None-Match竞穷，收到 304 狀態(tài)碼就可以復(fù)用緩存里的資源。

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

驗證資源是否被修改的條件有兩個 Last-modified 和 ETag (ETag 比 Last-modified 的精確度更高)鳞溉，需要預(yù)先在服務(wù)端的響應(yīng)報文里設(shè)置瘾带，配合條件請求使用。

13.HTTP 如何進行內(nèi)容協(xié)商熟菲？

內(nèi)容協(xié)商就是每個 URI 指向的資源可以是任何事物看政，可以有很多不同的表述。對于文檔來說抄罕，可以有不同的語言允蚣、不同的媒體格式，并針對不同的瀏覽器提供不同的壓縮編碼呆贿。

• 主動式內(nèi)容協(xié)商

• 客戶端在請求頭部中提出需要的表述形式嚷兔，服務(wù)器根據(jù)其來進行特定表述

• 響應(yīng)式內(nèi)容協(xié)商

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

協(xié)商要素

• 質(zhì)量因子q：內(nèi)容的質(zhì)量做入、可接受類型的優(yōu)先級
• 媒體資源的 MIME 類型
• 字符編碼 (UTF-8)
• 內(nèi)容編碼 (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 的重定向

重定向是服務(wù)器發(fā)起的跳轉(zhuǎn)冒晰，要求客戶端使用新的 URI 重新發(fā)送請求。在響應(yīng)頭字段 Location 中指示了要跳轉(zhuǎn)的 URI竟块。使用 Refresh 字段壶运，還可以實現(xiàn)延時重定向。

301 / 302 是常用的重定向狀態(tài)碼浪秘。分別代表永久性重定向和臨時性重定向蒋情。

除此之外還有：

• 303：類似于 302，重定向后的請求方法改為 GET 方法
• 307：類似于 302耸携，含義比 302 更明確棵癣，重定向后請求的方法和實體不允許變動
• 308：類似于 301，代表永久重定向违帆，重定向后請求的方法和實體不允許變動
• 300：是一個特殊的重定向狀態(tài)碼浙巫，會返回一個有多個鏈接選項的頁面金蜀，由用戶自行選擇
• 304：是一個特殊的重定向狀態(tài)碼刷后，服務(wù)端驗證過期緩存有效后，要求客戶端使用該緩存

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

(上文中提到過一些尝胆，這里只列舉一些常用的)

(開始報菜名)

通用首部字段

• Cache-Control 控制緩存
• Connection 連接管理
• Transfor-Encoding 報文主體的傳輸編碼格式
• Date 創(chuàng)建報文的時間
• Upgrade 升級為其他協(xié)議

請求首部字段

• Host 請求資源所在的服務(wù)器 (唯一一個HTTP/1.1規(guī)范里要求必須出現(xiàn)的字段)
• Accept 客戶端或者代理能夠處理的媒體類型
• If-Match 比較實體標(biāo)記 (ETag)
• If-None-Match 比較實體標(biāo)記 (ETag)，與 If-Match 相反
• If-Modified-Since 比較資源更新時間 (Last-Modified)
• If-Unmodified-Since 比較資源更新時間 (Last-Modified)护桦， 與 If-Modified-Since 相反
• Range 實體的字節(jié)范圍請求
• User-Agent 客戶端信息

響應(yīng)首部字段

• Accept-Ranges 能接受的字節(jié)范圍
• Location 命令客戶端重定向的 URI
• ETag 能夠表示資源唯一資源的字符串
• Server 服務(wù)器的信息

實體首部字段

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

16.你知道哪些 HTTP 狀態(tài)碼含衔？

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

(開始報菜名)

1xx

• 1xx：請求已經(jīng)接收到，需要進一步處理才能完成贪染，HTTP/1.0 不支持
• 100 Continue：上傳大文件前使用
• 101 Switch Protocols：協(xié)議升級使用
• 102 Processing：服務(wù)器已經(jīng)收到并正在處理請求缓呛，但無響應(yīng)可用

2xx

• 2xx：成功處理請求
• 200 OK：成功返回響應(yīng)
• 201 Created：有新資源在服務(wù)器端被成功創(chuàng)建
• 202 Accepted：服務(wù)器接受并開始處理請求，但請求未處理完成
• 206 Partial Content：使用range協(xié)議時返回部分響應(yīng)內(nèi)容時的響應(yīng)碼

3xx

請查閱上文重定向部分杭隙，這里不再贅述哟绊。

4xx

• 4xx：客戶端出現(xiàn)錯誤
• 400 Bad Request：服務(wù)器認(rèn)為客戶端出現(xiàn)了錯誤，但不明確痰憎，一般是 HTTP 請求格式錯誤
• 401 Unauthorized：用戶認(rèn)證信息確實或者不正確
• 403 Forbidden：服務(wù)器理解請求的含義票髓，但沒有權(quán)限執(zhí)行
• 407 Proxy Authentication Required：對需要經(jīng)由代理的請求，認(rèn)證信息未通過代理服務(wù)器的驗證
• 404 Not Found：服務(wù)器沒有找到對應(yīng)的資源
• 408 Request Timeout：服務(wù)器接收請求超時

5xx

• 5xx：服務(wù)器端出現(xiàn)錯誤
• 500 Internal Server Error：服務(wù)器內(nèi)部錯誤铣耘，且不屬于以下錯誤類型
• 502 Bad Gateway：代理服務(wù)器無法獲取到合法響應(yīng)
• 503 Service Unavailable：服務(wù)器資源尚未準(zhǔn)備好處理當(dāng)前請求
• 505 HTTP Version Not Supported：請求使用的 HTTP 協(xié)議版本不支持

小姐姐拿起桌旁已經(jīng)涼透的芋泥波波奶茶洽沟，喝了一口。

(精神小伙啊)

參考

• 透視 HTTP 協(xié)議 (羅劍鋒)

• 趣談網(wǎng)絡(luò)協(xié)議 (劉超)

• Web 協(xié)議詳解與抓包實戰(zhàn) (陶輝)