序

最近接觸到了整個網站的開發流程，所以就總結一下網站的執行機制，對網路應用如何工作有一個完整的層次化的認知。

第一步過程

• 首先，你得在瀏覽器裡輸入要網址:

  • 例如百度或者facebook。

第二步過程

• 瀏覽器查詢域名的IP地址（域名就是指輸入的網址）

  • 瀏覽器快取 – 瀏覽器會快取DNS記錄一段時間。 有趣的是，作業系統沒有告訴瀏覽器儲存DNS記錄的時間，這樣不同瀏覽器會儲存個自固定的一個時間（2分鐘到30分鐘不等）。

  • 路由器快取 – 接著，前面的查詢請求發向路由器，它一般會有自己的DNS快取。

  • ISP DNS 快取 – 接下來要check的就是ISP快取DNS的伺服器。在這一般都能找到相應的快取記錄。

  • 遞迴搜尋 – 你的ISP的DNS伺服器從跟域名伺服器開始進行遞迴搜尋，從.com頂級域名伺服器到Facebook的域名伺服器。一般DNS伺服器的快取中會 有.com域名伺服器中的域名，所以到頂級伺服器的匹配過程不是那麼必要了。

第三步過程

• 在請求之前，需要瀏覽器與伺服器建立連線（TCP或者UDP）

  • 與伺服器建立連線時TCP屬於安全的連線，需要三次握手，這裡不在說明。
• 與伺服器響應軟體建立管道連線（socket）

第四步過程

• 瀏覽器給web伺服器傳送一個HTTP請求

  • 因為像Facebook主頁這樣的動態頁面，開啟後在瀏覽器快取中很快甚至馬上就會過期，毫無疑問他們不能從中讀取。 
    所以，瀏覽器將把一下請求傳送到Facebook所在的伺服器：

  • 下面為整個一個請求，請求頭：

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; [...]
DontTrackMeHere: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...
 
]; c_user=2101[...]

• 1
• 2
• 3
• 4
• 5
• 6
• 7

• 1
• 2
• 3
• 4
• 5
• 6
• 7

• 解讀上面請求體

  • Connection頭要求伺服器為了後邊的請求不要關閉TCP連線。

  • 請求中也包含瀏覽器儲存的該域名的cookies。可能你已經知道，在不同頁面請求當中，cookies是與跟蹤一個網站狀態相匹配的鍵值。這樣cookies會儲存登入使用者名稱，伺服器分配的密碼和一些使用者設定等。Cookies會以文字文件形式儲存在客戶機裡，每次請求時傳送給伺服器。

• 補充說明

  • 用來看原始HTTP請求及其相應的工具很多。作者比較喜歡使用fiddler，當然也有像FireBug這樣其他的工具。這些軟體在網站優 化時會幫上很大忙。 
    除了獲取請求，還有一種是傳送請求，它常在提交表單用到。傳送請求通過URL傳遞其引數(e.g.: HTTP://robozzle.com/puzzle.aspx?id=85)。傳送請求在請求正文頭之後傳送其引數。

  • 像“HTTP://facebook.com/”中的斜槓是至關重要的。這種情況下，瀏覽器能安全的新增斜槓。而像“HTTP: //example.com/folderOrFile”這樣的地址，因為瀏覽器不清楚folderOrFile到底是資料夾還是檔案，所以不能自動新增 斜槓。這時，瀏覽器就不加斜槓直接訪問地址，伺服器會響應一個重定向，結果造成一次不必要的握手。

第五步過程

伺服器“處理”請求

• 伺服器接收到獲取請求，然後處理並返回一個響應。 
  這表面上看起來是一個順向的任務，但其實這中間發生了很多有意思的東西- 就像作者部落格這樣簡單的網站，何況像baidu那樣訪問量大的網站呢！

• 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。* 請求處理請求處理閱讀 請求及它的引數和cookies。它會讀取也可能更新一些資料，並講資料儲存在伺服器上。然後，需求處理會生成一個HTML響應。

• 所 有動態網站都面臨一個有意思的難點 -如何儲存資料。小網站一半都會有一個SQL資料庫來儲存資料，儲存大量資料和/或訪問量大的網站不得不找一些辦法把資料庫分配到多臺機器上。解決方案有：sharding （基於主鍵值講資料表分散到多個數據庫中），複製，利用弱語義一致性的簡化資料庫。 
  委託工作給批處理是一個廉價保持資料更新的技術。舉例來講，Fackbook得及時更新新聞feed，但資料支援下的“你可能認識的人”功能只需要每晚更新（作者猜測是這樣的，改功能如何完善不得而知）。批處理作業更新會導致一些不太重要的資料陳舊，但能使資料更新耕作更快更簡潔。

第六步

• 伺服器發回一個HTML響應.
• 下面就是一個響應頭（響應頭與body體分開的） 
  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 
  [email protected][…] 
  整個響應大小為35kB，其中大部分在整理後以blob型別傳輸。

內容編碼頭告訴瀏覽器整個響應體用gzip演算法進行壓縮。解壓blob塊後，你可以看到如下期望的HTML：

“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”> 

第七步

• 瀏覽器開始顯示HTML 
  
  • 在瀏覽器沒有完整接受全部HTML文件時，它就已經開始顯示這個頁面了

第八步

• 瀏覽器顯示HTML時，它會注意到需要獲取其他地址內容的標籤。這時，瀏覽器會發送一個獲取請求來重新獲得這些檔案。
• 下面是幾個我們訪問facebook.com時需要重獲取的幾個URL：

但 不像動態頁面那樣，靜態檔案會允許瀏覽器對其進行快取。有的檔案可能會不需要與伺服器通訊，而從快取中直接讀取。伺服器的響應中包含了靜態檔案儲存的期限 資訊，所以瀏覽器知道要把它們快取多長時間。還有，每個響應都可能包含像版本號一樣工作的ETag頭（被請求變數的實體值），如果瀏覽器觀察到檔案的版本 ETag資訊已經存在，就馬上停止這個檔案的傳輸。

試著猜猜看“fbcdn.net”在地址中代表什麼？聰明的答案是”Facebook內容分發網路”。Facebook利用內容分發網路（CDN）分發像圖片，CSS表和javascript檔案這些靜態檔案。所以，這些檔案會在全球很多CDN的資料中心中留下備份。

靜態內容往往代表站點的頻寬大小，也能通過CDN輕鬆的複製。通常網站會使用第三方的CDN。例如，Facebook的靜態檔案由最大的CDN提供商Akamai來託管。

舉例來講，當你試著ping static.ak.fbcdn.Net的時候，可能會從某個akamai.net伺服器上獲得響應。有意思的是，當你同樣再ping一次的時候，響應的伺服器可能就不一樣，這說明幕後的負載平衡開始起作用了。