⑴ 訪問網站的過程
1，瀏覽器通常指 IE FireFox等，客戶端使用的程序
2，每台連接互聯網的機器都有一個唯一的IP地址，IP地址是由4個0到256的數組成的，比如：222.131.0.229，127.0.0.1，由於每台聯網的機器的IP地址都是獨立的，因此可以通過IP判斷一台機器。
網站所在的伺服器通常有一個固定的IP地址，而我們瀏覽者每次上網的IP地址通常都不一樣，IP地址是由ISP分配的。
域名伺服器(domain name server)的簡稱為DNS，它存儲了域名與IP地址對應的列表。
3，瀏覽器得到域名指向的IP後，瀏覽器會把我們輸入的域名轉化為HTTP的服務請求，例如，輸入 www.mayi1992.com，可以轉化為 http://www.mayi1992.com/，通過這種方式瀏覽器向伺服器發出了請求。
由於輸入的是域名，因此伺服器接收到請求後，會查找域名下的默認網頁(通常為default.php或default.html)，如果直接輸入http://www.mayi1992.com/default.php就直接查找這個頁面。
4，返回的請求通常是一些文件，包括文字信息(.html .css .asp文件等)，圖片，flash等(每個文件都要有一個唯一的網址，比如 http://www.mayi1992.com/xhtml/)
5，瀏覽器將這些信息組織成用戶可以查看的網頁
⑵ 請說一下http請求的基本過程
首先http是一個應用層的協議，在這個層的協議，只是一種通訊規范，也就是因為雙方要進行通訊，大家要事先約定一個規范。
1.連接 當我們輸入這樣一個請求時，首先要建立一個socket連接，因為socket是通過ip和埠建立的，所以之前還有一個DNS解析過程，把www.mycompany.com變成ip，如果url里不包含埠號，則會使用該協議的默認埠號。
DNS的過程是這樣的：首先我們知道我們本地的機器上在配置網路時都會填寫DNS，這樣本機就會把這個url發給這個配置的DNS伺服器，如果能夠
找到相應的url則返回其ip，否則該DNS將繼續將該解析請求發送給上級DNS，整個DNS可以看做是一個樹狀結構，該請求將一直發送到根直到得到結
果。現在已經擁有了目標ip和埠號，這樣我們就可以打開socket連接了。
2.請求 連接成功建立後，開始向web伺服器發送請求，這個請求一般是GET或POST命令（POST用於FORM參數的傳遞）。GET命令的格式為：GET 路徑/文件名 HTTP/1.0
文件名指出所訪問的文件，HTTP/1.0指出Web瀏覽器使用的HTTP版本。現在可以發送GET命令：
GET /mydir/index.html HTTP/1.0，
3.應答 web伺服器收到這個請求，進行處理。從它的文檔空間中搜索子目錄mydir的文件index.html。如果找到該文件，Web伺服器把該文件內容傳送給相應的Web瀏覽器。
為了告知瀏覽器，，Web伺服器首先傳送一些HTTP頭信息，然後傳送具體內容（即HTTP體信息），HTTP頭信息和HTTP體信息之間用一個空行分開。
常用的HTTP頭信息有：
① HTTP 1.0 200 OK 這是Web伺服器應答的第一行，列出伺服器正在運行的HTTP版本號和應答代碼。代碼"200 OK"表示請求完成。
② MIME_Version:1.0它指示MIME類型的版本。
③ content_type:類型這個頭信息非常重要，它指示HTTP體信息的MIME類型。如：content_type:text/html指示傳送的數據是HTML文檔。
④ content_length:長度值它指示HTTP體信息的長度（位元組）。
4.關閉連接：當應答結束後，Web瀏覽器與Web伺服器必須斷開，以保證其它Web瀏覽器能夠與Web伺服器建立連接。
下面我們具體分析其中的數據包在網路中漫遊的經歷
在網路分層結構中，各層之間是嚴格單向依賴的。「服務」是描述各層之間關系的抽象概念，即網路中各層向緊鄰上層提供的一組操作。下層是服務提供者，
上層是請求服務的用戶。服務的表現形式是原語（primitive），如系統調用或庫函數。系統調用是操作系統內核向網路應用程序或高層協議提供的服務原
語。網路中的n層總要向n+1層提供比n-1層更完備的服務，否則n層就沒有存在的價值。
傳輸層實現的是「端到端」通信，引進網間進程通信概念，同時也要解決差錯控制，流量控制，數據排序（報文排序），連接管理等問題，為此提供不同的服
務方式。通常傳輸層的服務通過系統調用的方式提供，以socket的方式。對於客戶端，要想建立一個socket連接，需要調用這樣一些函數socket
() bind() connect(),然後就可以通過send()進行數據發送。
現在看數據包在網路中的穿行過程：
應用層
首先我們可以看到在應用層，根據當前的需求和動作，結合應用層的協議，有我們確定發送的數據內容，我們把這些數據放到一個緩沖區內，然後形成了應用層的報文data。
傳輸層
這些數據通過傳輸層發送，比如tcp協議。所以它們會被送到傳輸層處理，在這里報文打上了傳輸頭的包頭，主要包含埠號，以及tcp的各種制信息，這些信息是直接得到的，因為介面中需要指定埠。這樣就組成了tcp的數據傳送單位segment。tcp
是一種端到端的協議，利用這些信息，比如tcp首部中的序號確認序號，根據這些數字，發送的一方不斷的進行發送等待確認，發送一個數據段後，會開啟一個計
數器，只有當收到確認後才會發送下一個，如果超過計數時間仍未收到確認則進行重發，在接受端如果收到錯誤數據，則將其丟棄，這將導致發送端超時重發。通過
tcp協議，控制了數據包的發送序列的產生，不斷的調整發送序列，實現流控和數據完整。
網路層
然後待發送的數據段送到網路層，在網路層被打包，這樣封裝上了網路層的包頭，包頭內部含有源及目的的ip地址，該層數據發送單位被稱為packet。網路層開始負責將這樣的數據包在網路上傳輸，如何穿過路由器，最終到達目的地址。在這里，根據目的ip地址，就需要查找下一跳路由的地址。首先在本機，要查找本機的路由表，在windows上運行route print就可以看到當前路由表內容，有如下幾項：
Active Routes Default Route Persistent Route.
整個查找過程是這樣的:
(1)根據目的地址，得到目的網路號，如果處在同一個內網，則可以直接發送。
(2)如果不是，則查詢路由表，找到一個路由。
(3)如果找不到明確的路由，此時在路由表中還會有默認網關，也可稱為預設網關，IP用預設的網關地址將一個數據傳送給下一個指定的路由器，所以網關也可能是路由器，也可能只是內網向特定路由器傳輸數據的網關。
(4)
路由器收到數據後，它再次為遠程主機或網路查詢路由，若還未找到路由，該數據包將發送到該路由器的預設網關地址。而數據包中包含一個最大路由跳數，如果超
過這個跳數，就會丟棄數據包，這樣可以防止無限傳遞。路由器收到數據包後，只會查看網路層的包裹數據，目的ip。所以說它是工作在網路層，傳輸層的數據對
它來說則是透明的。
如果上面這些步驟都沒有成功，那麼該數據報就不能被傳送。如果不能傳送的數據報來自本機，那麼一般會向生成數據報的應用程序返回一個「主機不可達」或 「網路不可達」的錯誤。
以windows下主機的路由表為例，看路由的查找過程
======================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.2 192.168.1.101 10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.1.0 255.255.255.0 192.168.1.101 192.168.1.101 10
192.168.1.101 255.255.255.255 127.0.0.1 127.0.0.1 10
192.168.1.255 255.255.255.255 192.168.1.101 192.168.1.101 10
224.0.0.0 240.0.0.0 192.168.1.101 192.168.1.101 10
255.255.255.255 255.255.255.255 192.168.1.101 192.168.1.101 1
Default Gateway: 192.168.1.2
Network Destination 目的網段
Netmask 子網掩碼
Gateway 下一跳路由器入口的ip，路由器通過interface和gateway定義一調到下一個路由器的鏈路，通常情況下，interface和gateway是同一網段的。
Interface 到達該目的地的本路由器的出口ip（對於我們的個人pc來說，通常由機算機A的網卡，用該網卡的IP地址標識，當然一個pc也可以有多個網卡）。
網關這個概念，主要用於不同子網間的交互，當兩個子網內主機A,B要進行通訊時，首先A要將數據發送到它的本地網關，然後網關再將數據發送給B所在的網關，然後網關再發送給B。
默認網關，當一個數據包的目的網段不在你的路由記錄中，那麼，你的路由器該把那個數據包發送到哪裡！預設路由的網關是由你的連接上的default gateway決定的，也就是我們通常在網路連接里配置的那個值。
通常interface和gateway處在一個子網內，對於路由器來說，因為可能具有不同的interface,當數據包到達時，根據
Network
Destination尋找匹配的條目，如果找到，interface則指明了應當從該路由器的那個介面出去，gateway則代表了那個子網的網關地
址。
第一條 0.0.0.0 0.0.0.0 192.168.1.2 192.168.1.101 10
0.0.0.0
代表了預設路由。該路由記錄的意思是：當我接收到一個數據包的目的網段不在我的路由記錄中，我會將該數據包通過192.168.1.101這個介面發送到
192.168.1.2這個地址，這個地址是下一個路由器的一個介面，這樣這個數據包就可以交付給下一個路由器處理，與我無關。該路由記錄的線路質量
10。當有多個條目匹配時，會選擇具有較小Metric值的那個。
第三條 192.168.1.0 255.255.255.0 192.168.1.101 192.168.1.101 10
直
聯網段的路由記錄：當路由器收到發往直聯網段的數據包時該如何處理，這種情況，路由記錄的interface和gateway是同一個。當我接收到一個數
據包的目的網段是192.168.1.0時，我會將該數據包通過192.168.1.101這個介面直接發送出去，因為這個埠直接連接著
192.168.1.0這個網段，該路由記錄的線路質量
10 （因interface和gateway是同一個，表示數據包直接傳送給目的地址，不需要再轉給路由器）。
一般就分這兩種情況，目的地址與當前路由器介面是否在同一子網。如果是則直接發送，不需再轉給路由器，否則還需要轉發給下一個路由器繼續進行處理。
查找到下一跳ip地址後，還需要知道它的mac地址，這個地址要作為鏈路層數據裝進鏈路層頭部。這時需要arp協議，具體過程是這樣的，查找arp
緩沖，windows下運行arp
-a可以查看當前arp緩沖內容。如果裡面含有對應ip的mac地址，則直接返回。否則需要發生arp請求，該請求包含源的ip和mac地址，還有目的地
的ip地址，在網內進行廣播，所有的主機會檢查自己的ip與該請求中的目的ip是否一樣，如果剛好對應則返回自己的mac地址，同時將請求者的ip
mac保存。這樣就得到了目標ip的mac地址。
鏈路層
將mac地址及鏈路層控制信息加到數據包里，形成Frame，Frame在鏈路層協議下，完成了相鄰的節點間的數據傳輸，完成連接建立，控制傳輸速度，數據完整。
物理層
物理線路則只負責該數據以bit為單位從主機傳輸到下一個目的地。
下一個目的地接受到數據後，從物理層得到數據然後經過逐層的解包 到 鏈路層 到 網路層，然後開始上述的處理，在經網路層 鏈路層 物理層將數據封裝好繼續傳往下一個地址。
在上面的過程中，可以看到有一個路由表查詢過程，而這個路由表的建立則依賴於路由演算法。也就是說路由演算法實際上只是用來路由器之間更新維護路由表，
真正的數據傳輸過程並不執行這個演算法，只查看路由表。這個概念也很重要，需要理解常用的路由演算法。而整個tcp協議比較復雜，跟鏈路層的協議有些相似，其
中有很重要的一些機制或者概念需要認真理解，比如編號與確認，流量控制，重發機制，發送接受窗口。
tcp/ip基本模型及概念
物理層
設備，中繼器（repeater）,集線器（hub）。對於這一層來說，從一個埠收到數據，會轉發到所有埠。
鏈路層
協議：SDLC（Synchronous Data Link Control）HDLC（High-level Data Link
Control）
ppp協議獨立的鏈路設備中最常見的當屬網卡，網橋也是鏈路產品。集線器MODEM的某些功能有人認為屬於鏈路層，對此還有些爭議認為屬於物理層設備。除
此之外，所有的交換機都需要工作在數據鏈路層，但僅工作在數據鏈路層的僅是二層交換機。其他像三層交換機、四層交換機和七層交換機雖然可對應工作在OSI
的三層、四層和七層，但二層功能仍是它們基本的功能。
因為有了MAC地址表，所以才充分避免了沖突，因為交換機通過目的MAC地址知道應該把這個數據轉發到哪個埠。而不會像HUB一樣，會轉發到所有滴埠。所以，交換機是可以劃分沖突域滴。
網路層
四個主要的協議:
網際協議IP：負責在主機和網路之間定址和路由數據包。
地址解析協議ARP：獲得同一物理網路中的硬體主機地址。
網際控制消息協議ICMP：發送消息，並報告有關數據包的傳送錯誤。
互聯組管理協議IGMP：被IP主機拿來向本地多路廣播路由器報告主機組成員。
該層設備有三層交換機，路由器。
傳輸層
兩個重要協議 TCP 和 UDP 。
埠概念：TCP/UDP 使用 IP 地址標識網上主機，使用埠號來標識應用進程，即 TCP/UDP 用主機 IP
地址和為應用進程分配的埠號來標識應用進程。埠號是 16 位的無符號整數， TCP 的埠號和 UDP
的埠號是兩個獨立的序列。盡管相互獨立，如果 TCP 和 UDP
同時提供某種知名服務，兩個協議通常選擇相同的埠號。這純粹是為了使用方便，而不是協議本身的要求。利用埠號，一台主機上多個進程可以同時使用
TCP/UDP 提供的傳輸服務，並且這種通信是端到端的，它的數據由 IP 傳遞，但與 IP
數據報的傳遞路徑無關。網路通信中用一個三元組可以在全局唯一標志一個應用進程：（協議，本地地址，本地埠號）。
也就是說tcp和udp可以使用相同的埠。
可以看到通過(協議,源埠，源ip，目的埠，目的ip)就可以用來完全標識一組網路連接。
應用層
基於tcp：Telnet FTP SMTP DNS HTTP
基於udp：RIP NTP（網落時間協議）和DNS （DNS也使用TCP）SNMP TFTP
⑶ http 請求過程
HTTP通信機制是在一次完整的HTTP通信過程中，Web瀏覽器與Web伺服器之間將完成下列7個步驟：
1. 建立TCP連接
在HTTP工作開始之前，Web瀏覽器首先要通過網路與Web伺服器建立連接，該連接是通過TCP來完成的，該協議與IP協議共同構建Internet，即著名的TCP/IP協議族，因此Internet又被稱作是TCP/IP網路。HTTP是比TCP更高層次的應用層協議，根據規則，只有低層協議建立之後才能，才能進行更層協議的連接，因此，首先要建立TCP連接，一般TCP連接的埠號是80。
2. Web瀏覽器向Web伺服器發送請求命令
一旦建立了TCP連接，Web瀏覽器就會向Web伺服器發送請求命令。例如：GET/sample/hello.jsp HTTP/1.1。
3. Web瀏覽器發送請求頭信息
瀏覽器發送其請求命令之後，還要以頭信息的形式向Web伺服器發送一些別的信息，之後瀏覽器發送了一空白行來通知伺服器，它已經結束了該頭信息的發送。
4. Web伺服器應答
客戶機向伺服器發出請求後，伺服器會客戶機回送應答， HTTP/1.1 200 OK ，應答的第一部分是協議的版本號和應答狀態碼。
5. Web伺服器發送應答頭信息
正如客戶端會隨同請求發送關於自身的信息一樣，伺服器也會隨同應答向用戶發送關於它自己的數據及被請求的文檔。
6. Web伺服器向瀏覽器發送數據
Web伺服器向瀏覽器發送頭信息後，它會發送一個空白行來表示頭信息的發送到此為結束，接著，它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據。
7. Web伺服器關閉TCP連接
一般情況下，一旦Web伺服器向瀏覽器發送了請求數據，它就要關閉TCP連接，然後如果瀏覽器或者伺服器在其頭信息加入了這行代碼：
Connection:keep-alive
TCP連接在發送後將仍然保持打開狀態，於是，瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了為每個請求建立新連接所需的時間，還節約了網路帶寬。
⑷ 瀏覽器採用http 協議訪問網頁的工作過程
1. 首先嘛，你得在瀏覽器里輸入要網址:
2. 瀏覽器查找域名的IP地址
導航的第一步是通過訪問的域名找出其IP地址。DNS查找過程如下：
瀏覽器緩存 – 瀏覽器會緩存DNS記錄一段時間。 有趣的是，操作系統沒有告訴瀏覽器儲存DNS記錄的時間，這樣不同瀏覽器會儲存個自固定的一個時間（2分鍾到30分鍾不等）。
系統緩存 – 如果在瀏覽器緩存里沒有找到需要的記錄，瀏覽器會做一個系統調用（windows里是gethostbyname）。這樣便可獲得系統緩存中的記錄。
路由器緩存 – 接著，前面的查詢請求發向路由器，它一般會有自己的DNS緩存。
ISP DNS 緩存 – 接下來要check的就是ISP緩存DNS的伺服器。在這一般都能找到相應的緩存記錄。
遞歸搜索 – 你的ISP的DNS伺服器從跟域名伺服器開始進行遞歸搜索，從.com頂級域名伺服器到Facebook的域名伺服器。一般DNS伺服器的緩存中會有.com域名伺服器中的域名，所以到頂級伺服器的匹配過程不是那麼必要了。
DNS遞歸查找如下圖所示：
DNS有一點令人擔憂，這就是像wikipedia.org 或者 facebook.com這樣的整個域名看上去只是對應一個單獨的IP地址。還好，有幾種方法可以消除這個瓶頸：
循環 DNS 是DNS查找時返回多個IP時的解決方案。舉例來說，Facebook.com實際上就對應了四個IP地址。
負載平衡器 是以一個特定IP地址進行偵聽並將網路請求轉發到集群伺服器上的硬體設備。 一些大型的站點一般都會使用這種昂貴的高性能負載平衡器。
地理 DNS 根據用戶所處的地理位置，通過把域名映射到多個不同的IP地址提高可擴展性。這樣不同的伺服器不能夠更新同步狀態，但映射靜態內容的話非常好。
Anycast 是一個IP地址映射多個物理主機的路由技術。 美中不足，Anycast與TCP協議適應的不是很好，所以很少應用在那些方案中。
大多數DNS伺服器使用Anycast來獲得高效低延遲的DNS查找。
3. 瀏覽器給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; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]
GET 這個請求定義了要讀取的URL： 「http://facebook.com/」。 瀏覽器自身定義 (User-Agent 頭)， 和它希望接受什麼類型的相應 (Accept and Accept-Encoding 頭). 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到底是文件夾還是文件，所以不能自動添加 斜杠。這時，瀏覽器就不加斜杠直接訪問地址，伺服器會響應一個重定向，結果造成一次不必要的握手。
4. facebook服務的永久重定向響應
圖中所示為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/」。
為什麼伺服器一定要重定向而不是直接發會用戶想看的網頁內容呢？這個問題有好多有意思的答案。
其中一個原因跟搜索引擎排名有 關。你看，如果一個頁面有兩個地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎會認為它們是兩個網站，結果造成每一個的搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是 什麼意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。
還有一個是用不同的地址會造成緩存友好性變差。當一個頁面有好幾個名字時，它可能會在緩存里出現好幾次。
5. 瀏覽器跟蹤重定向地址
現在，瀏覽器知道了「http://www.facebook.com/」才是要訪問的正確地址，所以它會發送另一個獲取請求：
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. 伺服器「處理」請求
伺服器接收到獲取請求，然後處理並返回一個響應。
這表面上看起來是一個順向的任務，但其實這中間發生了很多有意思的東西- 就像作者博客這樣簡單的網站，何況像facebook那樣訪問量大的網站呢！
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，但數據支持下的「你可能認識的人」功能只需要每晚更新 （作者猜測是這樣的，改功能如何完善不得而知）。批處理作業更新會導致一些不太重要的數據陳舊，但能使數據更新耕作更快更簡潔。
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@[...]
整個響應大小為35kB，其中大部分在整理後以blob類型傳輸。
內容編碼頭告訴瀏覽器整個響應體用gzip演算法進行壓縮。解壓blob塊後，你可以看到如下期望的HTML：
<!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" />
...
關於壓縮，頭信息說明了是否緩存這個頁面，如果緩存的話如何去做，有什麼cookies要去設置（前面這個響應里沒有這點）和隱私信息等等。
請注意報頭中把Content-type設置為「text/html」。報頭讓瀏覽器將該響應內容以HTML形式呈現，而不是以文件形式下載它。瀏覽器會根據報頭信息決定如何解釋該響應，不過同時也會考慮像URL擴展內容等其他因素。
8. 瀏覽器開始顯示HTML
在瀏覽器沒有完整接受全部HTML文檔時，它就已經開始顯示這個頁面了：
9. 瀏覽器發送獲取嵌入在HTML中的對象
在瀏覽器顯示HTML時，它會注意到需要獲取其他地址內容的標簽。這時，瀏覽器會發送一個獲取請求來重新獲得這些文件。
下面是幾個我們訪問facebook.com時需要重獲取的幾個URL：
圖片
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
…
CSS 式樣表
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
…
JavaScript 文件
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…
這些地址都要經歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些域名，發送請求，重定向等等...
但 不像動態頁面那樣，靜態文件會允許瀏覽器對其進行緩存。有的文件可能會不需要與伺服器通訊，而從緩存中直接讀取。伺服器的響應中包含了靜態文件保存的期限 信息，所以瀏覽器知道要把它們緩存多長時間。還有，每個響應都可能包含像版本號一樣工作的ETag頭（被請求變數的實體值），如果瀏覽器觀察到文件的版本 ETag信息已經存在，就馬上停止這個文件的傳輸。
試著猜猜看「fbcdn.net」在地址中代表什麼？聰明的答案是"Facebook內容分發網路"。Facebook利用內容分發網路（CDN）分發像圖片，CSS表和JavaScript文件這些靜態文件。所以，這些文件會在全球很多CDN的數據中心中留下備份。
靜態內容往往代表站點的帶寬大小，也能通過CDN輕松的復制。通常網站會使用第三方的CDN。例如，Facebook的靜態文件由最大的CDN提供商Akamai來託管。
舉例來講，當你試著ping static.ak.fbcdn.net的時候，可能會從某個akamai.net伺服器上獲得響應。有意思的是，當你同樣再ping一次的時候，響應的伺服器可能就不一樣，這說明幕後的負載平衡開始起作用了。
10. 瀏覽器發送非同步（AJAX）請求
在Web 2.0偉大精神的指引下，頁面顯示完成後客戶端仍與伺服器端保持著聯系。
以 Facebook聊天功能為例，它會持續與伺服器保持聯系來及時更新你那些亮亮灰灰的好友狀態。為了更新這些頭像亮著的好友狀態，在瀏覽器中執行的 JavaScript代碼會給伺服器發送非同步請求。這個非同步請求發送給特定的地址，它是一個按照程式構造的獲取或發送請求。還是在Facebook這個例 子中，客戶端發送給http://www.facebook.com/ajax/chat/buddy_list.php一個發布請求來獲取你好友里哪個 在線的狀態信息。
提起這個模式，就必須要講講"AJAX"-- 「非同步JavaScript 和 XML」，雖然伺服器為什麼用XML格式來進行響應也沒有個一清二白的原因。再舉個例子吧，對於非同步請求，Facebook會返回一些JavaScript的代碼片段。
除了其他，fiddler這個工具能夠讓你看到瀏覽器發送的非同步請求。事實上，你不僅可以被動的做為這些請求的看客，還能主動出擊修改和重新發送它們。AJAX請求這么容易被蒙，可著實讓那些計分的在線游戲開發者們郁悶的了。（當然，可別那樣騙人家~）
Facebook聊天功能提供了關於AJAX一個有意思的問題案例：把數據從伺服器端推送到客戶端。因為HTTP是一個請求-響應協議，所以聊天伺服器不能把新消息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下伺服器端看自己有沒有新消息。
這些情況發生時長輪詢是個減輕伺服器負載挺有趣的技術。如果當被輪詢時伺服器沒有新消息，它就不理這個客戶端。而當尚未超時的情況下收到了該客戶的新消息，伺服器就會找到未完成的請求，把新消息做為響應返回給客戶端。
⑸ 瀏覽器採用http協議訪問網頁的工作過程是什麼
過程如下：
用戶在瀏覽器中輸入網址，計算機提取出域名；
瀏覽器通過DNS查找域名對應的IP地址，獲得IP地址後；
嘗試與對應的伺服器建立TCP連接，連接成功之後；
將用戶的請求裝入http數據包，通過建立的tcp連接發送給伺服器，等待數據返回；
如果數據成功返回，比如說，返回的是一個html頁面，則渲染這個頁面（可以理解為顯示出來）；
渲染的過程中會遇到一些數據標記，比如圖片，這時候就查找本地緩存，如果緩存里有且沒過期，就使用本地緩存的數據，否則就向伺服器發送請求。