瀏覽器輸入URL到展示頁面過程

一. 網絡通信

1. 在瀏覽器中輸入URL

 用戶輸入URL,例如https://www.baidu.com. 其中https為協(xié)議, www.baidu.com為網絡地址,及指出需要的網絡資源在那臺計算機上.

2. 應用層DNS解析域名

 客戶端先檢查本地是否有對應的IP地址,若找到側返回對應的IP地址.若沒有找到則請求上級DNS服務器,直到找到根節(jié)點

3. 客戶端發(fā)送https請求

  HTTP請求包括請求報頭和請求主體兩個部分,其中請求報頭包含了重要的信息,包括請求的方法(GET/ POST), 目標URL, 遵循的協(xié)議(http/https/ftp...),返回的信息是否需要緩存,以及客戶端是否發(fā)送cookie等

4. 打開一個socket與目標IP地址, 端口建立TCP連接

  位于傳輸層的TCP協(xié)議為傳輸報文提供可靠的字節(jié)流服務.它為了方便傳輸,將大塊的數據分割成以報文段為單位的數據進行管理,并為他們編號,方便服務器接受的時候能準確的還原報文信息. TCP協(xié)議通過"三次握手"等方法保證傳輸的可靠性.

   "三次握手"的過程,發(fā)送端先發(fā)送一個帶SYN標志的數據包給接收端,在一定的延遲時間內等待接受的回復. 接收端收到數據包后,傳回一個帶SYN/ACK標志的數據包以示傳達確認信息. 接收方收到后再發(fā)送一個帶ACK標志的數據包給接收方以示握手成功. 在這個過程中,如果發(fā)送端在規(guī)定延遲時間內沒有收到回復則默認接受方沒有收到請求,而再次發(fā)送,知道收到回復為止.

5. 網絡層IP協(xié)議查詢MAC地址

  IP協(xié)議的作用就是把TCP分割好的各種數據包傳送給接收方.而要保證確實能傳到接收方還需要接收方的MAC地址,也就是物理地址. IP地址和MAC地址是一一對應的關系,一個網絡設備的IP地址可以更換,但是MAC地址一般是固定不變的. ARP協(xié)議可以將IP地址解析成對應的MAC地址. 當通訊的雙方不在同一個局域網時,需要多次中轉才能到達最終的目標,在中轉的過程中需要通過下一個中轉站的MAC地址來搜索下一個中轉目標.

6. 數據到達數據鏈層(tcp建立連接后,發(fā)送http請求)

  再找到對方的MAC地址后,就將數據發(fā)送到數據鏈層傳輸. 這時,客戶端發(fā)送請求的階段結束.

7. 服務器接受數據

  接收端的服務器在鏈路層接收到數據包,在層層向上直到應用層. 這過程中包括在運輸層通過TCP協(xié)議將分段的數據包重新組成原來的HTTP請求報文.

8. 服務器響應請求

 服務器接收到客戶端發(fā)送的請求,查找客戶端請求的資源,并返回響應報文,響應報文中包括一個重要的信息----狀態(tài)碼.狀態(tài)碼有三位數字組成,其中比較常見的200 ok表示請求成功. 301表示永久重定向,即請求的資源已經永久的轉移到新的位置. 再返回301狀態(tài)碼的同時,響應報文也會附帶重定向的URL,客戶端接收到后將http請求的URL做相應的改變再重新發(fā)送. 404 not found 表示客戶端請求的資源找不到.

9. 服務器返回相應的文件

  對服務器響應進行解碼,根據資源類型決定如何處理, 頁面渲染.

二. 頁面渲染

  現(xiàn)在瀏覽器渲染頁面的過程是這樣的:解析HTML以構建DOM樹->構建渲染樹->布局渲染樹->繪制渲染樹

  DOM樹是由HTML文件中的標簽排列組成,渲染樹是在DOM樹中加入CSS或HTML中的style樣式而形成的.渲染樹只包含需要顯示在頁面中的DOM元素,像<head>元素或display屬性值為none的元素都不在渲染樹中.

  在瀏覽器還沒有接收到完整的HTML文件時,它就開始渲染頁面了,在遇到外部鏈入的腳本標簽或樣式標簽或圖片,會再次發(fā)送http請求重復上述的步驟. 在收到CSS文件后會對已經渲染的頁面重新渲染,加入他們應有的樣式,圖片文件加載完成立刻顯示在相應的位置. 在這一過程可能會觸發(fā)頁面的重繪或者重排.
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容