經典面試題:從 URL 輸入到頁面展現到底發生什麼?

Fundebug發表於2019-02-28

摘要: 經典面試題。

Fundebug經授權轉載,版權歸原作者所有。

前言

開啟瀏覽器從輸入網址到網頁呈現在大家面前,背後到底發生了什麼?經歷怎麼樣的一個過程?先給大家來張總體流程圖,具體步驟請看下文分解!

本文首發地址為GitHub 部落格,寫文章不易,請多多支援與關注!

經典面試題:從 URL 輸入到頁面展現到底發生什麼?

總體來說分為以下幾個過程:

  • DNS 解析:將域名解析成 IP 地址
  • TCP 連線:TCP 三次握手
  • 傳送 HTTP 請求
  • 伺服器處理請求並返回 HTTP 報文
  • 瀏覽器解析渲染頁面
  • 斷開連線:TCP 四次揮手

一、URL 到底是啥

URL(Uniform Resource Locator),統一資源定位符,用於定位網際網路上資源,俗稱網址。比如 www.w3school.com.cn/ht...,遵守以下的語法規則:

scheme://host.domain:port/path/filename
複製程式碼

各部分解釋如下:

  • scheme - 定義因特網服務的型別。常見的協議有 http、https、ftp、file,其中最常見的型別是 http,而 https 則是進行加密的網路傳輸。
  • host - 定義域主機(http 的預設主機是 www)
  • domain - 定義因特網域名,比如 w3school.com.cn
  • port - 定義主機上的埠號(http 的預設埠號是 80)
  • path - 定義伺服器上的路徑(如果省略,則文件必須位於網站的根目錄中)。
  • filename - 定義文件/資源的名稱

二、域名解析(DNS)

在瀏覽器輸入網址後,首先要經過域名解析,因為瀏覽器並不能直接通過域名找到對應的伺服器,而是要通過 IP 地址。大家這裡或許會有個疑問----計算機既可以被賦予 IP 地址,也可以被賦予主機名和域名。比如 www.hackr.jp。那怎麼不一開始就賦予個 IP 地址?這樣就可以省去解析麻煩。我們先來了解下什麼是 IP 地址

1. IP 地址

IP 地址是指網際網路協議地址,是 IP Address 的縮寫。IP 地址是 IP 協議提供的一種統一的地址格式,它為網際網路上的每一個網路和每一臺主機分配一個邏輯地址,以此來遮蔽實體地址的差異。IP 地址是一個 32 位的二進位制數,比如 127.0.0.1 為本機 IP。

域名就相當於 IP 地址喬裝打扮的偽裝者,帶著一副面具。它的作用就是便於記憶和溝通的一組伺服器的地址。使用者通常使用主機名或域名來訪問對方的計算機,而不是直接通過 IP 地址訪問。因為與 IP 地址的一組純數字相比,用字母配合數字的表示形式來指定計算機名更符合人類的記憶習慣。但要讓計算機去理解名稱,相對而言就變得困難了。因為計算機更擅長處理一長串數字。為了解決上述的問題,DNS 服務應運而生。

2. 什麼是域名解析

DNS 協議提供通過域名查詢 IP 地址,或逆向從 IP 地址反查域名的服務。DNS 是一個網路伺服器,我們的域名解析簡單來說就是在 DNS 上記錄一條資訊記錄。

例如 baidu.com  220.114.23.56(伺服器外網IP地址)80(伺服器埠號)
複製程式碼

3. 瀏覽器如何通過域名去查詢 URL 對應的 IP 呢

  • 瀏覽器快取:瀏覽器會按照一定的頻率快取 DNS 記錄。
  • 作業系統快取:如果瀏覽器快取中找不到需要的 DNS 記錄,那就去作業系統中找。
  • 路由快取:路由器也有 DNS 快取。
  • ISP 的 DNS 伺服器:ISP 是網際網路服務提供商(Internet Service Provider)的簡稱,ISP 有專門的 DNS 伺服器應對 DNS 查詢請求。
  • 根伺服器:ISP 的 DNS 伺服器還找不到的話,它就會向根伺服器發出請求,進行遞迴查詢(DNS 伺服器先問根域名伺服器.com 域名伺服器的 IP 地址,然後再問.baidu 域名伺服器,依次類推)

經典面試題:從 URL 輸入到頁面展現到底發生什麼?

4. 小結

瀏覽器通過向 DNS 伺服器傳送域名,DNS 伺服器查詢到與域名相對應的 IP 地址,然後返回給瀏覽器,瀏覽器再將 IP 地址打在協議上,同時請求引數也會在協議搭載,然後一併傳送給對應的伺服器。接下來介紹向伺服器傳送 HTTP 請求階段,HTTP 請求分為三個部分:TCP 三次握手、http 請求響應資訊、關閉 TCP 連線。

經典面試題:從 URL 輸入到頁面展現到底發生什麼?

三、TCP 三次握手

在客戶端傳送資料之前會發起 TCP 三次握手用以同步客戶端和服務端的序列號和確認號,並交換 TCP 視窗大小資訊。

經典面試題:從 URL 輸入到頁面展現到底發生什麼?

1. TCP 三次握手的過程如下:

  • 客戶端傳送一個帶 SYN=1,Seq=X 的資料包到伺服器埠(第一次握手,由瀏覽器發起,告訴伺服器我要傳送請求了)
  • 伺服器發回一個帶 SYN=1, ACK=X+1, Seq=Y 的響應包以示傳達確認資訊(第二次握手,由伺服器發起,告訴瀏覽器我準備接受了,你趕緊傳送吧)
  • 客戶端再回傳一個帶 ACK=Y+1, Seq=Z 的資料包,代表“握手結束”(第三次握手,由瀏覽器傳送,告訴伺服器,我馬上就發了,準備接受吧)

2. 為啥需要三次握手

謝希仁著《計算機網路》中講“三次握手”的目的是“為了防止已失效的連線請求報文段突然又傳送到了服務端,因而產生錯誤”。

四、傳送 HTTP 請求

TCP 三次握手結束後,開始傳送 HTTP 請求報文。

請求報文由請求行(request line)、請求頭(header)、請求體四個部分組成,如下圖所示:

經典面試題:從 URL 輸入到頁面展現到底發生什麼?

1. 請求行包含請求方法、URL、協議版本

  • 請求方法包含 8 種:GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。
  • URL 即請求地址,由 <協議>://<主機>:<埠>/<路徑>?<引數> 組成
  • 協議版本即 http 版本號
POST /chapter17/user.html HTTP/1.1
複製程式碼

以上程式碼中“POST”代表請求方法,“/chapter17/user.html”表示 URL,“HTTP/1.1”代表協議和協議的版本。現在比較流行的是 Http1.1 版本

2. 請求頭包含請求的附加資訊,由關鍵字/值對組成,每行一對,關鍵字和值用英文冒號“:”分隔。

請求頭部通知伺服器有關於客戶端請求的資訊。它包含許多有關的客戶端環境和請求正文的有用資訊。其中比如:Host,表示主機名,虛擬主機;Connection,HTTP/1.1 增加的,使用 keepalive,即持久連線,一個連線可以發多個請求;User-Agent,請求發出者,相容性以及定製化需求。

3. 請求體,可以承載多個請求引數的資料,包含回車符、換行符和請求資料,並不是所有請求都具有請求資料。

name=tom&password=1234&realName=tomson
複製程式碼

上面程式碼,承載著 name、password、realName 三個請求引數。

給大家推薦一個好用的 BUG 監控工具Fundebug,歡迎免費試用!

五、伺服器處理請求並返回 HTTP 報文

1. 伺服器

伺服器是網路環境中的高效能運算機,它偵聽網路上的其他計算機(客戶機)提交的服務請求,並提供相應的服務,比如網頁服務、檔案下載服務、郵件服務、視訊服務。而客戶端主要的功能是瀏覽網頁、看視訊、聽音樂等等,兩者截然不同。 每臺伺服器上都會安裝處理請求的應用——web server。常見的 web server 產品有 apache、nginx、IIS 或 Lighttpd 等。 web server 擔任管控的角色,對於不同使用者傳送的請求,會結合配置檔案,把不同請求委託給伺服器上處理相應請求的程式進行處理(例如 CGI 指令碼,JSP 指令碼,servlets,ASP 指令碼,伺服器端 JavaScript,或者一些其它的伺服器端技術等),然後返回後臺程式處理產生的結果作為響應。

經典面試題:從 URL 輸入到頁面展現到底發生什麼?

2. MVC 後臺處理階段

後臺開發現在有很多框架,但大部分都還是按照 MVC 設計模式進行搭建的。

MVC 是一個設計模式,將應用程式分成三個核心部件:模型(model)-- 檢視(view)--控制器(controller),它們各自處理自己的任務,實現輸入、處理和輸出的分離。

經典面試題:從 URL 輸入到頁面展現到底發生什麼?

1、檢視(view)

它是提供給使用者的操作介面,是程式的外殼。

2、模型(model)

**模型主要負責資料互動。**在 MVC 的三個部件中,模型擁有最多的處理任務。一個模型能為多個檢視提供資料。

3、控制器(controller)

**它負責根據使用者從"檢視層"輸入的指令,選取"模型層"中的資料,然後對其進行相應的操作,產生最終結果。**控制器屬於管理者角色,從檢視接收請求並決定呼叫哪個模型構件去處理請求,然後再確定用哪個檢視來顯示模型處理返回的資料。

這三層是緊密聯絡在一起的,但又是互相獨立的,每一層內部的變化不影響其他層。每一層都對外提供介面(Interface),供上面一層呼叫。

至於這一階段發生什麼?簡而言之,首先瀏覽器傳送過來的請求先經過控制器,控制器進行邏輯處理和請求分發,接著會呼叫模型,這一階段模型會獲取 redis db 以及 MySQL 的資料,獲取資料後將渲染好的頁面,響應資訊會以響應報文的形式返回給客戶端,最後瀏覽器通過渲染引擎將網頁呈現在使用者面前。

3. http 響應報文

響應報文由響應行(request line)、響應頭部(header)、響應主體三個部分組成。如下圖所示:

經典面試題:從 URL 輸入到頁面展現到底發生什麼?

(1) 響應行包含:協議版本,狀態碼,狀態碼描述

狀態碼規則如下:

  • 1xx:指示資訊--表示請求已接收,繼續處理。
  • 2xx:成功--表示請求已被成功接收、理解、接受。
  • 3xx:重定向--要完成請求必須進行更進一步的操作。
  • 4xx:客戶端錯誤--請求有語法錯誤或請求無法實現。
  • 5xx:伺服器端錯誤--伺服器未能實現合法的請求。

(2) 響應頭部包含響應報文的附加資訊,由 名/值 對組成

(3) 響應主體包含回車符、換行符和響應返回資料,並不是所有響應報文都有響應資料

六、瀏覽器解析渲染頁面

瀏覽器拿到響應文字 HTML 後,接下來介紹下瀏覽器渲染機制

經典面試題:從 URL 輸入到頁面展現到底發生什麼?

瀏覽器解析渲染頁面分為一下五個步驟:

  • 根據 HTML 解析出 DOM 樹
  • 根據 CSS 解析生成 CSS 規則樹
  • 結合 DOM 樹和 CSS 規則樹,生成渲染樹
  • 根據渲染樹計算每一個節點的資訊
  • 根據計算好的資訊繪製頁面

1. 根據 HTML 解析 DOM 樹

  • 根據 HTML 的內容,將標籤按照結構解析成為 DOM 樹,DOM 樹解析的過程是一個深度優先遍歷。即先構建當前節點的所有子節點,再構建下一個兄弟節點。
  • 在讀取 HTML 文件,構建 DOM 樹的過程中,若遇到 script 標籤,則 DOM 樹的構建會暫停,直至指令碼執行完畢。

2. 根據 CSS 解析生成 CSS 規則樹

  • 解析 CSS 規則樹時 js 執行將暫停,直至 CSS 規則樹就緒。
  • 瀏覽器在 CSS 規則樹生成之前不會進行渲染。

3. 結合 DOM 樹和 CSS 規則樹,生成渲染樹

  • DOM 樹和 CSS 規則樹全部準備好了以後,瀏覽器才會開始構建渲染樹。
  • 精簡 CSS 並可以加快 CSS 規則樹的構建,從而加快頁面相應速度。

4. 根據渲染樹計算每一個節點的資訊(佈局)

  • 佈局:通過渲染樹中渲染物件的資訊,計算出每一個渲染物件的位置和尺寸
  • 迴流:在佈局完成後,發現了某個部分發生了變化影響了佈局,那就需要倒回去重新渲染。

5. 根據計算好的資訊繪製頁面

  • 繪製階段,系統會遍歷呈現樹,並呼叫呈現器的“paint”方法,將呈現器的內容顯示在螢幕上。
  • 重繪:某個元素的背景顏色,文字顏色等,不影響元素周圍或內部佈局的屬性,將只會引起瀏覽器的重繪。
  • 迴流:某個元素的尺寸發生了變化,則需重新計算渲染樹,重新渲染。

七、斷開連線

當資料傳送完畢,需要斷開 tcp 連線,此時發起 tcp 四次揮手

經典面試題:從 URL 輸入到頁面展現到底發生什麼?

  • 發起方向被動方傳送報文,Fin、Ack、Seq,表示已經沒有資料傳輸了。並進入 FIN_WAIT_1 狀態。(第一次揮手:由瀏覽器發起的,傳送給伺服器,我請求報文傳送完了,你準備關閉吧)
  • 被動方傳送報文,Ack、Seq,表示同意關閉請求。此時主機發起方進入 FIN_WAIT_2 狀態。(第二次揮手:由伺服器發起的,告訴瀏覽器,我請求報文接受完了,我準備關閉了,你也準備吧)
  • 被動方向發起方傳送報文段,Fin、Ack、Seq,請求關閉連線。並進入 LAST_ACK 狀態。(第三次揮手:由伺服器發起,告訴瀏覽器,我響應報文傳送完了,你準備關閉吧)
  • 發起方向被動方傳送報文段,Ack、Seq。然後進入等待 TIME_WAIT 狀態。被動方收到發起方的報文段以後關閉連線。發起方等待一定時間未收到回覆,則正常關閉。(第四次揮手:由瀏覽器發起,告訴伺服器,我響應報文接受完了,我準備關閉了,你也準備吧)

參考文章

關於Fundebug

Fundebug專注於JavaScript、微信小程式、微信小遊戲、支付寶小程式、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線,Fundebug累計處理了10億+錯誤事件,付費客戶有Google、360、金山軟體、百姓網等眾多品牌企業。歡迎大家免費試用

經典面試題:從 URL 輸入到頁面展現到底發生什麼?

相關文章