從瀏覽器輸入 Google 網址的那一刻起，發生了什麼？
這篇將會從此一範例簡單的帶過幾個在你連上網站時所發生的網路事件
先讓我們來看一張圖
這是一張打開了 Google 的瀏覽器，以下將會用這個當做例子
在解答這個問題之前，我們要先暸解其中所用到的幾個技術與專有名詞
但礙於篇幅只能以最基本的情況做簡單的介紹
如果還是有不懂的地方，相信前幾屆鐵人賽也有一整個系列的文章在介紹這些東西
完整的網域名稱
在這個例子中為 "www.google.com"
全名 Media Access Control Address
簡單來說就是每個網路裝置獨一無二的識別號碼
讓電腦可以把 IP 對應回 MAC Address 的協定
識別電腦用的一組數值
常看到的 127.0.0.1 就是一組電腦識別自己用的 Lookback IP 位置
本系列文將用 IPv4 作為示範
一種電腦，會根據記憶體中的路由表來把帶有 IP 封包轉送到對的路徑
在現實生活中就跟郵差一樣
TCP 與 UDP 是兩個不同的傳輸層協定
TCP (Transmission Control Protocol)
有狀態的協定，建立連線前要先經過三方交握
有資料驗證、重傳機制，確保對面收到的東西是對的
三方交握的詳細可以看這篇，圖片也是這裡借來的
UDP (User Datagram Protocol)
無狀態協定，資料丟過去，對方沒收到就算了
有需要的話要在應用層實現重傳機制
大概像這樣
將 FQDN 解析回 IP（超級過度簡化，功能不只這樣）的系統
使用 UDP 作為底下的傳輸協定
在網址列中 我們可以看到 "https" 開頭
HTTPS 為 HTTP 的安全加密版本，將 HTTP 包在 TLS/SSL 裡面
文章將會忽略加密相關的行為，強制降級成 HTTP 來解說
HTTP 是一個建立在 TCP 之上的應用層協定
主要的請求封包像是這樣（以 HTTP 1.1 為例，RFC2616）
<Request Method> <Path>?<Param> HTTP/1.1
<Header>
<Body>
常見的Reqeust Method 有 GET, POST, HEAD 等
Header 一般至少會帶上 Host，來讓伺服器知道使用者想連哪個網站
藉此就可以放多個網站在同一台伺服器上 (VHost)
Body 的部分可以留空
給個範例會像是這樣
GET / HTTP/1.1
Host: www.example.com
或是
POST /process?action=login HTTP/1.1
Host: 169.254.13.37
username=seadog007&password=password
而回應封包會是以下的格式
HTTP/1.1 <Status Code> <Status>
<Header>
<body>
給個範例的話會像這樣
HTTP/1.1 200 OK
Content-Type: application/json
{"status": "OK"}
首先，你的瀏覽器並不能直接連上 FQDN，所以瀏覽器勢必得將 FQDN 轉回 IP
這時候 DNS 就派上用場了，瀏覽器會使用你電腦所設定的 DNS Server
（範例為 Google DNS, 8.8.8.8）
去問說 www.google.com 這個 FQDN 對應的伺服器 IP 是什麼
你也可以用一些工具（nslookup、dig等）做到同樣的事
找到 IP 之後，你的系統會隨機挑選一個 Source Port
用這個 Source Port 去跟伺服器的 Destination Port 建立 TCP 連線
HTTP 預設 Port 為 80
假設你電腦 IP 為 1.2.3.4，隨機產生的 Port 為 54321
(1.2.3.4:54321 -> 216.58.200.228:80)
那要怎麼建立 TCP 連線呢？
首先，你的電腦會先去找你設定的預設路由位置
將這個位置解析回 MAC Address (L2 Address)，找到對應的實體裝置（網路卡、無線裝置），並且將封包往你的路由器丟
像剛剛的例子封包就會長這樣
| OSI Layer | Source | Destination |
|---|---|---|
| L2 | 你電腦的 MAC Address | 路由器的 MAC Address |
| L3 | 你電腦的 IP (1.2.3.4) | 目標 Server 的 IP (216.58.200.228) |
| L4 | 54321 | 80 |
你的路由器會因為 L2 的目的地是他，所以收到這個封包，然後根據路由表中的 Nexthop 繼續改寫 L2 Destination 將封包轉送到目的地
封包到達伺服器後，將會用相同的方法，一路將封包轉送回來給你
同理，上方 DNS 查詢封包的轉送機制也是一樣的
唯一不同點在於 DNS 使用 UDP 作為底層，而 HTTP 使用 TCP 作為底層，需要三方交握來建立連線
經過三方交握之後，連線正式建立
連線建立後，瀏覽器將會發送 HTTP 請求給伺服器，並將回應丟回給瀏覽器去做相對應的顯示
按下 F12 打開開發者視窗，切換到網路頁面，將可以看到請求的細節
如此一來你就能看到網頁了
首先，要研究一個東西，要先了解這個東西的基本運作模式
這其中有許多部份不是由你電腦處理的，一般使用者也不會去了解與研究
像是封包丟出去給預設路由，也就是你的路由器後，這些封包會根據什麼樣的規則轉送
又或者是家裡如果有多台電腦的狀況，你家的路由器幫你做了什麼
而這個系列將會針對這些平常 End User 所碰不到的東西做安全上的探討
所以看完今天這篇，聰明的你應該稍稍了解了打開網頁後所會發生的一些事情
當然，這篇因著重於網路方便，省略了很多其他方面的東西
打開一個網頁所發生的事遠遠不只這些
而明天，我將會對封包被丟往路由器後的事做一些基本概念的講解
DNS使用UDP作為底層
假設我們今天有一IOT裝置使用TCP向Server發request常常莫名其妙request不見，按照道理說TCP不僅三向交握還會斷線重連，所以說原因其實出在DNS/FQDN這裡嗎? 硬體/韌體不肯給我們Log我也只能用猜的，大大你覺得呢?
TCP所提供的是掉包重送
並不是斷線重連喔
沒有看到傳輸過程我也沒辦法知道確切是什麼情況
建議聽看看封包再來下判斷
確實沒有很多端底層訊息很難判斷問題，感謝指正錯誤學到一課，開心
iThome鐵人賽
看影片追技術