一個(gè)騰訊在職的朋友問(wèn)道，當(dāng)我們?cè)跒g覽器的地址欄輸入 www.baidu.com ，然后回車，這一瞬間頁(yè)面發(fā)生了什么？下面以谷歌瀏覽器一一解釋．
一.域名解析
首先Chrome瀏覽器會(huì)解析www.baidu.com 這個(gè)域名對(duì)應(yīng)的IP地址。
1 瀏覽器搜索自身的DNS緩存,看是否有www.baidu.com 對(duì)應(yīng)的條目，如果有且沒(méi)有過(guò)期則解析到此結(jié)束。
2 如果沒(méi)有找到對(duì)應(yīng)的條目，那么Chrome會(huì)搜索操作系統(tǒng)自身的DNS緩存,如果找到且沒(méi)過(guò)期則停止搜索解析到此結(jié)束.
3 如果在Windows系統(tǒng)的DNS緩存也沒(méi)有找到，那么嘗試讀取hosts文件，看有沒(méi)有該域名對(duì)應(yīng)的IP地址，如果有則解析成功。
4 如果在hosts文件中也沒(méi)有找到對(duì)應(yīng)的條目，瀏覽器就會(huì)發(fā)起一個(gè)DNS的系統(tǒng)調(diào)用，就會(huì)向本地配置的首選DNS服務(wù)器發(fā)起域名解析請(qǐng)求，運(yùn)營(yíng)商的DNS服務(wù)器首先查找自身的緩存，找到對(duì)應(yīng)的條目，且沒(méi)有過(guò)期，則解析成功。
二.發(fā)起TCP的3次握手
拿到域名對(duì)應(yīng)的IP地址后，User-Agent（一般是指瀏覽器）會(huì)以一個(gè)隨機(jī)端口（1024 < 端口 < 65535）向服務(wù)器的WEB程序80端口發(fā)起TCP的連接請(qǐng)求。這個(gè)連接請(qǐng)求（原始的http請(qǐng)求經(jīng)過(guò)TCP/IP4層模型的層層封包）到達(dá)服務(wù)器端后，進(jìn)入到網(wǎng)卡，然后是進(jìn)入到內(nèi)核的TCP/IP協(xié)議棧，還有可能要經(jīng)過(guò)Netfilter防火墻的過(guò)濾，最終到達(dá)WEB程序，建立了TCP/IP的連接。在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，采用三次握手建立一個(gè)連接:
第一次握手：客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；
第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；
第三次握手：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。
握手過(guò)程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前，TCP 連接都將被一直保持下去。斷開連接時(shí)服務(wù)器和客戶端均可以主動(dòng)發(fā)起斷開TCP連接的請(qǐng)求，斷開過(guò)程需要經(jīng)過(guò)“第四次握手”，就是服務(wù)器和客戶端交互，最終確定斷開。
三.建立TCP連接后發(fā)起http請(qǐng)求
HTTP協(xié)議即超文本傳送協(xié)議(Hypertext Transfer Protocol )，是Web聯(lián)網(wǎng)的基礎(chǔ)，也是手機(jī)聯(lián)網(wǎng)常用的協(xié)議之一，HTTP協(xié)議是建立在TCP協(xié)議之上的一種應(yīng)用。HTTP連接最顯著的特點(diǎn)是客戶端發(fā)送的每次請(qǐng)求都需要服務(wù)器回送響應(yīng)，在請(qǐng)求結(jié)束后，會(huì)主動(dòng)釋放連接。從建立連接到關(guān)閉連接的過(guò)程稱為“一次連接”。
1）在HTTP 1.0中，客戶端的每次請(qǐng)求都要求建立一次單獨(dú)的連接，在處理完本次請(qǐng)求后，就自動(dòng)釋放連接。2）在HTTP 1.1中則可以在一次連接中處理多個(gè)請(qǐng)求，并且多個(gè)請(qǐng)求可以重疊進(jìn)行，不需要等待一個(gè)請(qǐng)求結(jié)束后再發(fā)送下一個(gè)請(qǐng)求。由于HTTP在每次請(qǐng)求結(jié)束后都會(huì)主動(dòng)釋放連接，因此HTTP連接是一種“短連接”，要保持客戶端程序的在線狀態(tài)，需要不斷地向服務(wù)器發(fā)起連接求。通常 的做法是即時(shí)不需要獲得任何數(shù)據(jù)，客戶端也保持每隔一段固定的時(shí)間向服務(wù)器發(fā)送一次“保持連接”的請(qǐng)求，服務(wù)器在收到該請(qǐng)求后對(duì)客戶端進(jìn)行回復(fù)，表明知道客戶端“在線”。若服務(wù)器長(zhǎng)時(shí)間無(wú)法收到客戶端的請(qǐng)求，則認(rèn)為客戶端“下線”，若客戶端長(zhǎng)時(shí)間無(wú)法收到服務(wù)器的回復(fù)，則認(rèn)為網(wǎng)絡(luò)已經(jīng)斷開。
進(jìn)過(guò)TCP3次握手之后，瀏覽器發(fā)起了http的請(qǐng)求，使用的http的方法 GET 方法，請(qǐng)求的URL是 / ,協(xié)議是HTTP/1.0。那么HTTP請(qǐng)求報(bào)文和響應(yīng)報(bào)文會(huì)是什么格式呢？
起始行：如 GET / HTTP/1.0 （請(qǐng)求的方法、請(qǐng)求的URL 請(qǐng)求所使用的協(xié)議）
頭部信息：User-Agent Host等成對(duì)出現(xiàn)的值
主體
起始行中的請(qǐng)求方法有以下：
GET
GET是http的默認(rèn)請(qǐng)求方式，一般用來(lái)獲取數(shù)據(jù)，傳輸?shù)臄?shù)據(jù)經(jīng)過(guò)url編碼后放在路徑?之后，多個(gè)鍵值對(duì)通過(guò)&連接，另外get的傳輸長(zhǎng)度一般不推薦超過(guò)255個(gè)字節(jié)。
GET方法一般被視為安全方法， 因?yàn)樗鼉H用來(lái)獲取數(shù)據(jù)而不會(huì)對(duì)服務(wù)器有其他改動(dòng)。像HEAD、GET、OPTIONS 和 TRACE這幾種http方法是被認(rèn)為是“安全的”，它們只會(huì)進(jìn)行獲取數(shù)據(jù)而不會(huì)修改服務(wù)器的狀態(tài)，可用于記錄日志、創(chuàng)建緩存或者創(chuàng)建其他統(tǒng)計(jì)信息。相反，像POST、PUT、DELETE 和 PATCH 等方法是有可能產(chǎn)生副作用。網(wǎng)絡(luò)爬蟲等一般不會(huì)使用這些方式
POST
POST一般用來(lái)上傳文件或者提交一個(gè)完整的web表單。瀏覽器中提交表單時(shí)，這里與get類似，每個(gè)鍵值對(duì)都是通過(guò)&分割, 其他非字母數(shù)字會(huì)進(jìn)行url轉(zhuǎn)碼。
為什么一些請(qǐng)求會(huì)使用POST提交數(shù)據(jù)?
GET請(qǐng)求數(shù)據(jù)都可以在URL中看到
GET提交的數(shù)據(jù)都會(huì)有長(zhǎng)度限制
一般規(guī)范，POST用來(lái)修改數(shù)據(jù)，GET用來(lái)獲取數(shù)據(jù)
GET請(qǐng)求提交的數(shù)據(jù)放置在HTTP請(qǐng)求協(xié)議頭中，而POST提交的數(shù)據(jù)放在實(shí)體數(shù)據(jù)中
其他請(qǐng)求方式
HEAD獲取某個(gè)URI響應(yīng)頭信息，基本與GET相同但是不返回響應(yīng)主體。
PUT通過(guò)提供的URI獲取到特定的內(nèi)容主體，如果存在則修改內(nèi)容，如果不存在則創(chuàng)建。
DELETE通過(guò)URI刪除指定內(nèi)容
TRACE返回接受到的請(qǐng)求，用來(lái)查看數(shù)據(jù)經(jīng)過(guò)中間服務(wù)器時(shí)發(fā)生了哪些變動(dòng)
OPTIONS返回給定URL支持的所有HTTP方法
CONNECT要求使用SSL和TLS進(jìn)行TCP通信
PATCH請(qǐng)求修改局部數(shù)據(jù)
那什么是****URL****、****URI****、****URN****？
URI Uniform Resource Identifier 統(tǒng)一資源標(biāo)識(shí)符
URL Uniform Resource Locator 統(tǒng)一資源定位符
格式如下： scheme://[username:password@]HOST:port/path/to/source
http://www.magedu.com/downloads/nginx-1.5.tar.gz
URN Uniform Resource Name 統(tǒng)一資源名稱。URL和URN 都屬于 URI。為了方便就把URL和URI暫時(shí)都通指一個(gè)東西
下面是Chrome發(fā)起的http請(qǐng)求報(bào)文頭部信息：
Accept 就是告訴服務(wù)器端，我接受那些MIME類型
Accept-Encoding 這個(gè)看起來(lái)是接受那些壓縮方式的文件
Accept-Lanague 告訴服務(wù)器能夠發(fā)送哪些語(yǔ)言
Connection 告訴服務(wù)器支持keep-alive特性
Cookie 每次請(qǐng)求時(shí)都會(huì)攜帶上Cookie以方便服務(wù)器端識(shí)別是否是同一個(gè)客戶端
Host 用來(lái)標(biāo)識(shí)請(qǐng)求服務(wù)器上的那個(gè)虛擬主機(jī)，比如Nginx里面可以定義很多個(gè)虛擬主機(jī)．那這里就是用來(lái)標(biāo)識(shí)要訪問(wèn)那個(gè)虛擬主機(jī)。
User-Agent 用戶代理，一般情況是瀏覽器，也有其他類型，如：wget curl 搜索引擎的蜘蛛等
條件請(qǐng)求首部：
If-Modified-Since 是瀏覽器向服務(wù)器端詢問(wèn)某個(gè)資源文件如果自從什么時(shí)間修改過(guò)，那么重新發(fā)給我，這樣就保證服務(wù)器端資源．文件更新時(shí)，瀏覽器再次去請(qǐng)求，而不是使用緩存中的文件
安全請(qǐng)求首部：
Authorization: 客戶端提供給服務(wù)器的認(rèn)證信息；
什么是****MIME****？
MIME（Multipurpose Internet Mail Extesions 多用途互聯(lián)網(wǎng)郵件擴(kuò)展）是一個(gè)互聯(lián)網(wǎng)標(biāo)準(zhǔn)，它擴(kuò)展了電子郵件標(biāo)準(zhǔn)，使其能夠支持非ASCII字符、二進(jìn)制格式附件等多種格式的郵件消息，這個(gè)標(biāo)準(zhǔn)被定義在RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049等RFC中。 由RFC 822轉(zhuǎn)變而來(lái)的RFC 2822，規(guī)定電子郵件標(biāo)準(zhǔn)并不允許在郵件消息中使用7位ASCII字符集以外的字符。正因如此，一些非英語(yǔ)字符消息和二進(jìn)制文件，圖像，聲音等非文字消息都不能在電子郵件中傳輸。MIME規(guī)定了用于表示各種各樣的數(shù)據(jù)類型的符號(hào)化方法。 此外，在萬(wàn)維網(wǎng)中使用的HTTP協(xié)議中也使用了MIME的框架，標(biāo)準(zhǔn)被擴(kuò)展為互聯(lián)網(wǎng)媒體類型。
MIME 遵循以下格式：major/minor 主類型/次類型 例如：
image/jpg
image/gif
text/html
video/quicktime
appliation/x-httpd-php
四.服務(wù)器端響應(yīng)http請(qǐng)求，瀏覽器得到html代碼
服務(wù)器端WEB程序接收到http請(qǐng)求以后，就開始處理該請(qǐng)求，處理之后就返回給瀏覽器html文件。
1xx: 信息性狀態(tài)碼
100, 101
2xx: 成功狀態(tài)碼
200：OK
3xx: 重定向狀態(tài)碼
301: 永久重定向, Location響應(yīng)首部的值仍為當(dāng)前URL，因此為隱藏重定向;
302: 臨時(shí)重定向，顯式重定向, Location響應(yīng)首部的值為新的URL
304：Not Modified 未修改，比如本地緩存的資源文件和服務(wù)器上比較時(shí)，發(fā)現(xiàn)并沒(méi)有修改，服務(wù)器返回一個(gè)304狀態(tài)碼，告訴瀏覽器，你不用請(qǐng)求該資源，直接使用本地的資源即可。
4xx: 客戶端錯(cuò)誤狀態(tài)碼
404: Not Found 請(qǐng)求的URL資源并不存在
5xx: 服務(wù)器端錯(cuò)誤狀態(tài)碼
500: Internal Server Error 服務(wù)器內(nèi)部錯(cuò)誤
502: Bad Gateway 前面代理服務(wù)器聯(lián)系不到后端的服務(wù)器時(shí)出現(xiàn)
504：Gateway Timeout 這個(gè)是代理能聯(lián)系到后端的服務(wù)器，但是后端的服務(wù)器在規(guī)定的時(shí)間內(nèi)沒(méi)有給代理服務(wù)器響應(yīng)
用Chrome瀏覽器看到的響應(yīng)頭信息：
Connection 使用keep-alive特性
Content-Encoding 使用gzip方式對(duì)資源壓縮
Content-type MIME類型為html類型，字符集是 UTF-8
Date 響應(yīng)的日期
Server 使用的WEB服務(wù)器
Transfer-Encoding:chunked 分塊傳輸編碼 是http中的一種數(shù)據(jù)傳輸機(jī)制，允許HTTP由網(wǎng)頁(yè)服務(wù)器發(fā)送給客戶端應(yīng)用（通常是網(wǎng)頁(yè)瀏覽器）的數(shù)據(jù)可以分成多個(gè)部分，分塊傳輸編碼只在HTTP協(xié)議1.1版本（HTTP/1.1）中提供
五. 瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源
瀏覽器拿到index.html文件后，就開始解析其中的html代碼，遇到j(luò)s/css/image等靜態(tài)資源時(shí)，就向服務(wù)器端去請(qǐng)求下載（會(huì)使用多線程下載，每個(gè)瀏覽器的線程數(shù)不一樣），這個(gè)時(shí)候就用上keep-alive特性了，建立一次HTTP連接，可以請(qǐng)求多個(gè)資源，下載資源的順序就是按照代碼里的順序，但是由于每個(gè)資源大小不一樣，而瀏覽器又多線程請(qǐng)求請(qǐng)求資源，順序并不一定是代碼里面的順序。
瀏覽器在請(qǐng)求靜態(tài)資源時(shí)（在未過(guò)期的情況下），向服務(wù)器端發(fā)起一個(gè)http請(qǐng)求（詢問(wèn)自從上一次修改時(shí)間到現(xiàn)在有沒(méi)有對(duì)資源進(jìn)行修改），如果服務(wù)器端返回304狀態(tài)碼（告訴瀏覽器服務(wù)器端沒(méi)有修改），那么瀏覽器會(huì)直接讀取本地的該資源的緩存文件。
六.瀏覽器對(duì)頁(yè)面進(jìn)行渲染呈現(xiàn)給用戶
最后，瀏覽器把請(qǐng)求到的靜態(tài)資源和html代碼進(jìn)行渲染，呈現(xiàn)給用戶。
總結(jié)
域名解析 --> 發(fā)起TCP的3次握手 --> 建立TCP連接后發(fā)起http請(qǐng)求 --> 服務(wù)器響應(yīng)http請(qǐng)求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對(duì)頁(yè)面進(jìn)行渲染呈現(xiàn)給用戶
