【網路】瀏覽器輸入URL到展示頁面全過程（含網際網路協議及HTTPS簡介）

眼已望穿發表於2018-07-03
瀏覽器協議HTTP

1 簡介

HTTP(Hypertext Transfer Protocol) 超文字傳輸協議，是全球資訊網的基礎，在瀏覽器中我們主要是用 HTTP 以及 HTTPS 進行網路訪問，那麼我們在瀏覽器的位址列輸入一個 URL到回車展示給我們頁面的過程發生了什麼呢？

2 URL 介紹

假設眾所周和，網際網路的資源是由 URL 定位讓我們訪問的，URL 就是統一資源定位符。一般我們訪問 baidu.com，就可以訪問到百度的首頁，最後訪問的實際完整地址是 https://www.baidu.com:443 完整的 URL 構成如下：

https://www.baidu.com:443/test/demo.html?name=lilei&age=23/#hi

模式協議(https) + 域名部分(www.baidu.com) + 埠部分(443) + 虛擬目錄(/test) + 檔名部分(/demo.html) + 引數部分(?name=lilei&age=23) + 錨點部分(#hi)

3 DNS 查詢

以 chrome 瀏覽器為例，當輸入 baidu.com 的時候，我們實際訪問的是 14.215.177.39，這是百度的 IP 地址，從 baidu.com 到 14.215.177.39 的過程就是一個 DNS 解析的過程。

首先會從瀏覽器裡 DNS 快取查詢，chrome://dns/，一旦查詢到了就完成了這個解析過程，但是如果沒有呢？ 那麼接著會從電腦本地的 hosts 檔案中查詢，以下為 windows 的 hosts 檔案，最後一行是我加的。

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

# localhost name resolution is handled within DNS itself.
#	127.0.0.1 localhost
#	::1 localhost
14.215.177.39 baidu.com // 這裡為例子演示
複製程式碼

可以在這裡改變這個 IP 地址，那麼就訪問不到百度首頁了。像最簡單的科學上 google 的方法就可以通過修改 hosts 檔案達到這個效果。

一般 hosts 檔案是沒有這個解析地址的，於是只能接著向上查詢運營商的解析，例如電信聯通移動以及著名的114。像這裡，有時候手機瀏覽器訪問網頁會出現奇奇怪怪的廣告，那麼很大可能是運營商 DNS 劫持，可以通過手動設定 DNS (例如 114.114.114.114) 避免。

到此，DNS 查詢過程就完成了，得到了域名對應的 IP 地址。

4 網際網路協議

在介紹接下來的三次握手之前先簡單瞭解一下計算網路協議，在分層中有4層 5層 7層等之分，我們這裡按 5 層來分析。

注: 該部分下主要內容和部分圖片來自阮一峰老師的部落格和圖解HTTP

  • 應用層
  • 傳輸層
  • 網路層
  • 鏈路層
  • 實體層

以下省去了實體層

網際網路協議簡圖

4.1 實體層

比較簡單，就是我們常見的光纜、電纜、無限電波等等物理連線。

4.2 鏈路層

位於實體層的上方，確定了 0 1 的分組方式。

4.2.1 乙太網協議

乙太網規定一組電訊號構成一個資料包，叫做“幀”，每一幀分成兩個部分：標頭(head)和資料(data)。 標頭說明資料包的傳送者、接受者，資料型別等等，而資料則是資料包的具體內容。

乙太網資料包

4.2.2 Mac 地址

乙太網資料包的標頭規定了傳送者和接受者，那麼是如何確定的呢？這裡就引入了 Mac 地址的概念。

乙太網規定了連入網路的所有裝置都必須具備“網路卡”介面，資料包都是從一塊網路卡傳遞到另一塊網路卡，網路卡的地址就是 Mac 地址。每一個 Mac 地址都是獨一無二的，具備了一對一的能力。

4.2.3 廣播

上面的情形只是理論上一個 Mac 地址對接另一個 Mac 地址，這一次真的眾所周知，網際網路千千萬，不可能只存在兩個 Mac 地址，那麼需要對接的 Mac 地址是如何識別對方的呢？

廣播

方法很原始，通過 ARP 協議，向本網路內的所有計算機傳送，接受方通過標頭來與自身 Mac 地址比較，如果一致就接受並處理，否則則拋棄。

通過乙太網協議、Mac 地址、廣播，鏈路層就實現了在同一網路內的多計算機通訊。

4.3 網路層

在鏈路層中，可以實現同一網路內的多計算機通訊，理論上是可以實現全網路通訊的，但是由於廣播的侷限性會導致不在同一子網路下的計算機無法通訊，且每個計算機”人手一包“的效率也是低下的。於是網路層引入一套新的地址，使我們能區分不同計算機是否屬於同一網路，這個就叫做網路地址，簡稱”網址“。

於是到網路層，計算機有了兩個地址。一個是 Mac 地址，一個是網路地址。前者是繫結網路卡上的，用於接受子網路下廣播的資料包，而後者是管理員分配。處理順序也是後者先於前者，畢竟要先知道你在哪個省再在哪個市。

4.3.1 IP 協議

網路地址也不是隨便定義的，遵循 IP 協議，這個網路地址也叫做 IP 地址。

目前廣泛使用的是 IPV4，這版規定網路地址由 32 個二進位制位組成。

例如百度的 IP 地址: 14.215.177.39 二進位制為: 00001110.11010111.10110001.00100111 一般都是使用十進位制來描述，從 0.0.0.0 - 255.255.255.255

IP 地址前部分代表網路，後部分代表主機，假如百度地址的網路部分是前 24 位，也就是 14.215.177，那麼主機部分就是後面的 39，處於同一個網路下的計算機，網路部分是相同的。

但是上面是舉例，實際上從 IP 地址並不能看出網路部分是前 24 位還是 前 16 位，沒想到吧，哈哈哈。但是可以通過子網掩碼來判別。

子網掩碼：表示網路特徵的一個引數，形式上等於 IP 地址，如果已知百度 IP 地址的網路部分是前 24 位，那麼他的子網掩碼的網路部分都是 1，主機都是 0，也就是 11111111.11111111.11111111.00000000，換成十進位制就是 255.255.255.0。

如何通過子網掩碼來確定兩臺計算機是否處於同一子網路呢？答案就是通過將兩個 IP 地址與子網掩碼進行 AND(&) 運算，如果兩個結果一樣，則確定就在同一網路。

例: 已知下面兩個 IP 地址的網路部分是前 24 位，請計算 14.215.177.39 與 14.215.177.255 是否處在同一子網路下。
解: 由已知條件可得網路部分為 14.215.177
    14.215.177.39 和 14.215.177.255 子網掩碼的二進位制為 11111111.11111111.11111111.00000000
    14.215.177.39 的二進位制為 00001110.11010111.10110001.00100111
    14.215.177.255 的二進位制為 00001110.11010111.10110001.11111111
    00001110.11010111.10110001.00100111 & 11111111.11111111.11111111.00000000 = 00001110.11010111.10110001.00000000
    00001110.11010111.10110001.11111111 & 11111111.11111111.11111111.00000000 = 00001110.11010111.10110001.00000000
答: 結果一致，所以 14.215.177.39 與 14.215.177.255 處在同一子網路下。
複製程式碼

IP 協議主要就是給計算機分配 IP 地址，確定哪些計算機在同一子網路下。

4.3.2 IP 資料包

IP 資料包與乙太網資料包結構類似，IP 資料包以標頭+資料包的形式儲存在乙太網資料包的資料部分。

IP資料包

4.3.3 ARP 協議

在之前鏈路層我們有提到 ARP 協議，通過該協議向子網路內的所有計算機傳送廣播。

ARP 協議也是傳送一個資料包，包含在乙太網資料包中，其中包含了它要查詢的主機的 IP 地址，在接收方的 Mac 地址填的是 FF:FF:FF:FF:FF:FF，表示這是一個"廣播"地址。然後接受方全部會接受這個廣播，取出其中的 IP 地址與自身比較，得出結果。

這裡需要補充的是如果兩個主機不在同一個子網路，那麼需要引入“閘道器(gateway)”來進行資料包的操作。

4.4 傳輸層

在 IP 地址 和 Mac 地址的協助下，我們的計算機可以實現全網路下通訊了，但是如何區分不同的網路請求呢，也就是說當接受一個資料包，如何分辨它是網頁內容還是聊天內容，這時候需要一個叫做“埠”的引數來確定使用這個資料包的程式(程式)。埠是 0 到 65535 之間的整數，0-1023 之間的被系統佔用，例如網頁訪問的通常都是 80 埠，一旦通過 SSL 加密，那麼也就是 HTTPS 訪問，埠會使用 443 埠，這也就是我們之前訪問 baidu.com 實際上訪問的是 https://www.baidu.com:443 的結果。

網路層實現了主機到主機的通訊，而傳輸層是建立埠到埠的通訊，因此 Unix 系統把主機+埠叫做套接字(socket)。

4.4.1 UDP 協議

通過上面的部分，我們知道埠到埠的通訊其實也是需要確定的，那麼 UDP 協議就是加上了埠資訊的資料包。標頭定義了發出埠和接收埠，資料部分就是具體的內容，該資料包儲存在 IP 資料包中。

UDP資料包

4.4.2 TCP 協議

UDP 協議的有點是簡單易實現，但是缺點就是無法確定對方是否接收到了。為了解決這個問題，TCP 協議誕生了，簡單理解，TCP 協議就是帶有必須確認功能的 UDP 協議。每發出一個資料包都需要得到對方的確認，一旦得不到哪個資料包的確認，就知道需要重發這個資料包了。

4.5 應用層

資料來源五花八門，應用層就是規定程式的資料格式。

TCP 協議可以為各種各樣的程式傳遞資料，比如 Email、WWW、FTP 等等。那麼，必須有不同協議規定電子郵件、網頁、FTP 資料的格式，這些應用程式協議就構成了"應用層"。

應用層資料包

最後的狀態就變成了這樣

資料包傳輸示意圖

5 三次握手

當了解了網際網路協議後，我們接著之前的 URL 訪問過程，獲得了伺服器 IP 地址以後，我們需要進行通訊，這會進行一次連線，這是通過 TCP 協議完成的。

三次握手

三次握手:

第一次由客戶端傳送 SYN 包到伺服器，等待伺服器確認；

第二次是伺服器接收到 SYN 資料包，將 SYN + 自己傳送的 ACK 包一同傳送給客戶端；

第三次是客戶端接收到伺服器傳送過來的 SYN + ACK 資料包後，再向伺服器傳送確認包 ACK，客戶端和伺服器進入連線狀態，完成三次握手。

6 HTTP 通訊

當客戶端和伺服器進入連線狀態後，那麼就可以進行 HTTP(應用層) 的通訊了。

完整的 HTTP 請求包含了起始行，請求頭，請求體三部分，常見的請求方法有 GET 和 POST。

完成了 HTTP 通訊，瀏覽器接收到伺服器的響應，該響應是一個封裝了 HTTP 報文的 Response 物件，主要包括狀態碼，響應頭，響應體三部分。

常見的狀態碼有：

  • 1XX: 指示資訊，表示請求已接受，繼續處理；
  • 2XX: 成功，表示請求已接受，已處理。常見的是 200；
  • 3XX：重定向，要完成請求必須進行更進一步地操作。例如常見的有 301 永久重定向和 302 臨時重定向。302 重定向的網站會保留原有的網址，而影響搜尋引擎的抓取；
  • 4XX：客戶端錯誤，請求有語法錯誤或請求無法實現。常見的有 400 錯誤，前後端協議欄位不一致；403錯誤，表示資源不可用，訪問被禁止；404 錯誤，資源不存在；
  • 5XX：服務端錯誤，無法響應客戶端請求。

6.1 HTTPS

隨著網際網路的普及，人們對安全的重視也與日俱增，HTTP 協議沒有辦法確認通訊方，有可能在傳輸過程中遭到篡改而不知。此時 HTTPS 出現了，它在 HTTP 上再加入加密處理和認證機制，HTTPS 是披著 SSL 外殼的 HTTP。

SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全（Transport Layer Security，TLS）是為網路通訊提供安全及資料完整性的一種安全協議。TLS與SSL在傳輸層對網路連線進行加密。

在 WEB 配置 HTTPS 的過程中，有一個叫做證照的東西，要理解證照，我們就得先了解一下 HTTPS 的加密解密過程，HTTPS 採用的是混合加密機制。

6.1.1 加密與解密

HTTPS 採用共享祕鑰加密和公開祕鑰加密兩者混用。

共享祕鑰加密：使用一對非對稱的祕鑰。一把叫做私有祕鑰，一把叫做公有祕鑰。傳送方使用公有祕鑰加密資訊，接收方使用私有祕鑰進行解密。

公開祕鑰加密：傳送方和接收方使用同一把祕鑰進行加密。但是被第三者獲得祕鑰後可以肆意妄為。

為了證實公開金鑰的“正統性”，我們聽說過的證照閃亮登場。通過數字證照認證機構(CA)頒佈的公開祕鑰證照，可以確定申請者的身份並對已申請的公開金鑰進行簽名，然後分配這個公開祕鑰，並將這個公開祕鑰放入公鑰證照後繫結一起。伺服器會將這份數字證照傳送給客戶端，以便進行公開祕鑰加密通訊。

加密方式

檢視客戶端證照

證照

6.1.2 通訊

SSL通訊

在以上流程中，應用層傳送資料時會附加一種叫做“Mac”的報文摘要，它能確定報文是否遭到篡改從而保證了報文的完整性。

6.1.3 小結

整個 HTTPS 通訊過程

HTTPS通訊過程

HTTPS 是使用 SSL 和 TLS 這兩個協議的，由於在通訊過程中需要加密和解密，所以與 HTTP 相比，HTTPS 的速度會慢 2-100 倍，雖然可以用 SSL 專用加速伺服器來改善一下，但是仍然沒有根本性的解決方法。

7 頁面渲染

當瀏覽器接受到響應報文，舉例是 html 檔案，就開始解析和渲染並呈現給使用者也就是我們。 一個完整的 html 檔案包括了 html 部分，css 部分，javascript 部分。

瀏覽器對 html 檔案的解析是逐行的，於是當讀取到外部連結的 css 或者 javascript 或者圖片時會重複 http 請求的過程，這也是前端效能優化的一個地方。

瀏覽器會將 html 解析成一個 DOM 樹，將 css 解析成 css rule 樹，然後根據 DOM 樹和 css rule 樹來構造 render 樹，之後就計算各節點應處的位置，接下來就是遍歷 render 樹來繪製每個節點。

其中涉及 DOM 樹的結構變化以及幾何屬性的變化會導致頁面重新渲染，這就是所謂的迴流；而外觀背景色等的操作不會引釋出局變化導致重新渲染，這就是重繪。在前端開發中應當盡力避免迴流來優化效能。 最後，一個完整的頁面就展現在了我們面前。

瀏覽器渲染

8 總結

簡(tai)而(chang)言(bu)之(kan)，在瀏覽器輸入 URL 後，會通過 DNS查詢得到這個域名所在的 IP 地址，通過 IP 地址以及 TCP 協議三次握手請求伺服器獲得資源後，瀏覽器對資源進行解析並渲染獲得最後的結果。

相關文章