摘要：基礎(chǔ)，超文本傳輸協(xié)議。不驗(yàn)證通信方的身份，通信方的身份有可能遭遇偽裝。無法證明報(bào)文的完整性，報(bào)文有可能遭篡改。多路復(fù)用，支持單個(gè)連接多次請(qǐng)求，即連接共享，即每一個(gè)都是是用作連接共享機(jī)制的。

走在前端的大道上

本篇將自己讀過的相關(guān) http/https 方法 文章中，對(duì)自己有啟發(fā)的章節(jié)片段總結(jié)在這（會(huì)對(duì)原文進(jìn)行刪改）,會(huì)不斷豐富提煉總結(jié)更新。

HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）。

WWW（World Wide Web）的三種技術(shù)：HTML、HTTP、URL。

RFC（Request for Comments，征求修正意見書），互聯(lián)網(wǎng)的設(shè)計(jì)文檔。

URI（Uniform Resource Indentifier，統(tǒng)一資源標(biāo)識(shí)符）

URL（Uniform Resource Locator，統(tǒng)一資源定位符）

URN（Uniform Resource Name，統(tǒng)一資源名稱），例如 urn:isbn:0-486-27557-4 。

URI 包含 URL 和 URN，目前 WEB 只有 URL 比較流行，所以見到的基本都是 URL。

超文本傳輸??協(xié)議（HTTP）是用于傳輸諸如HTML的超媒體文檔的應(yīng)用層協(xié)議。它被設(shè)計(jì)用于Web瀏覽器和Web服務(wù)器之間的通信，但它也可以用于其他目的。 HTTP遵循經(jīng)典的客戶端-服務(wù)端模型，客戶端打開一個(gè)連接以發(fā)出請(qǐng)求，然后等待它收到服務(wù)器端響應(yīng)。 HTTP是無狀態(tài)協(xié)議，意味著服務(wù)器不會(huì)在兩個(gè)請(qǐng)求之間保留任何數(shù)據(jù)（狀態(tài)）。

HTTP是明文傳輸?shù)模簿鸵馕吨?，介于發(fā)送端、接收端中間的任意節(jié)點(diǎn)都可以知道你們傳輸?shù)膬?nèi)容是什么。這些節(jié)點(diǎn)可能是路由器、代理等。

舉個(gè)最常見的例子，用戶登陸。用戶輸入賬號(hào)，密碼，采用HTTP的話，只要在代理服務(wù)器上做點(diǎn)手腳就可以拿到你的密碼了。

用戶登陸 --> 代理服務(wù)器（做手腳）--> 實(shí)際授權(quán)服務(wù)器

在發(fā)送端對(duì)密碼進(jìn)行加密？沒用的，雖然別人不知道你原始密碼是多少 ，但能夠拿到加密后的賬號(hào)密碼，照樣能登陸。

HTTP是應(yīng)用層協(xié)議，位于HTTP協(xié)議之下是傳輸協(xié)議TCP。TCP負(fù)責(zé)傳輸，HTTP則定義了數(shù)據(jù)如何進(jìn)行包裝。

簡(jiǎn)單快速、靈活、無連接、無狀態(tài)

請(qǐng)求報(bào)文

響應(yīng)報(bào)文

GET ----> 獲取資源
POST ----> 傳輸資源
PUT ----> 更新資源
DELETE ----> 刪除資源
HEAD ----> 獲取報(bào)文首部

GET在游覽器回退是無害的，而POST會(huì)再次提交請(qǐng)求

GET請(qǐng)求會(huì)被游覽器主動(dòng)緩存，而POST不會(huì)，除非手動(dòng)設(shè)置

GET請(qǐng)求參數(shù)會(huì)被完整的保留在游覽器歷史記錄里，而POST中的參數(shù)不會(huì)被保留

GET產(chǎn)生的URL地址可以被收藏，而POST不可以

GET參數(shù)通過URL傳遞，而POST放在Request body

GET請(qǐng)求只能進(jìn)行URL編碼，而POST支持多種編碼方式

GET請(qǐng)求在URL中傳遞的參數(shù)是有長(zhǎng)度限制的，而POST沒有限制

GET請(qǐng)求會(huì)把參數(shù)直接暴露在URL上，相比POST更安全

對(duì)參數(shù)的數(shù)據(jù)類型，GET只接受ASCII字符，而POST沒有限制

HTTPS科普掃盲帖
notes/HTTP

HTTPS相對(duì)于HTTP有哪些不同呢？其實(shí)就是在HTTP跟TCP中間加多了一層加密層TLS/SSL。

通俗的講，TLS、SSL其實(shí)是類似的東西，SSL是個(gè)加密套件，負(fù)責(zé)對(duì)HTTP的數(shù)據(jù)進(jìn)行加密。TLS是SSL的升級(jí)版。現(xiàn)在提到HTTPS，加密套件基本指的是TLS。

傳輸加密的流程

原先是應(yīng)用層將數(shù)據(jù)直接給到TCP進(jìn)行傳輸，現(xiàn)在改成應(yīng)用層將數(shù)據(jù)給到TLS/SSL，將數(shù)據(jù)加密后，再給到TCP進(jìn)行傳輸。

對(duì)安全或密碼學(xué)基礎(chǔ)有了解的同學(xué)，應(yīng)該知道常見的加密手段。一般來說，加密分為對(duì)稱加密、非對(duì)稱加密（也叫公開密鑰加密）

HTTPS開發(fā)的主要目的，是提供對(duì)網(wǎng)站服務(wù)器的身份認(rèn)證，保護(hù)交換數(shù)據(jù)的隱私與完整性

HTTPS協(xié)議需要到CA申請(qǐng)證書，一般免費(fèi)證書很少，需要交費(fèi)。

HTTP協(xié)議運(yùn)行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文，內(nèi)容可能會(huì)被竊聽。HTTPS運(yùn)行在SSL/TLS之上，SSL/TLS運(yùn)行在TCP之上，所有傳輸?shù)膬?nèi)容都經(jīng)過加密的。

HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

HTTPS可以有效的防止運(yùn)營(yíng)商劫持，解決了防劫持的一個(gè)大問題。

不驗(yàn)證通信方的身份，通信方的身份有可能遭遇偽裝。

無法證明報(bào)文的完整性，報(bào)文有可能遭篡改。

谷歌推行一種協(xié)議(HTTP 之下SSL之上[TCP]),可以算是HTTP2的前身,SPDY可以說是綜合了HTTPS和HTTP兩者優(yōu)點(diǎn)于一體的傳輸協(xié)議，比如

壓縮數(shù)據(jù)(HEADER)

多路復(fù)用

優(yōu)先級(jí)(可以給請(qǐng)求設(shè)置優(yōu)先級(jí))

SPDY構(gòu)成圖：

SPDY位于HTTP之下，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協(xié)議(將HTTP1.x的內(nèi)容封裝成一種新的frame格式)，同時(shí)可以使用已有的SSL功能。

HTTP2.0可以說是SPDY的升級(jí)版（其實(shí)原本也是基于SPDY設(shè)計(jì)的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，主要是以下兩點(diǎn)

HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強(qiáng)制使用 HTTPS

HTTP2.0 消息頭的壓縮算法采用 HPACK，而非 SPDY 采用的 DEFLATE

http2 新特性

新的二進(jìn)制格式（Binary Format），HTTP1.x的解析是基于文本?；谖谋緟f(xié)議的格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性，要做到健壯性考慮的場(chǎng)景必然很多，二進(jìn)制則不同，只認(rèn)0和1的組合?；谶@種考慮HTTP2.0的協(xié)議解析決定采用二進(jìn)制格式，實(shí)現(xiàn)方便且健壯。

多路復(fù)用（MultiPlexing），支持單個(gè)連接多次請(qǐng)求，即連接共享，即每一個(gè)request都是是用作連接共享機(jī)制的。一個(gè)request對(duì)應(yīng)一個(gè)id，這樣一個(gè)連接上可以有多個(gè)request，每個(gè)連接的request可以隨機(jī)的混雜在一起，接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務(wù)端請(qǐng)求里面。

header壓縮，如上文中所言，對(duì)前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復(fù)發(fā)送，HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份header fields表，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮　?/p>

服務(wù)端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能。目前，有大多數(shù)網(wǎng)站已經(jīng)啟用HTTP2.0，例如YouTuBe，淘寶網(wǎng)等網(wǎng)站，利用chrome控制臺(tái)可以查看是否啟用H2：

chrome=>Network=>Name欄右鍵=>√Protocol

本節(jié)參考文章：簡(jiǎn)單比較 http https http2、HTTPS科普掃盲帖

關(guān)于跨域，有兩個(gè)誤區(qū)：

? 動(dòng)態(tài)請(qǐng)求就會(huì)有跨域的問題

? 跨域只存在于瀏覽器端，不存在于安卓/ios/Node.js/python/ java等其它環(huán)境

? 跨域就是請(qǐng)求發(fā)不出去了

? 跨域請(qǐng)求能發(fā)出去，服務(wù)端能收到請(qǐng)求并正常返回結(jié)果，只是結(jié)果被瀏覽器攔截了之所以會(huì)跨域，是因?yàn)槭艿搅送床呗缘南拗?，同源策略要求源相同才能正常進(jìn)行通信，即協(xié)議、域名、端口號(hào)都完全一致。

不能向工作在不同源的的服務(wù)請(qǐng)求數(shù)據(jù)（client to server）

但是script標(biāo)簽?zāi)軌蚣虞d非同源的資源，不受同源策略的影響。

無法獲取不同源的document/cookie等BOM和DOM，可以說任何有關(guān)另外一個(gè)源的信息都無法得到 （client to client）

如下圖所示：

只要瀏覽器檢測(cè)到響應(yīng)頭帶上了CORS，并且允許的源包括了本網(wǎng)站，那么就不會(huì)攔截請(qǐng)求響應(yīng)。

CORS把請(qǐng)求分為兩種，一種是簡(jiǎn)單請(qǐng)求，另一種是需要觸發(fā)預(yù)檢請(qǐng)求，這兩者是相對(duì)的，怎樣才算“不簡(jiǎn)單”？只要屬于下面的其中一種就不是簡(jiǎn)單請(qǐng)求：
（1）使用了除GET/POST/HEAD之外的請(qǐng)求方式，如PUT/DELETE
（2）使用了除Accept/Accept-Language/Content-Language/Last-Event-ID/Content-Type：只限于三個(gè)值application/x-www-form-urlencoded、multipart/form-data、text/plain等幾個(gè)常用的http頭這個(gè)時(shí)候就認(rèn)為需要先發(fā)個(gè)預(yù)檢請(qǐng)求，預(yù)檢請(qǐng)求使用OPTIONS方式去檢查當(dāng)前請(qǐng)求是否安全

代碼里面只發(fā)了一個(gè)請(qǐng)求，但在控制臺(tái)看到了兩個(gè)請(qǐng)求，第一個(gè)是OPTIONS，服務(wù)端返回：

詳見阮一峰的跨域資源共享CORS詳解

JSONP是利用了script標(biāo)簽?zāi)軌蚩缬?，如下代碼所示：

function updateList (data) {
    console.log(data);
}

$body.append(‘");

代碼先定義一個(gè)全局函數(shù)，然后把這個(gè)函數(shù)名通過callback參數(shù)添加到script標(biāo)簽的src，script的src就是需要跨域的請(qǐng)求，然后這個(gè)請(qǐng)求返回可執(zhí)行的JS文本：// script響應(yīng)返回的js內(nèi)容為

updateList([{
    name: "hello"
}]);

由于它是一個(gè)js，并且已經(jīng)定義了upldateList函數(shù)，所以能正常執(zhí)行，并且跨域的數(shù)據(jù)通過傳參得到。這就是JSONP的原理。

跨域分為兩種，一種是跨域請(qǐng)求，另一種訪問跨域的頁面，跨域請(qǐng)求可以通過CORS/JSONP等方法進(jìn)行訪問，跨域的頁面主要通過postMesssage的方式。由于跨域請(qǐng)求不但能發(fā)出去還能帶上cookie，所以要規(guī)避跨站請(qǐng)求偽造攻擊的風(fēng)險(xiǎn)，特別是涉及到錢的那種請(qǐng)求。

本節(jié)參考文章：我知道的跨域與安全

主要的過程是：
1.瀏覽器解析 -> 2.查詢緩存 -> 3.dns查詢 -> 4.建立鏈接 -> 5.服務(wù)器處理請(qǐng)求 -> 6.服務(wù)器發(fā)送響應(yīng) -> 7.客戶端收到頁面 -> 8.解析HTML -> 9.構(gòu)建渲染樹 -> 10.開始顯示內(nèi)容(白屏?xí)r間) -> 11.首屏內(nèi)容加載完成(首屏?xí)r間) -> 12.用戶可交互(DOMContentLoaded) -> 13.加載完成(load)

跳轉(zhuǎn)-->應(yīng)用緩存-->dns-->tcp-->request-->response

本節(jié)摘要：

DNS域名解析；

建立TCP連接；

發(fā)送HTTP請(qǐng)求；

服務(wù)器處理請(qǐng)求；

返回響應(yīng)結(jié)果；

關(guān)閉TCP連接；

瀏覽器解析HTML；

瀏覽器布局渲染；

當(dāng)我們?cè)跒g覽器輸入網(wǎng)址并回車后，一切從這里開始。

我們?cè)跒g覽器輸入網(wǎng)址，其實(shí)就是要向服務(wù)器請(qǐng)求我們想要的頁面內(nèi)容，所有瀏覽器首先要確認(rèn)的是域名所對(duì)應(yīng)的服務(wù)器在哪里。將域名解析成對(duì)應(yīng)的服務(wù)器IP地址這項(xiàng)工作，是由DNS服務(wù)器來完成的。

客戶端收到你輸入的域名地址后，它首先去找本地的hosts文件，檢查在該文件中是否有相應(yīng)的域名、IP對(duì)應(yīng)關(guān)系，如果有，則向其IP地址發(fā)送請(qǐng)求，如果沒有，再去找DNS服務(wù)器。一般用戶很少去編輯修改hosts文件。

    DNS服務(wù)器層次結(jié)構(gòu)

瀏覽器客戶端向本地DNS服務(wù)器發(fā)送一個(gè)含有域名www.cnblogs.com的DNS查詢報(bào)文。本地DNS服務(wù)器把查詢報(bào)文轉(zhuǎn)發(fā)到根DNS服務(wù)器，根DNS服務(wù)器注意到其com后綴，于是向本地DNS服務(wù)器返回comDNS服務(wù)器的IP地址。本地DNS服務(wù)器再次向comDNS服務(wù)器發(fā)送查詢請(qǐng)求，comDNS服務(wù)器注意到其www.cnblogs.com后綴并用負(fù)責(zé)該域名的權(quán)威DNS服務(wù)器的IP地址作為回應(yīng)。最后，本地DNS服務(wù)器將含有www.cnblogs.com的IP地址的響應(yīng)報(bào)文發(fā)送給客戶端。

從客戶端到本地服務(wù)器屬于遞歸查詢，而DNS服務(wù)器之間的交互屬于迭代查詢。
正常情況下，本地DNS服務(wù)器的緩存中已有comDNS服務(wù)器的地址，因此請(qǐng)求根域名服務(wù)器這一步不是必需的。

費(fèi)了一頓周折終于拿到服務(wù)器IP了，下一步自然就是鏈接到該服務(wù)器。對(duì)于客戶端與服務(wù)器的TCP鏈接，必然要說的就是『三次握手』。

三次握手

客戶端發(fā)送一個(gè)帶有SYN標(biāo)志的數(shù)據(jù)包給服務(wù)端，服務(wù)端收到后，回傳一個(gè)帶有SYN/ACK標(biāo)志的數(shù)據(jù)包以示傳達(dá)確認(rèn)信息，最后客戶端再回傳一個(gè)帶ACK標(biāo)志的數(shù)據(jù)包，代表握手結(jié)束，連接成功。

上圖也可以這么理解：

客戶端：“你好，在家不，有你快遞?！?/p>

服務(wù)端：“在的，送來就行?！?/p>

客戶端：“好嘞?！?/p>

TCP三次握手
client----->server:SYN(發(fā)起一個(gè)TCP連接，同步報(bào)文)
server----->client:SYN+ACK(應(yīng)答報(bào)文，表示已創(chuàng)建連接)
client----->server:ACK(應(yīng)答報(bào)文，表示收到已連接)

與服務(wù)器建立了連接后，就可以向服務(wù)器發(fā)起請(qǐng)求了。這里我們先看下請(qǐng)求報(bào)文的結(jié)構(gòu)（如下圖）：

請(qǐng)求報(bào)文

在瀏覽器中查看報(bào)文首部（以google瀏覽器為例）：

請(qǐng)求行包括請(qǐng)求方法、URI、HTTP版本。首部字段傳遞重要信息，包括請(qǐng)求首部字段、通用首部字段和實(shí)體首部字段。我們可以從報(bào)文中看到發(fā)出的請(qǐng)求的具體信息。具體每個(gè)首部字段的作用，這里不做過多闡述。

服務(wù)器端收到請(qǐng)求后的由web服務(wù)器（準(zhǔn)確說應(yīng)該是http服務(wù)器）處理請(qǐng)求，諸如Apache、Ngnix、IIS等。web服務(wù)器解析用戶請(qǐng)求，知道了需要調(diào)度哪些資源文件，再通過相應(yīng)的這些資源文件處理用戶請(qǐng)求和參數(shù)，并調(diào)用數(shù)據(jù)庫信息，最后將結(jié)果通過web服務(wù)器返回給瀏覽器客戶端。

服務(wù)器處理請(qǐng)求

在HTTP里，有請(qǐng)求就會(huì)有響應(yīng)，哪怕是錯(cuò)誤信息。這里我們同樣看下響應(yīng)報(bào)文的組成結(jié)構(gòu)：

響應(yīng)報(bào)文

在響應(yīng)結(jié)果中都會(huì)有個(gè)一個(gè)HTTP狀態(tài)碼，比如我們熟知的200、301、404、500等。通過這個(gè)狀態(tài)碼我們可以知道服務(wù)器端的處理是否正常，并能了解具體的錯(cuò)誤。

狀態(tài)碼由3位數(shù)字和原因短語組成。根據(jù)首位數(shù)字，狀態(tài)碼可以分為五類：

狀態(tài)碼類別

為了避免服務(wù)器與客戶端雙方的資源占用和損耗，當(dāng)雙方?jīng)]有請(qǐng)求或響應(yīng)傳遞時(shí)，任意一方都可以發(fā)起關(guān)閉請(qǐng)求。與創(chuàng)建TCP連接的3次握手類似，關(guān)閉TCP連接，需要4次握手。

上圖可以這么理解：

客戶端：“兄弟，我這邊沒數(shù)據(jù)要傳了，咱關(guān)閉連接吧?！?/p>

服務(wù)端：“收到，我看看我這邊有木有數(shù)據(jù)了?！?/p>

服務(wù)端：“兄弟，我這邊也沒數(shù)據(jù)要傳你了，咱可以關(guān)閉連接了?！?/p>

客戶端：“好嘞?！?/p>

由客戶端發(fā)起的關(guān)閉連接

    * client----->server:FIN(請(qǐng)求關(guān)閉連接)
    * server----->client:ACK(收到了連接，但不會(huì)立即關(guān)閉，等到報(bào)文都發(fā)送完再回復(fù)一個(gè)FIN)
    * server----->client:FIN
    * client----->server:ACK(收到關(guān)閉)

由服務(wù)端發(fā)起的關(guān)閉連接

* 當(dāng)http設(shè)置了keepalive定時(shí)關(guān)閉，服務(wù)端會(huì)在結(jié)束數(shù)據(jù)傳送后關(guān)閉TCP連接

準(zhǔn)確地說，瀏覽器需要加載解析的不僅僅是HTML，還包括CSS、JS。以及還要加載圖片、視頻等其他媒體資源。

瀏覽器通過解析HTML，生成DOM樹，解析CSS，生成CSS規(guī)則樹，然后通過DOM樹和CSS規(guī)則樹生成渲染樹。渲染樹與DOM樹不同，渲染樹中并沒有head、display為none等不必顯示的節(jié)點(diǎn)。

要注意的是，瀏覽器的解析過程并非是串連進(jìn)行的，比如在解析CSS的同時(shí)，可以繼續(xù)加載解析HTML，但在解析執(zhí)行JS腳本時(shí)，會(huì)停止解析后續(xù)HTML，這就會(huì)出現(xiàn)阻塞問題，關(guān)于JS阻塞相關(guān)問題，這里不過多闡述,后面會(huì)多帶帶開篇講解。

根據(jù)渲染樹布局，計(jì)算CSS樣式，即每個(gè)節(jié)點(diǎn)在頁面中的大小和位置等幾何信息。HTML默認(rèn)是流式布局的，CSS和js會(huì)打破這種布局，改變DOM的外觀樣式以及大小和位置。這時(shí)就要提到兩個(gè)重要概念：repaint和reflow。

repaint：屏幕的一部分重畫，不影響整體布局，比如某個(gè)CSS的背景色變了，但元素的幾何尺寸和位置不變。
reflow： 意味著元件的幾何尺寸變了，我們需要重新驗(yàn)證并計(jì)算渲染樹。是渲染樹的一部分或全部發(fā)生了變化。這就是Reflow，或是Layout。

所以我們應(yīng)該盡量減少reflow和repaint，我想這也是為什么現(xiàn)在很少有用table布局的原因之一。

最后瀏覽器繪制各個(gè)節(jié)點(diǎn)，將頁面展示給用戶。

拓展閱讀：面試必考之http狀態(tài)碼有哪些、CDN與DNS知識(shí)匯總、前端工程師系列，TCP復(fù)習(xí)及濃縮總結(jié)（全干貨，支持面試）

推薦必讀：5分鐘讓你明白HTTP協(xié)議、分分鐘讓你理解HTTPS

本節(jié)參考文章：”天龍八步“細(xì)說瀏覽器輸入U(xiǎn)RL后發(fā)生了什么

在瀏覽器地址欄輸入U(xiǎn)RL

瀏覽器查看緩存，如果請(qǐng)求資源在緩存中并且新鮮，跳轉(zhuǎn)到轉(zhuǎn)碼步驟

如果資源未緩存，發(fā)起新請(qǐng)求

如果已緩存，檢驗(yàn)是否足夠新鮮，足夠新鮮直接提供給客戶端，否則與服務(wù)器進(jìn)行驗(yàn)證。

檢驗(yàn)新鮮通常有兩個(gè)HTTP頭進(jìn)行控制Expires和Cache-Control：

HTTP1.0提供Expires，值為一個(gè)絕對(duì)時(shí)間表示緩存新鮮日期

HTTP1.1增加了Cache-Control: max-age=,值為以秒為單位的最大新鮮時(shí)間

瀏覽器解析URL獲取協(xié)議，主機(jī)，端口，path

瀏覽器組裝一個(gè)HTTP（GET）請(qǐng)求報(bào)文

瀏覽器獲取主機(jī)ip地址（DNS解析），過程如下：

瀏覽器緩存

本機(jī)緩存

hosts文件

路由器緩存

ISP DNS緩存

DNS遞歸查詢（可能存在負(fù)載均衡導(dǎo)致每次IP不一樣）

打開一個(gè)socket與目標(biāo)IP地址，端口建立TCP鏈接，三次握手如下：

客戶端發(fā)送一個(gè)TCP的SYN=1，Seq=X的包到服務(wù)器端口

服務(wù)器發(fā)回SYN=1， ACK=X+1， Seq=Y的響應(yīng)包

客戶端發(fā)送ACK=Y+1， Seq=Z

TCP鏈接建立后發(fā)送HTTP請(qǐng)求

服務(wù)器接受請(qǐng)求并解析，將請(qǐng)求轉(zhuǎn)發(fā)到服務(wù)程序，如虛擬主機(jī)使用HTTP Host頭部判斷請(qǐng)求的服務(wù)程序

服務(wù)器檢查HTTP請(qǐng)求頭是否包含緩存驗(yàn)證信息如果驗(yàn)證緩存新鮮，返回304等對(duì)應(yīng)狀態(tài)碼

處理程序讀取完整請(qǐng)求并準(zhǔn)備HTTP響應(yīng)，可能需要查詢數(shù)據(jù)庫等操作

服務(wù)器將響應(yīng)報(bào)文通過TCP連接發(fā)送回瀏覽器

瀏覽器接收HTTP響應(yīng)，然后根據(jù)情況選擇關(guān)閉TCP連接或者保留重用，關(guān)閉TCP連接的四次握手如下：

主動(dòng)方發(fā)送Fin=1， Ack=Z， Seq= X報(bào)文

被動(dòng)方發(fā)送ACK=X+1， Seq=Z報(bào)文

被動(dòng)方發(fā)送Fin=1， ACK=X， Seq=Y報(bào)文

主動(dòng)方發(fā)送ACK=Y， Seq=X報(bào)文

瀏覽器檢查響應(yīng)狀態(tài)嗎：是否為1XX，3XX， 4XX， 5XX，這些情況處理與2XX不同

如果資源可緩存，進(jìn)行緩存

對(duì)響應(yīng)進(jìn)行解碼（例如gzip壓縮）

根據(jù)資源類型決定如何處理（假設(shè)資源為HTML文檔）

解析HTML文檔，構(gòu)件DOM樹，下載資源，構(gòu)造CSSOM樹，執(zhí)行js腳本，這些操作沒有嚴(yán)格的先后順序，以下分別解釋

構(gòu)建DOM樹：

Tokenizing：根據(jù)HTML規(guī)范將字符流解析為標(biāo)記

Lexing：詞法分析將標(biāo)記轉(zhuǎn)換為對(duì)象并定義屬性和規(guī)則

DOM construction：根據(jù)HTML標(biāo)記關(guān)系將對(duì)象組成DOM樹

解析過程中遇到圖片、樣式表、js文件，啟動(dòng)下載

構(gòu)建CSSOM樹：

Tokenizing：字符流轉(zhuǎn)換為標(biāo)記流

Node：根據(jù)標(biāo)記創(chuàng)建節(jié)點(diǎn)

CSSOM：節(jié)點(diǎn)創(chuàng)建CSSOM樹

根據(jù)DOM樹和CSSOM樹構(gòu)建渲染樹:

從DOM樹的根節(jié)點(diǎn)遍歷所有可見節(jié)點(diǎn)，不可見節(jié)點(diǎn)包括：

script,meta這樣本身不可見的標(biāo)簽。

被css隱藏的節(jié)點(diǎn)，如display: none

對(duì)每一個(gè)可見節(jié)點(diǎn)，找到恰當(dāng)?shù)腃SSOM規(guī)則并應(yīng)用

發(fā)布可視節(jié)點(diǎn)的內(nèi)容和計(jì)算樣式

js解析如下：

瀏覽器創(chuàng)建Document對(duì)象并解析HTML，將解析到的元素和文本節(jié)點(diǎn)添加到文檔中，此時(shí)document.readystate為loading

HTML解析器遇到?jīng)]有async和defer的script時(shí)，將他們添加到文檔中，然后執(zhí)行行內(nèi)或外部腳本。這些腳本會(huì)同步執(zhí)行，并且在腳本下載和執(zhí)行時(shí)解析器會(huì)暫停。這樣就可以用document.write()把文本插入到輸入流中。同步腳本經(jīng)常簡(jiǎn)單定義函數(shù)和注冊(cè)事件處理程序，他們可以遍歷和操作script和他們之前的文檔內(nèi)容

當(dāng)解析器遇到設(shè)置了async屬性的script時(shí)，開始下載腳本并繼續(xù)解析文檔。腳本會(huì)在它下載完成后盡快執(zhí)行，但是解析器不會(huì)停下來等它下載。異步腳本禁止使用document.write()，它們可以訪問自己script和之前的文檔元素

當(dāng)文檔完成解析，document.readState變成interactive

所有defer腳本會(huì)按照在文檔出現(xiàn)的順序執(zhí)行，延遲腳本能訪問完整文檔樹，禁止使用document.write()

瀏覽器在Document對(duì)象上觸發(fā)DOMContentLoaded事件

此時(shí)文檔完全解析完成，瀏覽器可能還在等待如圖片等內(nèi)容加載，等這些內(nèi)容完成載入并且所有異步腳本完成載入和執(zhí)行，document.readState變?yōu)閏omplete,window觸發(fā)load事件

顯示頁面（HTML解析過程中會(huì)逐步顯示頁面）

OSI 七層涵蓋:物理層,數(shù)據(jù)鏈路層,網(wǎng)絡(luò)層,傳輸層,會(huì)話層,表示層,應(yīng)用層;

五層因特網(wǎng)協(xié)議棧其實(shí)就是：

應(yīng)用層(dns,http) DNS解析成IP并發(fā)送http請(qǐng)求

傳輸層(tcp,udp) 建立tcp連接（三次握手）

網(wǎng)絡(luò)層(IP,ARP) IP尋址 為數(shù)據(jù)在結(jié)點(diǎn)之間傳輸創(chuàng)建邏輯鏈路

數(shù)據(jù)鏈路層(PPP) 封裝成幀 在通信實(shí)體間建立數(shù)據(jù)鏈路鏈接

物理層(利用物理介質(zhì)傳輸比特流) 物理傳輸（然后傳輸?shù)臅r(shí)候通過雙絞線，電磁波等各種介質(zhì)） 主要定義屋里設(shè)備如何傳輸數(shù)據(jù)

五層模型就是"會(huì)話,表示,應(yīng)用層"同為一層;

DNS是應(yīng)用層協(xié)議，事實(shí)上他是為其他應(yīng)用層協(xié)議工作的，包括不限于HTTP和SMTP以及FTP，用于將用戶提供的主機(jī)名解析為ip地址。
具體過程如下：
(1)瀏覽器緩存: 當(dāng)用戶通過瀏覽器訪問某域名時(shí)，瀏覽器首先會(huì)在自己的緩存中查找是否有該域名對(duì)應(yīng)的IP地址（若曾經(jīng)訪問過該域名且沒有清空緩存便存在)；

(2)系統(tǒng)緩存： 當(dāng)瀏覽器緩存中無域名對(duì)應(yīng)IP則會(huì)自動(dòng)檢查用戶計(jì)算機(jī)系統(tǒng)Hosts文件DNS緩存是否有該域名對(duì)應(yīng)IP；

(3)路由器緩存: 當(dāng)瀏覽器及系統(tǒng)緩存中均無域名對(duì)應(yīng)IP則進(jìn)入路由器緩存中檢查，以上三步均為客戶端的DNS緩存；

(4)ISP（互聯(lián)網(wǎng)服務(wù)提供商）DNS緩存: 當(dāng)在用戶客服端查找不到域名對(duì)應(yīng)IP地址，則將進(jìn)入ISP DNS緩存中進(jìn)行查詢。比如你用的是電信的網(wǎng)絡(luò)，則會(huì)進(jìn)入電信的DNS緩存服務(wù)器中進(jìn)行查找；(或者向網(wǎng)絡(luò)設(shè)置中指定的local DNS進(jìn)行查詢，如果在PC指定了DNS的話，如果沒有設(shè)置比如DNS動(dòng)態(tài)獲取，則向ISP DNS發(fā)起查詢請(qǐng)求)

(5)根域名服務(wù)器: 當(dāng)以上均未完成，則進(jìn)入根服務(wù)器進(jìn)行查詢。全球僅有13臺(tái)根域名服務(wù)器，1個(gè)主根域名服務(wù)器，其余12為輔根域名服務(wù)器。根域名收到請(qǐng)求后會(huì)查看區(qū)域文件記錄，若無則將其管轄范圍內(nèi)頂級(jí)域名（如.com）服務(wù)器IP告訴本地DNS服務(wù)器；

(6)頂級(jí)域名服務(wù)器: 頂級(jí)域名服務(wù)器收到請(qǐng)求后查看區(qū)域文件記錄，若無則將其管轄范圍內(nèi)主域名服務(wù)器的IP地址告訴本地DNS服務(wù)器；

(7)主域名服務(wù)器: 主域名服務(wù)器接受到請(qǐng)求后查詢自己的緩存，如果沒有則進(jìn)入下一級(jí)域名服務(wù)器進(jìn)行查找，并重復(fù)該步驟直至找到正確記錄；

(8)保存結(jié)果至緩存: 本地域名服務(wù)器把返回的結(jié)果保存到緩存，以備下一次使用，同時(shí)將該結(jié)果反饋給客戶端，客戶端通過這個(gè)IP地址與web服務(wù)器建立鏈接。

A: 域名直接到 IP

CNAME: 可以多個(gè)域名映射到一個(gè)主機(jī),類似在 Github Page就用 CNAME 指向

MX: 郵件交換記錄,用的不多,一般搭建郵件服務(wù)器才會(huì)用到

NS: 解析服務(wù)記錄,可以設(shè)置權(quán)重,指定誰解析

TTL: 就是生存時(shí)間(也叫緩存時(shí)間),一般的域名解析商都有默認(rèn)值,也可以人為設(shè)置

TXT: 一般指某個(gè)主機(jī)名或域名的說明