翻譯_在瀏覽器導航欄輸入URL並按下回車，到底發生了什麼？

What happens when you type an URL in the browsers and press enter? - 在瀏覽器導航欄輸入URL並按下回車，到底發生了什麼？

博客原文連接 What happens when you type an URL in the browser and press enter?

若是你從事WEB開發相關的職業， 我能夠很肯定的說，有人會問你這個問題 ：「在瀏覽器導航欄輸入URL並按下回車，到底發生了什麼？」。 對於瀏覽器背後發生的事情以及信息是如何經過互聯網傳輸到計算機， 有一個基本的瞭解老是好的。

==讓咱們想象下這樣一個情景，你想訪問google地圖的網頁，maps.google.com，查看你從公司到心儀的晚餐飯館預估的路程時間。==

==Tips: 學習經驗，你能夠代入這個場景多想象和回憶幾回，這樣你就不用死記硬背了。==

當咱們身處這個應用場景，整個過程發生了什麼呢？

1.你在瀏覽器的地址欄，輸入了URL: maps.google.com

與URI(統一資源標識符)相比， 咱們更熟悉URL（ Uniform Resourse Locator), 統一資源定位符。

URL表示資源的地點（互聯網上所處的位置）

URL也正是使用Web瀏覽器等訪問Web頁面時須要輸入的網頁地址, maps.google.com。

---

關於URI，作個簡單的瞭解。

==URI, Uniform Resourse Identifier的縮寫。==

• Uniform, 規定統一的格式可方便處理多種不一樣類型的資源，而不用根據上下文環境來識別資源指定的訪問方式。另外加入新增的協議方案（如 http:或ftp:)也更容易。
• Resourse， 資源的定義是「可標識的任何東西」。除了文檔文件呢、圖像或服務（例如天氣預報）等可以區別於其餘類型的， 均可視爲資源。另外，資源不只能夠是單一的，也能夠是多數的集合體。
• Identifier, 表示可標識的對象。 也成爲標識符。

URI就是就是由某個協議方案表示的資源的定位標識符。 協議方案是指訪問資源所使用的協議類型名稱。

採用HTTP協議時，協議方案就是http。除此以外，還有ftp、mailto、telnet、file協議等。

==URI與URL的區別==

URI用字符竄標識某一互聯網資源的全部信息，而URL表示資源的地點（互聯網上所處的位置）。可見URL是URI的子集。

2. DNS解析。

DNS(Domain Name System)協議是和HTTP協議同樣位於應用層的協議。它提供域名到IP地址之間的解析服務。

就像現實生活中的電話簿， URL和IP地址的映射關係，就像聯繫人和電話號碼。

計算機既能夠被賦予IP地址，也能夠被賦予主機名和域名。 好比， www.baidu.com

用戶一般使用主機名或域名來訪問對象的計算機，而不是直接經過IP地址訪問。 與IP地址的一組純數字相比，用字母配合數字的表示方法來制定計算機名更符合人類的記憶習慣。

計算機去理解字符竄，顯然是很困難的，它更擅長跟數字打交道。

DNS協議提供經過域名查找IP地址，或逆向從IP地址反查域名的服務。

舉個例子， www.google.com的IP地址爲: http://209.85.227.104 。
你也能夠在瀏覽器地址欄輸入 http://209.85.227.104， 來訪問www.google.com。 可是很難記住，不是嗎？咱們更願意記住www.google.com這個域名。

==瀏覽器的DNS解析機制的過程是怎麼樣呢？==

• 瀏覽器檢查緩存中的DNS記錄，嘗試找到maps.google.com對應的IP地址。

1. 首先檢查，瀏覽器中的DNS緩存記錄。 瀏覽器緩存中有一個DNS記錄庫，所以，DNS查詢， 首先發生在這裏。
2. 若是沒有在瀏覽器緩存中找到呢？ 瀏覽器向操做系統（OS, Operating System) 發送一個請求: 「gethostname on Windows」，來獲取計算機操做系統的DNS緩存記錄。
3. 若是在計算機系統，也沒找到DNS緩存記錄。瀏覽器接着去路由器那邊查找DNS緩存記錄， 路由器也保存着本身的DNS緩存記錄。
4. 若是以上DNS緩存記錄查找都失敗了，瀏覽器只能去ISP(Internet Service Provider，網絡服務提供者) DNS記錄緩存查找。ISP有一個本身的DNS服務器， 其中有DNS記錄緩存。 這是最後能在DNS緩存中，找到請求URL和對應IP地址的但願了。

你也許會問爲何會在這麼多層級保存着DNS記錄緩存？

信息緩存了那麼屢次，感受隱私被侵犯了。

可是緩存對於節約網絡流量，提升數據傳輸效率是很是重要的。

3. 請求URL的域名的IP地址在DNS緩存中都找不到？

ISP（Internet Service Provider, 網絡服務提供者）的DNS服務器將發起DNS查詢， 以查找maps.google.com對應服務器的IP地址。

前面提到過，爲了讓個人電腦鏈接到maps.google.com這個主機域名的服務器，我須要它對應的IP地址。

DNS查詢的目的就是在互聯網上搜索多個DNS服務器，直到在某個DNS服務器上找到網站正確的IP地址。

這種類型的搜索，成爲遞歸搜索。 由於搜索是持續重複從一個DNS服務器到另一個DNS服務器，直到找到咱們須要的IP地址，或返回一個錯誤響應：沒法找到對應的IP地址。

在這歌情景下，咱們更願意將ISP的DNS服務器解析稱爲DNS遞歸查詢，它的主要職責是經過在互聯網上詢問其餘DNS服務器以找到目標域名所對應的正確的IP地址。

其餘的DNS服務器，在此情景下，被稱爲域服務器，由於他們基於域的架構執行DNS搜索。

若是上述內容沒有繞暈你的話，下面我將解釋下什麼是「域架構」？

通常而言，網站的URL們通常包含着: 一個三級域（a third-level domain), 一個二級域（a second-level domain），一個頂級域（a top-level domain）和 一個根域（root domain）。在DNS查詢過程當中， 每一個域級別都有專屬於本身的域服務器。

對於maps.google.com而言。

ISP的DNS遞歸查詢，從根域服務器開始。 maps.google.com. ,主要後面帶了「."， 表示根域服務器。

根域名服務器定向到.com域服務器。

.com域服務器定向到google.com域服務器。

google.com域服務器將在它的DNS記錄中找到maps.google.com的匹配的IP地址，並將IP地址返回給ISP的DNS服務器，最後發送給你的瀏覽器。

ISP的DNS遞歸查詢過程

maps.google.com. 

=> Root Domain "."

=> Top-Level Domain ".com"

=> Second-Level Domain "google.com"

=> Third-Level Domain "maps.google.com

=> Ip: 212.23.42.42

=> Return IP to ISP DNS Server

=> Your web Broswer get the IP address from ISP DNS Server

上述的DNS查詢請求時使用小數據包發送的。這些數據包包含着，諸如請求內容和如若查找到IP地址，查詢結果返回對象。

這些數據包在到達正確的DNS服務器以前，在客戶端和服務器之間的多個網絡設備進行傳輸。

網絡設備經過「路由表」 （Router Table）來肯定數據包到達「目標DNS服務器」的最快方式。若是這些數據包丟失，會獲得一個請求失敗。 不然，它們將到達正確的DNS服務器， 獲取正確的IP地址，IP地址返回給ISP的DNS服務器，最後返回給您的瀏覽器。

4. 瀏覽器啓動與服務器的TCP鏈接。

一旦， 瀏覽器從ISP的DNS服務器那裏接收到正確的IP地址，它就會與匹配IP地址的服務器創建鏈接，從而能夠傳輸信息。

那麼客戶端（你的電腦）如何和服務器創建鏈接呢？

客戶端使用互聯網協議創建這樣的鏈接， 有許多不一樣的協議可使用， TCP是用於處理HTTP請求，最多見的傳輸協議。

創建TCP鏈接的做用就是爲了在客戶端（你的電腦）和服務器之間傳送數據包。

整個TCP創建鏈接過程當中，TCP/IP三次握手。

客戶端和服務器，交換SYN（synchronize 同步）數據包和 ACK（acknowledge 確認)數據包，創建TCP鏈接。

TCP/IP 三次握手的過程:

1. 客戶端經過網絡發送一個SYN數據包，向服務器詢問是否開放鏈接？
2. 若是服務器的端口可接受和開啓新鏈接，它將使用有一個SYN/ACK數據包來響應，客戶端發來的SYN數據包。
3. 客戶端收到從服務器端返回的SYN/ACK數據包，向服務器發送ACK數據包確認。

而後TCP鏈接就創建了。

// TCP/IP 握手過程

1. Client.send(SYN packet) => Asking Server? open for new connection

2. get SYN from Client
Server (ports) &&( accept new connection),  response(SYN/ACK packet) => Client

3. Client received response SYN/ACK packet from Server and confirm it by sending ACK packet to Server

TCP connection established

5. 瀏覽器向服務器發送HTTP請求

一旦，創建了TCP鏈接，能夠開始傳送數據了。

瀏覽器會發送一個GET請求，請求maps.google.com網頁。若是你提交的是驗證信息或表單信息，這多是一個POST請求。

這個請求還將包含額外的信息，例如: 瀏覽器類型（用戶代理），接受的數據類型，鏈接類型，域名，cookie信息等等。

// GET 請求樣本

GET http://facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml,[...]
User-Agent: Mozilla/4.0 (compatible); MSIE8.0; Windows NT 6.1; WOW64;[...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=12323232-[....]; locale=en us; ls=WW[...]

若是你對幕後發生的事情感到好奇，可使用Chrome瀏覽器的控制檯，按F12鍵(在windows系統可使用快捷鍵 Ctrl + Shift + J)， 在控制檯的區域有個Network，那裏你能到這些幕後發生的事情。

6. 服務器處理請求

服務器收到瀏覽器請求，而後交給專門處理瀏覽器請求的應用程序。

處理瀏覽器請求的應用程序（用ASP.NET，PHP， Ruby等語言編寫）讀取並檢查請求的信息（請求頭、cookie)，必要時更新服務器上的信息。最後，它以特定的數據格式（JSON, XML, HTML) 組裝響應。

7. 服務器返回HTTP響應給瀏覽器

服務器返回HTTP響應給瀏覽器，響應中包含你所請求的網頁內容，以及協議版本、響應狀態碼、狀態碼緣由語句、編碼方式、緩存類型、cookie設置、隱私信息、響應報文（服務器返回給瀏覽器的文本信息，一般HTML, CSS, JS, 圖片等文件就放在這一部分）等等。

//服務器HTTP響應 範例

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-Connection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT

第一行顯示了狀態碼，很是重要，由於它告訴咱們響應的狀態。

響應狀態碼描述了五種狀態：

1. 1xx，Informational，信息狀態碼，表示接受的請求正在處理。
2. 2xx，Success，成功狀態碼，表示請求正常處理完畢。
3. 3xx，Redirection， 重定向狀態碼，表示須要客戶端須要進行附加操做。
4. 4xx，Client Error，客戶端錯誤狀態碼，表示服務器沒法處理請求。
5. 5xx，Server Error，服務器錯誤狀態碼，表示服務器處理請求出錯。

所以，若是你遇到了一個錯誤，能夠查看一下HTTP響應，以檢查您收到的狀態代碼類型，從而對錯誤的緣由有個基本的判斷。

8. 瀏覽器解析渲染頁面

瀏覽器對內容的解析渲染, 這一部分（渲染樹構建、佈局及繪製），又能夠分爲下面五個部分。

1. 解析HTML並構建DOM樹。
2. 解析CSS並構建CSSOM樹。
3. 將DOM和CSSOM合併成一個渲染樹。
4. 根據渲染樹來佈局，以計算每一個節點的幾何信息。
5. 將各個節點繪製到屏幕上。

9.最後, 您將看到 maps.google.com 出如今您的瀏覽器中

儘管這彷佛是一個很是冗長乏味的過程，但咱們知道，在按下鍵盤上的回車鍵以後，頁面呈現的時間不到幾秒鐘。全部這些步驟都在幾毫秒內發生，咱們甚至都沒有注意到。

我真誠地但願本文可以對您有了解「輸入URL到頁面呈現」 有一個大概的瞭解！