點擊上方“Coder編程”,選擇“置頂公衆號”
技術文章第一時間送達!
地址:https://www.cnblogs.com/xuzekun/p/7527736.html
作者:白日夢想家12138
當我們在web瀏覽器的地址欄中輸入:www.baidu.com,然後回車,到底發生了什麼
過程概覽
1.對www.baidu.com這個網址進行DNS域名解析,得到對應的IP地址
2.根據這個IP,找到對應的服務器,發起TCP的三次握手
3.建立TCP連接後發起HTTP請求
4.服務器響應HTTP請求,瀏覽器得到html代碼
5.瀏覽器解析html代碼,並請求html代碼中的資源(如js、css圖片等)(先得到html代碼,才能去找這些資源)
6.瀏覽器對頁面進行渲染呈現給用戶
注:1.DNS域名解析採用的是遞歸查詢的方式,過程是,先去找DNS緩存->緩存找不到就去找根域名服務器->根域名又會去找下一級,這樣遞歸查找之後,找到了,給我們的web瀏覽器
2.爲什麼HTTP協議要基於TCP來實現?TCP是一個端到端的可靠的面相連接的協議,HTTP基於傳輸層TCP協議不用擔心數據傳輸的各種問題(當發生錯誤時,會重傳)
3.最後一步瀏覽器是如何對頁面進行渲染的?a)解析html文件構成 DOM樹,b)解析CSS文件構成渲染樹, c)邊解析,邊渲染 , d)JS 單線程運行,JS有可能修改DOM結構,意味着JS執行完成前,後續所有資源的下載是沒有必要的,所以JS是單線程,會阻塞後續資源下載
下面我們來詳細看看這幾個過程的具體細節:
1.域名解析
a)首先會搜索瀏覽器自身的DNS緩存(緩存時間比較短,大概只有1分鐘,且只能容納1000條緩存)
b)如果瀏覽器自身的緩存裏面沒有找到,那麼瀏覽器會搜索系統自身的DNS緩存
c)如果還沒有找到,那麼嘗試從 hosts文件裏面去找
d)在前面三個過程都沒獲取到的情況下,就遞歸地去域名服務器去查找,具體過程如下
DNS優化:兩個方面:DNS緩存、DNS負載均衡
2.TCP連接(三次握手)
拿到域名對應的IP地址之後,User-Agent(一般指瀏覽器)會以一個隨機端口(1024<端口<65535)向服務器的WEB程序(常用的有httpd,nginx)等的80端口。這個連接請求(原始的http請求經過TCP/IP4層模型的層層封包)到達服務器端後(這中間有各種路由設備,局域網內除外),進入到網卡,然後是進入到內核的TCP/IP協議棧(用於識別連接請求,解封包,一層一層的剝開),還有可能要經過Netfilter防火牆(屬於內核的模塊)的過濾,最終達到WEB程序,最終建立了TCP/IP的連接
圖解:
具體可以翻閱前面關於 TCP三次握手和四次揮手的博客
3.建立TCP連接之後,發起HTTP請求
HTTP請求報文由三部分組成:請求行,請求頭和請求正文
請求行:用於描述客戶端的請求方式,請求的資源名稱以及使用的HTTP協議的版本號(例:GET/books/java.html HTTP/1.1)
請求頭:用於描述客戶端請求哪臺主機,以及客戶端的一些環境信息等
注:這裏提一個請求頭 Connection,Connection設置爲 keep-alive用於說明 客戶端這邊設置的是,本次HTTP請求之後並不需要關閉TCP連接,這樣可以使下次HTTP請求使用相同的TCP通道,節省TCP建立連接的時間
請求正文:當使用POST, PUT等方法時,通常需要客戶端向服務器傳遞數據。這些數據就儲存在請求正文中(GET方式是保存在url地址後面,不會放到這裏)
4.服務器端響應http請求,瀏覽器得到html代碼
HTTP響應也由三部分組成:狀態碼,響應頭和實體內容
狀態碼:狀態碼用於表示服務器對請求的處理結果
列舉幾種常見的:200(沒有問題) 302(要你去找別人) 304(要你去拿緩存) 307(要你去拿緩存) 403(有這個資源,但是沒有訪問權限) 404(服務器沒有這個資源) 500(服務器這邊有問題)
若干響應頭:響應頭用於描述服務器的基本信息,以及客戶端如何處理數據
實體內容:服務器返回給客戶端的數據
注:html資源文件應該不是通過 HTTP響應直接返回去的,應該是通過nginx通過io操作去拿到的吧
5.瀏覽器解析html代碼,並請求html代碼中的資源
瀏覽器拿到html文件後,就開始解析其中的html代碼,遇到js/css/image等靜態資源時,就向服務器端去請求下載(會使用多線程下載,每個瀏覽器的線程數不一樣),這是時候就用上 keep-alive特性了,建立一次HTTP連接,可以請求多個資源,下載資源的順序就是按照代碼裏面的順序,但是由於每個資源大小不一樣,而瀏覽器又是多線程請求請求資源,所以這裏顯示的順序並不一定是代碼裏面的順序。
6.瀏覽器對頁面進行渲染呈現給用戶
最後,瀏覽器利用自己內部的工作機制,把請求的靜態資源和html代碼進行渲染,渲染之後呈現給用戶
瀏覽器是一個邊解析邊渲染的過程。首先瀏覽器解析HTML文件構建DOM樹,然後解析CSS文件構建渲染樹,等到渲染樹構建完成後,瀏覽器開始佈局渲染樹並將其繪製到屏幕上。這個過程比較複雜,涉及到兩個概念: reflow(迴流)和repain(重繪)。DOM節點中的各個元素都是以盒模型的形式存在,這些都需要瀏覽器去計算其位置和大小等,這個過程稱爲relow;當盒模型的位置,大小以及其他屬性,如顏色,字體,等確定下來之後,瀏覽器便開始繪製內容,這個過程稱爲repain。頁面在首次加載時必然會經歷reflow和repain。reflow和repain過程是非常消耗性能的,尤其是在移動設備上,它會破壞用戶體驗,有時會造成頁面卡頓。所以我們應該儘可能少的減少reflow和repain。
JS的解析是由瀏覽器中的JS解析引擎完成的。JS是單線程運行,JS有可能修改DOM結構,意味着JS執行完成前,後續所有資源的下載是沒有必要的,所以JS是單線程,會阻塞後續資源下載
自此一次完整的HTTP事務宣告完成.
總結:
域名解析 --> 發起TCP的3次握手 --> 建立TCP連接後發起http請求 --> 服務器響應http請求,瀏覽器得到html代碼 --> 瀏覽器解析html代碼,並請求html代碼中的資源(如js、css、圖片等) --> 瀏覽器對頁面進行渲染呈現給用戶
推薦
文末
歡迎關注個人微信公衆號:Coder編程
歡迎關注Coder編程公衆號,主要分享數據結構與算法、Java相關知識體系、框架知識及原理、Spring全家桶、微服務項目實戰、DevOps實踐之路、每日一篇互聯網大廠面試或筆試題以及PMP項目管理知識等。更多精彩內容正在路上~
新建了一個qq羣:315211365,歡迎大家進羣交流一起學習。謝謝了!也可以介紹給身邊有需要的朋友。文章收錄至
Github: https://github.com/CoderMerlin/coder-programming
Gitee: https://gitee.com/573059382/coder-programming
歡迎關注並star~
我知道你 “在看”