譯文：瀏覽器輸入URL發生了什麼？

翻譯：在瀏覽器導航欄輸入一個url後，發生了什麼？

做爲一名軟件開發人員，關於網站應用的工做原理以及其中涉及到的技術：包括瀏覽器、HTTP、web server、請求處理等等，你必定有一個清晰的畫面。

過程

1. 你在瀏覽器輸入一個url（www.baidu.com）

2. 瀏覽器對輸入的網站域名查找相應的ip地址

導航欄的第一步工做是去獲取訪問域名所對應的ip地址，DNS的查找過程以下：

• 瀏覽器緩存---瀏覽器會緩存DNS域名解析記錄一段時間。有趣的是,操做系統不會告訴瀏覽器每個NDS緩存的存活時間，因此瀏覽器瀏覽器只會緩存它們一小段固定時間（不一樣瀏覽器有所不一樣，通常是2-30分鐘）
• OS操做系統緩存---若是瀏覽器緩存不存在想要的ip記錄，瀏覽器會通知操做系統（在window系統是經過gethostbyname）。操做系統有本身的一份緩存。
• 路由器緩存---請求會繼續來到路由器，路由器有本身的緩存記錄
• ISP(Internet Servive Provider)互聯網服務商DNS緩存---下一步查找是ISP的DNS緩存服務器。
• ISP DNS服務器進行遞歸查找---你的ISP的DNS服務器開始了遞歸查找，從根域名服務器、經過頂級.com域名服務器，到baidu的域名服務器。很正常的，NDS服務器有.com域名服務器上的域名的緩存，因此到根服務器直接查找沒有必要。

有一件讓人擔憂的事情就是關於DNS域名解析，那就是像「baicu.com」這樣的完整的域名，好像只有單一的IP地址，幸運的是，這裏有些緩和瓶頸的方式。
  * 輪詢調度（Round-robin DNS）DNS是一種解決方案進行NDS域名解查找返回多個IP地址，比只有ip地址好。舉個例子，facebook.com 實際上映射了4個IP地址。
  * 負載均衡（Load-balancer）是硬件上的用來監聽某個特定的ip地址，對轉發請求到另外一臺服務器。不少網站都會特別的使高性能的負載均衡器。
  * Geographic DNS（地理）經過獲取客戶端的地址位置，將域名映射到不一樣的IP地址，從而提升了可擴張性。
  這個對於呈現靜態資源文件是很好的，這樣不一樣的服務器不須要更新共享狀態。
  * 任播（Anycast）是一種路徑選擇技術，對於單一的IP地址映射到多個物理服務器，很不幸，任播不適合TCP還有就是不多在在腳本使用。
  
許多DNS服務器自身是使用傳播是完成高效且低延遲的DNS查找

複製代碼

3. 瀏覽器發了一個HTTP 請求到web服務器

你可以很肯定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請求去獲取‘htt p://facebook.com/’，瀏覽器對本身作了標識，對服務器進行身份代表（user agent header）。還有聲明什麼類型的返回內容將會被接受（Accept and Accept-Encoding headers）。請求頭請求服務器保持TCP鏈接的打開以實現後續的請求。

這個請求也包含瀏覽器與該域名對應的cookies。或許你已經知道，cookies是跟蹤一個網站在不一樣的網頁請求的鍵值對。cookies存儲了登錄的用戶名，一個私密數字聯繫到用戶經過服務器，一些用戶的設置等等。Cookies會被保存在客戶端的某個文件裏面，每一個請求都會將cookies發送到服務器。

有不少種工具可讓你看到原生的HTTP requests請求，還有對應的responses返回。用來查看原生HTTP請求，我最喜歡的工具是fiddler,可是有不少其餘的工具例如FireBug。這些工具都很好對於優化站點。

對於GETQ請求以外，另一種類型的請求或許你很熟悉，那就是POST請求，典型的使用就是提交表單。一個get請求經過URL發送它的請求參數（例如：htt p://robozzle.com/puzzle.aspx?id=85）。一個POST請求在請求體添加請求參數而且發送，就是在請求頭下。

跟隨在URL"htt p://facebook.com/"的反斜槓是很是重要的，在這種狀況，瀏覽器能夠很安全的添加斜槓。對於「htt p://example.com/folderOrFile」這樣的URL形式，瀏覽器不能自動地添加反斜槓，由於它不肯定這個「folderOrFile」是個目錄仍是個文件。對於這種狀況，瀏覽器就會訪問這個網站不加反斜槓，那麼服務器就會返回一個重定向，致使沒有必要的往返。

4. FaceBoo 服務器返回一個永久重定向

這是一個來自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告訴瀏覽器訪問「www.facebook.com/」而不是「http:/…

這裏有趣的內容爲何服務器堅持重定向，而不是當即返回用戶想要看到的頁面。 有一個理由就是關於搜索引擎排名，看，若是有兩個不一樣的URL訪問同一個網頁，說http://www.igoro.com/ 還有 igoro.com/, 搜索引擎會認爲它們是兩個不一樣的網站，每一個都是低收入連接和那麼低的排名嗎，搜索引擎明白永久重定向（301），而後會結合兩個不一樣來源的傳入到同一個排名。 還有，相同的內容有多個URL對緩存不是很友好。當有一部份內容有多個名字，他將會潛在存在屢次在緩存。

5. 瀏覽器跟隨重定向

瀏覽器知道「htt p://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. 服務器處理請求

服務器將會收到一個get請求，對他進行處理，而後返回respones

這個看起來是一項直截了當的任務，但其實實際上這裏有不少有趣的工做發生。即便在 一個簡單的我的博客網站，更別說在一個超大型的網站像Facebook。

• Web服務軟件

Web服務軟件（Apache IIS）接受HTTP請求還有決定用什麼請求處理工具來處理本次請求，一個請求處理工具是一個項目（ASP,.NET,PHP,Ruby,...）讀取請求而後生成返回HTML。

在最簡單的狀況，請求處理工具可以被存儲在一個映射URLs結構的文件層次結構。舉個例子 htt p://example.com/folder1/page1.aspx URL 將會映射到文件/httpdocs/folder1/page1.aspx。web服務軟件也可以被配置以致於URLs可以手動映射到請求處理工具，因此對於page.aspx的公共URL能偶寫成：「ht tp://example.com/folder1/page1」

• 請求處理工具

請求處理工具獲取HTTP請求,請求參數，cookies。它可能讀取請求還可能更新一些存儲在服務器的數據。而後請求處理工具會生成返回一個HTML

有一個有趣的難題是每一個動態網站遇到的關於如何保存數據。小一點的網站常常會有一個單一的SQL數據庫去保存數據，可是網站保存一個巨大數量的數據或者有不少訪問者就不得不在多臺服務器之間分離數據庫。解決方案主要有：分片sharding（基於主鍵在多個數據庫之間分離數據表），複製replication，還有使用弱化一致性語義的簡化數據庫。

延時一些處理進行批量處理是可讓更新數據比較低性能消耗的技術。

7. 服務返回一個HTML respones

這是服務生成發回的。

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
複製代碼

整一個返回結果是36kb，the bulk of them in the byte blob at the end that I trimmed.（怎麼翻譯？）

Content-Encoding頭告訴瀏覽器返回體是使用gaip算法壓縮的。解壓文件，你就能夠看到期待的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，他會發現標籤裏面須要獲取其餘URLs,瀏覽器將會發送GET請求去獲取這些文件

這裏有些URLs是我訪問facebook網站檢索的

Images
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
…
CSS style sheets
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
…
JavaScript files
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
複製代碼

每個URls都會經歷跟請求HTML相同的處理過程，因此，瀏覽器將會查找DNS域名解析，發送請求

然而，靜態文件--不像動態頁面-容許瀏覽器緩存它們。有些文件或許是緩存提供的一點也沒有聯繫服務器。瀏覽器知道對某個特定的文件緩存多長時間是由於返回的文件包括一個過時的頭部。另外，每一個返回也包含一個ETag頭部像一個版本號---若是瀏覽器發現已經有一個跟ETag版本相同的文件，就會立刻中止傳輸。

10. 瀏覽器發送進一步的異步（Ajax）請求

Web2.0的精髓就是客戶端頁面能夠繼續跟客戶端交互即便在網已經請求渲染。

例如，Facebook 聊天將會繼續更新你的新登陸的或者退出的用戶列表。在你的瀏覽器Js已經被執行發送異步請求。異步請求是編程式指導GET或者POST請求到特定的URL.在Facebook這個例子，客戶端發送一個post請求htt p://www.facebook.com/ajax/chat/buddy_list.php 去獲取的你的在線好友列表。

這個模式有時候被聯繫到AJAX,表明「Asynchronous JavaScript And XML」，可是沒有特定的理由說爲何服務器須要格式化返回結果爲XML。