网页访问过程...
1. ?輸入URL：?
2. ?瀏覽器查詢域名指向的IP：?
DNS查詢過程如下（依次查詢，直到得到指向記錄）：?
? ?瀏覽器緩存 ?—— ?各瀏覽器不同，大約都在 ?2-30 分鐘之間。另外，緩存只存在于
進程中，瀏覽器關閉或重啟后失效。?
? ?操作系統緩存?
? ?路由器緩存?
? ?ISP DNS 緩存?
? ?遞歸搜索 ?—— ?該搜索由你所屬的ISP 的DNS服務器發起，首先找到互聯網根服務
器， ?從根服務器獲取到.com ?域名服務器，從.com ?域名服務器獲取到Facebook的
域名服務器（一般小公司沒有自己的域名服務器）。 ?由于根服務器及.com 域名服務
器都比較固定，通常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的技術精神就是即使頁面已經呈現完畢了，客戶端仍然能夠異步的與服務端進
行交互。
轉載于:https://www.cnblogs.com/yangzhi/p/3576552.html
總結
- 上一篇： linux修改网卡mac
- 下一篇： CentOS上使用libtld