一、前言
文章為了加深自我理解置济，參考：
前端經(jīng)典面試題: 從輸入URL到頁面加載發(fā)生了什么？
老生常談-從輸入url到頁面展示到底發(fā)生了什么
HTTP 請求頭與請求體
四種常見的POST提交方式
二钾唬、開始
從用戶開始輸入 url 到用戶見到頁面內(nèi)容十办，過程如下：
- 輸入 url
- 查找 ip ,從本地系統(tǒng)查找 hosts 文件，是否有 ip ? 有則下一步 : 沒有嗅绰，進(jìn)行 DNS 解析
- TCP 連接
- 發(fā)送 HTTP 請求
- 服務(wù)器處理并返回 HTTP 請求
- 瀏覽器解析渲染頁面
- 用戶看到完整頁面
三舍肠、具體過程
I. 輸入 url
用戶在瀏覽器中輸入網(wǎng)址的時候搀继，瀏覽器就只能的會從歷史記錄、書簽來搜索你當(dāng)前輸入的地址翠语，如果你訪問的是有緩存過的地址叽躯，網(wǎng)頁可能直接展示出來。
II. 查找 ip
每個域名都是對應(yīng)有一個 ip 地址肌括， 諸如 www.baidu.com 這些名稱只是用來方便用戶記憶点骑。所以在獲取網(wǎng)頁內(nèi)容之前，瀏覽器得先知道這個網(wǎng)址的 ip 地址谍夭，才能去到對應(yīng)的服務(wù)器去獲取資源黑滴。
首先，瀏覽器會嘗試在本地的 hosts 文件中去查看是否有相應(yīng)的 ip 記錄紧索，有的話就直接用對應(yīng)的 ip 跷跪，省去 DNS 解析。
DNS 解析
DNS （Domain Name System ,域名系統(tǒng)）解析齐板，就是一個網(wǎng)址到 ip 地址轉(zhuǎn)換的過程吵瞻，解析是一個遞歸查詢的過程。
經(jīng)過多次的服務(wù)器往返后甘磨，得到了對應(yīng)的 ip 地址橡羞。從上述過程中，可以看出網(wǎng)址的解析是一個從右向左的過程济舆，瀏覽器首先會去訪問
本地DNS服務(wù)器卿泽，查看是否有緩存 ip ，沒有滋觉，那么去訪問根服務(wù)器签夭，每個網(wǎng)址的真正地址是www.baidu.com.，就是在網(wǎng)址后還有一個點(diǎn)椎侠，這個點(diǎn)就是指向根服務(wù)器第租，然后根服務(wù)器告訴你，你應(yīng)該去問COM頂級域名服務(wù)器我纪，然后COM頂級域名服務(wù)器又告訴你慎宾，你應(yīng)該去問baidu.com服務(wù)器，這下終于找到負(fù)責(zé)人了浅悉，baidu.com服務(wù)器就會把它管理的www.baidu.com的 ip 地址返回告訴瀏覽器趟据，費(fèi)了這么大勁，瀏覽器終于如愿以償拿到 ip 了术健，接下來就可以向該 ip 拿頁面了汹碱。
問題是，如果每一次瀏覽器訪問個網(wǎng)站都要這么費(fèi)勁荞估，那用戶體驗不就很差咳促？所以聰明的瀏覽器在訪問過一次之后色难，會去緩存下這個網(wǎng)址對應(yīng)的 ip 地址，下次就能直接用了等缀。另外枷莉，聰明的本地DNS服務(wù)器、所有的服務(wù)器也會存下映射關(guān)系尺迂，以便下次使用笤妙。另外，也可以人為修改 Hosts 文件來指定網(wǎng)址的 ip 映射關(guān)系噪裕。
III. 建立 TCP 連接
瀏覽器在拿到 ip 地址之后蹲盘，就開始準(zhǔn)備 HTTP 請求了，但首先要先和服務(wù)器建立連接通道膳音，這時候就用到 TCP 建立三次握手了召衔。 TCP 協(xié)議是用來建立對話通道的，在客戶端和服務(wù)器還沒對接之前祭陷，是無法確定各種各樣的請求的苍凛，舉個網(wǎng)絡(luò)上看到的例子：
- 甲： “喂！是乙嗎兵志？”
- 乙： “是呀醇蝴，我是乙∠牒保”
- 甲： “那我們開始對話吧悠栓！”
只有確保的請求服務(wù)器正確，才可以真正開始請求按价。另外惭适，在請求頭會有一個
Connection: keep-alive，表示保持 TCP 連接楼镐，這樣客戶端在下次請求的時候癞志，就不需要重新建立 TCP 連接了，雖然這樣會損耗部分服務(wù)器性能鸠蚪，但對雙方（客戶端今阳、服務(wù)器）也都是有好處的师溅。
IV. 發(fā)起 HTTP 請求
典型的 HTTP 請求消息頭域茅信，如下：
POST/GET http://download.microtool.de:80/somedata.exe
Host: download.microtool.de
Accept:*/*
Pragma: no-cache
Cache-Control: no-cache
Referer: http://download.microtool.de/
User-Agent:Mozilla/4.04[en](Win95;I;Nav)
Range:bytes=554554-
總的來說 HTTP 請求包含三部分：請求行、請求頭墓臭、請求體（請求正文）蘸鲸。
a. 請求行
請求行分為三部分：請求方法、請求地址和協(xié)及版本窿锉。
HTTP/1.1定義的請求方法有 8 種：GET酌摇、POST膝舅、PUT、DELETE窑多、PATCH仍稀、HEAD、OPTIONS埂息、TRACE技潘，最常用的兩種 GET 和 POST。以下為 GET 和 POST 區(qū)別的文章：
GET VS POST
注意： 在 POST千康、PUT享幽、PATCH 三個請求中會包含請求體，其他的并沒有拾弃。
b. 請求頭
請求頭的詳細(xì)類型和內(nèi)容的詳細(xì)內(nèi)容谷歌搜索值桩，一下是一次請求的樣例：
c. 請求體
請求體主要是用來存放數(shù)據(jù)，數(shù)據(jù)類型存儲在 Content-Type 響應(yīng)頭上豪椿，接觸過的有：
-
application/x-www-form-urlencoded
最常見的 POST 提交數(shù)據(jù)方式奔坟，瀏覽器原生<form>表單，格式如下
POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3
-
application/json
主要用來提交 JSON 格式的數(shù)據(jù)搭盾，格式為：
POST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf-8
{"title":"test","sub":[1,2,3]}
-
multipart/form-data
使用表單上傳文件時的格式蛀蜜，用于上傳文件，格式如：
POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"
title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png
PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--
-
text/xml
傳輸數(shù)據(jù)增蹭，沒用過滴某，不清楚，格式如下：
POST http://www.example.com HTTP/1.1
Content-Type: text/xml
<?xml version="1.0"?>
<methodCall>
<methodName>examples.getStateName</methodName>
<params>
<param>
<value><i4>41</i4></value>
</param>
</params>
</methodCall>
V. 服務(wù)器處理請求并返回 HTTP 報文
HTTP 請求也是三部分請求：狀態(tài)碼滋迈、相應(yīng)頭霎奢、響應(yīng)體（響應(yīng)報文）。
a. 狀態(tài)碼
狀態(tài)碼由3位數(shù)組成饼灿，第一個數(shù)字定義了相應(yīng)類別幕侠，共有五種可能取值：
- 1XX 消息：代表請求已被接受，需要繼續(xù)處理碍彭。這類響應(yīng)是臨時響應(yīng)晤硕，通常情況下，服務(wù)器是不會給客戶端發(fā)送1xx響應(yīng)庇忌。
- 2XX 成功：代表請求成功被服務(wù)器接收舞箍、理解、接受皆疹。
- 3XX 重定向：代表客戶端需要采取進(jìn)一步的操作才能完成請求疏橄。
- 4XX 客戶端錯誤：代表客戶端看起來發(fā)生了錯誤，妨礙了服務(wù)器的處理。
- 5XX 服務(wù)器錯誤：表示服務(wù)器無法完成明顯有效的請求捎迫。
參考： HTTP 狀態(tài)碼
b. 響應(yīng)頭
涉及到服務(wù)器名稱晃酒、緩存、響應(yīng)體類型等窄绒，詳細(xì)內(nèi)容自行谷歌贝次。
c. 響應(yīng)體
響應(yīng)體除了有 JSON 數(shù)據(jù)等一些其他數(shù)據(jù)類型外，也是獲取 HTML彰导、CSS浊闪、JS、圖片等文件的地方螺戳。
HTTP 和 HTTPS
HTTPS 是 HTTP 請求前搁宾，客戶端與服務(wù)器先進(jìn)行一次握手（TLS/SSL握手），用于數(shù)據(jù)加密倔幼，具體加密我不懂盖腿，參考這里：圖解SSL/TLS協(xié)議。很明顯的是损同，雖然 HTTPS 更為安全翩腐，但與 HTTP 相比，多了一次連接膏燃，肯定會影響一部分的加載速度茂卦。一張圖說明：
VI. 瀏覽器解析渲染頁面
瀏覽器解析服務(wù)器返回的 HTML 時，是從上往下順序解析的组哩，遇到 CSS link等龙、JS link 就會向服務(wù)器請求該資源，瀏覽器也開始生成 DOM 結(jié)構(gòu)伶贰，但需要注意的是蛛砰，CSS 文件不會阻塞 DOM 結(jié)構(gòu)的生成，而 JS 文件會（因為 JS 可以操作 DOM）黍衙，所以如果在 HTML 頭部開始解析 JS 的話泥畅，瀏覽器會等 JS 請求完并且初始化結(jié)束才會繼續(xù)生成 DOM 結(jié)構(gòu)。這也是為什么 JS 經(jīng)常放在
<body>最后琅翻，而且用的是window.onload=function(){}位仁。不過可以在<script async></script>加個async方椎，告訴瀏覽器不用等我 JS 啦聂抢，趕緊開始生成你的 DOM 樹結(jié)構(gòu)（async是異步加載的意思）涛浙。
DOM 樹生成后迟隅，就要上色但骨，這時候就是 CSS 的作用了。一張圖說明：
另外智袭，這里有個視頻很好的講解了瀏覽器對網(wǎng)頁的處理：網(wǎng)站性能優(yōu)化（中/英）
VII. 用戶看到完整頁面
到此奔缠，用戶終于能完整的看到一個頁面了，沒想到吧吼野，在這么短短2秒校哎，瀏覽器做了這么多事，還跑了這么遠(yuǎn)瞳步，不容易闷哆。要學(xué)的內(nèi)容還很多，這是一篇前端新手的理解单起，參考很多東西抱怔，如有出錯，請嚴(yán)厲指出~
