日韩偷拍网,亚洲午夜无码久久,国产综合在线观看视频国产,色秘乱码一区二区三区色欲,亚洲第一色五月,含羞草一区二区三区无码观看,韩国啪啪免费视频,日韩天天干

1 HTTP

HTTP 協(xié)議是個(gè)無(wú)狀態(tài)協(xié)議，不會(huì)保存狀態(tài)。

2 Post 和 Get 的區(qū)別

先引入副作用和冪等的概念。

副作用指對(duì)服務(wù)器上的資源做改變，搜索是無(wú)副作用的，注冊(cè)是副作用的。

冪等指發(fā)送 M 和 N 次請(qǐng)求（兩者不相同且都大于 1），服務(wù)器上資源的狀態(tài)一致，比如注冊(cè) 10 個(gè)和 11 個(gè)帳號(hào)是不冪等的，對(duì)文章進(jìn)行更改 10 次和 11 次是冪等的。

在規(guī)范的應(yīng)用場(chǎng)景上說(shuō)，Get 多用于無(wú)副作用，冪等的場(chǎng)景，例如搜索關(guān)鍵字。Post 多用于副作用，不冪等的場(chǎng)景，例如注冊(cè)。

在技術(shù)上說(shuō)：

Get 請(qǐng)求能緩存，Post 不能
Post 相對(duì) Get 安全一點(diǎn)點(diǎn)，因?yàn)镚et 請(qǐng)求都包含在 URL 里，且會(huì)被瀏覽器保存歷史紀(jì)錄，Post 不會(huì)，但是在抓包的情況下都是一樣的。
Post 可以通過(guò) request body來(lái)傳輸比 Get 更多的數(shù)據(jù)，Get 沒(méi)有這個(gè)技術(shù)
URL有長(zhǎng)度限制，會(huì)影響 Get 請(qǐng)求，但是這個(gè)長(zhǎng)度限制是瀏覽器規(guī)定的，不是 RFC 規(guī)定的
Post 支持更多的編碼類(lèi)型且不對(duì)數(shù)據(jù)類(lèi)型限制

3 常見(jiàn)狀態(tài)碼

2XX 成功

200 OK，表示從客戶(hù)端發(fā)來(lái)的請(qǐng)求在服務(wù)器端被正確處理
204 No content，表示請(qǐng)求成功，但響應(yīng)報(bào)文不含實(shí)體的主體部分
205 Reset Content，表示請(qǐng)求成功，但響應(yīng)報(bào)文不含實(shí)體的主體部分，但是與 204 響應(yīng)不同在于要求請(qǐng)求方重置內(nèi)容
206 Partial Content，進(jìn)行范圍請(qǐng)求

3XX 重定向

301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
302 found，臨時(shí)性重定向，表示資源臨時(shí)被分配了新的 URL
303 see other，表示資源存在著另一個(gè) URL，應(yīng)使用 GET 方法獲取資源
304 not modified，表示服務(wù)器允許訪問(wèn)資源，但因發(fā)生請(qǐng)求未滿(mǎn)足條件的情況
307 temporary redirect，臨時(shí)重定向，和302含義類(lèi)似，但是期望客戶(hù)端保持請(qǐng)求方法不變向新的地址發(fā)出請(qǐng)求

4XX 客戶(hù)端錯(cuò)誤

400 bad request，請(qǐng)求報(bào)文存在語(yǔ)法錯(cuò)誤
401 unauthorized，表示發(fā)送的請(qǐng)求需要有通過(guò) HTTP 認(rèn)證的認(rèn)證信息
403 forbidden，表示對(duì)請(qǐng)求資源的訪問(wèn)被服務(wù)器拒絕
404 not found，表示在服務(wù)器上沒(méi)有找到請(qǐng)求的資源

5XX 服務(wù)器錯(cuò)誤

500 internal sever error，表示服務(wù)器端在執(zhí)行請(qǐng)求時(shí)發(fā)生了錯(cuò)誤
501 Not Implemented，表示服務(wù)器不支持當(dāng)前請(qǐng)求所需要的某個(gè)功能
503 service unavailable，表明服務(wù)器暫時(shí)處于超負(fù)載或正在停機(jī)維護(hù)，無(wú)法處理請(qǐng)求

4 HTTP 首部

5 HTTPS

HTTPS 還是通過(guò)了 HTTP 來(lái)傳輸信息，但是信息通過(guò) TLS 協(xié)議進(jìn)行了加密。

6 TLS

TLS 協(xié)議位于傳輸層之上，應(yīng)用層之下。首次進(jìn)行 TLS 協(xié)議傳輸需要兩個(gè) RTT ，接下來(lái)可以通過(guò) Session Resumption 減少到一個(gè) RTT。

在公眾號(hào)程序員小樂(lè)回復(fù)“Java”，獲取Java面試題和答案驚喜禮包。

在 TLS 中使用了兩種加密技術(shù)，分別為：對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密。

對(duì)稱(chēng)加密：

對(duì)稱(chēng)加密就是兩邊擁有相同的秘鑰，兩邊都知道如何將密文加密解密。

非對(duì)稱(chēng)加密：

有公鑰私鑰之分，公鑰所有人都可以知道，可以將數(shù)據(jù)用公鑰加密，但是將數(shù)據(jù)解密必須使用私鑰解密，私鑰只有分發(fā)公鑰的一方才知道。

TLS 握手過(guò)程如下圖：

客戶(hù)端發(fā)送一個(gè)隨機(jī)值，需要的協(xié)議和加密方式
服務(wù)端收到客戶(hù)端的隨機(jī)值，自己也產(chǎn)生一個(gè)隨機(jī)值，并根據(jù)客戶(hù)端需求的協(xié)議和加密方式來(lái)使用對(duì)應(yīng)的方式，發(fā)送自己的證書(shū)（如果需要驗(yàn)證客戶(hù)端證書(shū)需要說(shuō)明）
客戶(hù)端收到服務(wù)端的證書(shū)并驗(yàn)證是否有效，驗(yàn)證通過(guò)會(huì)再生成一個(gè)隨機(jī)值，通過(guò)服務(wù)端證書(shū)的公鑰去加密這個(gè)隨機(jī)值并發(fā)送給服務(wù)端，如果服務(wù)端需要驗(yàn)證客戶(hù)端證書(shū)的話會(huì)附帶證書(shū)
服務(wù)端收到加密過(guò)的隨機(jī)值并使用私鑰解密獲得第三個(gè)隨機(jī)值，這時(shí)候兩端都擁有了三個(gè)隨機(jī)值，可以通過(guò)這三個(gè)隨機(jī)值按照之前約定的加密方式生成密鑰，接下來(lái)的通信就可以通過(guò)該密鑰來(lái)加密解密

通過(guò)以上步驟可知，在 TLS 握手階段，兩端使用非對(duì)稱(chēng)加密的方式來(lái)通 ? ? ?信，但是因?yàn)榉菍?duì)稱(chēng)加密損耗的性能比對(duì)稱(chēng)加密大，所以在正式傳輸數(shù)據(jù)時(shí)，兩端使用對(duì)稱(chēng)加密的方式通信。

PS：以上說(shuō)明的都是 TLS 1.2 協(xié)議的握手情況，在 1.3 協(xié)議中，首次建立連接只需要一個(gè) RTT，后面恢復(fù)連接不需要 RTT 了。

7 HTTP 2.0

HTTP 2.0 相比于 HTTP 1.X，可以說(shuō)是大幅度提高了 web 的性能。

在 HTTP 1.X 中，為了性能考慮，我們會(huì)引入雪碧圖、將小圖內(nèi)聯(lián)、使用多個(gè)域名等等的方式。這一切都是因?yàn)闉g覽器限制了同一個(gè)域名下的請(qǐng)求數(shù)量，當(dāng)頁(yè)面中需要請(qǐng)求很多資源的時(shí)候，隊(duì)頭阻塞（Head of line blocking）會(huì)導(dǎo)致在達(dá)到最大請(qǐng)求數(shù)量時(shí)，剩余的資源需要等待其他資源請(qǐng)求完成后才能發(fā)起請(qǐng)求。

在 HTTP 1.X 中，因?yàn)殛?duì)頭阻塞的原因，你會(huì)發(fā)現(xiàn)請(qǐng)求是這樣的

在 HTTP 2.0 中，因?yàn)橐肓硕嗦窂?fù)用，你會(huì)發(fā)現(xiàn)請(qǐng)求是這樣的

8 二進(jìn)制傳輸

HTTP 2.0 中所有加強(qiáng)性能的核心點(diǎn)在于此。在之前的 HTTP 版本中，我們是通過(guò)文本的方式傳輸數(shù)據(jù)。在 HTTP 2.0 中引入了新的編碼機(jī)制，所有傳輸?shù)臄?shù)據(jù)都會(huì)被分割，并采用二進(jìn)制格式編碼。

9 多路復(fù)用

在 HTTP 2.0 中，有兩個(gè)非常重要的概念，分別是幀（frame）和流（stream）。

在公眾號(hào)程序員小樂(lè)回復(fù)“offer”，獲取算法面試題和答案驚喜禮包。

幀代表著最小的數(shù)據(jù)單位，每個(gè)幀會(huì)標(biāo)識(shí)出該幀屬于哪個(gè)流，流也就是多個(gè)幀組成的數(shù)據(jù)流。

多路復(fù)用，就是在一個(gè) TCP 連接中可以存在多條流。換句話說(shuō)，也就是可以發(fā)送多個(gè)請(qǐng)求，對(duì)端可以通過(guò)幀中的標(biāo)識(shí)知道屬于哪個(gè)請(qǐng)求。通過(guò)這個(gè)技術(shù)，可以避免 HTTP 舊版本中的隊(duì)頭阻塞問(wèn)題，極大的提高傳輸性能。

10 Header 壓縮

在 HTTP 1.X 中，我們使用文本的形式傳輸 header，在 header 攜帶 cookie 的情況下，可能每次都需要重復(fù)傳輸幾百到幾千的字節(jié)。

在 HTTP 2.0 中，使用了 HPACK 壓縮格式對(duì)傳輸?shù)?header 進(jìn)行編碼，減少了 header 的大小。并在兩端維護(hù)了索引表，用于記錄出現(xiàn)過(guò)的 header ，后面在傳輸過(guò)程中就可以傳輸已經(jīng)記錄過(guò)的 header 的鍵名，對(duì)端收到數(shù)據(jù)后就可以通過(guò)鍵名找到對(duì)應(yīng)的值。

11 服務(wù)端 Push

在 HTTP 2.0 中，服務(wù)端可以在客戶(hù)端某個(gè)請(qǐng)求后，主動(dòng)推送其他資源。

可以想象以下情況，某些資源客戶(hù)端是一定會(huì)請(qǐng)求的，這時(shí)就可以采取服務(wù)端 push 的技術(shù)，提前給客戶(hù)端推送必要的資源，這樣就可以相對(duì)減少一點(diǎn)延遲時(shí)間。當(dāng)然在瀏覽器兼容的情況下你也可以使用 prefetch 。

12 QUIC

這是一個(gè)谷歌出品的基于 UDP 實(shí)現(xiàn)的同為傳輸層的協(xié)議，目標(biāo)很遠(yuǎn)大，希望替代 TCP 協(xié)議。

該協(xié)議支持多路復(fù)用，雖然 HTTP 2.0 也支持多路復(fù)用，但是下層仍是 TCP，因?yàn)?TCP 的重傳機(jī)制，只要一個(gè)包丟失就得判斷丟失包并且重傳，導(dǎo)致發(fā)生隊(duì)頭阻塞的問(wèn)題，但是 UDP 沒(méi)有這個(gè)機(jī)制
實(shí)現(xiàn)了自己的加密協(xié)議，通過(guò)類(lèi)似 TCP 的 TFO 機(jī)制可以實(shí)現(xiàn) 0-RTT，當(dāng)然 TLS 1.3 已經(jīng)實(shí)現(xiàn)了 0-RTT 了
支持重傳和糾錯(cuò)機(jī)制（向前恢復(fù)），在只丟失一個(gè)包的情況下不需要重傳，使用糾錯(cuò)機(jī)制恢復(fù)丟失的包

糾錯(cuò)機(jī)制：通過(guò)異或的方式，算出發(fā)出去的數(shù)據(jù)的異或值并單獨(dú)發(fā)出一個(gè)包，服務(wù)端在發(fā)現(xiàn)有一個(gè)包丟失的情況下，通過(guò)其他數(shù)據(jù)包和異或值包算出丟失包
在丟失兩個(gè)包或以上的情況就使用重傳機(jī)制，因?yàn)樗悴怀鰜?lái)了

13 DNS

DNS 的作用就是通過(guò)域名查詢(xún)到具體的 IP。

因?yàn)?IP 存在數(shù)字和英文的組合（IPv6），很不利于人類(lèi)記憶，所以就出現(xiàn)了域名。你可以把域名看成是某個(gè) IP 的別名，DNS 就是去查詢(xún)這個(gè)別名的真正名稱(chēng)是什么。

在 TCP 握手之前就已經(jīng)進(jìn)行了 DNS 查詢(xún)，這個(gè)查詢(xún)是操作系統(tǒng)自己做的。當(dāng)你在瀏覽器中想訪問(wèn) www.google.com 時(shí)，會(huì)進(jìn)行一下操作：

操作系統(tǒng)會(huì)首先在本地緩存中查詢(xún)
沒(méi)有的話會(huì)去系統(tǒng)配置的 DNS 服務(wù)器中查詢(xún)
如果這時(shí)候還沒(méi)得話，會(huì)直接去 DNS 根服務(wù)器查詢(xún)，這一步查詢(xún)會(huì)找出負(fù)責(zé) com 這個(gè)一級(jí)域名的服務(wù)器
然后去該服務(wù)器查詢(xún) google 這個(gè)二級(jí)域名
接下來(lái)三級(jí)域名的查詢(xún)其實(shí)是我們配置的，你可以給 www 這個(gè)域名配置一個(gè) IP，然后還可以給別的三級(jí)域名配置一個(gè) IP

以上介紹的是 DNS 迭代查詢(xún)，還有種是遞歸查詢(xún)，區(qū)別就是前者是由客戶(hù)端去做請(qǐng)求，后者是由系統(tǒng)配置的 DNS 服務(wù)器做請(qǐng)求，得到結(jié)果后將數(shù)據(jù)返回給客戶(hù)端。

PS：DNS 是基于 UDP 做的查詢(xún)。

14 從輸入 URL 到頁(yè)面加載完成的過(guò)程

這是一個(gè)很經(jīng)典的面試題，在這題中可以將本文講得內(nèi)容都串聯(lián)起來(lái)。

首先做 DNS 查詢(xún)，如果這一步做了智能 DNS 解析的話，會(huì)提供訪問(wèn)速度最快的 IP 地址回來(lái)
接下來(lái)是 TCP 握手，應(yīng)用層會(huì)下發(fā)數(shù)據(jù)給傳輸層，這里 TCP 協(xié)議會(huì)指明兩端的端口號(hào)，然后下發(fā)給網(wǎng)絡(luò)層。網(wǎng)絡(luò)層中的 IP 協(xié)議會(huì)確定 IP 地址，并且指示了數(shù)據(jù)傳輸中如何跳轉(zhuǎn)路由器。然后包會(huì)再被封裝到數(shù)據(jù)鏈路層的數(shù)據(jù)幀結(jié)構(gòu)中，最后就是物理層面的傳輸了
TCP 握手結(jié)束后會(huì)進(jìn)行 TLS 握手，然后就開(kāi)始正式的傳輸數(shù)據(jù)
數(shù)據(jù)在進(jìn)入服務(wù)端之前，可能還會(huì)先經(jīng)過(guò)負(fù)責(zé)負(fù)載均衡的服務(wù)器，它的作用就是將請(qǐng)求合理的分發(fā)到多臺(tái)服務(wù)器上，這時(shí)假設(shè)服務(wù)端會(huì)響應(yīng)一個(gè) HTML 文件
首先瀏覽器會(huì)判斷狀態(tài)碼是什么，如果是 200 那就繼續(xù)解析，如果 400 或 500 的話就會(huì)報(bào)錯(cuò)，如果 300 的話會(huì)進(jìn)行重定向，這里會(huì)有個(gè)重定向計(jì)數(shù)器，避免過(guò)多次的重定向，超過(guò)次數(shù)也會(huì)報(bào)錯(cuò)
瀏覽器開(kāi)始解析文件，如果是 gzip 格式的話會(huì)先解壓一下，然后通過(guò)文件的編碼格式知道該如何去解碼文件
文件解碼成功后會(huì)正式開(kāi)始渲染流程，先會(huì)根據(jù) HTML 構(gòu)建 DOM 樹(shù)，有 CSS 的話會(huì)去構(gòu)建 CSSOM 樹(shù)。如果遇到 script 標(biāo)簽的話，會(huì)判斷是否存在?async?或者?defer?，前者會(huì)并行進(jìn)行下載并執(zhí)行 JS，后者會(huì)先下載文件，然后等待 HTML 解析完成后順序執(zhí)行，如果以上都沒(méi)有，就會(huì)阻塞住渲染流程直到 JS 執(zhí)行完畢。遇到文件下載的會(huì)去下載文件，這里如果使用 HTTP 2.0 協(xié)議的話會(huì)極大的提高多圖的下載效率。
初始的 HTML 被完全加載和解析后會(huì)觸發(fā) DOMContentLoaded 事件
CSSOM 樹(shù)和 DOM 樹(shù)構(gòu)建完成后會(huì)開(kāi)始生成 Render 樹(shù)，這一步就是確定頁(yè)面元素的布局、樣式等等諸多方面的東西
在生成 Render 樹(shù)的過(guò)程中，瀏覽器就開(kāi)始調(diào)用 GPU 繪制，合成圖層，將內(nèi)容顯示在屏幕上了

來(lái)源：高效運(yùn)維
版權(quán)申明：內(nèi)容來(lái)源網(wǎng)絡(luò)，版權(quán)歸原創(chuàng)者所有。除非無(wú)法確認(rèn)，我們都會(huì)標(biāo)明作者及出處，如有侵權(quán)煩請(qǐng)告知，我們會(huì)立即刪除并表示歉意。謝謝!

感謝閱讀

這樣理解 HTTP，面試再也不用慌了~