1. 輸入URL:
2. 瀏覽器查詢網域名稱指向的IP:
DNS查詢過程如下(依次查詢,直到得到指向記錄):
瀏覽器緩衝 —— 各瀏覽器不同,大約都在 2-30 分鐘之間。另外,緩衝只存在於
進程中,瀏覽器關閉或重啟後失效。
作業系統緩衝
路由器緩衝
ISP DNS 緩衝
遞迴搜尋 —— 該搜尋由你所屬的ISP 的DNS伺服器發起,首先找到互連網根服務
器, 從根伺服器擷取到.com 網域名稱伺服器,從.com 網域名稱伺服器擷取到Facebook的
網域名稱伺服器(一般小公司沒有自己的網域名稱伺服器)。 由於根伺服器及.com 網域名稱服務 (DNS)
器都比較固定,通常ISP 的DNS伺服器已經緩衝了.com 網域名稱伺服器,即,可以省略
對根伺服器的查詢。
題外話:像facebook、wikipedia這種規模的網站,如果它的網域名稱只是指向一個IP,那麼
可能很容易就掛掉了。通常人們採用以下幾種技術解決這個瓶頸:
Round-robin DNS:一個網域名稱指向多個IP,DNS伺服器返回多個IP。
Load-balancer:採用高效能負載平衡裝置,將請求重新導向到其它IP。
Geographic DNS:一個網域名稱指向多個IP,根據用戶端所處的物理位置返回最近的IP。
適合不常更新的靜態內容例如js、css及圖片等。可能CDN採用這種方式。
Anycast:一個IP 映射到多台物理伺服器。由於不能很好的相容TCP協議,應用場
景很少。但大多數DNS伺服器使用這種方式。
3. 瀏覽器向web伺服器發送HTTP請求。
像facebook這種網站的首頁是不會緩衝到瀏覽器端的。
此次請求如下:
GET:擷取http://facebook.com的內容。
User-Agent:瀏覽器的標識。
Accept:瀏覽器能接受的響應類型。
Accept-Encoding:瀏覽器能接受的資料編碼類別型。
Connection:瀏覽器將在對一個server的多次訪問中重用一個串連。
Cookie:該瀏覽器中儲存的此網域名稱下的所有cookie值。每次請求都會發送所有cookie。
可以使用fiddler 查看請求和響應的原始http資訊。
Post請求與Get請求的區別:Get請求的參數在URL中,Post請求的參數在請求體中。
4. Facebook伺服器返回一個永久重新導向響應。
伺服器返回的響應如下:
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
伺服器返回301永久重新導向響應告訴瀏覽器轉向http://www.facebook.com/(最初請求
的是http://facebook.com/)。
對於為什麼使用用戶端的重新導向而非直接將內容響應出來有以下兩個原因:
為了SEO。對於搜尋引擎來說,www.facebook.com 和facebook.com 兩個不同的URL
會各自分一批流量,不利於排名。而搜尋引擎能夠識別301重新導向,會將兩個URL
的流量合并。
為了最佳化緩衝。對於緩衝來說,兩個URL將儲存兩份緩衝。使用了重新導向後,緩衝
依據的僅僅是www.facebook.com,只產生一份緩衝。
5. 瀏覽器轉向。
現在瀏覽器知道www.facebook.com才是正確的URL,於是發起另一此Get請求:
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. 伺服器開始處理請求。
Web伺服器。
IIS 或apache 等接收到http 請求後,為請求選擇一個處理常式。請求處理常式
(ASP.NET、PHP、Ruby等)負責讀取請求資訊,產生HTML響應。
請求處理常式。
請求處理常式讀取請求資訊、URL、參數、cookie 等。然後讀取或更新儲存在
器段的資料。最後產生一段HTML文本。
7. 伺服器向瀏覽器返迴響應資訊。
以下是響應內容:
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
最後一行是一大堆亂碼,這裡省略掉了。
可以看到Content-Encoding的值是gzip,表示響應體的內容是使用gzip壓縮過的,所以
看上去是一堆亂碼。瀏覽器會將它解壓。解壓後內容如下:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en" id="facebook" class=" no_js">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
...
回應標頭還告訴瀏覽器是否可以快取頁面面、怎樣快取頁面面、需要設定的cookie(此例中沒
有)以及隱私資訊等。Content-Type的值是text/html表示,瀏覽器應該把響應內容作為
html來呈現,而不是下載這個檔案。實際上瀏覽器還會考慮其它因素,例如URL的尾碼
名以決定以什麼方式呈現或下載。
8. 瀏覽器開始呈現HTML。
在完全接收整個HTML文檔之前就已開始呈現。
9. 瀏覽器請求擷取HTML文檔中內嵌的對象。
在呈現過程中,瀏覽器會分析HTML中的需要下載內容的標籤。瀏覽器發起GET請求獲
取這些檔案。這些檔案可能包括圖片、CSS樣式表、js 檔案等等。
請求這些檔案的過程與請求HTML文檔類似,包括在DNS伺服器中查詢網域名稱指向、向
URL發送請求、重新導向等等。
然而,靜態檔案是可以允許瀏覽器緩衝的。一些檔案可以直接從瀏覽器緩衝擷取,而不
必重新向伺服器請求。瀏覽器知道應該緩衝多久——伺服器返回的回應標頭中寫著呢。作
為瀏覽器緩衝到期時間的補充,回應標頭中可能還會包含一個”ETag”,標識檔案的版本—
—當瀏覽器接收一個響應時發現該響應的Etag版本在緩衝中已經存在了,則會停止下載
檔案。
題外話:像facebook這種規模的網站都會使用CDN(content delivery network,內容分
髮網絡)——可以將靜態內容例片、樣式表、js 檔案等部署在CDN上——這些檔案
會被copy到很多伺服器上。
10. 瀏覽器發送ajax請求。
Web 2.0的技術精神就是即使頁面已經呈現完畢了,用戶端仍然能夠非同步與服務端進
行互動。