青草青青青视频,成人亚洲精品777777大片,国产亚洲精品久久久久久,青青草大香蕉伊人,欧美日韩三级在线,人妻一区二区三区,丁香激情婷婷午夜版,亚洲成人黄色视频

這是前端食堂的第25篇原創(chuàng)?

「觀感度：?????」

「口味：剁椒魚頭」

「烹飪時(shí)間：20min」

本文已收錄在Github，https://github.com/Geekhyt/front-end-canteen，感謝Star。

從淡黃的長(zhǎng)裙和蓬松的頭發(fā)我察覺(jué)到，面前坐著的這位女面試官屬實(shí)是有點(diǎn)東西。我的自我介紹也變得聲情并茂起來(lái)。Skr~~~ 在此期間，小姐姐面無(wú)改色的看著我的簡(jiǎn)歷。不過(guò)無(wú)所謂，這些都不重要。

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

你覺(jué)得自己最擅長(zhǎng)的是什么？

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

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

應(yīng)用層、表示層、會(huì)話層、傳輸層、網(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)
保證可靠交付
具備擁塞控制
點(diǎn)對(duì)點(diǎn)傳播
有序

UDP：

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

3.TCP 的三次握手和四次揮手簡(jiǎn)單說(shuō)一下

三次握手

1.客戶端主動(dòng)發(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 的時(shí)間 -> CLOSED

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

(小白回答版)

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

敲黑板！

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

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

(面試官：理解的不錯(cuò))

5.你知道哪些 HTTP 的請(qǐng)求方法？

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

6.說(shuō)一下HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3各版本之間的區(qū)別？

請(qǐng)移步我的另一篇專欄。

HTTP的世界觀

7.說(shuō)一下你對(duì)HTTPS的了解

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

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

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

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

TLS1.3 則簡(jiǎn)化了握手過(guò)程，完全握手只需要一個(gè)消息往返，提升了性能。不僅如此，還對(duì)部分不安全的加密算法進(jìn)行了刪減。

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

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

即使大費(fèi)力氣破解了一次的密鑰，之前的歷史消息也不會(huì)受到影響，保證了前向安全。

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

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

(基操，勿6)

9.說(shuō)一說(shuō)你對(duì)DNS的理解？

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

由根DNS服務(wù)器、頂級(jí)域 DNS 服務(wù)器和權(quán)威 DNS 服務(wù)器組成。

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

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

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

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

10.說(shuō)一說(shuō)你對(duì) CDN 的理解？

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

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

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

11.說(shuō)一說(shuō)你對(duì) WebSocket 的理解？

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

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

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

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

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

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

強(qiáng)緩存

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

(這里的 max-age 的時(shí)間計(jì)算起點(diǎn)是響應(yīng)報(bào)文的創(chuàng)建時(shí)刻，而不是客戶端收到報(bào)文的時(shí)刻。)

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

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

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

協(xié)商緩存

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

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

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

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

內(nèi)容協(xié)商就是每個(gè) URI 指向的資源可以是任何事物，可以有很多不同的表述。對(duì)于文檔來(lái)說(shuō)，可以有不同的語(yǔ)言、不同的媒體格式，并針對(duì)不同的瀏覽器提供不同的壓縮編碼。

主動(dòng)式內(nèi)容協(xié)商

客戶端在請(qǐng)求頭部中提出需要的表述形式，服務(wù)器根據(jù)其來(lái)進(jìn)行特定表述

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

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

協(xié)商要素

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

14.說(shuō)一說(shuō) HTTP 的重定向

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

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

除此之外還有：

303：類似于 302，重定向后的請(qǐng)求方法改為 GET 方法
307：類似于 302，含義比 302 更明確，重定向后請(qǐng)求的方法和實(shí)體不允許變動(dòng)
308：類似于 301，代表永久重定向，重定向后請(qǐng)求的方法和實(shí)體不允許變動(dòng)
300：是一個(gè)特殊的重定向狀態(tài)碼，會(huì)返回一個(gè)有多個(gè)鏈接選項(xiàng)的頁(yè)面，由用戶自行選擇
304：是一個(gè)特殊的重定向狀態(tài)碼，服務(wù)端驗(yàn)證過(guò)期緩存有效后，要求客戶端使用該緩存

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

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

(開(kāi)始報(bào)菜名)

通用首部字段

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

請(qǐng)求首部字段

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

響應(yīng)首部字段

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

實(shí)體首部字段

Allow 資源可支持 HTTP 請(qǐng)求方法
Last-Modified 資源最后修改時(shí)間
Expires 實(shí)體主體過(guò)期時(shí)間
Content-Language 實(shí)體資源語(yǔ)言
Content-Encoding 實(shí)體編碼格式
Content-Length 實(shí)體大小
Content-Type 實(shí)體媒體類型

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