從URL輸入到頁面展現到底發生什么?

前言

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


從URL輸入到頁面展現

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

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

一、URL 到底是啥

URL(Uniform Resource Locator),統一資源定位符,用于定位互聯網上資源,俗稱網址。
比如 http://www.w3school.com.cn/html/index.asp,遵守以下的語法規則:

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 域名服務器,依次類推)
DNS解析流程

4. 小結

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

三、TCP 三次握手

在客戶端發送數據之前會發起 TCP 三次握手用以同步客戶端和服務端的序列號和確認號,并交換 TCP 窗口大小信息

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)、請求體四個部分組成,如下圖所示:

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 三個請求參數。

五、服務器處理請求并返回 HTTP 報文

1. 服務器

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

服務器和客戶端區別.png

2.MVC 后臺處理階段

后臺開發現在有很多框架,但大部分都還是按照 MVC 設計模式進行搭建的。
MVC 是一個設計模式,將應用程序分成三個核心部件:模型(model)-- 視圖(view)--控制器(controller),它們各自處理自己的任務,實現輸入、處理和輸出的分離。


MVC架構

1、視圖(view)

它是提供給用戶的操作界面,是程序的外殼。

2、模型(model)

模型主要負責數據交互。在 MVC 的三個部件中,模型擁有最多的處理任務。一個模型能為多個視圖提供數據。

3、控制器(controller)

它負責根據用戶從"視圖層"輸入的指令,選取"模型層"中的數據,然后對其進行相應的操作,產生最終結果。控制器屬于管理者角色,從視圖接收請求并決定調用哪個模型構件去處理請求,然后再確定用哪個視圖來顯示模型處理返回的數據。
這三層是緊密聯系在一起的,但又是互相獨立的,每一層內部的變化不影響其他層。每一層都對外提供接口(Interface),供上面一層調用。
至于這一階段發生什么?簡而言之,首先瀏覽器發送過來的請求先經過控制器,控制器進行邏輯處理和請求分發,接著會調用模型,這一階段模型會獲取 redis db 以及 MySQL 的數據,獲取數據后將渲染好的頁面,響應信息會以響應報文的形式返回給客戶端,最后瀏覽器通過渲染引擎將網頁呈現在用戶面前。

3.http 響應報文

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


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

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

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

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

六、瀏覽器解析渲染頁面

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

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

  • 根據 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 四次揮手

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

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

參考文章

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,428評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,024評論 3 413
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,285評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,548評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,328評論 6 404
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,878評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 42,971評論 3 439
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,098評論 0 286
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,616評論 1 331
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,554評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,725評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,243評論 5 355
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 43,971評論 3 345
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,361評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,613評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,339評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,695評論 2 370

推薦閱讀更多精彩內容