百度牛掰面試題-當在瀏覽器地址欄輸入一個URL後回車，將會發生的事情

1. 首先嘛，你得在瀏覽器裏輸入要網址:

2. 瀏覽器查找域名的IP地址

導航的第一步是經過訪問的域名找出其IP地址。DNS查找過程以下：

 

• 瀏覽器緩存 – 瀏覽器會緩存DNS記錄一段時間。 有趣的是，操做系統沒有告訴瀏覽器儲存DNS記錄的時間，這樣不一樣瀏覽器會儲存個自固定的一個時間（2分鐘到30分鐘不等）。
• 系統緩存 – 若是在瀏覽器緩存裏沒有找到須要的記錄，瀏覽器會作一個系統調用（windows裏是gethostbyname）。這樣即可得到系統緩存中的記錄。
• 路由器緩存 – 接着，前面的查詢請求發向路由器，它通常會有本身的DNS緩存。
• ISP DNS 緩存 – 接下來要check的就是ISP緩存DNS的服務器。在這通常都能找到相應的緩存記錄。
• 遞歸搜索 – 你的ISP的DNS服務器從跟域名服務器開始進行遞歸搜索，從.com頂級域名服務器到Facebook的域名服務器。通常DNS服務器的緩存中會有.com域名服務器中的域名，因此到頂級服務器的匹配過程不是那麼必要了。

DNS遞歸查找以下圖所示：

做者：何偉鵬
連接：https://www.zhihu.com/question/34873227/answer/70038032
來源：知乎
著做權歸做者全部，轉載請聯繫做者得到受權。

DNS具備兩層含義：①一個由分層的DNS服務器實現的分佈式數據庫；②一個容許主機查詢分佈式數據庫的應用層協議。有三種類型的DNS服務器：根DNS服務器、頂級DNS服務器和權威DNS服務器。這些服務器如下圖的層次結構組織起來。除此以外，還有一類重要的DNS，稱爲本地DNS服務器。嚴格來講本地DNS服務器並不屬於DNS服務器的層次結構，但它在整個查詢的過程當中卻扮演着重要的角色。
首先，瀏覽器所在的主機向本地DNS服務器發送一個含有知乎域名的DNS查詢報文。本地DNS服務器把查詢報文轉發到根DNS服務器，該根DNS服務器注意到其com後綴並向本地DNS服務器返回com的頂級域名服務器的IP地址。該本地DNS服務器再次向comDNS服務器發送查詢請求，comDNS服務器注意到其http://zhihu.com後綴並用負責該域名的權威DNS服務器的IP地址做爲迴應。最後，本地域名服務器將含有http://zhihu.com的IP地址的響應報文發送給客戶端主機。

這裏的查詢過程是包含遞歸查詢和迭代查詢的，客戶端主機發送給本地服務器的查詢是遞歸查詢，然後面的三個查詢是迭代查詢

 

DNS有一點使人擔心，這就是像

wikipedia.org

或者

facebook.com

這樣的整個域名看上去只是對應一個單獨的IP地址，不過事實上後面可能對應着多個ip地址（也是學習到了，一個ip地址能夠對應多個域名據說一個IP能夠綁定多個域名，那麼…? - 互聯網，一個域名也能夠對應多個ip地址負載均衡實現，一個域名對應多個IP地址，cry！）還好，有幾種方法能夠消除這個瓶頸：

• 循環 DNS 是DNS查找時返回多個IP時的解決方案。舉例來講，

  Facebook.com

  實際上就對應了四個IP地址。
• 負載平衡器 是以一個特定IP地址進行偵聽並將網絡請求轉發到集羣服務器上的硬件設備。 一些大型的站點通常都會使用這種昂貴的高性能負載平衡器。
• 地理 DNS 根據用戶所處的地理位置，經過把域名映射到多個不一樣的IP地址提升可擴展性。這樣不一樣的服務器不可以更新同步狀態，但映射靜態內容的話很是好。
• Anycast是一個IP地址映射多個物理主機的路由技術。 美中不足，Anycast與TCP協議適應的不是很好，因此不多應用在那些方案中。

大多數DNS服務器使用Anycast來得到高效低延遲的DNS查找。

關於DNS的獲取流程，我想再補充些知識：
DNS是應用層協議，事實上他是爲其餘應用層協議工做的，包括不限於HTTP和SMTP以及FTP，用於將用戶提供的主機名解析爲ip地址。
具體過程以下：
①用戶主機上運行着DNS的客戶端，就是咱們的PC機或者手機客戶端運行着DNS客戶端了
②瀏覽器將接收到的url中抽取出域名字段，就是訪問的主機名，好比

http://www.baidu.com/

, 並將這個主機名傳送給DNS應用的客戶端
③DNS客戶機端向DNS服務器端發送一份查詢報文，報文中包含着要訪問的主機名字段（中間包括一些列緩存查詢以及分佈式DNS集羣的工做）
④該DNS客戶機最終會收到一份回答報文，其中包含有該主機名對應的IP地址
⑤一旦該瀏覽器收到來自DNS的IP地址，就能夠向該IP地址定位的HTTP服務器發起TCP鏈接

DNS服務的體系架構是怎樣的？

DNS domain name system 主要做用就是將主機域名轉換爲ip地址

假設運行在用戶主機上的某些應用程序（如Webl瀏覽器或者郵件閱讀器）須要將主機名轉換爲IP地址。這些應用程序將調用DNS的客戶機端，並指明須要被轉換的主機名。（在不少基於UNIX的機器上，應用程序爲了執行這種轉換須要調用函數gethostbyname（））。用戶主機的DNS客戶端接收到後，向網絡中發送一個DNS查詢報文。全部DNS請求和回答報文使用的UDP數據報通過端口53發送（至於爲何使用UDP，請參看爲何域名根服務器只能有13臺呢？ - 郭無意的回答）通過若干ms到若干s的延時後，用戶主機上的DNS客戶端接收到一個提供所但願映射的DNS回答報文。這個查詢結果則被傳遞到調用DNS的應用程序。所以，從用戶主機上調用應用程序的角度看，DNS是一個提供簡單、直接的轉換服務的黑盒子。但事實上，實現這個服務的黑盒子很是複雜，它由分佈於全球的大量DNS服務器以及定義了DNS服務器與查詢主機通訊方式的應用層協議組成。


關於DNS的進一步瞭解能夠參看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.: RoboZZle stats for puzzle 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">
 <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時，它會注意到須要獲取其餘地址內容的標籤。這時，瀏覽器會發送一個獲取請求來從新得到這些文件。

下面是幾個咱們訪問http://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信息已經存在，就立刻中止這個文件的傳輸。

 

試着猜猜看「http://fbcdn.net」在地址中表明什麼？聰明的答案是」Facebook內容分發網絡」。Facebook利用內容分發網絡（CDN）分發像圖片，CSS表和JavaScript文件這些靜態文件。因此，這些文件會在全球不少CDN的數據中心中留下備份。

靜態內容每每表明站點的帶寬大小，也能經過CDN輕鬆的複製。一般網站會使用第三方的CDN。例如，Facebook的靜態文件由最大的CDN提供商Akamai來託管。

舉例來說，當你試着ping http://static.ak.fbcdn.net的時候，可能會從某個http://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://fex.baidu.com/blog/2014/05/what-happen/