【网络】浏览器输入URL到展示页面全过程(含互联网协议及HTTPS简介)
這里寫自定義目錄標題
- 前言
- 1.URL介紹
- 2.DNS查找
- 3.互聯網協議
- 3.1 實體層
- 3.2 鏈路層
- 3.2.1 以太網協議
- 3.2.2 Mac地址
- 3.2.3 廣播
- 3.3 網絡層
- 3.3.1 IP 協議
- 3.3.2 IP 數據包
- 3.3.3 ARP協議
- 3.4 傳輸層
- 3.4.1 UDP協議
- 3.4.2 TCP協議
- 3.5 應用層
- 4. 三次握手
- 5.HTTP通信
- 5.1 HTTPS
- 5.1.1 加密與解密
- 5.1.2 通信
- 5.1.3 小結
- 6. 頁面渲染
- 總結
前言
HTTP(Hypertext Transfer Protocol) 超文本傳輸協議，是萬維網的基礎，在瀏覽器中我們主要是用 HTTP 以及 HTTPS 進行網絡訪問，那么我們在瀏覽器的地址欄輸入一個 URL到回車展示給我們頁面的過程發生了什么呢？
1.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)
2.DNS查找
以 chrome 瀏覽器為例，當輸入 baidu.com的時候，我們實際訪問的是 14.215.177.39，這是百度的 IP 地址，從 baidu.com 到 14.215.177.39 的過程就是一個 DNS 解析的過程。
首先會從瀏覽器里 DNS 緩存查找，chrome://dns/，一旦查找到了就完成了這個解析過程，但是如果沒有呢？ 那么接著會從電腦本地的 hosts 文件中查找，以下為 windows 的 hosts 文件，最后一行是我加的。
可以在這里改變這個 IP 地址，那么就訪問不到百度首頁了。像最簡單的科學上 google 的方法就可以通過修改 hosts 文件達到這個效果。
一般 hosts 文件是沒有這個解析地址的，于是只能接著向上查找運營商的解析，例如電信聯通移動以及著名的114。像這里，有時候手機瀏覽器訪問網頁會出現奇奇怪怪的廣告，那么很大可能是運營商 DNS 劫持，可以通過手動設置 DNS (例如 114.114.114.114) 避免。
到此，DNS 查找過程就完成了，得到了域名對應的 IP 地址。
3.互聯網協議
在介紹接下來的三次握手之前先簡單了解一下計算網絡協議，在分層中有4層 5層 7層等之分，我們這里按 5 層來分析。
注: 該部分下主要內容和部分圖片來自阮一峰老師的博客和圖解HTTP
- 應用層
- 傳輸層
- 網絡層
- 鏈路層
- 實體層
以下省去了實體層
3.1 實體層
比較簡單，就是我們常見的光纜、電纜、無限電波等等物理連接。
3.2 鏈路層
位于實體層的上方，確定了 0 1 的分組方式。
3.2.1 以太網協議
以太網規定一組電信號構成一個數據包，叫做“幀”，每一幀分成兩個部分：標頭(head)和數據(data)。 標頭說明數據包的發送者、接受者，數據類型等等，而數據則是數據包的具體內容。
3.2.2 Mac地址
以太網數據包的標頭規定了發送者和接受者，那么是如何確定的呢？這里就引入了 Mac 地址的概念。
以太網規定了連入網絡的所有設備都必須具備“網卡”接口，數據包都是從一塊網卡傳遞到另一塊網卡，網卡的地址就是 Mac 地址。每一個 Mac 地址都是獨一無二的，具備了一對一的能力。
3.2.3 廣播
上面的情形只是理論上一個 Mac 地址對接另一個 Mac 地址，這一次真的眾所周知，互聯網千千萬，不可能只存在兩個 Mac 地址，那么需要對接的 Mac 地址是如何識別對方的呢？
方法很原始，通過 ARP 協議，向本網絡內的所有計算機發送，接受方通過標頭來與自身 Mac 地址比較，如果一致就接受并處理，否則則拋棄。
通過以太網協議、Mac 地址、廣播，鏈路層就實現了在同一網絡內的多計算機通信。
3.3 網絡層
在鏈路層中，可以實現同一網絡內的多計算機通信，理論上是可以實現全網絡通信的，但是由于廣播的局限性會導致不在同一子網絡下的計算機無法通信，且每個計算機”人手一包“的效率也是低下的。于是網絡層引入一套新的地址，使我們能區分不同計算機是否屬于同一網絡，這個就叫做網絡地址，簡稱”網址“。
于是到網絡層，計算機有了兩個地址。一個是 Mac 地址，一個是網絡地址。前者是綁定網卡上的，用于接受子網絡下廣播的數據包，而后者是管理員分配。處理順序也是后者先于前者，畢竟要先知道你在哪個省再在哪個市。
3.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 協議主要就是給計算機分配 IP 地址，確定哪些計算機在同一子網絡下。
3.3.2 IP 數據包
IP 數據包與以太網數據包結構類似，IP 數據包以標頭+數據包的形式保存在以太網數據包的數據部分。
3.3.3 ARP協議
在之前鏈路層我們有提到 ARP 協議，通過該協議向子網絡內的所有計算機發送廣播。
ARP 協議也是發送一個數據包，包含在以太網數據包中，其中包含了它要查詢的主機的 IP 地址，在接收方的 Mac 地址填的是 FF:FF:FF:FF:FF:FF，表示這是一個"廣播"地址。然后接受方全部會接受這個廣播，取出其中的 IP 地址與自身比較，得出結果。
這里需要補充的是如果兩個主機不在同一個子網絡，那么需要引入“網關(gateway)”來進行數據包的操作。
3.4 傳輸層
在 IP 地址 和 Mac 地址的協助下，我們的計算機可以實現全網絡下通信了，但是如何區分不同的網絡請求呢，也就是說當接受一個數據包，如何分辨它是網頁內容還是聊天內容，這時候需要一個叫做“端口”的參數來確定使用這個數據包的程序(進程)。端口是 0 到 65535 之間的整數，0-1023 之間的被系統占用，例如網頁訪問的通常都是 80 端口，一旦通過 SSL 加密，那么也就是 HTTPS 訪問，端口會使用 443 端口，這也就是我們之前訪問baidu.com 實際上訪問的是 https://www.baidu.com:443 的結果。
網絡層實現了主機到主機的通信，而傳輸層是建立端口到端口的通信，因此 Unix 系統把主機+端口叫做套接字(socket)。
3.4.1 UDP協議
通過上面的部分，我們知道端口到端口的通信其實也是需要確定的，那么 UDP 協議就是加上了端口信息的數據包。標頭定義了發出端口和接收端口，數據部分就是具體的內容，該數據包存儲在 IP 數據包中。
3.4.2 TCP協議
UDP 協議的優點是簡單易實現，但是缺點就是無法確定對方是否接收到了。為了解決這個問題，TCP 協議誕生了，簡單理解，TCP 協議就是帶有必須確認功能的 UDP 協議。每發出一個數據包都需要得到對方的確認，一旦得不到哪個數據包的確認，就知道需要重發這個數據包了。
3.5 應用層
數據來源五花八門，應用層就是規定程序的數據格式。
TCP 協議可以為各種各樣的程序傳遞數據，比如 Email、WWW、FTP 等等。那么，必須有不同協議規定電子郵件、網頁、FTP 數據的格式，這些應用程序協議就構成了"應用層"。
最后的狀態就變成了這樣
4. 三次握手
當了解了互聯網協議后，我們接著之前的 URL 訪問過程，獲得了服務器 IP 地址以后，我們需要進行通信，這會進行一次連接，這是通過 TCP 協議完成的。
三次握手:
第一次由客戶端發送 SYN 包到服務器，等待服務器確認；
第二次是服務器接收到 SYN 數據包，將 SYN + 自己發送的 ACK 包一同發送給客戶端；
第三次是客戶端接收到服務器發送過來的 SYN + ACK 數據包后，再向服務器發送確認包 ACK，客戶端和服務器進入連接狀態，完成三次握手。
5.HTTP通信
當客戶端和服務器進入連接狀態后，那么就可以進行 HTTP(應用層) 的通信了。
完整的 HTTP 請求包含了起始行，請求頭，請求體三部分，常見的請求方法有 GET 和 POST。
完成了 HTTP 通信，瀏覽器接收到服務器的響應，該響應是一個封裝了 HTTP 報文的 Response 對象，主要包括狀態碼，響應頭，響應體三部分。
常見的狀態碼有：
- 1XX: 指示信息，表示請求已接受，繼續處理；
- 2XX: 成功，表示請求已接受，已處理。常見的是 200；
- 3XX：重定向，要完成請求必須進行更進一步地操作。例如常見的有 301 永久重定向和 302 臨時重定向。302 重定向的網站會保留原有的網址，而影響搜索引擎的抓取；
- 4XX：客戶端錯誤，請求有語法錯誤或請求無法實現。常見的有 400 錯誤，前后端協議字段不一致；403錯誤，表示資源不可用，訪問被禁止；404 錯誤，資源不存在；
- 5XX：服務端錯誤，無法響應客戶端請求。
5.1 HTTPS
隨著互聯網的普及，人們對安全的重視也與日俱增，HTTP 協議沒有辦法確認通信方，有可能在傳輸過程中遭到篡改而不知。此時 HTTPS 出現了，它在 HTTP 上再加入加密處理和認證機制，HTTPS 是披著 SSL 外殼的 HTTP。
SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全（Transport Layer Security，TLS）是為網絡通信提供安全及數據完整性的一種安全協議。TLS與SSL在傳輸層對網絡連接進行加密。
在 WEB 配置 HTTPS 的過程中，有一個叫做證書的東西，要理解證書，我們就得先了解一下 HTTPS 的加密解密過程，HTTPS 采用的是混合加密機制。
5.1.1 加密與解密
HTTPS 采用共享秘鑰加密和公開秘鑰加密兩者混用。
共享秘鑰加密：使用一對非對稱的秘鑰。一把叫做私有秘鑰，一把叫做公有秘鑰。發送方使用公有秘鑰加密信息，接收方使用私有秘鑰進行解密。
公開秘鑰加密：發送方和接收方使用同一把秘鑰進行加密。但是被第三者獲得秘鑰后可以肆意妄為。
為了證實公開密鑰的“正統性”，我們聽說過的證書閃亮登場。通過數字證書認證機構(CA)頒布的公開秘鑰證書，可以確定申請者的身份并對已申請的公開密鑰進行簽名，然后分配這個公開秘鑰，并將這個公開秘鑰放入公鑰證書后綁定一起。服務器會將這份數字證書發送給客戶端，以便進行公開秘鑰加密通信。
查看客戶端證書
5.1.2 通信
在以上流程中，應用層發送數據時會附加一種叫做“Mac”的報文摘要，它能確定報文是否遭到篡改從而保證了報文的完整性。
5.1.3 小結
整個 HTTPS 通信過程
HTTPS 是使用 SSL 和 TLS 這兩個協議的，由于在通信過程中需要加密和解密，所以與 HTTP 相比，HTTPS 的速度會慢 2-100 倍，雖然可以用 SSL 專用加速服務器來改善一下，但是仍然沒有根本性的解決方法。
6. 頁面渲染
當瀏覽器接受到響應報文，舉例是 html 文件，就開始解析和渲染并呈現給用戶也就是我們。 一個完整的 html 文件包括了 html 部分，css 部分，javascript 部分。
瀏覽器對 html 文件的解析是逐行的，于是當讀取到外部鏈接的 css 或者 javascript 或者圖片時會重復 http 請求的過程，這也是前端性能優化的一個地方。
瀏覽器會將 html 解析成一個 DOM 樹，將 css 解析成 css rule 樹，然后根據 DOM 樹和 css rule 樹來構造 render 樹，之后就計算各節點應處的位置，接下來就是遍歷 render 樹來繪制每個節點。
其中涉及 DOM 樹的結構變化以及幾何屬性的變化會導致頁面重新渲染，這就是所謂的回流；而外觀背景色等的操作不會引發布局變化導致重新渲染，這就是重繪。在前端開發中應當盡力避免回流來優化性能。 最后，一個完整的頁面就展現在了我們面前。
總結
簡(tai)而(chang)言(bu)之(kan)，在瀏覽器輸入 URL 后，會通過 DNS查找得到這個域名所在的 IP 地址，通過 IP 地址以及 TCP 協議三次握手請求服務器獲得資源后，瀏覽器對資源進行解析并渲染獲得最后的結果。
總結
以上是生活随笔為你收集整理的【网络】浏览器输入URL到展示页面全过程(含互联网协议及HTTPS简介)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Pytest入门【2】
- 下一篇： overflow-x理解_前端系列学习笔