從 URL 到頁面返回的過程?
第一步：客戶機提出域名解析請求,並將該請求傳送給本地的域名伺服器。
第二步：當本地的域名伺服器收到請求後,就先查詢本地的快取,如果有該紀錄項,則本地的域名伺服器就直接把查詢的結果返回。
第三步：如果本地的快取中沒有該紀錄,則本地域名伺服器就直接把請求發給根域名伺服器,然後根域名伺服器再返回給本地域名伺服器一個所查詢域(根的子域)的主域名伺服器的地址。
第四步：本地伺服器再向上一步返回的域名伺服器傳送請求,然後接受請求的伺服器查詢自己的快取,如果沒有該紀錄,則返回相關的下級的域名伺服器的地址。
第五步：重複第四步,直到找到正確的紀錄。
#這麼說當然沒問題，那完美解答？
*先有一個前提，我們在使用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/” 而非“ofollow,noindex">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那樣。