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

時間 2019-11-06

標籤前端面試補缺十二輸入 url 看到頁面發生全過程握手揮手詳解欄目快樂工作简体版

原文原文鏈接

前言

本系列最開始是爲了本身面試準備的.後來發現整理愈來愈多,差很少有十二萬字符,最後決定仍是分享出來給你們.html

爲了分享整理出來,花費了本身大量的時間,起碼是隻本身用的三倍時間.若是喜歡的話,歡迎收藏,關注我!謝謝!前端

文章連接

合集篇:

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

後續更新計劃

後續還會繼續添加設計模式,前端工程化,項目流程,部署,閉環,vue常考知識點 等內容.若是以爲內容不錯的話歡迎收藏,關注我!謝謝!web

求一分內推

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

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

整體來講分爲如下幾個過程:算法

1.瀏覽器的地址欄輸入URL並按下回車。數據庫

2.瀏覽器查找當前URL是否存在緩存，並比較緩存是否過時。json

3.DNS解析URL對應的IP。segmentfault

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（服務器端口號）
複製代碼

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 的數據包，表明「握手結束」（第三次握手，由瀏覽器發送，告訴服務器，我立刻就發了，準備接受吧）

完成TCP鏈接後開使向服務器進行請求

爲啥須要三次握手

謝希仁著《計算機網絡》中講「三次握手」的目的是「爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤」。

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

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

服務器在收到瀏覽器發送的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字符串，而後瀏覽器本身解析並渲染。

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

8.關閉TCP鏈接（四次揮手）

經過四次揮手關閉鏈接(FIN ACK, ACK, FIN ACK, ACK)。

第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。(第一次揮手：由瀏覽器發起的，發送給服務器，我請求報文發送完了，你準備關閉吧)

第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。(第二次揮手：由服務器發起的，告訴瀏覽器，我請求報文接受完了，我準備關閉了，你也準備吧)

第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。(第三次揮手：由服務器發起，告訴瀏覽器，我響應報文發送完了，你準備關閉吧)

第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。(第四次揮手：由瀏覽器發起，告訴服務器，我響應報文接受完了，我準備關閉了，你也準備吧)