當我們在瀏覽器的地址欄輸入 www.linux178.com 普气，然后回車，回車這一瞬間到看到頁面到底發(fā)生了什么呢爱态？
以下過程僅是個人理解：
域名解析 --> 發(fā)起TCP的3次握手 --> 建立TCP連接后發(fā)起http請求 --> 服務器響應http請求挑格，瀏覽器得到html代碼 --> 瀏覽器解析html代碼师幕，并請求html代碼中的資源（如js专控、css抹凳、圖片等） --> 瀏覽器對頁面進行渲染呈現(xià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/
以下就是上面過程的一一分析，我們就以Chrome瀏覽器為例：
1.域名解析
首先Chrome瀏覽器會解析 www.linux178.com 這個域名（準確的叫法應該是主機名）對應的IP地址伦腐。怎么解析到對應的IP地址赢底？
① Chrome瀏覽器 會首先搜索瀏覽器自身的DNS緩存（緩存時間比較短，大概只有1分鐘柏蘑，且只能容納1000條緩存）幸冻，看自身的緩存中是否有www.linux178.com 對應的條目，而且沒有過期咳焚，如果有且沒有過期則解析到此結束洽损。
注：我們怎么查看Chrome自身的緩存？可以使用 chrome://net-internals/#dns 來進行查看
② 如果瀏覽器自身的緩存里面沒有找到對應的條目革半，那么Chrome會搜索操作系統(tǒng)自身的DNS緩存,如果找到且沒有過期則停止搜索解析到此結束.
注：怎么查看操作系統(tǒng)自身的DNS緩存碑定，以Windows系統(tǒng)為例，可以在命令行下使用 ipconfig /displaydns 來進行查看
③ 如果在Windows系統(tǒng)的DNS緩存也沒有找到又官，那么嘗試讀取hosts文件（位于C:\Windows\System32\drivers\etc）延刘，看看這里面有沒有該域名對應的IP地址，如果有則解析成功六敬。
④ 如果在hosts文件中也沒有找到對應的條目碘赖，瀏覽器就會發(fā)起一個DNS的系統(tǒng)調用，就會向本地配置的首選DNS服務器（一般是電信運營商提供的外构，也可以使用像Google提供的DNS服務器）發(fā)起域名解析請求（通過的是UDP協(xié)議向DNS的53端口發(fā)起請求普泡，這個請求是遞歸的請求，也就是運營商的DNS服務器必須得提供給我們該域名的IP地址）典勇，運營商的DNS服務器首先查找自身的緩存，找到對應的條目叮趴，且沒有過期割笙，則解析成功。如果沒有找到對應的條目眯亦，則有運營商的DNS代我們的瀏覽器發(fā)起迭代DNS解析請求伤溉，它首先是會找根域的DNS的IP地址（這個DNS服務器都內置13臺根域的DNS的IP地址），找打根域的DNS地址妻率，就會向其發(fā)起請求（請問www.linux178.com這個域名的IP地址是多少奥夜恕？）宫静，根域發(fā)現(xiàn)這是一個頂級域com域的一個域名走净，于是就告訴運營商的DNS我不知道這個域名的IP地址券时，但是我知道com域的IP地址，你去找它去伏伯，于是運營商的DNS就得到了com域的IP地址橘洞，又向com域的IP地址發(fā)起了請求（請問www.linux178.com這個域名的IP地址是多少?）,com域這臺服務器告訴運營商的DNS我不知道www.linux178.com這個域名的IP地址，但是我知道linux178.com這個域的DNS地址说搅，你去找它去炸枣，于是運營商的DNS又向linux178.com這個域名的DNS地址（這個一般就是由域名注冊商提供的烫扼，像萬網嗤军，新網等）發(fā)起請求（請問www.linux178.com這個域名的IP地址是多少组橄？）董栽，這個時候linux178.com域的DNS服務器一查浴麻，誒耀销，果真在我這里拍鲤，于是就把找到的結果發(fā)送給運營商的DNS服務器离唐，這個時候運營商的DNS服務器就拿到了www.linux178.com這個域名對應的IP地址背伴，并返回給Windows系統(tǒng)內核沸毁，內核又把結果返回給瀏覽器，終于瀏覽器拿到了www.linux178.com 對應的IP地址傻寂，該進行一步的動作了息尺。
注：一般情況下是不會進行以下步驟的
如果經過以上的4個步驟，還沒有解析成功疾掰，那么會進行如下步驟（以下是針對Windows操作系統(tǒng)）：
⑤ 操作系統(tǒng)就會查找NetBIOS name Cache（NetBIOS名稱緩存搂誉，就存在客戶端電腦中的），那這個緩存有什么東西呢静檬？凡是最近一段時間內和我成功通訊的計算機的計算機名和Ip地址炭懊，就都會存在這個緩存里面。什么情況下該步能解析成功呢拂檩？就是該名稱正好是幾分鐘前和我成功通信過侮腹，那么這一步就可以成功解析。
⑥ 如果第⑤步也沒有成功稻励，那會查詢WINS 服務器（是NETBIOS名稱和IP地址對應的服務器）
⑦ 如果第⑥步也沒有查詢成功父阻，那么客戶端就要進行廣播查找
⑧ 如果第⑦步也沒有成功，那么客戶端就讀取LMHOSTS文件（和HOSTS文件同一個目錄下望抽，寫法也一樣）
如果第八步還沒有解析成功加矛，那么就宣告這次解析失敗，那就無法跟目標計算機進行通信煤篙。只要這八步中有一步可以解析成功斟览，那就可以成功和目標計算機進行通信。
看下圖抓包截圖：
Linux虛擬機測試辑奈，使用命令 wget www.linux178.com 來請求苛茂，發(fā)現(xiàn)直接使用chrome瀏覽器請求時已烤，干擾請求比較多，所以就使用wget命令來請求味悄，不過使用wget命令只能把index.html請求回來草戈，并不會對index.html中包含的靜態(tài)資源（js、css等文件）進行請求侍瑟。
抓包分析：
① 號包唐片，這個是那臺虛擬機在廣播，要獲取192.168.100.254（也就是網關）的MAC地址涨颜，因為局域網的通信靠的是MAC地址费韭，它為什么需要跟網關進行通信是因為我們的DNS服務器IP是外圍IP，要出去必須要依靠網關幫我們出去才行庭瑰。
② 號包星持，這個是網關收到了虛擬機的廣播之后，回應給虛擬機的回應弹灭，告訴虛擬機自己的MAC地址督暂，于是客戶端找到了路由出口。
③ 號包穷吮，這個包是wget命令向系統(tǒng)配置的DNS服務器提出域名解析請求（準確的說應該是wget發(fā)起了一個DNS解析的系統(tǒng)調用）逻翁，請求的域名www.linux178.com,期望得到的是IP6的地址（AAAA代表的是IPv6地址）
④ 號包，這個DNS服務器給系統(tǒng)的響應捡鱼，很顯然目前使用IPv6的還是極少數八回，所以得不到AAAA記錄的
⑤ 號包，這個還是請求解析IPv6地址驾诈，但是www.linux178.com.leo.com這個主機名是不存在的缠诅，所以得到結果就是no such name
⑥ 號包，這個才是請求的域名對應的IPv4地址（A記錄）
⑦ 號包乍迄，DNS服務器不管是從緩存里面管引，還是進行迭代查詢最終得到了域名的IP地址，響應給了系統(tǒng)闯两，系統(tǒng)再給了wget命令褥伴，wget于是得到了www.linux178.com的IP地址，這里也可以看出客戶端和本地的DNS服務器是遞歸的查詢（也就是服務器必須給客戶端一個結果）這就可以開始下一步了生蚁，進行TCP的三次握手噩翠。
2.發(fā)起TCP的3次握手
拿到域名對應的IP地址之后戏自，User-Agent（一般是指瀏覽器）會以一個隨機端口（1024 < 端口 < 65535）向服務器的WEB程序（常用的有httpd,nginx等）80端口發(fā)起TCP的連接請求邦投。這個連接請求（原始的http請求經過TCP/IP4層模型的層層封包）到達服務器端后（這中間通過各種路由設備，局域網內除外）擅笔，進入到網卡志衣，然后是進入到內核的TCP/IP協(xié)議棧（用于識別該連接請求屯援，解封包，一層一層的剝開）念脯，還有可能要經過Netfilter防火墻（屬于內核的模塊）的過濾狞洋，最終到達WEB程序（本文就以Nginx為例），最終建立了TCP/IP的連接绿店。
如下圖：
1） Client首先發(fā)送一個連接試探吉懊，ACK=0 表示確認號無效，SYN = 1 表示這是一個連接請求或連接接受報文假勿，同時表示這個數據報不能攜帶數據借嗽，seq = x 表示Client自己的初始序號（seq = 0 就代表這是第0號包），這時候Client進入syn_sent狀態(tài)转培，表示客戶端等待服務器的回復
2） Server監(jiān)聽到連接請求報文后恶导，如同意建立連接，則向Client發(fā)送確認浸须。TCP報文首部中的SYN 和 ACK都置1 惨寿，ack = x + 1表示期望收到對方下一個報文段的第一個數據字節(jié)序號是x+1，同時表明x為止的所有數據都已正確收到（ack=1其實是ack=0+1,也就是期望客戶端的第1個包）删窒，seq = y 表示Server 自己的初始序號（seq=0就代表這是服務器這邊發(fā)出的第0號包）裂垦。這時服務器進入syn_rcvd，表示服務器已經收到Client的連接請求易稠，等待client的確認缸废。
3） Client收到確認后還需再次發(fā)送確認，同時攜帶要發(fā)送給Server的數據驶社。ACK 置1 表示確認號ack= y + 1 有效（代表期望收到服務器的第1個包）企量，Client自己的序號seq= x + 1（表示這就是我的第1個包，相對于第0個包來說的）亡电，一旦收到Client的確認之后届巩，這個TCP連接就進入Established狀態(tài)，就可以發(fā)起http請求了份乒。
看抓包截圖：
⑨ 號包 這個就是對應上面的步驟 1）
⑩ 號包 這個對應的上面的步驟 2）
號包 這個對應的上面的步驟 3）
TCP 為什么需要3次握手恕汇？
舉個例子：
假設一個老外在故宮里面迷路了，看到了小明或辖，于是就有下面的對話：
老外： 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模型中應用層的協(xié)議也不例外察迟，TCP是一個端到端的可靠的面向連接的協(xié)議斩狱，所以HTTP基于傳輸層TCP協(xié)議不用擔心數據的傳輸的各種問題。
3.建立TCP連接后發(fā)起http請求
進過TCP3次握手之后扎瓶，瀏覽器發(fā)起了http的請求（看第包）喊废，使用的http的方法 GET 方法，請求的URL是 / ,協(xié)議是HTTP/1.0
下面是第12號包的詳細內容：
以上的報文是HTTP請求報文栗弟。
那么HTTP請求報文和響應報文會是什么格式呢污筷？
起始行：如 GET / HTTP/1.0 （請求的方法 請求的URL 請求所使用的協(xié)議）
頭部信息：User-Agent Host等成對出現(xiàn)的值
主體
不管是請求報文還是響應報文都會遵循以上的格式。
那么起始行中的請求方法有哪些種呢乍赫？
GET: 完整請求一個資源 （常用）
HEAD: 僅請求響應首部
POST：提交表單 （常用）
PUT: (webdav) 上傳文件（但是瀏覽器不支持該方法）
DELETE：(webdav) 刪除
OPTIONS：返回請求的資源所支持的方法的方法
TRACE: 追求一個資源請求中間所經過的代理（該方法不能由瀏覽器發(fā)出）
那什么是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.magedu.com/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 就是告訴服務器端诈皿，我接受那些MIME類型
Accept-Encoding 這個看起來是接受那些壓縮方式的文件
Accept-Lanague 告訴服務器能夠發(fā)送哪些語言
Connection 告訴服務器支持keep-alive特性
Cookie 每次請求時都會攜帶上Cookie以方便服務器端識別是否是同一個客戶端
Host 用來標識請求服務器上的那個虛擬主機，比如Nginx里面可以定義很多個虛擬主機
那這里就是用來標識要訪問那個虛擬主機像棘。
User-Agent 用戶代理稽亏，一般情況是瀏覽器，也有其他類型缕题，如：wget curl 搜索引擎的蜘蛛等
條件請求首部：
If-Modified-Since 是瀏覽器向服務器端詢問某個資源文件如果自從什么時間修改過截歉，那么重新發(fā)給我，這樣就保證服務器端資源
文件更新時烟零，瀏覽器再次去請求瘪松，而不是使用緩存中的文件
安全請求首部：
Authorization: 客戶端提供給服務器的認證信息；
什么是MIME锨阿？
MIME（Multipurpose Internet Mail Extesions 多用途互聯(lián)網郵件擴展）是一個互聯(lián)網標準宵睦，它擴展了電子郵件標準，使其能夠支持非ASCII字符墅诡、二進制格式附件等多種格式的郵件消息壳嚎，這個標準被定義在RFC 2045、RFC 2046、RFC 2047诬辈、RFC 2048、RFC 2049等RFC中荐吉。 由RFC 822轉變而來的RFC 2822焙糟，規(guī)定電子郵件標準并不允許在郵件消息中使用7位ASCII字符集以外的字符。正因如此样屠，一些非英語字符消息和二進制文件穿撮，圖像，聲音等非文字消息都不能在電子郵件中傳輸痪欲。MIME規(guī)定了用于表示各種各樣的數據類型的符號化方法悦穿。 此外，在萬維網中使用的HTTP協(xié)議中也使用了MIME的框架业踢，標準被擴展為互聯(lián)網媒體類型栗柒。
MIME 遵循以下格式：major/minor 主類型/次類型 例如：
image/jpgimage/giftext/htmlvideo/quicktimeappliation/x-httpd-php
4.服務器端響應http請求，瀏覽器得到html代碼
看下圖 第12號包是http請求包知举，第32包是http響應包
服務器端WEB程序接收到http請求以后瞬沦，就開始處理該請求，處理之后就返回給瀏覽器html文件雇锡。
第32號包 是服務器返回給客戶端http響應包（200 ok 響應的MIME類型是text/html）逛钻，代表這一次客戶端發(fā)起的http請求已成功響應。200 代表是的 響應成功的狀態(tài)碼锰提，還有其他的狀態(tài)碼如下：
1xx: 信息性狀態(tài)碼
100, 101
2xx: 成功狀態(tài)碼
200：OK
3xx: 重定向狀態(tài)碼
301: 永久重定向, Location響應首部的值仍為當前URL曙痘，因此為隱藏重定向;
302: 臨時重定向，顯式重定向, Location響應首部的值為新的URL
304：Not Modified 未修改立肘，比如本地緩存的資源文件和服務器上比較時边坤，發(fā)現(xiàn)并沒有修改，服務器返回一個304狀態(tài)碼谅年，
告訴瀏覽器惩嘉，你不用請求該資源，直接使用本地的資源即可踢故。
4xx: 客戶端錯誤狀態(tài)碼
404: Not Found 請求的URL資源并不存在
5xx: 服務器端錯誤狀態(tài)碼
500: Internal Server Error 服務器內部錯誤
502: Bad Gateway 前面代理服務器聯(lián)系不到后端的服務器時出現(xiàn)
504：Gateway Timeout 這個是代理能聯(lián)系到后端的服務器文黎，但是后端的服務器在規(guī)定的時間內沒有給代理服務器響應
用Chrome瀏覽器看到的響應頭信息：
Connection 使用keep-alive特性
Content-Encoding 使用gzip方式對資源壓縮
Content-type MIME類型為html類型，字符集是 UTF-8
Date 響應的日期
Server 使用的WEB服務器
Transfer-Encoding:chunked 分塊傳輸編碼 是http中的一種數據傳輸機制殿较，允許HTTP由網頁服務器發(fā)送給客戶端應用（通常是網頁瀏覽器）的數據可以分成多個部分耸峭，分塊傳輸編碼只在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）
那到底服務器端接收到http請求后是怎么樣生成html文件？
假設服務器端使用nginx+PHP(fastcgi)架構提供服務
① nginx讀取配置文件
我們在瀏覽器的地址欄里面輸入的是 http://www.linux178.com （http://可以不用輸入淋纲，瀏覽器會自動幫我們添加）劳闹，其實完整的應該是http://www.linux178.com./ 后面還有個點（這個點代表就是根域，一般情況下我們不用輸入，也不顯示）,后面的/也是不用添加本涕，瀏覽器會自動幫我們添加（且看第3部那個圖里面的URL）业汰，那么實際請求的URL是http://www.linux178.com/，那么好了Nginx在收到 瀏覽器 GET / 請求時菩颖，會讀取http請求里面的頭部信息样漆，根據Host來匹配 自己的所有的虛擬主機的配置文件的server_name,看看有沒有匹配的，有匹配那么就讀取該虛擬主機的配置晦闰，發(fā)現(xiàn)如下配置：
`root ``/web/echo`
通過這個就知道所有網頁文件的就在這個目錄下 這個目錄就是/ 當我們http://www.linux178.com/時就是訪問這個目錄下面的文件放祟，例如訪問http://www.linux178.com/index.html,那么代表/web/echo下面有個文件叫index.html
`index index.html index.htm index.php`
通過這個就能得知網站的首頁文件是那個文件，也就是我們在入http://www.linux178.com/ 呻右，nginx就會自動幫我們把index.html（假設首頁是index.php 當然是會嘗試的去找到該文件跪妥，如果沒有找到該文件就依次往下找，如果這3個文件都沒有找到声滥，那么就拋出一個404錯誤）加到后面眉撵，那么添加之后的URL是/index.php,然后根據后面的配置進行處理
`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后綴的（后面跟的參數）都交給后端的fastcgi進程進行處理。
② 把php文件交給fastcgi進程去處理
于是nginx把/index.php這個URL交給了后端的fastcgi進程處理落塑，等待fastcgi處理完成后（結合數據庫查詢出數據执桌，填充模板生成html文件）返回給nginx一個index.html文檔，Nginx再把這個index.html返回給瀏覽器芜赌，于是乎瀏覽器就拿到了首頁的html代碼仰挣，同時nginx寫一條訪問日志到日志文件中去。
注1：nginx是怎么找index.php文件的缠沈？
當nginx發(fā)現(xiàn)需要/web/echo/index.php文件時膘壶，就會向內核發(fā)起IO系統(tǒng)調用(因為要跟硬件打交道，這里的硬件是指硬盤洲愤，通常需要靠內核來操作颓芭，而內核提供的這些功能是通過系統(tǒng)調用來實現(xiàn)的)，告訴內核柬赐，我需要這個文件,內核從/開始找到web目錄亡问，再在web目錄下找到echo目錄，最后在echo目錄下找到index.php文件肛宋，于是把這個index.php從硬盤上讀取到內核自身的內存空間州藕，然后再把這個文件復制到nginx進程所在的內存空間，于是乎nginx就得到了自己想要的文件了酝陈。
注2：尋找文件在文件系統(tǒng)層面是怎么操作的床玻？
比如nginx需要得到/web/echo/index.php這個文件
每個分區(qū)（像ext3 ext3等文件系統(tǒng)，block塊是文件存儲的最小單元 默認是4096字節(jié)）都是包含元數據區(qū)和數據區(qū)沉帮，每一個文件在元數據區(qū)都有元數據條目（一般是128字節(jié)大行馑馈）贫堰，每一個條目都有一個編號，我們稱之為inode（index node 索引節(jié)點）待牵，這個inode里面包含 文件類型其屏、權限、連接次數缨该、屬主和數組的ID偎行、時間戳、這個文件占據了那些磁盤塊也就是塊的編號（block压彭，每個文件可以占用多個block,并且block不一定是連續(xù)的，每個block是有編號的）渗常，如下圖所示：
還有一個要點：目錄其實也普通是文件壮不，也需要占用磁盤塊，目錄不是一個容器皱碘。你看默認創(chuàng)建的目錄就是4096字節(jié)询一，也就說只需要占用一個磁盤塊，但這是不確定的癌椿。所以要找到目錄也是需要到元數據區(qū)里面找到對應的條目健蕊，只有找到對應的inode就可找到目錄所占用的磁盤塊。
那到底目錄里面存放著什么踢俄，難道不是文件或者其他目錄嗎缩功？
其實目錄存著這么一張表（姑且這么理解），里面放著 目錄或者文件的名稱和對應的inode號（暫時稱之為映射表）,如下圖：
假設
/ 在數據區(qū)占據 1都办、2號block 嫡锌，/其實也是一個目錄 里面有3個目錄 web 111
web 占據 5號block 是目錄 里面有2個目錄 echo data
echo 占據 11號 block 是目錄 里面有1個文件 index.php
index.php 占據 15 16號 block 是文件
其在文件系統(tǒng)中分布如下圖所示
那么內核究竟是怎么找到index.php這個文件的呢？
內核拿到nginx的IO系統(tǒng)調用要獲取/web/echo/index.php這個文件請求之后
① 內核讀取元數據區(qū) / 的inode琳钉，從inode里面讀取/所對應的數據塊的編號势木，然后在數據區(qū)找到其對應的塊（1 2號塊），讀取1號塊上的映射表找到web這個名稱在元數據區(qū)對應的inode號
② 內核讀取web對應的inode（3號）歌懒，從中得知web在數據區(qū)對應的塊是5號塊啦桌，于是到數據區(qū)找到5號塊，從中讀取映射表及皂，知道echo對應的inode是5號甫男，于是到元數據區(qū)找到5號inode
③ 內核讀取5號inode，得到echo在數據區(qū)對應的是11號塊验烧，于是到數據區(qū)讀取11號塊得到映射表查剖，得到index.php對應的inode是9號
④ 內核到元數據區(qū)讀取9號inode，得到index.php對應的是15和16號數據塊噪窘，于是就到數據區(qū)域找到15 16號塊笋庄，讀取其中的內容效扫，得到index.php的完整內容
5. 瀏覽器解析html代碼，并請求html代碼中的資源
瀏覽器拿到index.html文件后直砂，就開始解析其中的html代碼菌仁，遇到js/css/image等靜態(tài)資源時，就向服務器端去請求下載（會使用多線程下載静暂，每個瀏覽器的線程數不一樣）济丘，這個時候就用上keep-alive特性了，建立一次HTTP連接洽蛀，可以請求多個資源摹迷，下載資源的順序就是按照代碼里的順序，但是由于每個資源大小不一樣郊供，而瀏覽器又多線程請求請求資源峡碉，所以從下圖看出，這里顯示的順序并不一定是代碼里面的順序驮审。
瀏覽器在請求靜態(tài)資源時（在未過期的情況下）鲫寄，向服務器端發(fā)起一個http請求（詢問自從上一次修改時間到現(xiàn)在有沒有對資源進行修改），如果服務器端返回304狀態(tài)碼（告訴瀏覽器服務器端沒有修改）疯淫，那么瀏覽器會直接讀取本地的該資源的緩存文件地来。
詳細的瀏覽器工作原理請看：http://kb.cnblogs.com/page/129756/
6.瀏覽器對頁面進行渲染呈現(xiàn)給用戶
最后，瀏覽器利用自己內部的工作機制熙掺，把請求到的靜態(tài)資源和html代碼進行渲染未斑，渲染之后呈現(xiàn)給用戶。
自此一次完整的HTTP事務宣告完成.
本文出自 “雷納科斯的博客” 博客币绩，轉載自http://linux5588.blog.51cto.com/65280/1351007
