http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/

http://www.cnblogs.com/wenanry/archive/2010/02/25/1673368.html

http://www.jianshu.com/p/d9361badf49a

當在瀏覽器中輸入一個url后回車，后臺發生了什么？比如輸入url后，你看到了百度的首頁，那么這一切是如何發生的呢？

作為一個軟件開發者，你一定會對網絡應用如何工作有一個完整的層次化的認知，同樣這里也包括這些應用所用到的技術：像瀏覽器，HTTP，HTML，網絡服務器，需求處理等等。

本文將更深入的研究當你輸入一個網址的時候，后臺到底發生了一件件什么樣的事～

1. You enter a URL into the browser（輸入一個url地址）

2. The browser looks up the IP address for the domain name（瀏覽器查找域名的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查找。

解析域名，找到主機IP過程：

（1）瀏覽器會緩存DNS一段時間，一般2-30分鐘不等。如果有緩存，直接返回IP，否則下一步。

（2）緩存中無法找到IP，瀏覽器會進行一個系統調用，查詢hosts文件。如果找到，直接返回IP，否則下一步。（在計算機本地目錄etc下有一個hosts文件，hosts文件中保存有域名與IP的對應解析，通常也可以修改hosts科學上網或破解軟件。）

（3）進行了（1）（2）本地查詢無果，只能借助于網絡。路由器一般都會有自己的DNS緩存，ISP服務商DNS緩存，這時一般都能夠得到相應的IP。如果還是無果，只能借助于DNS遞歸解析了。

（4）這時，ISP的DNS服務器就會開始從根域名服務器開始遞歸搜索，從.com頂級域名服務器，到baidu的域名服務器。

到這里，瀏覽器就獲得了IP。在DNS解析過程中，常常會解析出不同的IP。比如，電信的是一個IP，網通的是另一個IP。這是采取了智能DNS的結果， 降低運營商間訪問延時，在多個運營商設置主機房，就近訪問主機。電信用戶返回電信主機IP，網通用戶返回網通主機IP。當然，劫持DNS，也可以屏蔽掉一 部分網點的訪問，某防火長城也加入了這一特性。

3. The browser sends a HTTP request to the web server(瀏覽器給web服務器發送一個HTTP請求)

瀏覽器與網站建立TCP連接

瀏覽器利用IP直接與網站主機通信。瀏覽器發出TCP（SYN標志位為1）連接請求，主機返回TCP（SYN，ACK標志位均為1）應答報文，瀏覽器收到 應答報文發現ACK標志位為1，表示連接請求確認。瀏覽器返回TCP（）確認報文，主機收到確認報文，三次握手，TCP鏈接建立完成。

瀏覽器發起GET請求

瀏覽器向主機發起一個HTTP-GET方法報文請求。請求中包含訪問的URL，也就是http://www.baidu.com/ ，還有User-Agent用戶瀏覽器操作系統信息，編碼等。值得一提的是Accep-Encoding和Cookies項。Accept- Encoding一般采用gzip，壓縮之后傳輸html文件。Cookies如果是首次訪問，會提示服務器建立用戶緩存信息，如果不是，可以利用 Cookies對應鍵值，找到相應緩存，緩存里面存放著用戶名，密碼和一些用戶設置項。

因為像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. The facebook server responds with a permanent redirect (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. The browser follows the redirect(瀏覽器跟蹤重定向地址)

現在，瀏覽器知道了“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. The server ‘handles’ the request(服務器“處理”請求)

服務器接收到獲取請求，然后處理并返回一個響應。

這表面上看起來是一個順向的任務，但其實這中間發生了很多有意思的東西- 就像作者博客這樣簡單的網站，何況像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響應

顯示頁面或返回其他

返回狀態碼200 OK，表示服務器可以相應請求，返回報文，由于在報頭中Content-type為“text/html”，瀏覽器以HTML形式呈現，而不是下載文件。
但是，對于大型網站存在多個主機站點，往往不會直接返回請求頁面，而是重定向。返回的狀態碼就不是200 OK，而是301,302以3開頭的重定向碼，瀏覽器在獲取了重定向響應后，在響應報文中Location項找到重定向地址，瀏覽器重新第一步訪問即可。

補充一點的就是，重定向是為了負載均衡或者導入流量，提高SEO排名。利用一個前端服務器接受請求，然后負載到不同的主機上，可以大大提高站點的業務并發 處理能力；重定向也可將多個域名的訪問，集中到一個站點；由于baidu.com，www.baidu.com會被搜索引擎認為是兩個網站，照成每個的鏈 接數都會減少從而降低排名，永久重定向會將兩個地址關聯起來，搜索引擎會認為是同一個網站，從而提高排名。

圖中為服務器生成并返回的響應：

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. The browser begins rendering the HTML(瀏覽器開始顯示HTML)

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

客戶端下載完資源后，便進入了我們關注的前端模塊了。瀏覽器會解析HTML成樹形的數據結構DOM，生成DOM Tree，瀏覽器將css代碼解析成樹形的數據結構CSSOM，生成CSS Rule Tree。

DOM和CSSOM都是以Bytes->charcters->tokens->nodes->object model這樣的方式生成最終的數據。DOM樹的生成過程是一個深度遍歷過程：當前節點的所有節點都構建好之后才回去構建當前節點的下一個兄弟節點。

DOM Tree和CSS Rule Tree結合生成Render Tree

渲染頁面

布局

有了Render Tree，瀏覽器知道網頁中有哪些節點、各個節點的css定義以及他們的從屬關系。接著就開始布局，計算出每個節點在屏幕中的位置

渲染

瀏覽器在知道了哪些節點要展示，并且每個節點的css屬性是什么、每個節點在屏幕中的位置在哪里的時候，就會進入了最后一步，按照算出來的規則，通過顯卡，把內容畫到屏幕上。

但是javascript可以根據DOM API操作DOM。比如JS修改了DOM或者CSS屬性，也會重新的觸發布局和渲染的執行過程。

9. The browser sends requests for objects embedded in HTML(瀏覽器發送獲取嵌入在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. The browser sends further asynchronous (AJAX) requests(瀏覽器發送異步（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是一個請求-響應協議，所以聊天服務器不能把新消息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下服務器端看自己有沒有新消息。

這些情況發生時長輪詢是個減輕服務器負載挺有趣的技術。如果當被輪詢時服務器沒有新消息，它就不理這個客戶端。而當尚未超時的情況下收到了該客戶的新消息，服務器就會找到未完成的請求，把新消息做為響應返回給客戶端。

總結一下

希望看了本文，你能明白不同的網絡模塊是如何協同工作的

參考資料：

1.what happens when you type in a URL in browser [closed]

http://stackoverflow.com/questions/2092527/what-happens-when-you-type-in-a-url-in-browser；

2.What is the complete process from entering a url to the browser's address bar to get the rendered page in browser

http://stackoverflow.com/questions/5165310/what-is-the-complete-process-from-entering-a-url-to-the-browsers-address-bar-to； 3.What really happens when you navigate to a URL http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/； 4. 當你輸入一個網址的時候，實際會發生什么? http://www.cnblogs.com/wenanry/archive/2010/02/25/1673368.html；

總結

以上是生活随笔為你收集整理的从输入URL到页面显示的过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。