從瀏覽器網址列輸入網址、按下 Enter 後會發生什麼事？

如果有面試過軟體工程師的工作，不論前端或後端，「從瀏覽器網址列輸入網址、按下 Enter 後會發生什麼事？」都是非常高頻率會出現的題目。

這個題目之所以如此高頻，是因為這問題會觸及到網頁開發、網絡技術相關的重要概念。而因為題目很廣，能夠切入的角度非常多，所以讓這個題目變得非常靈活，可廣可深。如果沒有對概念融會貫通、只是背答案，很可能在追問的問題後就答不出來。

從宏觀的角度看

如果從宏觀的角度看，當從瀏覽器網址列輸入網址、按下 Enter 後，瀏覽器會先透過 DNS (域名系統) 查找 IP，然後對在該 IP 位置的伺服器發送 HTTP 請求，然後伺服器會回應，最後瀏覽器把收到的回應渲染到畫面上。

DNS

這時就有幾個問題可以討論，第一個是 DNS，你可能會問為什麼需要有 DNS 的存在? 關於這問題，是因為我們輸入的通常是網址的域名，但是實際上是要到某個 IP 位置，所以需要有域名對應到 IP 的表，而實際上就是透過 DNS 來維持的表，來對應域名與 IP。

舉例來說：

momoshop.com.tw 對應的 IP 是 61.219.4.15
static.azoleonline.click 對應的 IP 是 54.71.13.152

這時又有另一個問題，世界上有成千上億的 IP，輸入網址後，如何快速查找到對應的 IP?

DNS 的做法是分組，每一個組會進一步拆解。一開始會先問 DNS Resolver，這時會先去問根伺服器 (Root)，問完後會去問頂級域名伺服器 (Top-level Domain)，然後再進一步問權威名稱伺服器 (Authoritative)。如上圖樹狀的結構來分組，查找就會變快很多。

當然每次都這樣一層層問，很麻煩且要等傳輸時間，所以會有快取來處理。不過快取就會有過期的問題，例如對應的 IP 要換，就會需要等時間來讓快取失效，或手動設置來讓快取失效。

如果你想要測試到某個域名的聯通性，可以在終端機使用 ping 指令；透過 ping 我們也可以獲得到達目標機器的往返時間。這能有助於我們選擇該把機器部署在哪裡。舉例來說，如果你的服務使用者都在台灣，假設 AWS 有東京、首爾、新加坡，這幾個物理距離跟台灣都很近的機房，如果主要考量是速度，你該選哪一個呢?

這可以透過在 AWS 開三台機器，然後每台都 ping 一下來協助判斷。目前社群中也有一些網站 (例如 AWS Ping Test) 直接都幫你測好，讓你可以直接看。

發送請求後，資料如何傳輸?

前面談到，當找到伺服器的 IP 後，瀏覽器會對在該 IP 位置的伺服器發送 HTTP 請求，然後伺服器會回應。然而，在這段過程中，發生了什麼事? 資料是如何傳輸的?

具體來說，硬體層如何傳送封包跟物流如何送貨到你家，概念上是很類似的。就像物流通常不會直接從倉庫把貨運到你家，而是會先到不同的集貨站，例如從國外寄送到台北，可能會先到港口，然後再把物品轉去台北的集貨站，然後再由送貨員送到你家。

資料封包 (data packet) 的傳送也一樣，不會是直接送到伺服器，也不會是直接由伺服器傳給客戶端。在這過程中，會有非常多的路由器，然後路由器有演算法 (最短路徑演算法) 來判斷，然後最終傳送到目的地。

分層模型

在討論資料傳輸時，業界有一個 OSI (Open Systems Interconnection) 的模型在描述，從物理層 (Physical Layer) 一路到應用層 (Application Layer)，例如海底電纜是物理層，我們常談到的 HTTP 是在應用層的協定。

小賴推薦可以不用去背 OSI，但是可以思考為什麼要分層? 之所以會分層，是因為這麼做能讓整體變得乾淨好維護。

舉例來說今天 HTTP 發送一個 GET 請求，發到表示層 (Presentation Layer) 後，所有從應用層 (Application Layer) 送來的東西，都會被認為是同一包，然後表示層加入自己要處理的部分。這樣的做法，讓每層可以處理自己負責的就好，就會變得很乾淨好維護。

而在每一層的溝通，都需要有協定 (protocol)，才能確保不同系統與通信設備之間的溝通，能夠被標準化。避免每個系統都用自己的方式傳資料，導致不兼容的混亂。我們常聽到的 HTTP、TCP、UDP、IP 都是協定。

在 E+ 版本的摘要中，會收錄小賴在直播中談到關於 HTTP、TCP、UDP、IP 的深度內容，且搭配簡報的圖文好讀版。有興趣的讀者歡迎訂閱 E+ (連結)