【網絡】瀏覽器輸入URL到展現頁面全過程（含互聯網協議及HTTPS簡介）

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 數據包以標頭+數據包的形式保存在以太網數據包的數據部分。

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 數據包中。

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 通訊

在以上流程中，應用層發送數據時會附加一種叫作「Mac」的報文摘要，它能肯定報文是否遭到篡改從而保證了報文的完整性。

6.1.3 小結

整個 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 協議三次握手請求服務器得到資源後，瀏覽器對資源進行解析並渲染得到最後的結果。