從 URL 到頁面返回的過程?

向前輩學習系列，從一個小白來看這篇文章作的理解。

blog.csdn.net/wdzxl198/ar…

做者：Atlas 來源：CSDN

#首先是簡單解法：

第一步：客戶機提出域名解析請求,並將該請求發送給本地的域名服務器。

第二步：當本地的域名服務器收到請求後,就先查詢本地的緩存,若是有該紀錄項,則本地的域名服務器就直接把查詢的結果返回。

第三步：若是本地的緩存中沒有該紀錄,則本地域名服務器就直接把請求發給根域名服務器,而後根域名服務器再返回給本地域名服務器一個所查詢域(根的子域)的主域名服務器的地址。

第四步：本地服務器再向上一步返回的域名服務器發送請求,而後接受請求的服務器查詢本身的緩存,若是沒有該紀錄,則返回相關的下級的域名服務器的地址。

第五步：重複第四步,直到找到正確的紀錄。

#這麼說固然沒問題，那完美解答？

*先有一個前提，咱們在使用facebook。

1. 輸入一個url地址

2. 瀏覽器查找域名的ip地址

先找瀏覽器緩存，因爲操做系統不會告訴瀏覽器給老子保存DNS記錄多久，因此瀏覽器會給存儲個2-30分鐘不等。

若是瀏覽器緩存中沒有，操做系統會作一個系統調用，windows中是一個gethosbyname來獲取系統緩存中的記錄

還找不到，我們只能去ISP了，在這裏通常都找到記錄。在這裏作的是一個遞歸操做，從頂級域名服務器到facebook服務器。找完爺爺，爺爺告訴你找爸爸，找完爸爸找兒子，最後兒子就是facebook服務器中通常都會有。

3. 瀏覽器給web服務器發送一個HTTP請求

GET http://facebook.com/ HTTP/1.1
 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
 Accept-Encoding: gzip, deflate
 Connection: Keep-Alive
 Host: facebook.com
 Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

複製代碼

GET 這個請求定義了要讀取的URL： 「facebook.com/」。

瀏覽器自身定義 (User-Agent 頭)， 和它但願接受什麼類型的相應

(Acceptand Accept-Encoding 頭).

Connection頭要求服務器爲了後邊的請求不要關閉TCP鏈接。

請求中也包含瀏覽器存儲的該域名的cookies。可能你已經知道，在不一樣頁面請求當中，cookies是與跟蹤一個網站狀態相匹配的鍵值。這樣cookies會存儲登陸用戶名，服務器分配的密碼和一些用戶設置等。Cookies會以文本文檔形式存儲在客戶機裏，每次請求時發送給服務器。

4. 永久重定向響應

HTTP/1.1 301 Moved Permanently
 Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
 pre-check=0
 Expires: Sat, 01 Jan 2000 00:00:00 GMT
 Location: http://www.facebook.com/
 P3P: CP="DSP LAW"
 Pragma: no-cache
 Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
 path=/; domain=.facebook.com; httponly
 Content-Type: text/html; charset=utf-8
 X-Cnection: close
 Date: Fri, 12 Feb 2010 05:09:51 GMT
 Content-Length: 0

複製代碼

假設你輸入的是 facebook.com，服務器會給你一個永久定向迴響這樣瀏覽器就會訪問「www.facebook.com/」 而非「facebook.com/」。狸貓換太子啊，偷偷…

緣由在於一個網站排名的緣由，若是一個網站運用負載均衡有兩個ip地址(這裏涉及到了負載均衡看下文)，可是又想把訪問量歸到一個網站上去，這就是重定向。

5. 瀏覽器跟蹤重定向地址

當你孩子從小就抱錯了，天然一直把那個小烏龜王八養大，你的瀏覽器也就一直跟蹤這個重定向的地址。

GET http://www.facebook.com/ HTTP/1.1
 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
 Accept-Language: en-US
 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
 Accept-Encoding: gzip, deflate
 Connection: Keep-Alive
 Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
 Host: www.facebook.com
複製代碼

6. 服務器處理請求

請求處理閱讀會帶着它的參數和cookie，會讀取也可能更新一些數據，並將數據存儲在服務器上，需求處理此時會生成一個HTML響應。

7. 服務器發回一個html響應

HTTP/1.1 200 OK
 Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
 pre-check=0
 Expires: Sat, 01 Jan 2000 00:00:00 GMT
 P3P: CP="DSP LAW"
 Pragma: no-cache
 Content-Encoding: gzip
 Content-Type: text/html; charset=utf-8
 X-Cnection: close
 Transfer-Encoding: chunked
 Date: Fri, 12 Feb 2010 09:05:55 GMT

 2b3Tn@[...]
複製代碼

大體是這樣的HTML，整個響應爲35kB，大部分整理後以blob類型傳輸，內容編碼頭告訴瀏覽器整個響應體用gzip算法進行壓縮。

8.瀏覽器顯示html

在瀏覽器沒有完整接受所有HTML文檔時，它就已經開始顯示了。

9.瀏覽器發送獲取嵌入在HTML中的對象

在獲取了html後咱們還要接着經過訪問其餘的url地址來獲取其餘文件。這些文件都要通過一個和獲取html相似的過程

此外，靜態文件會容許瀏覽器對其進行緩存。有的文件可能會不須要與服務器通信，而從緩存中直接讀取。服務器的響應中包含了靜態文件保存的期限 信息，因此瀏覽器知道要把它們緩存多長時間。還有，每一個響應均可能包含像版本號同樣工做的ETag頭（被請求變量的實體值），若是瀏覽器觀察到文件的版本 ETag信息已經存在，就立刻中止這個文件的傳輸。

10.瀏覽器發送異步ajax請求

當頁面實現完後，客戶端仍然與服務器保持着聯繫。爲了獲取一些實時更新的信息，好比facebook中的好友是否在線的實時更新，經過javascript會不斷給服務器發送異步請求得到這些信息。

#負載平衡？

負載平衡器是以一個特定IP地址進行偵聽並將網絡請求轉發到集羣服務器上的硬件設備。 一些大型的站點通常都會使用這種昂貴的高性能負載平衡器。 地理 DNS 根據用戶所處的地理位置，經過把域名映射到多個不一樣的IP地址提升可擴展性。

#fiddler？

一個讓你看到瀏覽器發送的異步請求的工具

#Web 服務器軟件？

Web 服務器軟件 web服務器軟件（像IIS和阿帕奇）接收到HTTP請求，而後肯定執行什麼請求處理來處理它。請求處理就是一個可以讀懂請求而且能生成HTML來進行響應的程序（像ASP.NET,PHP,RUBY...）。

舉 個最簡單的例子，需求處理能夠以映射網站地址結構的文件層次存儲。像http://example.com/folder1/page1.aspx這個地 址會映射/httpdocs/folder1/page1.aspx這個文件。web服務器軟件能夠設置成爲地址人工的對應請求處理，這樣 page1.aspx的發佈地址就能夠是http://example.com/folder1/page1。

#解決存儲數據的問題？

小網站一半都會有一個SQL數據庫來存儲數據，存儲大量數據和/或訪問量大的網站不得不找一些辦法把數據庫分配到多臺機器上。解決方案 有：sharding （基於主鍵值講數據表分散到多個數據庫中），複製，利用弱語義一致性的簡化數據庫。

#sharding？

#利用弱語義一致性的簡化數據庫?

。。。。

#blob類型?

BLOB (binary large object)，二進制大對象，是一個能夠存儲二進制文件的容器。在計算機中，BLOB經常是數據庫中用來存儲二進制文件的字段類型。BLOB是一個大文件，典型的BLOB是一張圖片或一個聲音文件，因爲它們的尺寸，必須使用特殊的方式來處理（例如：上傳、下載或者存放到一個數據庫）。

#ETag頭？

Etag 是URL的Entity Tag，用於標示URL對象是否改變，區分不一樣語言和Session等等。具體內部含義是使服務器控制的，就像Cookie那樣。