聲明：本文章中的說法僅是個人理解總結(jié)，不一定完全正確，但是可以有助於理解。

關(guān)於HTTP協(xié)議可以參考以下：

HTTP協(xié)議漫談  http://kb.cnblogs.com/page/140611/
HTTP協(xié)議概覽  http://www.cnblogs.com/vamei/archive/2013/05/11/3069788.html
瞭解HTTP Headers的方方面面  http://kb.cnblogs.com/page/55442/

當我們在瀏覽器的地址欄輸入 www. ，然後回車，回車這一瞬間到看到頁面到底發(fā)生了什麼呢？

域名解析 --> 發(fā)起TCP的3次握手 --> 建立TCP連接後發(fā)起http請求 --> 服務(wù)器響應(yīng)http請求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現(xiàn)給用戶

以下就是上面過程的一一分析，我們就以Chrome瀏覽器為例：

一.域名解析

首先Chrome瀏覽器會解析 www. 這個域名（準確的叫法應(yīng)該是主機名）對應(yīng)的IP地址。怎麼解析到對應(yīng)的IP地址？

1 Chrome瀏覽器 會首先搜索瀏覽器自身的DNS緩存（緩存時間比較短，大概只有1分鐘，且只能容納1000條緩存），看自身的緩存中是否有www. 對應(yīng)的條目，而且沒有過期，如果有且沒有過期則解析到此結(jié)束。
     註：我們怎麼查看Chrome自身的緩存？可以使用 chrome://net-internals/#dns 來進行查看

2 如果瀏覽器自身的緩存裡面沒有找到對應(yīng)的條目，那麼Chrome會搜索操作系統(tǒng)自身的DNS緩存,如果找到且沒有過期則停止搜索解析到此結(jié)束.
      註：怎麼查看操作系統(tǒng)自身的DNS緩存，以Windows系統(tǒng)為例，可以在命令行下使用 ipconfig /displaydns 來進行查看  

3 如果在Windows系統(tǒng)的DNS緩存也沒有找到，那麼嘗試讀取hosts文件（位於C:\Windows\System32\drivers\etc），看看這裡面有沒有該域名對應(yīng)的IP地址，如果有則解析成功。


4 如果在hosts文件中也沒有找到對應(yīng)的條目，瀏覽器就會發(fā)起一個DNS的系統(tǒng)調(diào)用，就會向本地配置的首選DNS服務(wù)器（一般是電信運營商提供的，也可以使用像Google提供的DNS服務(wù)器）發(fā)起域名解析請求（通過的是UDP協(xié)議向DNS的53端口發(fā)起請求，這個請求是遞歸的請求，也就是運營商的DNS服務(wù)器必須得提供給我們該域名的IP地址），運營商的DNS服務(wù)器首先查找自身的緩存，找到對應(yīng)的條目，且沒有過期，則解析成功。如果沒有找到對應(yīng)的條目，則有運營商的DNS代我們的瀏覽器發(fā)起迭代DNS解析請求，它首先是會找根域的DNS的IP地址（這個DNS服務(wù)器都內(nèi)置13臺根域的DNS的IP地址），找打根域的DNS地址，就會向其發(fā)起請求（請問www.這個域名的IP地址是多少啊？），根域發(fā)現(xiàn)這是一個頂級域com域的一個域名，於是就告訴運營商的DNS我不知道這個域名的IP地址，但是我知道com域的IP地址，你去找它去，於是運營商的DNS就得到了com域的IP地址，又向com域的IP地址發(fā)起了請求（請問www.這個域名的IP地址是多少?）,com域這臺服務(wù)器告訴運營商的DNS我不知道www.這個域名的IP地址，但是我知道這個域的DNS地址，你去找它去，於是運營商的DNS又向這個域名的DNS地址（這個一般就是由域名註冊商提供的，像萬網(wǎng)，新網(wǎng)等）發(fā)起請求（請問www.這個域名的IP地址是多少？），這個時候域的DNS服務(wù)器一查，誒，果真在我這裡，於是就把找到的結(jié)果發(fā)送給運營商的DNS服務(wù)器，這個時候運營商的DNS服務(wù)器就拿到了www.這個域名對應(yīng)的IP地址，並返回給Windows系統(tǒng)內(nèi)核，內(nèi)核又把結(jié)果返回給瀏覽器，終於瀏覽器拿到了www.對應(yīng)的IP地址，該進行一步的動作了。

註：一般情況下是不會進行以下步驟的

如果經(jīng)過以上的4個步驟，還沒有解析成功，那麼會進行如下步驟：

5 操作系統(tǒng)就會查找NetBIOS name Cache（NetBIOS名稱緩存，就存在客戶端電腦中的），那這個緩存有什麼東西呢？凡是最近一段時間內(nèi)和我成功通訊的計算機的計算機名和Ip地址，就都會存在這個緩存裡面。什麼情況下該步能解析成功呢？就是該名稱正好是幾分鐘前和我成功通信過，那麼這一步就可以成功解析。

6 如果第5步也沒有成功，那會查詢WINS 服務(wù)器（是NETBIOS名稱和IP地址對應(yīng)的服務(wù)器）

7 如果第6步也沒有查詢成功，那麼客戶端就要進行廣播查找

8 如果第7步也沒有成功，那麼客戶端就讀取LMHOSTS文件（和HOSTS文件同一個目錄下，寫法也一樣）

如果第八步還沒有解析成功，那麼就宣告這次解析失敗，那就無法跟目標計算機進行通信。只要這八步中有一步可以解析成功，那就可以成功和目標計算機進行通信。

看下圖抓包截圖：
Linux虛擬機測試，使用命令 wget www. 來請求，發(fā)現(xiàn)直接使用chrome瀏覽器請求時，干擾請求比較多，所以就使用wget命令來請求，不過使用wget命令只能把index.html請求回來，並不會對index.html中包含的靜態(tài)資源（js、css等文件）進行請求。

抓包分析：

1 號包，這個是那臺虛擬機在廣播，要獲取192.168.100.254（也就是網(wǎng)關(guān)）的MAC地址，因為局域網(wǎng)的通信靠的是MAC地址，它為什麼需要跟網(wǎng)關(guān)進行通信是因為我們的DNS服務(wù)器IP是外圍IP，要出去必須要依靠網(wǎng)關(guān)幫我們出去才行。
2 號包，這個是網(wǎng)關(guān)收到了虛擬機的廣播之後，回應(yīng)給虛擬機的回應(yīng)，告訴虛擬機自己的MAC地址，於是客戶端找到了路由出口。

3 號包，這個包是wget命令向系統(tǒng)配置的DNS服務(wù)器提出域名解析請求（準確的說應(yīng)該是wget發(fā)起了一個DNS解析的系統(tǒng)調(diào)用），請求的域名www.,期望得到的是IP6的地址（AAAA代表的是IPv6地址）
4 號包，這個DNS服務(wù)器給系統(tǒng)的響應(yīng)，很顯然目前使用IPv6的還是極少數(shù)，所以得不到AAAA記錄的
5 號包，這個還是請求解析IPv6地址，但是www..leo.com這個主機名是不存在的，所以得到結(jié)果就是no such name

6 號包，這個才是請求的域名對應(yīng)的IPv4地址（A記錄）
7 號包，DNS服務(wù)器不管是從緩存裡面，還是進行迭代查詢最終得到了域名的IP地址，響應(yīng)給了系統(tǒng)，系統(tǒng)再給了wget命令，wget於是得到了www.的IP地址，這裡也可以看出客戶端和本地的DNS服務(wù)器是遞歸的查詢（也就是服務(wù)器必須給客戶端一個結(jié)果）這就可以開始下一步了，進行TCP的三次握手。

二.發(fā)起TCP的3次握手

拿到域名對應(yīng)的IP地址之後，User-Agent（一般是指瀏覽器）會以一個隨機端口（1024 < 端口 < 65535）向服務(wù)器的WEB程序（常用的有httpd,nginx等）80端口發(fā)起TCP的連接請求。這個連接請求（原始的http請求經(jīng)過TCP/IP4層模型的層層封包）到達服務(wù)器端後（這中間通過各種路由設(shè)備，局域網(wǎng)內(nèi)除外），進入到網(wǎng)卡，然後是進入到內(nèi)核的TCP/IP協(xié)議棧（用於識別該連接請求，解封包，一層一層的剝開），還有可能要經(jīng)過Netfilter防火牆（屬於內(nèi)核的模塊）的過濾，最終到達WEB程序（本文就以Nginx為例），最終建立了TCP/IP的連接。

如下圖：

1） Client首先發(fā)送一個連接試探，ACK=0 表示確認號無效，SYN = 1 表示這是一個連接請求或連接接受報文，同時表示這個數(shù)據(jù)報不能攜帶數(shù)據(jù)，seq = x 表示Client自己的初始序號（seq = 0 就代表這是第0號包），這時候Client進入syn_sent狀態(tài)，表示客戶端等待服務(wù)器的回覆
2） Server監(jiān)聽到連接請求報文後，如同意建立連接，則向Client發(fā)送確認。TCP報文首部中的SYN 和 ACK都置1 ，ack = x + 1表示期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)序號是x+1，同時表明x為止的所有數(shù)據(jù)都已正確收到（ack=1其實是ack=0+1,也就是期望客戶端的第1個包），seq = y 表示Server 自己的初始序號（seq=0就代表這是服務(wù)器這邊發(fā)出的第0號包）。這時服務(wù)器進入syn_rcvd，表示服務(wù)器已經(jīng)收到Client的連接請求，等待client的確認。
3） Client收到確認後還需再次發(fā)送確認，同時攜帶要發(fā)送給Server的數(shù)據(jù)。ACK 置1 表示確認號ack= y + 1 有效（代表期望收到服務(wù)器的第1個包），Client自己的序號seq= x + 1（表示這就是我的第1個包，相對於第0個包來說的），一旦收到Client的確認之後，這個TCP連接就進入Established狀態(tài)，就可以發(fā)起http請求了。

看抓包截圖：

9 號包 這個就是對應(yīng)上面的步驟 1）
10 號包 這個對應(yīng)的上面的步驟 2）
11 號包 這個對應(yīng)的上面的步驟 3）

TCP 為什麼需要3次握手？

舉個例子：

假設(shè)一個老外在故宮裡面迷路了，看到了小明，於是就有下面的對話：

老外： Excuse me，Can you Speak English?
小明： yes 。
老外： OK,I want ...

在問路之前，老外先問小明是否會說英語，小明回答是的，這時老外才開始問路

2個計算機通信是靠協(xié)議（目前流行的TCP/IP協(xié)議）來實現(xiàn),如果2個計算機使用的協(xié)議不一樣，那是不能進行通信的，所以這個3次握手就相當於試探一下對方是否遵循TCP/IP協(xié)議，協(xié)商完成後就可以進行通信了，當然這樣理解不是那麼準確。

為什麼HTTP協(xié)議要基於TCP來實現(xiàn)？

目前在Internet中所有的傳輸都是通過TCP/IP進行的，HTTP協(xié)議作為TCP/IP模型中應(yīng)用層的協(xié)議也不例外，TCP是一個端到端的可靠的面向連接的協(xié)議，所以HTTP基於傳輸層TCP協(xié)議不用擔心數(shù)據(jù)的傳輸?shù)母鞣N問題。

三.建立TCP連接後發(fā)起http請求

進過TCP3次握手之後，瀏覽器發(fā)起了http的請求（看第?包），使用的http的方法 GET 方法，請求的URL是 / ,協(xié)議是HTTP/1.0

下面是第12號包的詳細內(nèi)容：

以上的報文是HTTP請求報文。

那麼HTTP請求報文和響應(yīng)報文會是什麼格式呢？

起始行：如 GET / HTTP/1.0 （請求的方法  請求的URL 請求所使用的協(xié)議）
頭部信息：User-Agent  Host等成對出現(xiàn)的值
主體

不管是請求報文還是響應(yīng)報文都會遵循以上的格式。

那麼起始行中的請求方法有哪些種呢？

GET: 完整請求一個資源 （常用）
HEAD: 僅請求響應(yīng)首部
POST：提交表單  （常用）
PUT: (webdav) 上傳 
DELETE：(webdav) 刪除 
OPTIONS：返回請求的資源所支持的方法的方法 
TRACE: 追求一個資源請求中間所經(jīng)過的代理 

那什麼是URL、URI、URN？

URI  Uniform Resource Identifier 統(tǒng)一資源標識符
URL  Uniform Resource Locator 統(tǒng)一資源定位符 
格式如下：  scheme://[username:password@]HOST:port/path/to/source
             http://www./downloads/nginx-1.5.tar.gz

URN  Uniform Resource Name 統(tǒng)一資源名稱

URL和URN 都屬於 URI

為了方便就把URL和URI暫時都通指一個東西

請求的協(xié)議有哪些種？

有以下幾種：

http/0.9: stateless
http/1.0: MIME, keep-alive (保持連接), 緩存
http/1.1: 更多的請求方法，更精細的緩存控制，持久連接(persistent connection) 比較常用

下面是Chrome發(fā)起的http請求報文頭部信息

其中

Accept  就是告訴服務(wù)器端，我接受那些MIME類型
Accept-Encoding  這個看起來是接受那些壓縮方式的文件
Accept-Lanague   告訴服務(wù)器能夠發(fā)送哪些語言 
Connection       告訴服務(wù)器支持keep-alive特性
Cookie           每次請求時都會攜帶上Cookie以方便服務(wù)器端識別是否是同一個客戶端
Host             用來標識請求服務(wù)器上的那個虛擬主機，比如Nginx裡面可以定義很多個虛擬主機
                 那這裡就是用來標識要訪問那個虛擬主機。
User-Agent       用戶代理，一般情況是瀏覽器，也有其他類型，如：wget curl 搜索引擎的蜘蛛等     

條件請求首部：
If-Modified-Since 是瀏覽器向服務(wù)器端詢問某個資源文件如果自從什麼時間修改過，那麼重新發(fā)給我，這樣就保證服務(wù)器端資源
             文件更新時，瀏覽器再次去請求，而不是使用緩存中的文件
安全請求首部：
Authorization: 客戶端提供給服務(wù)器的認證信息；

什麼是MIME？

MIME（Multipurpose Internet Mail Extesions 多用途互聯(lián)網(wǎng)郵件擴展）是一個互聯(lián)網(wǎng)標準，它擴展了電子郵件標準，使其能夠支持非ASCII字符、二進制格式附件等多種格式的郵件消息，這個標準被定義在RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049等RFC中。 由RFC 822轉(zhuǎn)變而來的RFC 2822，規(guī)定電子郵件標準並不允許在郵件消息中使用7位ASCII字符集以外的字符。正因如此，一些非英語字符消息和二進制文件，圖像，聲音等非文字消息都不能在電子郵件中傳輸。MIME規(guī)定了用於表示各種各樣的數(shù)據(jù)類型的符號化方法。 此外，在萬維網(wǎng)中使用的HTTP協(xié)議中也使用了MIME的框架，標準被擴展為互聯(lián)網(wǎng)媒體類型。

MIME 遵循以下格式：major/minor 主類型/次類型 例如：

image/jpg
image/gif
text/html
video/quicktime
appliation/x-httpd-php

四.服務(wù)器端響應(yīng)http請求，瀏覽器得到html代碼

看下圖 第12號包是http請求包，第32包是http響應(yīng)包

服務(wù)器端WEB程序接收到http請求以後，就開始處理該請求，處理之後就返回給瀏覽器html文件。

第32號包 是服務(wù)器返回給客戶端http響應(yīng)包（200 ok 響應(yīng)的MIME類型是text/html），代表這一次客戶端發(fā)起的http請求已成功響應(yīng)。200 代表是的 響應(yīng)成功的狀態(tài)碼，還有其他的狀態(tài)碼如下：

1xx: 信息性狀態(tài)碼
     100, 101
2xx: 成功狀態(tài)碼
     200：OK
3xx: 重定向狀態(tài)碼
     301: 永久重定向, Location響應(yīng)首部的值仍為當前URL，因此為隱藏重定向;
     302: 臨時重定向，顯式重定向, Location響應(yīng)首部的值為新的URL
     304：Not Modified  未修改，比如本地緩存的資源文件和服務(wù)器上比較時，發(fā)現(xiàn)並沒有修改，服務(wù)器返回一個304狀態(tài)碼，
                         告訴瀏覽器，你不用請求該資源，直接使用本地的資源即可。
4xx: 客戶端錯誤狀態(tài)碼
     404: Not Found  請求的URL資源並不存在
5xx: 服務(wù)器端錯誤狀態(tài)碼
     500: Internal Server Error  服務(wù)器內(nèi)部錯誤
     502: Bad Gateway  前面代理服務(wù)器聯(lián)繫不到後端的服務(wù)器時出現(xiàn)
     504：Gateway Timeout  這個是代理能聯(lián)繫到後端的服務(wù)器，但是後端的服務(wù)器在規(guī)定的時間內(nèi)沒有給代理服務(wù)器響應(yīng)

用Chrome瀏覽器看到的響應(yīng)頭信息：

Connection            使用keep-alive特性
Content-Encoding      使用gzip方式對資源壓縮
Content-type          MIME類型為html類型，字符集是 UTF-8
Date                  響應(yīng)的日期
Server                使用的WEB服務(wù)器
Transfer-Encoding:chunked   分塊傳輸編碼 是http中的一種數(shù)據(jù)傳輸機制，允許HTTP由網(wǎng)頁服務(wù)器發(fā)送給客戶端應(yīng)用（通常是網(wǎng)頁瀏覽器）的數(shù)據(jù)可以分成多個部分，分塊傳輸編碼只在HTTP協(xié)議1.1版本（HTTP/1.1）中提供
Vary  這個可以參考（http://blog.csdn.net/tenfyguo/article/details/5939000）
X-Pingback  參考（http://blog.sina.com.cn/s/blog_bb80041c0101fmfz.html）

那到底服務(wù)器端接收到http請求後是怎麼樣生成html文件？

假設(shè)服務(wù)器端使用nginx+php(fastcgi)架構(gòu)提供服務(wù)

1 nginx讀取配置文件

我們在瀏覽器的地址欄裡面輸入的是 http://www. （http://可以不用輸入，瀏覽器會自動幫我們添加），其實完整的應(yīng)該是http://www../ 後面還有個點（這個點代表就是根域，一般情況下我們不用輸入，也不顯示）,後面的/也是不用添加，瀏覽器會自動幫我們添加（且看第3部那個圖裡面的URL），那麼實際請求的URL是http://www./，那麼好了Nginx在收到 瀏覽器 GET / 請求時，會讀取http請求裡面的頭部信息，根據(jù)Host來匹配 自己的所有的虛擬主機的配置文件的server_name,看看有沒有匹配的，有匹配那麼就讀取該虛擬主機的配置，發(fā)現(xiàn)如下配置：

root /web/echo   

通過這個就知道所有網(wǎng)頁文件的就在這個目錄下 這個目錄就是/ 當我們http://www./時就是訪問這個目錄下面的文件，例如訪問http://www./index.html,那麼代表/web/echo下面有個文件叫index.html

index index.html index.htm index.php  

通過這個就能得知網(wǎng)站的首頁文件是那個文件，也就是我們在入http://www./ ，nginx就會自動幫我們把index.html（假設(shè)首頁是index.php 當然是會嘗試的去找到該文件，如果沒有找到該文件就依次往下找，如果這3個文件都沒有找到，那麼就拋出一個404錯誤）加到後面，那麼添加之後的URL是/index.php,然後根據(jù)後面的配置進行處理

location ~ .*\.php(\/.*)*$ {
   root /web/echo;
   fastcgi_pass   127.0.0.1:9000;
   fastcgi_index  index.php;
   astcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
   include        fastcgi_params;
}

這一段配置指明凡是請求的URL中匹配（這裡是啟用了正則表達式進行匹配） *.php後綴的（後面跟的參數(shù)）都交給後端的fastcgi進程進行處理。

2 把php文件交給fastcgi進程去處理

於是nginx把/index.php這個URL交給了後端的fastcgi進程處理，等待fastcgi處理完成後（結(jié)合數(shù)據(jù)庫查詢出數(shù)據(jù)，填充模板生成html文件）返回給nginx一個index.html文檔，Nginx再把這個index.html返回給瀏覽器，於是乎瀏覽器就拿到了首頁的html代碼，同時nginx寫一條訪問日誌到日誌文件中去。

注1：nginx是怎麼找index.php文件的？

當nginx發(fā)現(xiàn)需要/web/echo/index.php文件時，就會向內(nèi)核發(fā)起IO系統(tǒng)調(diào)用(因為要跟硬件打交道，這裡的硬件是指硬盤，通常需要靠內(nèi)核來操作，而內(nèi)核提供的這些功能是通過系統(tǒng)調(diào)用來實現(xiàn)的)，告訴內(nèi)核，我需要這個文件,內(nèi)核從/開始找到web目錄，再在web目錄下找到echo目錄，最後在echo目錄下找到index.php文件，於是把這個index.php從硬盤上讀取到內(nèi)核自身的內(nèi)存空間，然後再把這個文件複製到nginx進程所在的內(nèi)存空間，於是乎nginx就得到了自己想要的文件了。

注2：尋找文件在文件系統(tǒng)層面是怎麼操作的？

比如nginx需要得到/web/echo/index.php這個文件

每個分區(qū)（像ext3 ext3等文件系統(tǒng)，block塊是文件存儲的最小單元 默認是4096字節(jié)）都是包含元數(shù)據(jù)區(qū)和數(shù)據(jù)區(qū)，每一個文件在元數(shù)據(jù)區(qū)都有元數(shù)據(jù)條目（一般是128字節(jié)大小），每一個條目都有一個編號，我們稱之為inode（index node 索引節(jié)點），這個inode裡面包含 文件類型、權(quán)限、連接次數(shù)、屬主和數(shù)組的ID、時間戳、這個文件佔據(jù)了那些磁盤塊也就是塊的編號（block，每個文件可以佔用多個block,並且block不一定是連續(xù)的，每個block是有編號的），如下圖所示：

還有一個要點：目錄其實也普通是文件，也需要佔用磁盤塊，目錄不是一個容器。你看默認創(chuàng)建的目錄就是4096字節(jié)，也就說只需要佔用一個磁盤塊，但這是不確定的。所以要找到目錄也是需要到元數(shù)據(jù)區(qū)裡面找到對應(yīng)的條目，只有找到對應(yīng)的inode就可找到目錄所佔用的磁盤塊。

那到底目錄裡面存放著什麼，難道不是文件或者其他目錄嗎？

其實目錄存著這麼一張表（姑且這麼理解），裡面放著 目錄或者文件的名稱和對應(yīng)的inode號（暫時稱之為映射表）,如下圖：

假設(shè)

/           在數(shù)據(jù)區(qū)佔據(jù) 1、2號block ，/其實也是一個目錄 裡面有3個目錄  web 111
web         佔據(jù) 5號block  是目錄 裡面有2個目錄 echo data
echo        佔據(jù) 11號 block  是目錄  裡面有1個文件 index.php
index.php   佔據(jù) 15 16號 block  是文件

其在文件系統(tǒng)中分佈如下圖所示

那麼內(nèi)核究竟是怎麼找到index.php這個文件的呢？

內(nèi)核拿到nginx的IO系統(tǒng)調(diào)用要獲取/web/echo/index.php這個文件請求之後

1 內(nèi)核讀取元數(shù)據(jù)區(qū) / 的inode，從inode裡面讀取/所對應(yīng)的數(shù)據(jù)塊的編號，然後在數(shù)據(jù)區(qū)找到其對應(yīng)的塊（1 2號塊），讀取1號塊上的映射表找到web這個名稱在元數(shù)據(jù)區(qū)對應(yīng)的inode號
2 內(nèi)核讀取web對應(yīng)的inode（3號），從中得知web在數(shù)據(jù)區(qū)對應(yīng)的塊是5號塊，於是到數(shù)據(jù)區(qū)找到5號塊，從中讀取映射表，知道echo對應(yīng)的inode是5號，於是到元數(shù)據(jù)區(qū)找到5號inode
3 內(nèi)核讀取5號inode，得到echo在數(shù)據(jù)區(qū)對應(yīng)的是11號塊，於是到數(shù)據(jù)區(qū)讀取11號塊得到映射表，得到index.php對應(yīng)的inode是9號
4 內(nèi)核到元數(shù)據(jù)區(qū)讀取9號inode，得到index.php對應(yīng)的是15和16號數(shù)據(jù)塊，於是就到數(shù)據(jù)區(qū)域找到15 16號塊，讀取其中的內(nèi)容，得到index.php的完整內(nèi)容

五. 瀏覽器解析html代碼，並請求html代碼中的資源

瀏覽器拿到index.html文件後，就開始解析其中的html代碼，遇到j(luò)s/css/image等靜態(tài)資源時，就向服務(wù)器端去請求下載（會使用多線程下載，每個瀏覽器的線程數(shù)不一樣），這個時候就用上keep-alive特性了，建立一次HTTP連接，可以請求多個資源，下載資源的順序就是按照代碼裡的順序，但是由於每個資源大小不一樣，而瀏覽器又多線程請求請求資源，所以從下圖看出，這裡顯示的順序並不一定是代碼裡面的順序。

瀏覽器在請求靜態(tài)資源時（在未過期的情況下），向服務(wù)器端發(fā)起一個http請求（詢問自從上一次修改時間到現(xiàn)在有沒有對資源進行修改），如果服務(wù)器端返回304狀態(tài)碼（告訴瀏覽器服務(wù)器端沒有修改），那麼瀏覽器會直接讀取本地的該資源的緩存文件。

詳細的瀏覽器工作原理請看：http://kb.cnblogs.com/page/129756/

六.瀏覽器對頁面進行渲染呈現(xiàn)給用戶

最後，瀏覽器利用自己內(nèi)部的工作機制，把請求到的靜態(tài)資源和html代碼進行渲染，渲染之後呈現(xiàn)給用戶。

自此一次完整的HTTP事務(wù)宣告完成.