如何向學妹解釋在地址欄中輸入網址後發生了什麼？

前幾天有個學妹問我爲何在瀏覽器裏面輸了網址就會顯示出來頁面，雖然這個現象很常見，可是要想解釋清楚確實有些小困難，當時也只是簡單的回答了她，如今想趁着這個機會好好整理下相關知識。整理完才以爲其實就和咱們去一個地方找人是一個道理。因此說藝術源於生活卻又高於生活，技術一樣如此。

在回答這個問題前， 咱們先來了解下咱們日常說的那個網址究竟是啥？

網址的學名叫作統一資源定位符（Uniform Resource Locator， 常縮寫爲URL）， 咱們知道如今的互聯網其實就是由衆多資源所構成的一張巨大的網， 如何定位那些資源就是靠的URL， 所以咱們也能夠把URL理解爲是網絡上資源的「門牌號「， 咱們在瀏覽器中輸入網址， 就至關於開一輛車（瀏覽器）去找一個地址（URL）

1. 緩存查找

若是你要出門找一個地方， 第一想法確定是先想這個地方你有沒有去過， 你要是去過的話那就不須要問人直接過去就行了。 咱們的系統也是這麼想的。 當你在瀏覽器中輸入了URL以後， 瀏覽器會先查看 瀏覽器緩存 中有沒有這個地址， 若是沒有那就再去 系統緩存， 若是系統緩存尚未， 那就去路由器緩存找， 總之只要緩存中有， 就說明有這個資源， 那瀏覽器直接顯示出來就行了。

Tips： 這裏說下 hosts文件 ， hosts 是一個沒有擴展名的系統文件， 能夠用記事本等工具打開， 其做用就是將一些經常使用的網址域名與其對應的IP地址創建一個關聯「數據庫」， 當用戶在瀏覽器中輸入一個須要登陸的網址時， 系統會首先自動從 hosts 文件中尋找對應的 IP 地址，一旦找到， 系統會當即打開對應網頁， 若是沒有找到， 則系統會再將網址提交 DNS 域名解析服務器進行IP地址的解析。 須要注意的是， hosts文件配置的映射是靜態的， 若是網絡上的計算機更改了請及時更新IP地址， 不然將不能訪問。

2. DNS 解析

若是你認得去那個地址的路天然是最好， 那若是你根本就沒去過那咋辦？ 確定會有人說導航， 但並非全部的地方都是導航能搜到的， 這個時候咱們天然而然就會想着去問路人了。 瀏覽器也是這樣的， 若是在本地緩存中沒有找到想要的資源， 那就只能去其餘網絡上的機器中尋找我想要的資源了。 那你怎麼知道你要的資源在那臺機器上？ 這時， DNS就橫空出世了。

DNS（Domain Name System， 域名系統），DNS解析的過程就是尋找哪臺機器上有你須要資源的過程。當你在瀏覽器中輸入一個地址時， 例如 www.baidu.com， 其實這段URL並非真正意義上的地址。 互聯網上每一臺計算機的惟一標識是它的 IP 地址（好比127.0.0.1就是咱們本機的 IP 地址）， 可是 IP 地址並不方便記憶（畢竟都是很長的數字串）， 因此也就出現了網址（URL）這個玩意了， 目的就是爲了方便普通用戶去尋找網絡上的其餘計算機。 因此 DNS 實際上充當了一個翻譯的角色， 將網址翻譯成 IP 地址（就跟我想去南京大學， 問路的那我的告訴我南京大學在廣州路上是一個道理）。

2.1 DNS 解析過程

DNS解析實際上是一個遞歸查詢的過程：

在上述過程當中， 首先在本地域名服務器中查詢 IP 地址， 若是沒有找到， 本地域名服務器會向根域名服務器發送一個請求， 若是根域名服務器也不存在該域名時， 本地域名會向com頂級域名服務器發送一個請求， 依次類推下去。 直到最後找到目標網址所對應的 IP， 並將其緩存到本地， 以供下次使用。

2.2 DNS負載均衡

在講DNS負載均衡前先來看張圖片：

看到這可能就會有人犯嘀咕了， 咱們不是 ping 的同一個網址嗎， 爲啥兩次IP都不同啊？ 其實緣由很簡單， 若是每次都同樣是否說明你請求的資源都位於同一臺機器上面， 那麼這臺機器須要多高的性能和儲存才能知足億萬請求呢？ 其實真實的互聯網世界背後存在成千上百臺服務器， 大型的網站甚至更多。 可是在用戶的眼中， 它須要的只是處理他的請求， 哪臺機器處理請求並不重要。 DNS能夠返回一個合適的機器的IP給用戶， 例如能夠根據每臺機器的負載量， 該機器離用戶地理位置的距離等等， 這種過程就是DNS負載均衡， 又叫作DNS重定向。

再來舉個例子， 若是你在新街口用地圖搜南京大學， 返回給你的第一條數據可能就是南京大學鼓樓校區（由於距離最近）， 但若是你是在仙林用地圖搜南京大學， 返回給你的第一條數據就有多是南京大學仙林校區了。 DNS負載均衡簡單來講也是這個道理。

2.3 DNS 污染

DNS 污染（DNS cache pollution）， 又稱域名服務器緩存投毒（DNS cache poisoning）， 是指一些刻意製造或無心中製造出來的域名服務器數據包， 把域名指往不正確的IP地址。

某些網絡運營商爲了某些目的， 對DNS進行了某些操做， 致使上網的用戶沒法經過域名取得正確的IP地址。 某些國家或地區出於某些目的爲了防止某網站被訪問， 並且其又掌握部分國際DNS根目錄服務器或鏡像， 也會利用此方法進行屏蔽。 （Google、 Facebook等）

至於若是防止DNS污染， 這裏只說一個方法就是修改hosts文件， 其餘的自行搜索吧。

3. TCP鏈接

其實在上面DNS解析的圖中就已經有了TCP鏈接的過程了：

咱們經過DNS解析獲取到了網址所對應的IP地址後， 便須要發起TCP鏈接請求， 這裏總共須要三次握手， 具體的過程就不贅述了， 能夠查閱相關資料， 這裏推薦劉欣老師的《TCP/IP 之 大明王朝郵差》， 以及大學計算機網絡課本里面的TCP相關章節。

4. HTTP 請求

握手成功後， 瀏覽器就能夠向服務器發送http請求了， 請求數據包。 發送HTTP請求的過程就是構建HTTP請求報文並經過TCP協議中發送到服務器指定端口(HTTP協議80/8080, HTTPS協議443)。HTTP請求報文是由三部分組成: 請求行,請求報頭和請求正文。

4.1 請求行

格式以下:

Method  RequestURL  HTTPVersion CRLF
複製代碼

例如：

GET index.html HTTP/1.1
複製代碼

經常使用的方法有: GET, POST, PUT, DELETE, OPTIONS, HEAD。

4.2 請求報頭

請求報頭容許客戶端向服務器傳遞請求的附加信息和客戶端自身的信息。

Tips：客戶端不必定特指瀏覽器， 有時候也可以使用Linux下的CURL命令以及HTTP客戶端測試工具等。

常見的請求報頭有: Accept, AcceptCharset, AcceptEncoding, AcceptLanguage, ContentType, Authorization, Cookie, UserAgent等。

上圖是使用Chrome開發者工具截取的對百度的HTTP請求以及響應報文， 從圖中能夠看出， 請求報頭中使用了Accept, AcceptEncoding, AcceptLanguage, CacheControl, Connection, Cookie等字段。 Accept 用於指定客戶端用於接受哪些類型的信息， AcceptEncoding 與 Accept 相似， 它用於指定接受的編碼方式。Connection 設置爲 Keepalive 用於告訴客戶端本次 HTTP 請求結束以後並不須要關閉 TCP 鏈接， 這樣可使下次 HTTP 請求使用相同的 TCP 通道， 節省 TCP 鏈接創建的時間。

5. 服務器響應

這部分對應的就是後端工程師眼中的 HTTP。 後端從在固定的端口接收到 TCP 報文開始， 這一部分對應於編程語言中的 socket。 它會對 TCP 鏈接進行處理， 對 HTTP 協議進行解析， 並按照報文格式進一步封裝成 HTTP Request對象， 供上層使用。 這一部分工做通常是由 Web 服務器去進行， 經常使用的Web服務器有 Tomcat, IIS 和 Netty 等等。

HTTP響應報文也是由三部分組成: 狀態碼, 響應報頭和響應報文。 篇幅緣由這裏就不詳細展開了。

6. 瀏覽器解析網頁信息

服務器返回給瀏覽器的文本信息， 一般是 HTML, CSS, JS, 圖片等文件， 那麼瀏覽器是如何對澤瀉內容進行渲染呢？ 一般是下面五個步驟：

1. 處理 HTML 標記並構建 DOM 樹。
2. 處理 CSS 標記並構建 CSSOM 樹。
3. 將 DOM 與 CSSOM 合併成一個渲染樹。
4. 根據渲染樹來佈局， 以計算每一個節點的幾何信息。
5. 將各個節點繪製到屏幕上。

不過這五個步驟在不一樣內核的瀏覽器中執行細節是不一樣的， 想深刻了解的能夠查閱相關資料， 這裏推薦一篇文章：《瀏覽器渲染頁面過程與頁面優化》

瀏覽器是一個邊解析邊渲染的過程。 首先瀏覽器解析HTML文件構建DOM樹， 而後解析CSS文件構建渲染樹， 等到渲染樹構建完成後， 瀏覽器開始佈局渲染樹並將其繪製到屏幕上。

JS的解析是由瀏覽器中的 JS 解析引擎完成的。 JS是單線程運行， 也就是說， 在同一個時間內只能作一件事， 全部的任務都須要排隊， 前一個任務結束， 後一個任務才能開始。 可是又存在某些任務比較耗時， 如IO讀寫等， 因此須要一種機制能夠先執行排在後面的任務， 這就是： 同步任務(synchronous)和異步任務(asynchronous)。 JS的執行機制就能夠看作是一個主線程加上一個任務隊列(task queue)。 同步任務就是放在主線程上執行的任務， 異步任務是放在任務隊列中的任務。 全部的同步任務在主線程上執行， 造成一個執行棧; 異步任務有了運行結果就會在任務隊列中放置一個事件； 腳本運行時先依次運行執行棧， 而後會從任務隊列裏提取事件， 運行任務隊列中的任務， 這個過程是不斷重複的， 因此又叫作事件循環(Event loop)。 以下圖所示：

7. 總結

當上述步驟執行完成後咱們即可在瀏覽器中看到一個完整的頁面了， 總結下其實就只有幾步：

1. 瀏覽器地址欄輸入url
2. 瀏覽器會先查看瀏覽器緩存系統緩存路由緩存， 若有存在緩存， 就直接顯示。 若是沒有， 接着第3步
3. 域名解析（DNS）獲取相應的 IP
4. 瀏覽器向服務器發起 tcp 鏈接， 與瀏覽器創建 tcp 三次握手
5. 握手成功， 瀏覽器向服務器發送 http 請求， 請求數據包
6. 服務器請求數據， 將數據返回到瀏覽器
7. 瀏覽器接收響應， 讀取頁面內容， 解析 html 源碼， 生成 Dom 樹
8. 解析 css 樣式、 瀏覽器渲染， js交互

其實簡單來看這幾個過程並非很複雜， 可是每一個步驟均可以深挖出一大堆的知識， 好比DNS的優化、頁面渲染的優化、 HTTPS等等很是多的東西， 這裏考慮到篇幅以及科普效果不少東西都一筆帶過了，想深刻了解的能夠在微信公衆號 「01二進制」 後臺回覆 「計算機網絡書籍」 獲取相關專業書籍進行閱讀。