深情一眼摯愛萬年，我們從URL走到頁面

深情一眼摯愛萬年，我們從URL走到頁面

來自專欄小谷悠悠伴我行

是否有那麼一個時刻讓你感到原來一瞬間也可以變得無比的漫長呢？是恬靜的你看著他球場軒昂？還是陽光的你看著她舞台綻放？哈哈，我相信在座的各位，你們心裡都有一段自己的電影 。那麼今天，請讓我們回憶一下如何從URL走到頁面（ 請腦海播放《一眼萬年》）。

---

從輸入URL到我們看見頁面，剛開始我們的感覺是轉瞬即是，在學習了其中的蜿蜒之後又感到那是多麼的綿長。

總的來說就是Web使用HTTP協議作為規範，通過指定的訪問地址獲取（上傳）伺服器資源。

各位看官，來來來，我們先複習一下一些乾貨知識

一 網路基礎TCP/IP

1.TCP/IP協議族

通常使用的網路是在TCP/IP協議族的基礎上運作的。HTTP是其內部一個子集。我們知道，計算機與網路設備之間的相互通信是基於相同的方法和規範，這個我們稱之為協議，那麼所有的此類協議並集就是TCP/IP協議族。

2.TCP/IP的分層管理

TCP/IP協議族裡最重要的一條就是分層。按層次分為以下四層：

應用層、傳輸層、網路層和數據鏈路層。這樣分層的好處是可以進行各層單獨的設計改變，無需全局改變，只管自己，使設計簡單化。

3.各層的作用

應用層

決定了向用戶提供應用服務時通信的活動。TCP/IP協議族內預存了各類通用的應用服務，比如：FTP（File Transfer Protocol、文件傳輸協議），DNS（Domain Name System、域名系統）。HTTP協議也在這一層。

傳輸層

傳輸層對上層應用層，提供處於網路連接中的兩台計算機之間的數據傳輸。該層有兩個性質不同的協議：TCP（Transmission Control Protocol、傳輸控制協議），UDP(User Data Protocol、用戶數據協議)。

網路層

用於處理在網路上流動的數據包。數據包是網路傳輸的最小單位。該層規定了通過怎樣的路徑（傳輸路線）到達對方計算機，並把數據吧傳送給對方。即該層的作用就是在眾多的路線中選擇最優的一條傳輸路線。

鏈路層（數據鏈路層、網路介面層）

用來處理連接網路的硬體部分。包括控制操作系統、硬體的設備驅動、NIC（Network Interface Card、網路適配器，即網卡）及光纖等物理可見部分（包括連接器等一切傳輸媒介）

4 TCP/IP通信傳輸流

利用TCP/IP協議族進行網路通信時，會通過分層順序與對方進行通信。發送端從應用層往下走，接收端則嚮應用層往上走。

「報告！那我們為什麼要複習這些呢？」

「獨秀同學請坐，我們接著說！」

從URL到頁面的傳輸過程：

首先，作為發送端的客戶端在應用層（HTTP協議）發出一個想看某個web頁面的HTTP請求。接著，為了傳輸方便，在傳輸層（TCP/IP協議）把從應用層收到的數據（HTTP報文）進行分割，並在各個報文上打上標記序號及埠號後轉發給網路層。在網路層（IP協議），增加作為通信目的地的MAC地址後轉發給鏈路層。這樣一來，發往網路的通信請求就準備齊全了。接收端的伺服器在鏈路層接收到數據，按順序往上層發送，一直到應用層。當數據傳輸到應用層，才算真正接收到由客戶端發送的HTTP請求。發送端在層與層之間傳輸數據時，每經過一層時必定會被打上一個該層所屬的首部信息。反之，在接收端每經過一層時會消去對應的首部信息。這種把信息層層包裝起來的做法成為封裝。

「哦哦，原來是這樣！！」

「好了，我們具體走走過程」

一 輸入URL

URL（Uniform Resource Locator）,即統一資源定位符。簡單理解，我們常說的網站名就是它了，比如百度（www.baidu.com）。一些常用到的URL協議：http,https,ftp,file協議等，其中http是明文傳輸，容易被破解，造成信息丟失泄露，https是加密傳輸，安全有保障，常見於購物網站。

二 域名解析

1、瀏覽器緩存解析

在我們向瀏覽器輸入網址的時候，瀏覽器就已經開始在匹配可能的URL了，它會從歷史記錄，書籤等瀏覽器本地緩存，尋找已經輸入的字元串可能對應的之前使用過並已保存的URL，然後給出提示，讓你可以補全URL地址。像chrome瀏覽器，它會直接從緩存中把網頁展示出來，在按下 enter之前，頁面就已經展現了。

2、系統緩存解析

如果瀏覽器本地緩存中沒有對應的域名信息，緊接著瀏覽器會查看系統緩存情況，在本地硬碟的 hosts 文件，看看其中有沒有和這個域名相對應的信息，如果有的話就直接使用 hosts 文件裡面的 IP 地址。

3、路由器緩存解析

一般路由器也會緩存域名信息。在WIFI下，如果系統緩存里沒有找到域名信息，當路由器有緩存該請求域名的情況下就會直接使用路由器上的緩存來解析域名信息

4、ISP DNS緩存解析

如果在本地的 hosts 文件沒有能夠找到對應的 ip 地址，瀏覽器會發出一個 DNS請求到本地DNS伺服器 。本地DNS伺服器一般都是你的網路接入伺服器商ISP提供，比如中國電信，中國移動。查詢你輸入的網址的DNS請求到達本地DNS伺服器之後，本地DNS伺服器會首先查詢它的緩存記錄，如果緩存中有此條記錄，就可以直接返回結果。如果沒有，本地DNS伺服器還要向DNS根伺服器進行查詢。

5、域伺服器查詢解析

根DNS伺服器沒有記錄具體的域名和IP地址的對應關係，而是告訴本地DNS伺服器，你可以到域伺服器上去繼續查詢，並給出域伺服器的地址。本地DNS伺服器繼續向域伺服器發出請求，假如請求的對象是.com域伺服器。.com域伺服器收到請求之後，也不會直接返回域名和IP地址的對應關係，而是告訴本地DNS伺服器，你的域名的解析伺服器的地址。 最後，本地DNS伺服器向域名的解析伺服器發出請求，這時就能收到一個域名和IP地址對應關係，本地DNS伺服器不僅要把IP地址返回給用戶電腦，還要把這個對應關係保存在緩存中，以備下次別的用戶查詢時，可以直接返回結果，加快網路訪問。

簡單點，給個圖片簡單點

三 去往伺服器的路上

拿到域名對應的IP地址之後，瀏覽器會以一個隨機埠（1024<埠<65535）向伺服器的WEB程序（常用的有Apache,nginx等）80埠發起TCP的連接請求。這個連接請求到達伺服器端後（這中間通過各種路由設備，區域網內除外），進入到網卡，然後是進入到內核的TCP/IP協議棧（用於識別該連接請求，解封包，一層一層的剝開），還有可能要經過Netfilter防火牆（屬於內核的模塊）的過濾，最終到達WEB程序，最終建立了TCP/IP的連接。建立了TCP連接之後，發起一個http請求。一個典型的 http request header 一般需要包括請求的方法，例如 GET 或者 POST 等，這裡我們先不說。這就是我們之前說的TCP/IP通信傳輸流，前面的圖示很清楚。

四 伺服器處理

1、伺服器的永久重定向響應

伺服器給瀏覽器響應一個301永久重定向響應，瀏覽器訪問「http://www.google.com/」 而不是「http://google.com/」。為什麼要如此麻煩？其中一個原因跟搜索引擎排名有關。如果一個頁面有兩個地址，就像http://www.Google.com/和http://Google.com/，搜索引擎會認為它們是兩個網站，結果造成每個搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是什麼意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。還有就是用不同的地址會造成緩存友好性變差，當一個頁面有好幾個名字時，它可能會在緩存里出現好幾次。

2、瀏覽器跟蹤重定向地址

現在瀏覽器明確了 "http://www.google.com/"才是要訪問的正確地址，所以它會發送另一個http請求，從頭再走一遍。

3、伺服器處理請求

現在正確的http請求終於發送到了伺服器這裡，那麼，伺服器是如何處理我們的請求的呢？後端從在固定的埠接收到TCP報文開始，它會對TCP連接進行處理，對HTTP協議進行解析，並按照報文格式進一步封裝成HTTP Request對象，供上層使用。有些的網站會將你的請求送到反向代理伺服器中，因為當網站訪問量非常大，一台伺服器已經不夠用了。於是將同一個應用部署在多台伺服器上，將大量用戶的請求分配給多台機器處理。此時，客戶端不是直接通過HTTP協議訪問某網站應用伺服器，而是先請求到Nginx反向代理伺服器，Nginx再請求應用伺服器，然後將結果返回給客戶端。這樣做的另一個好處，就是萬一其中一台伺服器光榮了，只要還有其他伺服器正常運行，就不會影響用戶使用。

五 瀏覽器渲染並展示網頁

在瀏覽器沒有完整接受全部HTML文檔時，它就已經開始一點點地解析並顯示這個頁面了，不同瀏覽器解析的過程可能不太一樣，下圖對應的是WebKit內核渲染的過程，這個過程包括：

解析html以構建dom樹 -> 構建render樹 -> 布局render樹 -> 繪製render樹

瀏覽器在解析html文件時，會」自上而下,一句一句「載入，並在載入過程中進行解析渲染。在解析過程中，如果遇到Link標籤、script標籤和img標籤等，會再發相應請求獲取CSS、JS和圖片，過程和HTML讀取類似。並且請求過程是非同步的，並不會影響html文檔進行載入。。

解析過程中，瀏覽器首先會解析HTML文件構建DOM樹，然後解析CSS文件構建渲染樹，等到渲染樹構建完成後，瀏覽器開始布局渲染樹並將其繪製到屏幕上。這個過程比較複雜，涉及到兩個概念: reflow(迴流)和repain(重繪)。DOM節點中的各個元素都是以盒模型的形式存在，這些都需要瀏覽器去計算其位置和大小等，這個過程稱為relow;當盒模型的位置,大小以及其他屬性，如顏色,字體,等確定下來之後，瀏覽器便開始繪製內容，這個過程稱為repain。頁面在首次載入時必然會經歷reflow和repain。reflow和repain過程是非常消耗性能的，尤其是在移動設備上，它會破壞用戶體驗，有時會造成頁面卡頓。所以我們應該儘可能少的減少reflow和repain。

當文檔載入過程中遇到JS文件，html文檔會掛起渲染（載入解析渲染同步）的線程，不僅要等待文檔中JS文件載入完畢，還要等待解析執行完畢，才可以恢復html文檔的渲染線程。因為JS有可能會修改DOM，最為經典的例子是document.write，這意味著，在JS執行完成前，後續所有資源的下載可能是沒有必要的，這是js阻塞後續資源下載的根本原因。所以JS代碼最好還是放在html文檔末尾。JS的解析是由瀏覽器中的JS解析引擎完成的。JS是單線程運行，也就是說，在同一個時間內只能做一件事，所有的任務都需要排隊，前一個任務結束，後一個任務才能開始。但是又存在某些任務比較耗時，如IO讀寫等，所以需要一種機制可以先執行排在後面的任務，這就是：同步任務(synchronous)和非同步任務(asynchronous)。JS的執行機制就可以看做是一個主線程加上一個任務隊列(task queue)。同步任務就是放在主線程上執行的任務，非同步任務是放在任務隊列中的任務。所有的同步任務在主線程上執行，形成一個執行棧;非同步任務有了運行結果就會在任務隊列中放置一個事件；腳本運行時先依次運行執行棧，然後會從任務隊列里提取事件，運行任務隊列中的任務，這個過程是不斷重複的，所以又叫做事件循環(Event loop)。

僅僅讀完這些文字需要多久？ 但在有些時候我們打開網頁可能真的一秒不到（體會不到的同學建議使用chrome瀏覽器+固態硬碟+100M光纖）！從URL到頁面，這裡面的彎彎繞繞實在是太多，本文也只是強行說明了一番，後面內容部分參考自原博主，在此表示感謝！有不對之處歡迎批評指正，有些細節沒有詳述，待小白再學習學習。

本文作者：Jirengu-WK

原創內容，轉載請註明出處。

參考

1 https://www.cnblogs.com/xianyulaodi/p/6547807.html#_label0

2《圖解HTTP》[日] 上野宣 2014-05

推薦閱讀：