前言
有一天不知道在哪裡看到的圖片，應該是 Twitter 吧？
是關於瀏覽器輸入網址之後到底發生什麼事情的圖片，還記得剛開始轉職學習 Ruby on Rails 的時候，只能講出 HTTP 是一個通訊協議，其實講了等於沒講，就像跟別人說豬是一個動物一樣。
解釋最多只能說到 『 客戶端發出 request 然後伺服器送回一個 response 』
下面就是我看到的那張圖片，試著剖析一下這個圖片從起點到終點的過程
DNS
當從瀏覽器輸入一段網址之後，第一站來到的就是 DNS ( Domain Name System )
可以看到圖片中先去 Cache 那邊找了一下，Cache 主要在檢查你是不是有來過這個網站，至於為什麼要去檢查呢？當然是節省時間啦！如果你來過就不需要透過 DNS 在幫你查找一次目的地到底在哪裡，如果沒有的話，就是 DNS 該發揮功用的時候了，它會解析輸入的網址把他轉化成 IP 位置。
從 Root Domain 到 Top Level Domain 一層一層的分析，來確定這段網址完整的 IP 位置，也就是說 DNS 像一個巨無霸的電話簿，可以根據輸入的網址來產生此網址的 IP 位置。
那為什麼要有 DNS 呢？ 就是因為人們基本上記不起來 IP 位置 (216.58.216.164)，到底誰會知道這個是 Google 啦？
所以才有了 DNS 這個系統來存放域名以及對應的 IP 位置！
IP
為什麼會需要 IP 位置呢？
IP 就是你這台主機在網際網路中的地址，當你要寄信時，總要知道要寄去哪裡嗎？收信的時候，你也會想知道是誰寄過來的
這樣的功能在 IP 的協議中叫做標識裝置或網路。
你沒看錯，IP 也是一個協議…
所以當有了目的地的 IP 位置後，就可以接著往下一步走了！
建立 TCP 通道
這邊開始就會提到 TCP/IP 的三次交握，經典！經典中的經典！你在查維基百科一定會看到的字眼。
三次交握主要的目的是建立起虛擬的連線，來確定客戶端和伺服器端能夠有穩定且安全的傳輸通道。
可能會想問，為什麼不是 4 次，而是 3 次？簡單來說，4 次太多，2 次不夠，3 次剛好
是因為如果只進行 2 次的話，沒辦法真正的確立雙方的身份，就沒辦法建立一個雙向的通道來傳輸資訊！
舉個例子：
# A想和B借 1000 元，所以A傳了一張紙條給B，上面寫著 "可以和你借 1000 元嗎？"
A -> B
# B是一個很好的人，他回傳說 "可以，但我要知道你是誰，這邊是本票，請你簽完傳回來"
A <- B
# A簽完本票蓋完章後，傳回去給B，接著兩人建立了可以匯款的通道了！
A -> B所以說少了第 3 次交握，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 的網路層中，做了很多我們看不到的事情，這邊真的是要大大感謝那些天才們的設計，讓我們可以專注在應用層面的執行，少了很多複雜的東西！
伺服器回應
伺服器收到 GET https://example.com HTTP/1.1 後，會根據你的請求去拿取特定的資源並且回傳 response
這邊看到圖片中有許多不同的數字，其實代表的是 HTTP Response Code，這是經過協議的，每一個回傳的數字都有特殊的意義。
像是 404 大家最常看到的數字，這代表請求的資源並不存在，所謂的不存在並不是壞掉喔，是根本沒有這項資源，所以這邊的回應是正常的，伺服器端也沒有出現任何問題。
而另一個是工程師比較常遇到的 500 就代表是伺服器端遇到了不符合預期的錯誤，並且沒辦法做出相對的回應，其實就是壞掉了啦!
而如果回應的是 200，那就是伺服器根據所請求的資源正確的回應給客戶端，這時候我們就會收到一大包的 HTML + CSS + JS 檔案，並且回傳至瀏覽器!
解析 HTML + CSS + JS
OK，收到一大堆資料，要怎麼顯示在瀏覽器上讓使用者看懂呢？
這時候會先解析 HTML 檔案並且建立 DOM Tree，如下圖所示：
同時也會根據得到的 Script 來解析 CSS 的 CSSOM Tree
而在分別解析 HTML 和 CSS 的時間，JS 就會順勢的被 Load 進去，最後一起變成 Render Tree！
接著把這個 Render Tree 丟回到瀏覽器，根據瀏覽器內建的引擎來渲染這個 Render Tree，最終變成看到的網站！
結語
看到這張圖片的時候覺得畫得很可愛而且很詳細，可以讓人快速地理解 HTTP 從開始到結束的旅程，希望這篇文章可以幫助所有剛接觸 Web 開發的新手們搞懂 HTTP 到底是什麼，以及中間經過了什麼旅程，最後又是怎麼渲染到瀏覽器上的。