https://cloud.tencent.com/developer/article/1396399css
http://www.javashuo.com/article/p-elokxkxq-do.htmlhtml
https://cloud.tencent.com/developer/article/1343200前端
https://cloud.tencent.com/developer/article/1166319nginx
從 URL 輸入到頁面展示到底發生什麼?
摘要: 經典面試題。git
- 原文:從 URL 輸入到頁面展示到底發生什麼?
- 做者:浪裏行舟
Fundebug經受權轉載,版權歸原做者全部。github
前言
打開瀏覽器從輸入網址到網頁呈如今你們面前,背後到底發生了什麼?經歷怎麼樣的一個過程?先給你們來張整體流程圖,具體步驟請看下文分解!web
本文首發地址爲GitHub 博客,寫文章不易,請多多支持與關注!面試
整體來講分爲如下幾個過程:ajax
- DNS 解析:將域名解析成 IP 地址
- TCP 鏈接:TCP 三次握手
- 發送 HTTP 請求
- 服務器處理請求並返回 HTTP 報文
- 瀏覽器解析渲染頁面
- 斷開鏈接:TCP 四次揮手
1、URL 究竟是啥
URL(Uniform Resource Locator),統一資源定位符,用於定位互聯網上資源,俗稱網址。好比 http://www.w3school.com.cn/ht...,遵照如下的語法規則:redis
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 - 定義文檔/資源的名稱
2、域名解析(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 域名服務器,依次類推)
4. 小結
瀏覽器經過向 DNS 服務器發送域名,DNS 服務器查詢到與域名相對應的 IP 地址,而後返回給瀏覽器,瀏覽器再將 IP 地址打在協議上,同時請求參數也會在協議搭載,而後一併發送給對應的服務器。接下來介紹向服務器發送 HTTP 請求階段,HTTP 請求分爲三個部分:TCP 三次握手、http 請求響應信息、關閉 TCP 鏈接。
3、TCP 三次握手
在客戶端發送數據以前會發起 TCP 三次握手用以同步客戶端和服務端的序列號和確認號,並交換 TCP 窗口大小信息。
1. TCP 三次握手的過程以下:
- 客戶端發送一個帶 SYN=1,Seq=X 的數據包到服務器端口(第一次握手,由瀏覽器發起,告訴服務器我要發送請求了)
- 服務器發回一個帶 SYN=1, ACK=X+1, Seq=Y 的響應包以示傳達確認信息(第二次握手,由服務器發起,告訴瀏覽器我準備接受了,你趕忙發送吧)
- 客戶端再回傳一個帶 ACK=Y+1, Seq=Z 的數據包,表明「握手結束」(第三次握手,由瀏覽器發送,告訴服務器,我立刻就發了,準備接受吧)
2. 爲啥須要三次握手
謝希仁著《計算機網絡》中講「三次握手」的目的是「爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端,於是產生錯誤」。
4、發送 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 三個請求參數。
給你們推薦一個好用的 BUG 監控工具Fundebug,歡迎免費試用!
5、服務器處理請求並返回 HTTP 報文
1. 服務器
服務器是網絡環境中的高性能計算機,它偵聽網絡上的其餘計算機(客戶機)提交的服務請求,並提供相應的服務,好比網頁服務、文件下載服務、郵件服務、視頻服務。而客戶端主要的功能是瀏覽網頁、看視頻、聽音樂等等,二者大相徑庭。 每臺服務器上都會安裝處理請求的應用——web server。常見的 web server 產品有 apache、nginx、IIS 或 Lighttpd 等。
web server 擔任管控的角色,對於不一樣用戶發送的請求,會結合配置文件,把不一樣請求委託給服務器上處理相應請求的程序進行處理(例如 CGI 腳本,JSP 腳本,servlets,ASP 腳本,服務器端 JavaScript,或者一些其它的服務器端技術等),而後返回後臺程序處理產生的結果做爲響應。
2. MVC 後臺處理階段
後臺開發如今有不少框架,但大部分都仍是按照 MVC 設計模式進行搭建的。
MVC 是一個設計模式,將應用程序分紅三個核心部件:模型(model)-- 視圖(view)--控制器(controller),它們各自處理本身的任務,實現輸入、處理和輸出的分離。
一、視圖(view)
它是提供給用戶的操做界面,是程序的外殼。
二、模型(model)
模型主要負責數據交互。在 MVC 的三個部件中,模型擁有最多的處理任務。一個模型能爲多個視圖提供數據。
三、控制器(controller)
它負責根據用戶從"視圖層"輸入的指令,選取"模型層"中的數據,而後對其進行相應的操做,產生最終結果。控制器屬於管理者角色,從視圖接收請求並決定調用哪一個模型構件去處理請求,而後再肯定用哪一個視圖來顯示模型處理返回的數據。
這三層是緊密聯繫在一塊兒的,但又是互相獨立的,每一層內部的變化不影響其餘層。每一層都對外提供接口(Interface),供上面一層調用。
至於這一階段發生什麼?簡而言之,首先瀏覽器發送過來的請求先通過控制器,控制器進行邏輯處理和請求分發,接着會調用模型,這一階段模型會獲取 redis db 以及 MySQL 的數據,獲取數據後將渲染好的頁面,響應信息會以響應報文的形式返回給客戶端,最後瀏覽器經過渲染引擎將網頁呈如今用戶面前。
3. http 響應報文
響應報文由響應行(request line)、響應頭部(header)、響應主體三個部分組成。以下圖所示:
(1) 響應行包含:協議版本,狀態碼,狀態碼描述
狀態碼規則以下:
- 1xx:指示信息--表示請求已接收,繼續處理。
- 2xx:成功--表示請求已被成功接收、理解、接受。
- 3xx:重定向--要完成請求必須進行更進一步的操做。
- 4xx:客戶端錯誤--請求有語法錯誤或請求沒法實現。
- 5xx:服務器端錯誤--服務器未能實現合法的請求。
(2) 響應頭部包含響應報文的附加信息,由 名/值 對組成
(3) 響應主體包含回車符、換行符和響應返回數據,並非全部響應報文都有響應數據
6、瀏覽器解析渲染頁面
瀏覽器拿到響應文本 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」方法,將呈現器的內容顯示在屏幕上。
- 重繪:某個元素的背景顏色,文字顏色等,不影響元素周圍或內部佈局的屬性,將只會引發瀏覽器的重繪。
- 迴流:某個元素的尺寸發生了變化,則需從新計算渲染樹,從新渲染。
7、斷開鏈接
當數據傳送完畢,須要斷開 tcp 鏈接,此時發起 tcp 四次揮手。
- 發起方向被動方發送報文,Fin、Ack、Seq,表示已經沒有數據傳輸了。並進入 FIN_WAIT_1 狀態。(第一次揮手:由瀏覽器發起的,發送給服務器,我請求報文發送完了,你準備關閉吧)
- 被動方發送報文,Ack、Seq,表示贊成關閉請求。此時主機發起方進入 FIN_WAIT_2 狀態。(第二次揮手:由服務器發起的,告訴瀏覽器,我請求報文接受完了,我準備關閉了,你也準備吧)
- 被動方向發起方發送報文段,Fin、Ack、Seq,請求關閉鏈接。並進入 LAST_ACK 狀態。(第三次揮手:由服務器發起,告訴瀏覽器,我響應報文發送完了,你準備關閉吧)
- 發起方向被動方發送報文段,Ack、Seq。而後進入等待 TIME_WAIT 狀態。被動方收到發起方的報文段之後關閉鏈接。發起方等待必定時間未收到回覆,則正常關閉。(第四次揮手:由瀏覽器發起,告訴服務器,我響應報文接受完了,我準備關閉了,你也準備吧)
參考文章
第一種解釋:
通常會經歷如下幾個過程:
一、首先,在瀏覽器地址欄中輸入url
二、瀏覽器先查看瀏覽器緩存-系統緩存-路由器緩存,若是緩存中有,會直接在屏幕中顯示頁面內容。若沒有,則跳到第三步操做。
三、在發送http請求前,須要域名解析(DNS解析)(DNS(域名系統,Domain Name System)是互聯網的一項核心服務,它做爲能夠將域名和IP地址相互映射的一個分佈式數據庫,可以令人更方便的訪問互聯網,而不用去記住IP地址。),解析獲取相應的IP地址。
dns也是能夠進行優化加載速度的
四、瀏覽器向服務器發起tcp鏈接,與瀏覽器創建tcp三次握手。(TCP即傳輸控制協議。TCP鏈接是互聯網鏈接協議集的一種。)
五、握手成功後,瀏覽器向服務器發送http請求,請求數據包。
六、服務器處理收到的請求,將數據返回至瀏覽器
七、瀏覽器收到HTTP響應
八、讀取頁面內容,瀏覽器渲染,解析html源碼
九、生成Dom樹、解析css樣式、js交互
十、客戶端和服務器交互
十一、ajax查詢
其中,步驟2的具體過程是:
- 瀏覽器緩存:瀏覽器會記錄DNS一段時間,所以,只是第一個地方解析DNS請求;
- 操做系統緩存:若是在瀏覽器緩存中不包含這個記錄,則會使系統調用操做系統,獲取操做系統的記錄(保存最近的DNS查詢緩存);
- 路由器緩存:若是上述兩個步驟均不能成功獲取DNS記錄,繼續搜索路由器緩存;
- ISP緩存:若上述均失敗,繼續向ISP搜索。
第二種解釋:
第一步:客戶機提出域名解析請求,並將該請求發送給本地的域名服務器。 第二步:當本地的域名服務器收到請求後,就先查詢本地的緩存,若是有該紀錄項,則本地的域名服務器就直接把查詢的結果返回。 第三步:若是本地的緩存中沒有該紀錄,則本地域名服務器就直接把請求發給根域名服務器,而後根域名服務器再返回給本地域名服務器一個所查詢域(根的子域)的主域名服務器的地址。 第四步:本地服務器再向上一步返回的域名服務器發送請求,而後接受請求的服務器查詢本身的緩存,若是沒有該紀錄,則返回相關的下級的域名服務器的地址。 第五步:重複第四步,直到找到正確的紀錄。