該文章同步發佈於 我的部落格

也歡迎關注我的 Facebook 以及 Instagram 接收軟體相關的資訊！

前言

有天在網路上看到一張很有趣的圖片，是關於瀏覽器輸入網址後發生的行為，還記得一開始在學習的時候，只能粗淺的理解 HTTP 是一個通訊協議，客戶端發出 request 然後伺服器送回一個 response。

下面是我看到的那張圖片，今天就來解析一下到底發生了什麼事吧！

DNS

當我們從瀏覽器輸入一段網址之後，第一站來到的就是 DNS ( Domain Name System )

可以看到圖片中他先去 Cache 那邊找了一下，Cache 就是在檢查你是不是有來過這個網站，基本上我們第一次到一個網站的時候，拿下來的 HTML、CSS 等等的檔案都會被快取在瀏覽器的記憶體裡面。

所以這也是為什麼會先去看看 Cache 有沒有，如果沒有的話，就是 DNS 該發揮功用的時候了，他會解析我們輸入的網址把他轉化成 IP 位置。

從 Root Domain 到 Top Level Domain 一層一層的分析，來確定這段網址完整的 IP 位置，也就是說 DNS 其實很像一個巨無霸的電話簿，可以根據輸入的網址來產生此網址的 IP 位置。

那為什麼要有 DNS 呢？ 是因為人們基本上記不起來 IP 位置 (216.58.216.164)，這樣子你會知道這個是 Google 嗎？

所以才有了 DNS 這個系統 (分離式資料庫) 來存放域名對應的 IP 位置！

IP

那為什麼在 HTTP 裡面會需要 IP 位置呢？

因為 IP 就是你這台主機在網際網路中的地址，當你要送信時，你也要寫上你的地址吧？至於要收你信的人，也要有地址啊！

這樣的功能在 IP 協議中叫做標識裝置或網路。

所以當我們有了目的地的 IP 位置後，就可以接著往下一步走了！

開始 TCP 通道

這邊開始就會提到 TCP/IP 的三次交握，也是常常會在面試中被問到的題目。

三次交握主要的目的是建立起虛擬的連線，來確定客戶端和伺服器端能夠有穩定且安全的傳輸通道。

那為什麼要進行三次呢？

是因為如果只進行兩次的話，沒辦法真正的確立雙方的身份，就沒辦法建立一個雙向的通道來傳輸資訊！

舉個例子：

# A想和B借 1000 元，所以A傳了一張紙條給B，上面寫著 "可以和你借 1000 元嗎？"
A -> B 

# B是一個很好的人，他回傳說 "可以，但我要知道你是誰，這邊是本票，請你簽完傳回來"
A <- B

# A簽完本票蓋完章後，傳回去給B，接著兩人建立了可以匯款的通道了！
A -> B

所以說少了第三次交握，B是不會知道A是誰的，這樣子隨便的給 1000 元，不是一件安全的事情！

當然上面只是舉例，在真正的 TCP/IP 中，要看的是 ISN，但這邊也不細講，總之確立彼此的身份是在 TCP/IP 協議中很重要的一個步驟。

發出請求

前置步驟中，我們得到了目的地的 IP 位置，也建立起了虛擬的傳輸通道來進行資料交換，這時候我們就可以正式的發出 HTTP 的 request

在 HTTP 的 request 中有很多種方法，較常使用的是 GET POST DELETE PATCH 這些。

GET -> 請求展示資源，單純獲取資料
POST -> 請求提交實體資源，通常會造成 side effect
PATH -> 請求更改某部分資源
DELETE -> 請求刪除某實體資源

這邊只是比較大略的提一下 HTTP 的方法，可以往上看一下圖片，發出的請求是 GET https://example.com HTTP/1.1。

第一個是我們上面提到的 GET 方法，而中間則是 Domain 的名字，使用的是 HTTP/1.1 的協議。

這邊看起來很簡單也很好理解，但這都是在應用層面的顯示，其實在 TCP 的傳輸層和 IP 的網路層中，做了很多我們看不到的事情，這邊真的是要大大感謝 OSI 模型的設計，讓我們可以專注在應用層面的執行，少了很多複雜的東西！

伺服器回應

伺服器收到 GET https://example.com HTTP/1.1 後，會根據你的請求去拿取特定的資源並且回傳 response

這邊看到圖片中有許多不同的數字，其實代表的是 HTTP Response Code，這是經過協議的，每一個回傳的數字都有特殊的意義。

像是 404 大家最常看到的數字，這代表請求的資源並不存在，所謂的不存在並不是壞掉喔，是根本沒有這項資源，所以這邊的回應還是正常的，伺服器端也沒有出現任何問題。

而另一個是工程師比較常遇到的 500 就代表是伺服器端遇到了不符合預期的錯誤，並且沒辦法做出回應導致壞掉，相信大家最討厭看到的也是這個數字～

而如果回應的是 200，那就是伺服器根據所請求的資源正確的回應給客戶端，這時候我們就會收到一大包的 HTML + CSS + JS 檔案，並且回到瀏覽器！

解析 HTML + CSS + JS

這時候會解析 HTML 檔案建立 DOM Tree，如下圖所示：

同時也會根據載入的 Script 來解析 CSS 的 CSSOM Tree

而在分別解析 HTML 和 CSS 的時間，JS 就會順勢的被 Load 進去，最後一起變成 Render Tree！

接著把這個 Render Tree 丟回到瀏覽器，根據瀏覽器內建的引擎來渲染這個 Render Tree，最終變成我們看到的網站！

小結

看到這張圖片的瞬間覺得很有趣，真的算是畫得很詳細，可以讓人快速的理解 HTTP 是什麼，經過了什麼關卡，到最後的結果呈現。

還記得幾個月前就有想寫 什麼是 HTTP？ 了，但拖延症發作，想學的太多，就一直到看到這張圖片才有了動力來紀錄一下！