前端面試查漏補缺--(十二) 從輸入URL到看到頁面發生的全過程(含三握手,四揮手詳解)

shotCat發表於2019-02-24

前言

本系列最開始是為了自己面試準備的.後來發現整理越來越多,差不多有十二萬字元,最後決定還是分享出來給大家.

為了分享整理出來,花費了自己大量的時間,起碼是隻自己用的三倍時間.如果喜歡的話,歡迎收藏,關注我!謝謝!

文章連結

合集篇:

前端面試查漏補缺--Index篇(12萬字元合集) 包含目前已寫好的系列其他十幾篇文章.後續新增值文章不會再在每篇新增連結,強烈建議議點贊,關注合集篇!!!!,謝謝!~

後續更新計劃

後續還會繼續新增設計模式,前端工程化,專案流程,部署,閉環,vue常考知識點 等內容.如果覺得內容不錯的話歡迎收藏,關注我!謝謝!

求一份內推

目前本人也在準備跳槽,希望各位大佬和HR小姐姐可以內推一份靠譜的武漢 前端崗位!郵箱:bupabuku@foxmail.com.謝謝啦!~

從輸入URL到看到頁面發生的全過程

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

1.瀏覽器的位址列輸入URL並按下回車。

2.瀏覽器查詢當前URL是否存在快取,並比較快取是否過期。

3.DNS解析URL對應的IP。

4.根據IP建立TCP連線(三次握手)。

5.HTTP發起請求。

6.伺服器處理請求,瀏覽器接收HTTP響應。

7.瀏覽器解析渲染頁面。

8.關閉TCP連線(四次揮手)。

1, 輸入URL並按下回車。

url一般包含這幾個部分.可以順帶提以下知識點

知識點:

  • 協議:主要是HTTP協議,HTTPS協議,FTP協議,FILe協議
  • 域名: 定義因特網域名,比如 google.com
  • 埠號:通常預設都是隱藏的 http預設埠號為80 https預設埠號為443
  • 補充: 同源策略 - 在前端進行資料請求時,由於瀏覽器的同源策略,協議,域名,埠號有一個不同會存在跨域請求,需要進行跨域處理

2.瀏覽器查詢當前URL是否存在快取,並比較快取是否過期。

瀏覽器首先查詢當前URL是否有快取,有的話,再查詢是否過期,沒過期則讀快取.過期了則訪問web伺服器.

知識點: 詳細解釋可以看本系列的"瀏覽器快取"這節.

3.DNS解析URL對應的IP。

解析過程:

1.首先瀏覽器會檢視自己的DNS快取是否存在.

2.如果沒有找到,瀏覽器會先查詢本地hosts檔案是否有這個網址對映關係,如果有就呼叫這個IP地址對映,完成域名解析。

3.如果沒有找到,則會在作業系統快取中查詢本地的DNS解析器快取,如果找到則返回。

4.如果沒有找到,則會在路由器快取中進行查詢,如果找到則返回。

5.如果還是沒有找到,則會按ISP(運營商)DNS快取、根域名伺服器、頂級域名伺服器、主域名伺服器的順序,逐步讀取快取,直到拿到IP地址.

為什麼要DNS解析

網際網路上每一臺計算機的唯一標識是它的IP地址,但是IP地址並不方便記憶。使用者更喜歡用方便記憶的網址去尋找網際網路上的其它計算機,也就是上面提到的百度的網址。所以網際網路設計者需要在使用者的方便性與可用性方面做一個權衡,這個權衡就是一個網址到IP地址的轉換,這個過程就是DNS解析,即實現了網址到IP地址的轉換

IP 地址

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

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

什麼是域名解析

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

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

相關名詞解釋:

  • 瀏覽器快取:瀏覽器會按照一定的頻率快取 DNS 記錄。
  • hosts檔案: Hosts是一個沒有副檔名的系統檔案,可以用記事本等工具開啟,其作用就是將一些常用的網址域名與其對應的IP地址建立一個關聯“資料庫”.一般位於系統盤C:\Windows\System32\drivers\etc中,如果進去沒有看到Hos檔案,是因為某些系統將Host檔案隱藏了。
  • 作業系統快取:如果瀏覽器快取中找不到需要的 DNS 記錄,那就去作業系統的DNS快取中讀取該域名所對應的IP地址。
  • 路由快取:路由器也有 DNS 快取。
  • ISP 的 DNS 伺服器:ISP 是網際網路服務提供商(Internet Service Provider)的簡稱,ISP 有專門的 DNS 伺服器應對 DNS 查詢請求。
  • 根伺服器:ISP 的 DNS 伺服器還找不到的話,它就會向根伺服器發出請求,進行遞迴查詢(DNS 伺服器先問根域名伺服器.com 域名伺服器的 IP 地址,然後再問.baidu 域名伺服器,依次類推)

4.根據IP建立TCP連線(三次握手)

三次握手的過程:

  • 客戶端傳送一個syn包:即帶有 SYN=1,Seq=x 的資料包到伺服器埠,並進入SYN_SENT狀態,等待伺服器確認;(第一次握手,由瀏覽器發起,告訴伺服器我要傳送請求了)
  • 伺服器收到syn包,必須確認客戶的SYN,同時發回一個帶 SYN=1, ACK=x+1, Seq=y 的響應包以示傳達確認資訊,即SYN+ACK包,此時伺服器進入SYN_RECV狀態;(第二次握手,由伺服器發起,告訴瀏覽器我準備接受了,你趕緊傳送吧)
  • 客戶端收到伺服器的SYN+ACK包,向伺服器傳送確認包ACK,即回傳一個帶 ACK=y+1, Seq=Z 的資料包,代表“握手結束”(第三次握手,由瀏覽器傳送,告訴伺服器,我馬上就發了,準備接受吧)

前端面試查漏補缺--(十二) 從輸入URL到看到頁面發生的全過程(含三握手,四揮手詳解)

完成TCP連線後開使向伺服器進行請求

為啥需要三次握手

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

5.HTTP發起請求 && 6.伺服器處理請求,瀏覽器接收HTTP響應。

  • 完整的HTTP請求包含請求起始行、請求頭部、請求主體三部分。

前端面試查漏補缺--(十二) 從輸入URL到看到頁面發生的全過程(含三握手,四揮手詳解)

  • 伺服器在收到瀏覽器傳送的HTTP請求之後,會將收到的HTTP報文封裝成HTTP的Request物件,並通過不同的Web伺服器進行處理,處理完的結果以HTTP的Response物件返回,主要包括狀態碼,響應頭,響應報文三個部分。
  • 綜合起來,完整的HTTP請報文一般包括了:通用頭部請求/響應頭部請求/響應體

通用頭部

包括如下:

//General 

Request Url: 請求的web伺服器地址

Request Method: 請求方式
(Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE)

Status Code: 請求的返回狀態碼,如200代表成功

Remote Address: 請求的遠端伺服器地址(會轉為IP)

Referrer Policy: (引用策略)用來監管哪些訪問來源資訊 (IE暫不支援)
複製程式碼

請求/響應頭部:

常用的請求頭部(部分):

Accept: 接收型別,表示瀏覽器支援的MIME型別
(對標服務端返回的Content-Type)
Accept-Encoding:瀏覽器支援的壓縮型別,如gzip等,超出型別不能接收
Content-Type:客戶端傳送出去實體內容的型別
Cache-Control: 指定請求和響應遵循的快取機制,如no-cache
If-Modified-Since:對應服務端的Last-Modified,用來匹配看檔案是否變動,只能精確到1s之內,http1.0中
Expires:快取控制,在這個時間內不會請求,直接使用快取,http1.0,而且是服務端時間
Max-age:代表資源在本地快取多少秒,有效時間內不會請求,而是使用快取,http1.1中
If-None-Match:對應服務端的ETag,用來匹配檔案內容是否改變(非常精確),http1.1中
Cookie: 有cookie並且同域訪問時會自動帶上
Connection: 當瀏覽器與伺服器通訊時對於長連線如何進行處理,如keep-alive
Host:請求的伺服器URL
Origin:最初的請求是從哪裡發起的(只會精確到埠),Origin比Referer更尊重隱私
Referer:該頁面的來源URL(適用於所有型別的請求,會精確到詳細頁面地址,csrf攔截常用到這個欄位)
User-Agent:使用者客戶端的一些必要資訊,如UA頭部等

複製程式碼

常用的響應頭部(部分):

Access-Control-Allow-Headers: 伺服器端允許的請求Headers
Access-Control-Allow-Methods: 伺服器端允許的請求方法
Access-Control-Allow-Origin: 伺服器端允許的請求Origin頭部(譬如為*)
Content-Type:服務端返回的實體內容的型別
Date:資料從伺服器傳送的時間
Cache-Control:告訴瀏覽器或其他客戶,什麼環境可以安全的快取文件
Last-Modified:請求資源的最後修改時間
Expires:應該在什麼時候認為文件已經過期,從而不再快取它
Max-age:客戶端的本地資源應該快取多少秒,開啟了Cache-Control後有效
ETag:請求變數的實體標籤的當前值
Set-Cookie:設定和頁面關聯的cookie,伺服器通過這個頭部把cookie傳給客戶端
Keep-Alive:如果客戶端有keep-alive,服務端也會有響應(如timeout=38)
Server:伺服器的一些相關資訊
複製程式碼

一般來說,請求頭部和響應頭部是匹配分析的。

譬如,請求頭部的Accept要和響應頭部的Content-Type匹配,否則會報錯

譬如,跨域請求時,請求頭部的Origin要匹配響應頭部的Access-Control-Allow-Origin,否則會報跨域錯誤

譬如,在使用快取時,請求頭部的If-Modified-Since、If-None-Match分別和響應頭部的Last-Modified、ETag對應

請求/響應實體:

http請求時,除了頭部,還有訊息實體,一般來說

請求實體中會將一些需要的引數都放入進入(用於post請求)。

譬如實體中可以放引數的序列化形式(a=1&b=2這種),或者直接放表單物件(Form Data物件,上傳時可以夾雜引數以及檔案),等等

而一般響應實體中,就是放服務端需要傳給客戶端的內容

一般現在的介面請求時,實體中就是對於的資訊的json格式,而像頁面請求這種,裡面就是直接放了一個html字串,然後瀏覽器自己解析並渲染。

前端面試查漏補缺--(十二) 從輸入URL到看到頁面發生的全過程(含三握手,四揮手詳解)

7.瀏覽器解析渲染頁面

流程簡述

瀏覽器核心拿到內容後,渲染步驟大致可以分為以下幾步:

1. 解析HTML,構建DOM樹

2. 解析CSS,生成CSS規則樹

3. 合併DOM樹和CSS規則,生成render樹

4. 佈局render樹(Layout/reflow),負責各元素尺寸、位置的計算

5. 繪製render樹(paint),繪製頁面畫素資訊

6. 瀏覽器會將各層的資訊傳送給GPU,GPU會將各層合成(composite),顯示在螢幕上

PS:
reflow:也稱作layout,中文叫回流,一般意味著元素的內容、結構、位置或尺寸發生了變化,需要重新計算樣式和渲染樹,這個過程稱為reflow。

repaint:中文重繪,意味著元素髮生的改變只是影響了元素的一些外觀之類的時候(例如:背景色,邊框顏色,文字顏色等),此時只需要應用新樣式繪製這個元素就可以了。

複製程式碼

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”方法,將呈現器的內容顯示在螢幕上。
  • 重繪:某個元素的背景顏色,文字顏色等,不影響元素周圍或內部佈局的屬性,將只會引起瀏覽器的重繪。
  • 迴流:某個元素的尺寸發生了變化,則需重新計算渲染樹,重新渲染。

前端面試查漏補缺--(十二) 從輸入URL到看到頁面發生的全過程(含三握手,四揮手詳解)

8.關閉TCP連線(四次揮手)

通過四次揮手關閉連線(FIN ACK, ACK, FIN ACK, ACK)。

前端面試查漏補缺--(十二) 從輸入URL到看到頁面發生的全過程(含三握手,四揮手詳解)

  1. 第一次揮手:Client傳送一個FIN,用來關閉Client到Server的資料傳送,Client進入FIN_WAIT_1狀態。(第一次揮手:由瀏覽器發起的,傳送給伺服器,我請求報文傳送完了,你準備關閉吧)
  2. 第二次揮手:Server收到FIN後,傳送一個ACK給Client,確認序號為收到序號+1(與SYN相同,一個FIN佔用一個序號),Server進入CLOSE_WAIT狀態。(第二次揮手:由伺服器發起的,告訴瀏覽器,我請求報文接受完了,我準備關閉了,你也準備吧)
  3. 第三次揮手:Server傳送一個FIN,用來關閉Server到Client的資料傳送,Server進入LAST_ACK狀態。(第三次揮手:由伺服器發起,告訴瀏覽器,我響應報文傳送完了,你準備關閉吧)
  4. 第四次揮手:Client收到FIN後,Client進入TIME_WAIT狀態,接著傳送一個ACK給Server,確認序號為收到序號+1,Server進入CLOSED狀態,完成四次揮手。(第四次揮手:由瀏覽器發起,告訴伺服器,我響應報文接受完了,我準備關閉了,你也準備吧)

感謝及參考

相關文章