閱讀目錄

• 輸入地址
• 瀏覽器查找域名的 IP 地址
• 瀏覽器向 web 服務(wù)器發(fā)送一個(gè) HTTP 請(qǐng)求
• 服務(wù)器的***重定向響應(yīng)
• 瀏覽器跟蹤重定向地址
• 服務(wù)器處理請(qǐng)求
• 服務(wù)器返回一個(gè) HTTP 響應(yīng)
• 瀏覽器顯示 HTML
• 瀏覽器發(fā)送請(qǐng)求獲取嵌入在 HTML 中的資源(如圖片、音頻、視頻、CSS、JS等等)

剛開始寫這篇文章還是挺糾結(jié)的，因?yàn)榫W(wǎng)上搜索“從輸入url到頁面展示到底發(fā)生了什么”，你可以搜到一大堆的資料。而且面試這道題基本是必考題，二月份面試的時(shí)候，雖然知道這個(gè)過程發(fā)生了什么，不過當(dāng)面試官一步步追問下去的，很多細(xì)節(jié)就不太清楚了。

最近剛好也在看http協(xié)議相關(guān)的東西，所以想對(duì)這個(gè)話題來個(gè)深入的總結(jié)，本文的目的是通過輸入url之后發(fā)生的事情來做知識(shí)的總結(jié)和擴(kuò)展。所以文章可能會(huì)很雜。

總的過程大概如下:

1、輸入地址

當(dāng)我們開始在瀏覽器中輸入網(wǎng)址的時(shí)候，瀏覽器其實(shí)就已經(jīng)在智能的匹配可能得 url 了，他會(huì)從歷史記錄，書簽等地方，找到已經(jīng)輸入的字符串可能對(duì)應(yīng)的 url，然后給出智能提示，讓你可以補(bǔ)全url地址。對(duì)于 google的chrome 的瀏覽器，他甚至?xí)苯訌木彺嬷邪丫W(wǎng)頁展示出來，就是說，你還沒有按下 enter，頁面就出來了。

2、瀏覽器查找域名的 IP 地址

1)、請(qǐng)求一旦發(fā)起，瀏覽器首先要做的事情就是解析這個(gè)域名，一般來說，瀏覽器會(huì)首先查看本地硬盤的 hosts 文件，看看其中有沒有和這個(gè)域名對(duì)應(yīng)的規(guī)則，如果有的話就直接使用 hosts 文件里面的 ip 地址。

2)、如果在本地的 hosts 文件沒有能夠找到對(duì)應(yīng)的 ip 地址，瀏覽器會(huì)發(fā)出一個(gè) DNS請(qǐng)求到本地DNS服務(wù)器 。本地DNS服務(wù)器一般都是你的網(wǎng)絡(luò)接入服務(wù)器商提供，比如中國電信，中國移動(dòng)。

3)、查詢你輸入的網(wǎng)址的DNS請(qǐng)求到達(dá)本地DNS服務(wù)器之后，本地DNS服務(wù)器會(huì)首先查詢它的緩存記錄，如果緩存中有此條記錄，就可以直接返回結(jié)果，此過程是遞歸的方式進(jìn)行查詢。如果沒有，本地DNS服務(wù)器還要向DNS根服務(wù)器進(jìn)行查詢。

4)、根DNS服務(wù)器沒有記錄具體的域名和IP地址的對(duì)應(yīng)關(guān)系，而是告訴本地DNS服務(wù)器，你可以到域服務(wù)器上去繼續(xù)查詢，并給出域服務(wù)器的地址。這種過程是迭代的過程。

5)、本地DNS服務(wù)器繼續(xù)向域服務(wù)器發(fā)出請(qǐng)求，在這個(gè)例子中，請(qǐng)求的對(duì)象是.com域服務(wù)器。.com域服務(wù)器收到請(qǐng)求之后，也不會(huì)直接返回域名和IP地址的對(duì)應(yīng)關(guān)系，而是告訴本地DNS服務(wù)器，你的域名的解析服務(wù)器的地址。

6)、***，本地DNS服務(wù)器向域名的解析服務(wù)器發(fā)出請(qǐng)求，這時(shí)就能收到一個(gè)域名和IP地址對(duì)應(yīng)關(guān)系，本地DNS服務(wù)器不僅要把IP地址返回給用戶電腦，還要把這個(gè)對(duì)應(yīng)關(guān)系保存在緩存中，以備下次別的用戶查詢時(shí)，可以直接返回結(jié)果，加快網(wǎng)絡(luò)訪問。

下面這張圖很***的解釋了這一過程：   

 

知識(shí)擴(kuò)展：

1).什么是DNS?

DNS(Domain Name System，域名系統(tǒng))，因特網(wǎng)上作為域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫，能夠使用戶更方便的訪問互聯(lián)網(wǎng)，而不用去記住能夠被機(jī)器直接讀取的IP數(shù)串。通過主機(jī)名，最終得到該主機(jī)名對(duì)應(yīng)的IP地址的過程叫做域名解析(或主機(jī)名解析)。

通俗的講，我們更習(xí)慣于記住一個(gè)網(wǎng)站的名字，比如www.baidu.com,而不是記住它的ip地址，比如：167.23.10.2。而計(jì)算機(jī)更擅長記住網(wǎng)站的ip地址，而不是像www.baidu.com等鏈接。因?yàn)?，DNS就相當(dāng)于一個(gè)電話本，比如你要找www.baidu.com這個(gè)域名，那我翻一翻我的電話本，我就知道，哦，它的電話(ip)是167.23.10.2。

2).DNS查詢的兩種方式：遞歸查詢和迭代查詢

a、遞歸解析

當(dāng)局部DNS服務(wù)器自己不能回答客戶機(jī)的DNS查詢時(shí)，它就需要向其他DNS服務(wù)器進(jìn)行查詢。此時(shí)有兩種方式，如圖所示的是遞歸方式。局部DNS服務(wù)器自己負(fù)責(zé)向其他DNS服務(wù)器進(jìn)行查詢，一般是先向該域名的根域服務(wù)器查詢，再由根域名服務(wù)器一級(jí)級(jí)向下查詢。***得到的查詢結(jié)果返回給局部DNS服務(wù)器，再由局部DNS服務(wù)器返回給客戶端。   

 

b、迭代解析

當(dāng)局部DNS服務(wù)器自己不能回答客戶機(jī)的DNS查詢時(shí)，也可以通過迭代查詢的方式進(jìn)行解析，如圖所示。局部DNS服務(wù)器不是自己向其他DNS服務(wù)器進(jìn)行查詢，而是把能解析該域名的其他DNS服務(wù)器的IP地址返回給客戶端DNS程序，客戶端DNS程序再繼續(xù)向這些DNS服務(wù)器進(jìn)行查詢，直到得到查詢結(jié)果為止。也就是說，迭代解析只是幫你找到相關(guān)的服務(wù)器而已，而不會(huì)幫你去查。比如說：baidu.com的服務(wù)器ip地址在192.168.4.5這里，你自己去查吧，本人比較忙，只能幫你到這里了。   

 

3).DNS域名稱空間的組織方式

我們?cè)谇懊嬗姓f到根DNS服務(wù)器，域DNS服務(wù)器，這些都是DNS域名稱空間的組織方式。按其功能命名空間中用來描述 DNS 域名稱的五個(gè)類別的介紹詳見下表中，以及與每個(gè)名稱類型的示例 

(盜圖) 

4)DNS負(fù)載均衡

當(dāng)一個(gè)網(wǎng)站有足夠多的用戶的時(shí)候，假如每次請(qǐng)求的資源都位于同一臺(tái)機(jī)器上面，那么這臺(tái)機(jī)器隨時(shí)可能會(huì)蹦掉。處理辦法就是用DNS負(fù)載均衡技術(shù)，它的原理是在DNS服務(wù)器中為同一個(gè)主機(jī)名配置多個(gè)IP地址,在應(yīng)答DNS查詢時(shí),DNS服務(wù)器對(duì)每個(gè)查詢將以DNS文件中主機(jī)記錄的IP地址按順序返回不同的解析結(jié)果,將客戶端的訪問引導(dǎo)到不同的機(jī)器上去,使得不同的客戶端訪問不同的服務(wù)器,從而達(dá)到負(fù)載均衡的目的｡例如可以根據(jù)每臺(tái)機(jī)器的負(fù)載量，該機(jī)器離用戶地理位置的距離等等。

3、瀏覽器向 web 服務(wù)器發(fā)送一個(gè) HTTP 請(qǐng)求

拿到域名對(duì)應(yīng)的IP地址之后，瀏覽器會(huì)以一個(gè)隨機(jī)端口(1024<端口<65535)向服務(wù)器的WEB程序(常用的有httpd,nginx等)80端口發(fā)起TCP的連接請(qǐng)求。這個(gè)連接請(qǐng)求到達(dá)服務(wù)器端后(這中間通過各種路由設(shè)備，局域網(wǎng)內(nèi)除外)，進(jìn)入到網(wǎng)卡，然后是進(jìn)入到內(nèi)核的TCP/IP協(xié)議棧(用于識(shí)別該連接請(qǐng)求，解封包，一層一層的剝開)，還有可能要經(jīng)過Netfilter防火墻(屬于內(nèi)核的模塊)的過濾，最終到達(dá)WEB程序，最終建立了TCP/IP的連接。

TCP連接如圖所示:   

 

建立了TCP連接之后，發(fā)起一個(gè)http請(qǐng)求。一個(gè)典型的 http request header 一般需要包括請(qǐng)求的方法，例如 GET 或者 POST 等，不常用的還有 PUT 和 DELETE 、HEAD、OPTION以及 TRACE 方法，一般的瀏覽器只能發(fā)起 GET 或者 POST 請(qǐng)求。

客戶端向服務(wù)器發(fā)起http請(qǐng)求的時(shí)候，會(huì)有一些請(qǐng)求信息，請(qǐng)求信息包含三個(gè)部分：

| 請(qǐng)求方法URI協(xié)議/版本

| 請(qǐng)求頭(Request Header)

| 請(qǐng)求正文：

下面是一個(gè)完整的HTTP請(qǐng)求例子：

GET/sample.jspHTTP/1.1   Accept:image/gif.image/jpeg,*/*    
Accept-Language:zh-cn    
Connection:Keep-Alive    
Host:localhost    
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)    
Accept-Encoding:gzip,deflate    
 
username=jinqiao&password=1234  

注意：***一個(gè)請(qǐng)求頭之后是一個(gè)空行，發(fā)送回車符和換行符，通知服務(wù)器以下不再有請(qǐng)求頭。

(1)請(qǐng)求的***行是“方法URL議/版本”：GET/sample.jsp HTTP/1.1

(2)請(qǐng)求頭(Request Header)

請(qǐng)求頭包含許多有關(guān)的客戶端環(huán)境和請(qǐng)求正文的有用信息。例如，請(qǐng)求頭可以聲明瀏覽器所用的語言，請(qǐng)求正文的長度等。

Accept:image/gif.image/jpeg.*/*    
Accept-Language:zh-cn    
Connection:Keep-Alive    
Host:localhost    
User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)    
Accept-Encoding:gzip,deflate.  

(3)請(qǐng)求正文

請(qǐng)求頭和請(qǐng)求正文之間是一個(gè)空行，這個(gè)行非常重要，它表示請(qǐng)求頭已經(jīng)結(jié)束，接下來的是請(qǐng)求正文。請(qǐng)求正文中可以包含客戶提交的查詢字符串信息：

username=jinqiao&password=1234 

知識(shí)擴(kuò)展：

1)TCP三次握手

***次握手：客戶端A將標(biāo)志位SYN置為1,隨機(jī)產(chǎn)生一個(gè)值為seq=J(J的取值范圍為=1234567)的數(shù)據(jù)包到服務(wù)器，客戶端A進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)端B確認(rèn);

第二次握手：服務(wù)端B收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道客戶端A請(qǐng)求建立連接，服務(wù)端B將標(biāo)志位SYN和ACK都置為1，ack=J+1，隨機(jī)產(chǎn)生一個(gè)值seq=K，并將該數(shù)據(jù)包發(fā)送給客戶端A以確認(rèn)連接請(qǐng)求，服務(wù)端B進(jìn)入SYN_RCVD狀態(tài)。

第三次握手：客戶端A收到確認(rèn)后，檢查ack是否為J+1，ACK是否為1，如果正確則將標(biāo)志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給服務(wù)端B，服務(wù)端B檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端A和服務(wù)端B進(jìn)入ESTABLISHED狀態(tài)，完成三次握手，隨后客戶端A與服務(wù)端B之間可以開始傳輸數(shù)據(jù)了。

如圖所示：   

 

2)為什需要三次握手?

《計(jì)算機(jī)網(wǎng)絡(luò)》第四版中講“三次握手”的目的是“為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤”

書中的例子是這樣的，“已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的***個(gè)連接請(qǐng)求報(bào)文段并沒有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接

假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒有要求建立連接。”。主要目的防止server端一直等待，浪費(fèi)資源。

3)TCP四次揮手

***次揮手：Client發(fā)送一個(gè)FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進(jìn)入FIN_WAIT_1狀態(tài)。

第二次揮手：Server收到FIN后，發(fā)送一個(gè)ACK給Client，確認(rèn)序號(hào)為收到序號(hào)+1(與SYN相同，一個(gè)FIN占用一個(gè)序號(hào))，Server進(jìn)入CLOSE_WAIT狀態(tài)。

第三次揮手：Server發(fā)送一個(gè)FIN，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入LAST_ACK狀態(tài)。

第四次揮手：Client收到FIN后，Client進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送一個(gè)ACK給Server，確認(rèn)序號(hào)為收到序號(hào)+1，Server進(jìn)入CLOSED狀態(tài)，完成四次揮手。   

 

4)為什么建立連接是三次握手，而關(guān)閉連接卻是四次揮手呢?

這是因?yàn)榉?wù)端在LISTEN狀態(tài)下，收到建立連接請(qǐng)求的SYN報(bào)文后，把ACK和SYN放在一個(gè)報(bào)文里發(fā)送給客戶端。而關(guān)閉連接時(shí)，當(dāng)收到對(duì)方的FIN報(bào)文時(shí)，僅僅表示對(duì)方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，己方也未必全部數(shù)據(jù)都發(fā)送給對(duì)方了，所以己方可以立即close，也可以發(fā)送一些數(shù)據(jù)給對(duì)方后，再發(fā)送FIN報(bào)文給對(duì)方來表示同意現(xiàn)在關(guān)閉連接，因此，己方ACK和FIN一般都會(huì)分開發(fā)送。

4、服務(wù)器的***重定向響應(yīng)

服務(wù)器給瀏覽器響應(yīng)一個(gè)301***重定向響應(yīng)，這樣瀏覽器就會(huì)訪問“http://www.google.com/” 而非“http://google.com/”。

為什么服務(wù)器一定要重定向而不是直接發(fā)送用戶想看的網(wǎng)頁內(nèi)容呢?其中一個(gè)原因跟搜索引擎排名有關(guān)。如果一個(gè)頁面有兩個(gè)地址，就像http://www.yy.com/和http://yy.com/，搜索引擎會(huì)認(rèn)為它們是兩個(gè)網(wǎng)站，結(jié)果造成每個(gè)搜索鏈接都減少從而降低排名。而搜索引擎知道301***重定向是什么意思，這樣就會(huì)把訪問帶www的和不帶www的地址歸到同一個(gè)網(wǎng)站排名下。還有就是用不同的地址會(huì)造成緩存友好性變差，當(dāng)一個(gè)頁面有好幾個(gè)名字時(shí)，它可能會(huì)在緩存里出現(xiàn)好幾次。

擴(kuò)展知識(shí)

1)301和302的區(qū)別。

301和302狀態(tài)碼都表示重定向，就是說瀏覽器在拿到服務(wù)器返回的這個(gè)狀態(tài)碼后會(huì)自動(dòng)跳轉(zhuǎn)到一個(gè)新的URL地址，這個(gè)地址可以從響應(yīng)的Location首部中獲取(用戶看到的效果就是他輸入的地址A瞬間變成了另一個(gè)地址B)——這是它們的共同點(diǎn)。

他們的不同在于。301表示舊地址A的資源已經(jīng)被***地移除了(這個(gè)資源不可訪問了)，搜索引擎在抓取新內(nèi)容的同時(shí)也將舊的網(wǎng)址交換為重定向之后的網(wǎng)址;

302表示舊地址A的資源還在(仍然可以訪問)，這個(gè)重定向只是臨時(shí)地從舊地址A跳轉(zhuǎn)到地址B，搜索引擎會(huì)抓取新的內(nèi)容而保存舊的網(wǎng)址。 SEO302好于301

2)重定向原因：

(1)網(wǎng)站調(diào)整(如改變網(wǎng)頁目錄結(jié)構(gòu));

(2)網(wǎng)頁被移到一個(gè)新地址;

(3)網(wǎng)頁擴(kuò)展名改變(如應(yīng)用需要把.php改成.Html或.shtml)。

這種情況下，如果不做重定向，則用戶收藏夾或搜索引擎數(shù)據(jù)庫中舊地址只能讓訪問客戶得到一個(gè)404頁面錯(cuò)誤信息，訪問流量白白喪失;再者某些注冊(cè)了多個(gè)域名的網(wǎng)站，也需要通過重定向讓訪問這些域名的用戶自動(dòng)跳轉(zhuǎn)到主站點(diǎn)等。

3)什么時(shí)候進(jìn)行301或者302跳轉(zhuǎn)呢?

當(dāng)一個(gè)網(wǎng)站或者網(wǎng)頁24—48小時(shí)內(nèi)臨時(shí)移動(dòng)到一個(gè)新的位置，這時(shí)候就要進(jìn)行302跳轉(zhuǎn)，而使用301跳轉(zhuǎn)的場(chǎng)景就是之前的網(wǎng)站因?yàn)槟撤N原因需要移除掉，然后要到新的地址訪問，是***性的。

清晰明確而言：使用301跳轉(zhuǎn)的大概場(chǎng)景如下：

• 域名到期不想續(xù)費(fèi)(或者發(fā)現(xiàn)了更適合網(wǎng)站的域名)，想換個(gè)域名。
• 在搜索引擎的搜索結(jié)果中出現(xiàn)了不帶www的域名，而帶www的域名卻沒有收錄，這個(gè)時(shí)候可以用301重定向來告訴搜索引擎我們目標(biāo)的域名是哪一個(gè)。
• 空間服務(wù)器不穩(wěn)定，換空間的時(shí)候。
• 瀏覽器跟蹤重定向地址

現(xiàn)在瀏覽器知道了 "http://www.google.com/"才是要訪問的正確地址，所以它會(huì)發(fā)送另一個(gè)http請(qǐng)求。這里沒有啥好說的

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

經(jīng)過前面的重重步驟，我們終于將我們的http請(qǐng)求發(fā)送到了服務(wù)器這里，其實(shí)前面的重定向已經(jīng)是到達(dá)服務(wù)器了，那么，服務(wù)器是如何處理我們的請(qǐng)求的呢?

后端從在固定的端口接收到TCP報(bào)文開始，它會(huì)對(duì)TCP連接進(jìn)行處理，對(duì)HTTP協(xié)議進(jìn)行解析，并按照?qǐng)?bào)文格式進(jìn)一步封裝成HTTP Request對(duì)象，供上層使用。

一些大一點(diǎn)的網(wǎng)站會(huì)將你的請(qǐng)求到反向代理服務(wù)器中，因?yàn)楫?dāng)網(wǎng)站訪問量非常大，網(wǎng)站越來越慢，一臺(tái)服務(wù)器已經(jīng)不夠用了。于是將同一個(gè)應(yīng)用部署在多臺(tái)服務(wù)器上，將大量用戶的請(qǐng)求分配給多臺(tái)機(jī)器處理。此時(shí)，客戶端不是直接通過HTTP協(xié)議訪問某網(wǎng)站應(yīng)用服務(wù)器，而是先請(qǐng)求到Nginx，Nginx再請(qǐng)求應(yīng)用服務(wù)器，然后將結(jié)果返回給客戶端，這里Nginx的作用是反向代理服務(wù)器。同時(shí)也帶來了一個(gè)好處，其中一臺(tái)服務(wù)器萬一掛了，只要還有其他服務(wù)器正常運(yùn)行，就不會(huì)影響用戶使用。

如圖所示：  

 

通過Nginx的反向代理，我們到達(dá)了web服務(wù)器，服務(wù)端腳本處理我們的請(qǐng)求，訪問我們的數(shù)據(jù)庫，獲取需要獲取的內(nèi)容等等，當(dāng)然，這個(gè)過程涉及很多后端腳本的復(fù)雜操作。由于對(duì)這一塊不熟，所以這一塊只能介紹這么多了。

擴(kuò)展閱讀：

1)什么是反向代理?

客戶端本來可以直接通過HTTP協(xié)議訪問某網(wǎng)站應(yīng)用服務(wù)器，網(wǎng)站管理員可以在中間加上一個(gè)Nginx，客戶端請(qǐng)求Nginx，Nginx請(qǐng)求應(yīng)用服務(wù)器，然后將結(jié)果返回給客戶端，此時(shí)Nginx就是反向代理服務(wù)器。  

 

 

7、服務(wù)器返回一個(gè) HTTP 響應(yīng)

經(jīng)過前面的6個(gè)步驟，服務(wù)器收到了我們的請(qǐng)求，也處理我們的請(qǐng)求，到這一步，它會(huì)把它的處理結(jié)果返回，也就是返回一個(gè)HTPP響應(yīng)。

HTTP響應(yīng)與HTTP請(qǐng)求相似，HTTP響應(yīng)也由3個(gè)部分構(gòu)成，分別是：

l 狀態(tài)行

l 響應(yīng)頭(Response Header)

l 響應(yīng)正文

HTTP/1.1 200 OK    
Date: Sat, 31 Dec 2005 23:59:59 GMT    
Content-Type: text/html;charset=ISO-8859-1   Content-Length: 122   ＜html＞    
＜head＞    
＜title＞http＜/title＞    
＜/head＞    
＜body＞    
＜!-- body goes here --＞    
＜/body＞    
＜/html＞  

狀態(tài)行：

狀態(tài)行由協(xié)議版本、數(shù)字形式的狀態(tài)代碼、及相應(yīng)的狀態(tài)描述，各元素之間以空格分隔。

格式: HTTP-Version Status-Code Reason-Phrase CRLF

例如: HTTP/1.1 200 OK \r\n

-- 協(xié)議版本：是用http1.0還是其他版本

-- 狀態(tài)描述：狀態(tài)描述給出了關(guān)于狀態(tài)代碼的簡(jiǎn)短的文字描述。比如狀態(tài)代碼為200時(shí)的描述為 ok

-- 狀態(tài)代碼：狀態(tài)代碼由三位數(shù)字組成，***個(gè)數(shù)字定義了響應(yīng)的類別，且有五種可能取值。如下

1xx：信息性狀態(tài)碼，表示服務(wù)器已接收了客戶端請(qǐng)求，客戶端可繼續(xù)發(fā)送請(qǐng)求。

100 Continue

101 Switching Protocols

2xx：成功狀態(tài)碼，表示服務(wù)器已成功接收到請(qǐng)求并進(jìn)行處理。200 OK 表示客戶端請(qǐng)求成功

204 No Content 成功，但不返回任何實(shí)體的主體部分

206 Partial Content 成功執(zhí)行了一個(gè)范圍(Range)請(qǐng)求

3xx：重定向狀態(tài)碼，表示服務(wù)器要求客戶端重定向。

301 Moved Permanently ***性重定向，響應(yīng)報(bào)文的Location首部應(yīng)該有該資源的新URL

302 Found 臨時(shí)性重定向，響應(yīng)報(bào)文的Location首部給出的URL用來臨時(shí)定位資源

303 See Other 請(qǐng)求的資源存在著另一個(gè)URI，客戶端應(yīng)使用GET方法定向獲取請(qǐng)求的資源

304 Not Modified 服務(wù)器內(nèi)容沒有更新，可以直接讀取瀏覽器緩存

307 Temporary Redirect 臨時(shí)重定向。與302 Found含義一樣。302禁止POST變換為GET，但實(shí)際使用時(shí)并不一定，307則更多瀏覽器可能會(huì)遵循這一標(biāo)準(zhǔn)，但也依賴于瀏覽器具體實(shí)現(xiàn)

4xx：客戶端錯(cuò)誤狀態(tài)碼，表示客戶端的請(qǐng)求有非法內(nèi)容。

400 Bad Request 表示客戶端請(qǐng)求有語法錯(cuò)誤，不能被服務(wù)器所理解

401 Unauthonzed 表示請(qǐng)求未經(jīng)授權(quán)，該狀態(tài)代碼必須與 WWW-Authenticate 報(bào)頭域一起使用

403 Forbidden 表示服務(wù)器收到請(qǐng)求，但是拒絕提供服務(wù)，通常會(huì)在響應(yīng)正文中給出不提供服務(wù)的原因

404 Not Found 請(qǐng)求的資源不存在，例如，輸入了錯(cuò)誤的URL

5xx：服務(wù)器錯(cuò)誤狀態(tài)碼，表示服務(wù)器未能正常處理客戶端的請(qǐng)求而出現(xiàn)意外錯(cuò)誤。

500 Internel Server Error 表示服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤，導(dǎo)致無法完成客戶端的請(qǐng)求

503 Service Unavailable 表示服務(wù)器當(dāng)前不能夠處理客戶端的請(qǐng)求，在一段時(shí)間之后，服務(wù)器可能會(huì)恢復(fù)正常

響應(yīng)頭：

響應(yīng)頭部：由關(guān)鍵字/值對(duì)組成，每行一對(duì)，關(guān)鍵字和值用英文冒號(hào)":"分隔，典型的響應(yīng)頭有：   

 

響應(yīng)正文

包含著我們需要的一些具體信息，比如cookie，html,image，后端返回的請(qǐng)求數(shù)據(jù)等等。這里需要注意，響應(yīng)正文和響應(yīng)頭之間有一行空格，表示響應(yīng)頭的信息到空格為止，下圖是fiddler抓到的請(qǐng)求正文，紅色框中的：響應(yīng)正文： 

 

8、瀏覽器顯示 HTML

在瀏覽器沒有完整接受全部HTML文檔時(shí)，它就已經(jīng)開始顯示這個(gè)頁面了，瀏覽器是如何把頁面呈現(xiàn)在屏幕上的呢?不同瀏覽器可能解析的過程不太一樣，這里我們只介紹webkit的渲染過程，下圖對(duì)應(yīng)的就是WebKit渲染的過程，這個(gè)過程包括：

解析html以構(gòu)建dom樹 -> 構(gòu)建render樹 -> 布局render樹 -> 繪制render樹  

 

 

瀏覽器在解析html文件時(shí)，會(huì)”自上而下“加載，并在加載過程中進(jìn)行解析渲染。在解析過程中，如果遇到請(qǐng)求外部資源時(shí)，如圖片、外鏈的CSS、iconfont等，請(qǐng)求過程是異步的，并不會(huì)影響html文檔進(jìn)行加載。

解析過程中，瀏覽器首先會(huì)解析HTML文件構(gòu)建DOM樹，然后解析CSS文件構(gòu)建渲染樹，等到渲染樹構(gòu)建完成后，瀏覽器開始布局渲染樹并將其繪制到屏幕上。這個(gè)過程比較復(fù)雜，涉及到兩個(gè)概念: reflow(回流)和repain(重繪)。

DOM節(jié)點(diǎn)中的各個(gè)元素都是以盒模型的形式存在，這些都需要瀏覽器去計(jì)算其位置和大小等，這個(gè)過程稱為relow;當(dāng)盒模型的位置,大小以及其他屬性，如顏色,字體,等確定下來之后，瀏覽器便開始繪制內(nèi)容，這個(gè)過程稱為repain。

頁面在***加載時(shí)必然會(huì)經(jīng)歷reflow和repain。reflow和repain過程是非常消耗性能的，尤其是在移動(dòng)設(shè)備上，它會(huì)破壞用戶體驗(yàn)，有時(shí)會(huì)造成頁面卡頓。所以我們應(yīng)該盡可能少的減少reflow和repain。

 

當(dāng)文檔加載過程中遇到j(luò)s文件，html文檔會(huì)掛起渲染(加載解析渲染同步)的線程，不僅要等待文檔中js文件加載完畢，還要等待解析執(zhí)行完畢，才可以恢復(fù)html文檔的渲染線程。因?yàn)镴S有可能會(huì)修改DOM，最為經(jīng)典的document.write，這意味著，在JS執(zhí)行完成前，后續(xù)所有資源的下載可能是沒有必要的，這是js阻塞后續(xù)資源下載的根本原因。所以我明平時(shí)的代碼中，js是放在html文檔末尾的。

JS的解析是由瀏覽器中的JS解析引擎完成的，比如谷歌的是V8。JS是單線程運(yùn)行，也就是說，在同一個(gè)時(shí)間內(nèi)只能做一件事，所有的任務(wù)都需要排隊(duì)，前一個(gè)任務(wù)結(jié)束，后一個(gè)任務(wù)才能開始。但是又存在某些任務(wù)比較耗時(shí)，如IO讀寫等，所以需要一種機(jī)制可以先執(zhí)行排在后面的任務(wù)，這就是：同步任務(wù)(synchronous)和異步任務(wù)(asynchronous)。

JS的執(zhí)行機(jī)制就可以看做是一個(gè)主線程加上一個(gè)任務(wù)隊(duì)列(task queue)。同步任務(wù)就是放在主線程上執(zhí)行的任務(wù)，異步任務(wù)是放在任務(wù)隊(duì)列中的任務(wù)。所有的同步任務(wù)在主線程上執(zhí)行，形成一個(gè)執(zhí)行棧;異步任務(wù)有了運(yùn)行結(jié)果就會(huì)在任務(wù)隊(duì)列中放置一個(gè)事件;腳本運(yùn)行時(shí)先依次運(yùn)行執(zhí)行棧，然后會(huì)從任務(wù)隊(duì)列里提取事件，運(yùn)行任務(wù)隊(duì)列中的任務(wù)，這個(gè)過程是不斷重復(fù)的，所以又叫做事件循環(huán)(Event loop)。具體的過程可以看我這篇文章：點(diǎn)擊這里

9、瀏覽器發(fā)送請(qǐng)求獲取嵌入在 HTML 中的資源(如圖片、音頻、視頻、CSS、JS等等)

其實(shí)這個(gè)步驟可以并列在步驟8中，在瀏覽器顯示HTML時(shí)，它會(huì)注意到需要獲取其他地址內(nèi)容的標(biāo)簽。這時(shí)，瀏覽器會(huì)發(fā)送一個(gè)獲取請(qǐng)求來重新獲得這些文件。比如我要獲取外圖片，CSS，JS文件等，類似于下面的鏈接：

圖片：http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif

CSS式樣表：http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css

JavaScript 文件：http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js

這些地址都要經(jīng)歷一個(gè)和HTML讀取類似的過程。所以瀏覽器會(huì)在DNS中查找這些域名，發(fā)送請(qǐng)求，重定向等等...

不像動(dòng)態(tài)頁面，靜態(tài)文件會(huì)允許瀏覽器對(duì)其進(jìn)行緩存。有的文件可能會(huì)不需要與服務(wù)器通訊，而從緩存中直接讀取，或者可以放到CDN中

------------分割線------------

至此，從輸入url到頁面展示的過程終于整理完了。本文前前后后整理了差不多一個(gè)星期，當(dāng)然，網(wǎng)上有很多文章的順序可能跟本文不太一樣，也是可以的。

如今已離開呆了一年的大YY，進(jìn)入了另一家公司，有很多東西在后面等著學(xué)習(xí)，有點(diǎn)小壓力的同時(shí)也有很強(qiáng)烈的興奮，哈哈。愿你在金三銀四里找到滿意的工作，干巴爹。

當(dāng)然，文筆有限，有誤之處，歡迎指出，本文參考了很多的文章，不過很多文章的鏈接不記得了，所以只列出了下面三個(gè)參考鏈接。