1. 首先是輸入網址

　　以www.facebook.com為例

1. 瀏覽器查詢域名對應IP

2.1 瀏覽器發起DNS查詢請求：
在廣域網中，我們是基於IP地址進行通訊的。但通常客戶訪問的是一個網址，為此，我們需要先得到網址對應的IP地址，這就需要域名服務系統將域名轉換成IP地址。如下圖所示，在客戶端瀏覽器中輸入網址：http://www.cricode.com時，瀏覽器會根據本地客戶端DNS伺服器配置(下圖為DNS伺服器配置)，向DNS伺服器獲取域名對應的IP地址。

域名解析伺服器是基於UDP協議實現的一個應用程式，通常通過監聽53埠來獲取客戶端的域名解析請求。

　　瀏覽器快取——瀏覽器會記錄DNS一段時間（2-30分鐘不等，視瀏覽器而定） 
　　系統快取——瀏覽器裡沒找到DNS快取，此時瀏覽器做一個系統呼叫（window下是gethostbyname）。如發現匹配則採用。（與此對應有host惡意劫持更改攻擊） 
　　路由器快取——路由器也會有DNS快取（快取你上過的網站，所以有時路由器需要進行DNS重新整理） 
　　ISP DNS快取——接下來是在ISP（網際網路服務提供商）的DNS伺服器的快取上查詢。 
　　遞迴查詢——DNS快取裡沒有的話，ISP DNS伺服器會先後從根域名伺服器（root）、.com頂級域名伺服器、baidu域名伺服器獲取IP（一般快取內都會有，所以這一步一般不會發生）

2.2 多IP域名DNS查詢解決方案 
　　迴圈DNS——單個域名、多個IP列表迴圈應對DNS查詢 
　　負載均衡器——一個特定IP的負載均衡伺服器（例如：反向代理伺服器）負責監聽請求並轉發給後面的多個伺服器叢集的某一個，實現多個伺服器負載均衡 
　　地理DNS——根據使用者所處地理位置，返回不同的IP（應用：CDN） 
　　anycast——一個IP地址對映多個物理主機的路由技術

3.瀏覽器給web伺服器傳送HTTP請求 
　　得到域名對應的IP後，就開始傳送HTTP(S)請求了. 
　　請求頭詳解： 
　　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[…]

　　請求告訴伺服器： 
　　1. 我要獲取（GET） http://facebook.com/ （GET的URL）這個頁面 
　　2. Accept：我能接受這些型別的檔案 
　　3. 我使用的是何種作業系統上的哪個型別那個版本的瀏覽器 
　　4. 承認接受何種方式的壓縮檔案 
　　5. 連線型別：短連線？長連線？ 
　　6. 主機域名 
　　7. 傳送儲存在本機的cookies資訊給伺服器

　　除了傳送獲取請求，還能傳送提交響應請求（如：搜尋時要把搜尋的內容一併發給伺服器進行處理（在請求URL後面增加特定的使用者引數），以獲取特定的內容） 
　　注意：URL後面加斜槓與不加斜槓的區別(資料夾與單個檔案的區別) 
　　

4.重定向 
　　當我們輸入不完整的網址http://www.facebook.com 時，或者網站遷移做了重定向設定時，伺服器會進行一次重定向響應。 
　　下面是重定向之後返回的響應頭： 
　　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

　　1. 301 永久重定向 
　　2. 新的Location：……

　　為什麼要重定向，而不直接返回使用者想看的內容呢？（既然伺服器已經經過重定向知道了使用者需要什麼）

　　答：原因之一：與搜尋引擎排名有關。你看，如果一個頁面有兩個地址，就像http://www.igoro.com/ 和http://igoro.com/，搜尋引擎會認為它們是兩個網站，結果造成每一個的搜尋連結都減少從而降低排名。而搜尋引擎知道301永久重定向是 什麼意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。

5.新的請求 
　　重定向之後會發佈一個新的獲取請求

6.伺服器處理請求 
6.1 web伺服器軟體 
　　伺服器作業系統種類：Linux（一般是廠家根據開源定製）、windows server系列（微軟） 
　　主要的伺服器軟體：IIS、Apache、Tomcat、JBOSS、Nginx、lighttpd、Tetty 
　　伺服器軟體的作用：接收、處理與響應請求（瞭解CGI的作用）

6.2 處理流程： 
　　web伺服器軟體（如IIS或者Apache）接收到HTTP請求 
　　確定執行那個請求處理程式（一個能讀懂請求並且能生成HTML來進行響應的程式）（例如：Asp.NET,PHP,RUBY……）來處理它 
　　請求處理器閱讀請求頭的引數和cookies資訊 
　　更新伺服器上的資訊：例如更新資料庫資訊、服務端cookies 
　　生成HTML，壓縮（gzip或其他），響應請求傳送給使用者

7.伺服器發回一個HTML響應 
　　響應包括響應頭（響應引數與資訊）、響應包（主體檔案） 
　　響應包採用特定方法壓縮，整個響應以blob型別傳輸，響應頭指示響應包以何種方式壓縮 
　　這個響應頭與重定向的響應頭不太一樣，這個響應頭還包含著快取選項，cookies設定和隱私資訊等

8.瀏覽器開始顯示HTML 
　　瀏覽器在沒有完整接收全部HTML檔案，就已經開始顯示頁面了

9.瀏覽器獲取其他檔案 
　　瀏覽器解析HTML遇到需要下載的檔案時，便再次向伺服器（CDN）傳送獲取檔案的請求。 
　　注意： 
　　1. 動態頁面無法快取，靜態檔案允許瀏覽器進行快取。 
　　2. 靜態檔案本地有快取時直接從本地讀取 
　　3. 請求響應頭內包含著靜態檔案儲存的期限，瀏覽器知道下載的靜態檔案要靜默保留多久。 
　　4. 響應頭還會有靜態檔案的ETag（相當於版本號），當瀏覽器發現請求的靜態檔案的響應頭的ETag與現有的快取檔案不符時，便會再次向伺服器獲取靜態檔案。

10.瀏覽器傳送非同步（AJAX）請求 
　　web 2.0的一大特徵就是頁面顯示完全後客戶端仍舊與伺服器端保持聯絡（keep-alive） 
　　瀏覽器執行特定的JS程式碼會給伺服器傳送非同步請求，獲取最新的動態訊息，使得頁面能保持較新的狀態。 
　　HTTP是一個請求-響應協議，只有在客戶端傳送請求，伺服器端才能做出響應，而不能主動把訊息或者文件發給客戶所以，要想保持頁面處於最新的狀態，需要定時進行輪詢（定時傳送AJAX請求以更新頁面內容） 
　　AJAX請求十分容易更改，且使用者十分容易自己製造和傳送AJAX請求，所以沒有驗證碼的沒有IP限制條件的投票就是一個小遊戲了（參照工作室兩次刷票：自己定義IP，自己定時傳送AJAX請求，然後票就嘩嘩的上了）。 
　　優化小方案：如果伺服器被輪詢時沒有新訊息，它就不理這個客戶端。而當請求尚未超時的情況下如果收到了該客戶的新訊息，伺服器就找到未完成的請求，把新訊息作為響應傳送給客戶端（這樣就無需頻繁地響應請求了）. 
備註:此文章並非原創,原文地址http://www.cnblogs.com/rollenholt/archive/2012/03/23/2414345.html