當我們在瀏覽器輸入 www.youtube.com 按下 Enter 鍵時，網頁幾乎瞬間就載入了。但你有沒有想過，電腦是怎麼知道要連到哪台伺服器的呢？這背後的功臣就是 DNS（Domain Name System，網域名稱系統）。DNS 就像網際網路的電話簿，將我們容易記憶的網域名稱轉換成電腦能理解的 IP 位址。今天我們就來深入了解 DNS 到底是什麼、它如何運作，以及為什麼它對我們的上網體驗如此重要。

DNS 的基本概念

什麼是 DNS？

DNS 全名為 Domain Name System，中文稱為「網域名稱系統」。簡單來說，DNS 是一個分散式的資料庫系統，負責將人類容易記憶的網域名稱（例如 facebook.com）轉換成電腦網路中實際使用的 IP 位址（例如 157.240.1.35）。想像一下，如果沒有 DNS，我們每次想上 Facebook 就得記住一串數字，那上網會變得多麼麻煩啊！

我們可以把 DNS 比喻成一本巨大的通訊錄。當你想打電話給朋友時，你只需要記住他的名字，然後在通訊錄裡找到對應的電話號碼。DNS 做的就是類似的事情，只不過它查找的是網站的「電話號碼」——也就是 IP 位址。

這套系統採用階層式架構，從全球的根伺服器開始，一層層往下延伸到各個網域的權威伺服器。這種設計讓 DNS 能夠處理數十億個網域名稱，同時保持高效率的查詢速度。更重要的是，DNS 是分散式的，沒有單一故障點，這讓整個網際網路更加穩定可靠。

為什麼需要 DNS？

你可能會問，為什麼不直接使用 IP 位址就好？原因很簡單：IP 位址對人類來說太難記了。試想一下，如果你要記住常用的十個網站的 IP 位址，像是 142.250.185.46（Google）、13.107.42.14（Microsoft）等等，是不是很容易搞混？而且 IP 位址可能會改變，但網域名稱可以保持不變，這為網站管理者提供了靈活性。

DNS 的出現解決了這個問題。它讓我們可以用有意義、容易記憶的名稱來訪問網站。當網站需要更換伺服器或 IP 位址時，只需要更新 DNS 記錄就好，使用者完全不會察覺到任何變化。這就像你的朋友換了手機號碼，只要更新通訊錄就能繼續聯絡，不需要記新的號碼。

此外，DNS 還支援負載平衡 (Load Balance) 和故障轉移 (Failover) 功能。一個網域名稱可以對應到多個 IP 位址，當某台伺服器故障時，DNS 可以自動將流量導向其他正常運作的伺服器。這對於大型網站來說至關重要，確保了服務的高可用性。

DNS 的運作原理

DNS 查詢的完整流程

當我們在瀏覽器輸入一個網址時，DNS 查詢就開始了。這個過程看似簡單，實際上涉及多個步驟和不同的伺服器協作。讓我們一步步來看看當你輸入 www.example.com 時會發生什麼事。

首先，你的電腦會檢查本地快取，看看最近是否查詢過這個網域。如果有，就直接使用快取中的 IP 位址，這樣可以節省時間。如果沒有，查詢請求會被送到你的 ISP（網際網路服務供應商）提供的 DNS 解析器，或者你手動設定的 DNS 伺服器。

DNS 解析器收到請求後，它會先查看自己的快取。如果沒有找到，它就會開始一系列的查詢過程。首先，它會向根名稱伺服器詢問：「誰知道 .com 網域的資訊？」根伺服器會回覆：「你去找 .com 的 TLD 伺服器吧。」

接著，解析器向 TLD 伺服器詢問：「example.com 的權威伺服器在哪裡?」TLD 伺服器會提供權威名稱伺服器的位址。

最後，解析器向 example.com 的權威名稱伺服器查詢 www.example.com 的 IP 位址。權威伺服器回覆正確的 IP 位址後,解析器會將這個結果快取起來,並回傳給你的電腦。整個過程通常在幾十毫秒內完成,我們幾乎感覺不到任何延遲。

下圖是完整流程：

DNS 解析的四大伺服器

DNS 系統的運作依賴四種主要的伺服器類型,每一種都扮演著不可或缺的角色。了解這些伺服器的功能,可以幫助我們更深入理解 DNS 的工作機制。

遞迴解析器(Recursive Resolver)

遞迴解析器是 DNS 查詢的起點,也是最接近使用者的那一層。當你的電腦需要解析一個網域名稱時,它會將請求發送給遞迴解析器。這個解析器就像是一個勤奮的圖書館員,它會代替你去查找所需的資訊。

遞迴解析器的特點是它會「遞迴」地進行查詢,也就是說,它會一直追問下去直到找到答案。它會記住你查詢過的結果,下次有人查詢相同的網域時,就能直接提供答案,不需要再跑一遍完整的查詢流程。大多數 ISP 都會提供自己的遞迴解析器,但你也可以使用像 Google Public DNS 或 Cloudflare 這樣的公共 DNS 服務。

根名稱伺服器(Root Nameserver)

根名稱伺服器位於 DNS 階層架構的最頂端。全球只有 13 組根伺服器(標記為 A 到 M),但實際上透過任播技術,每組根伺服器在世界各地都有多個實體伺服器副本,總數超過數百台。

根伺服器不會直接告訴你某個網站的 IP 位址,它們的工作是指引查詢到正確的 TLD 伺服器。當遞迴解析器詢問 www.example.com 的位址時,根伺服器會說:「我不知道具體位址,但我知道誰負責 .com 網域,你去問它。」這就像是總機告訴你應該轉接到哪個部門。

TLD 名稱伺服器

TLD(Top-Level Domain)名稱伺服器負責管理頂級網域,像是 .com、.org、.tw 等等。每個 TLD 都有專門的名稱伺服器來處理該網域下的查詢。當你查詢 example.com 時,.com 的 TLD 伺服器會告訴你哪個權威名稱伺服器負責 example.com 這個網域。

TLD 伺服器維護著該頂級網域下所有註冊網域的記錄。它們就像是各個城市的資訊中心,知道城市裡每條街道的負責單位。台灣的 .tw 網域就是由 TWNIC(台灣網路資訊中心)負責管理其 TLD 伺服器。

權威名稱伺服器(Authoritative Nameserver)

權威名稱伺服器是 DNS 查詢鏈的最後一站,它擁有特定網域的最終、最權威的資訊。如果說前面的伺服器都在指路,那麼權威名稱伺服器就是真正知道答案的那個人。

當查詢到達 example.com 的權威名稱伺服器時,它會查看自己的記錄,然後回覆:「www.example.com 的 IP 位址是 93.184.216.34。」這個答案就會一路傳回給遞迴解析器,最終到達你的電腦。網域的擁有者可以透過 DNS 管理介面來設定和更新權威名稱伺服器上的記錄。

DNS 記錄類型有哪些？

A 記錄與 AAAA 記錄

DNS 記錄是儲存在權威名稱伺服器上的資料,定義了網域名稱與各種資源之間的對應關係。最基本也最重要的是 A 記錄和 AAAA 記錄。

A 記錄(Address Record)是最常見的 DNS 記錄類型,它將網域名稱對應到 IPv4 位址。例如,www.example.com 的 A 記錄可能指向 93.184.216.34。當你在瀏覽器輸入這個網址時,DNS 會查詢 A 記錄來找到對應的伺服器。

AAAA 記錄(也讀作「quad-A」)則是 A 記錄的 IPv6 版本。隨著 IPv4 位址逐漸耗盡,IPv6 變得越來越重要。AAAA 記錄將網域名稱對應到 128 位元的 IPv6 位址,例如 2606:2800:220:1:248:1893:25c8:1946。現代網站通常會同時設定 A 和 AAAA 記錄,以支援使用不同 IP 協定的使用者。

CNAME、MX 與其他常見記錄

除了 A 和 AAAA 記錄,還有許多其他類型的 DNS 記錄服務於不同目的。CNAME 記錄(Canonical Name)用於建立別名。例如,你可以設定 www.example.com 為 example.com 的 CNAME,這樣兩個網址都會指向同一個地方。這在管理多個子網域時特別方便。

MX 記錄(Mail Exchange)指定了接收電子郵件的郵件伺服器。當有人寄信到 user@example.com 時,發送方的郵件伺服器會查詢 example.com 的 MX 記錄,找出應該將郵件送到哪台伺服器。MX 記錄還包含優先順序,讓你可以設定主要和備用郵件伺服器。

TXT 記錄可以儲存任意文字資訊,常用於網域驗證、SPF(Sender Policy Framework)設定來防止郵件欺騙,或是 DKIM 數位簽章。NS 記錄(Name Server)則指定了該網域使用哪些名稱伺服器。還有 PTR 記錄用於反向 DNS 查詢,SOA 記錄儲存網域的管理資訊等等。

DNS 的快取 (暫存) 機制

瀏覽器與作業系統快取

為了提升效能和減少網路流量,DNS 系統在多個層級實作了快取機制。最接近使用者的快取存在於瀏覽器和作業系統中。當你訪問一個網站時,瀏覽器會將 DNS 查詢結果儲存在記憶體中。下次你再訪問同一個網站時,瀏覽器就能直接使用快取的 IP 位址,不需要再進行 DNS 查詢。

每個瀏覽器都有自己的 DNS 快取管理機制。Chrome 瀏覽器的快取通常會保留數分鐘到數小時,你可以在網址列輸入 chrome://net-internals/#dns 來查看和清除快取。Firefox、Safari 等瀏覽器也都有類似的功能。

作業系統層級的 DNS 快取則由系統的 DNS 客戶端服務管理。Windows、macOS 和 Linux 都會維護自己的 DNS 快取。當瀏覽器的快取過期或沒有找到記錄時,就會詢問作業系統的快取。這層快取通常保留時間較長,能夠讓多個應用程式共享 DNS 查詢結果。

TTL 生存時間的重要性

TTL(Time To Live,生存時間)是 DNS 記錄中的一個重要參數,它決定了這筆記錄可以被快取多久。TTL 以秒為單位,例如 TTL=3600 表示這筆記錄可以被快取一小時。當 TTL 到期後,快取會被視為過期,下次查詢時就需要重新向權威伺服器取得最新資料。

設定適當的 TTL 值需要在效能和靈活性之間取得平衡。較長的 TTL(例如 86400 秒,即 24 小時)可以減少 DNS 查詢次數,降低伺服器負載,提升網站存取速度。但缺點是,當你需要更改 IP 位址時,更新會較慢生效,因為舊的記錄可能還在全球各地的快取中。

較短的 TTL(例如 300 秒,即 5 分鐘)讓你能快速更新 DNS 記錄,這在伺服器遷移或故障轉移時很有用。但代價是會產生更多的 DNS 查詢流量。一般建議是,在正常運作時使用較長的 TTL,而在計劃進行變更前幾天先降低 TTL 值,這樣變更時就能更快生效。

常見的 DNS 問題與解決方法

DNS 解析失敗怎麼辦？

有時候我們會遇到網頁無法開啟的情況,錯誤訊息顯示「DNS_PROBE_FINISHED_NXDOMAIN」或「找不到伺服器」。這通常是 DNS 解析出現問題。首先,你可以嘗試清除 DNS 快取。在 Windows 上,開啟命令提示字元並執行 ipconfig /flushdns;在 macOS 上使用 sudo dscacheutil -flushcache;Linux 用戶則可以重啟 systemd-resolved 服務。

如果清除快取後問題仍然存在,可能是你的 DNS 伺服器本身出了問題。這時候切換到其他 DNS 伺服器通常能解決問題。你也可以檢查網路連線是否正常,嘗試 ping 8.8.8.8 這樣的 IP 位址,如果能 ping 通但網頁打不開,就確認是 DNS 問題。

有時候問題出在網域本身。網域可能過期未續約,或是 DNS 記錄設定錯誤。如果你是網域管理者,可以使用 nslookup 或 dig 這類工具來檢查 DNS 記錄是否正確。線上工具如 DNS Checker 可以幫你從全球不同地點檢查 DNS 傳播狀況。Google 自己也有 Google Admin Toolbox 可以用喔！

如何更換 DNS 伺服器？

更換 DNS 伺服器是改善上網速度和安全性的簡單方法。在 Windows 10/11 上,進入「設定」>「網路和網際網路」>「乙太網路」或「Wi-Fi」,點擊你的連線,選擇「編輯 IP 設定」,然後手動輸入 DNS 伺服器位址。

macOS 用戶可以前往「系統設定」>「網路」,選擇你的網路連線,點擊「進階」,然後在「DNS」分頁中新增伺服器。你可以新增多個 DNS 伺服器,系統會依序嘗試使用它們。

在路由器層級更改 DNS 設定會影響連接到該路由器的所有裝置。登入路由器管理介面(通常是 192.168.1.1 或 192.168.0.1),找到 WAN 或網際網路設定,將 DNS 伺服器從「自動取得」改為「手動設定」,然後輸入你想使用的 DNS 伺服器位址。更改後記得重啟路由器讓設定生效。

公共 DNS 服務推薦

Google DNS、Cloudflare DNS 等選擇

市面上有許多優質的公共 DNS 服務可供選擇。Google Public DNS 是最早也是最受歡迎的公共 DNS 之一,主要 DNS 位址是 8.8.8.8 和 8.8.4.4(IPv4),或 2001:4860:4860::8888 和 2001:4860:4860::8844(IPv6)。Google DNS 以穩定性和全球覆蓋率著稱,在世界各地都有伺服器節點。

Cloudflare 的 1.1.1.1 是後起之秀,主打速度和隱私。Cloudflare 承諾不會記錄使用者的查詢資料,並在 24 小時後刪除所有日誌。他們的 DNS 服務在許多效能測試中都名列前茅,備用伺服器是 1.0.0.1。Cloudflare 還提供 1.1.1.1 for Families 服務,可以過濾惡意軟體和成人內容。

Quad9(9.9.9.9)注重安全性,會封鎖已知的惡意網域,保護你免受網路釣魚和惡意軟體威脅。OpenDNS(208.67.222.222 和 208.67.220.220)提供家長控制功能,可以過濾不適當的內容。台灣用戶可以考慮使用 HiNet 的 DNS(168.95.1.1 和 168.95.192.1),因為地理位置較近,理論上延遲會較低。

選擇 DNS 服務時,可以考慮速度、隱私政策、安全功能和可靠性。你也可以使用 DNS Benchmark 這類工具來測試不同 DNS 服務在你所在位置的實際表現,選擇最適合自己的那一個。

DNS 安全性議題

DNS 劫持與中間人攻擊

DNS 系統雖然便利,但也存在安全隱憂。DNS 劫持(DNS Hijacking)是指攻擊者透過修改 DNS 設定,將你導向錯誤的 IP 位址。這可能發生在你的路由器、電腦或 ISP 的 DNS 伺服器上。攻擊者可能將你導向偽造的銀行網站,竊取你的帳號密碼和個人資料。

DNS 快取污染(DNS Cache Poisoning)是另一種常見攻擊。攻擊者向 DNS 伺服器發送偽造的回應,讓伺服器快取錯誤的記錄。當其他使用者查詢這個網域時,就會得到錯誤的 IP 位址。這種攻擊可以影響大量用戶,而且很難被發現。

中間人攻擊 (Man-in-the-Middle) 利用 DNS 查詢未加密的特性。攻擊者可以攔截你的 DNS 查詢,並回傳偽造的回應。傳統的 DNS 查詢是明文傳輸的,任何人都能看到你查詢了哪些網站,這也是隱私方面的問題。要防範這些攻擊,可以使用有信譽的 DNS 服務、定期檢查路由器設定、保持系統更新,並注意網站的 SSL 憑證是否正確。

DNSSEC 是什麼？

DNSSEC (DNS Security Extensions) 是為了解決 DNS 安全問題而開發的一套擴充協定。它透過數位簽章來驗證 DNS 回應的真實性,確保你收到的 DNS 記錄確實來自權威伺服器,而且沒有被竄改過。

DNSSEC 的運作原理類似於 HTTPS 的數位憑證。網域擁有者會用私鑰對 DNS 記錄進行簽章,而查詢者可以用公鑰來驗證簽章。每一層的 DNS 伺服器都會驗證下一層的簽章,形成一條信任鏈,從根伺服器一直延伸到目標網域。

雖然 DNSSEC 提供了更好的安全性,但它的部署還不夠普及。啟用 DNSSEC 需要額外的設定和管理,而且會增加 DNS 回應的大小和處理時間。不過,越來越多的網域開始支援 DNSSEC,尤其是政府機關和金融機構的網站。GCP 的 Cloud DNS 也有提供 DNSSEC 的功能，說明文件在此。

除了 DNSSEC,DNS over HTTPS(DoH)和 DNS over TLS(DoT)也是提升 DNS 安全性的技術。它們透過加密連線來傳輸 DNS 查詢,防止被竊聽或竄改。Firefox 和 Chrome 等現代瀏覽器都已經支援 DoH,讓你的 DNS 查詢更加私密和安全。

結論

DNS 是網際網路基礎建設中不可或缺的一部分,它將複雜的 IP 位址轉換成我們容易記憶的網域名稱,讓上網變得簡單直覺。透過本文,我們了解了 DNS 的基本概念、運作原理、各種記錄類型,以及快取機制。我們也探討了常見的 DNS 問題和解決方法,介紹了值得信賴的公共 DNS 服務,並討論了 DNS 的安全性議題。

雖然 DNS 的運作過程複雜,涉及多層伺服器的協作,但對一般使用者來說,它就是默默在背後工作,讓我們能順暢地瀏覽網頁、收發郵件、使用各種網路服務。當你遇到連線問題時,現在你知道如何從 DNS 的角度來診斷和解決。選擇適合的 DNS 服務,注意安全性,就能享受更快速、更安全的上網體驗。

DNS 技術還在不斷演進,從 DNSSEC 到 DoH,都是為了讓這個系統更安全、更有效率。作為網路使用者,了解 DNS 的基本知識能幫助我們更好地掌控自己的上網體驗,也能在遇到問題時知道該如何應對。希望這篇文章能讓你對 DNS 有更深入的認識!

常見問題解答

Q1: DNS 和 IP 位址有什麼差別?

IP 位址是網路上每台裝置的實際地址,就像門牌號碼一樣。DNS 則是將容易記憶的網域名稱(如 google.com)轉換成 IP 位址的系統。簡單說,DNS 是翻譯機,IP 位址是目的地。我們輸入網域名稱,DNS 幫我們找到對應的 IP 位址,然後電腦才知道要連到哪台伺服器。

Q2: 更換 DNS 能提升網速嗎?

可以,但效果有限。更換到速度較快的 DNS 服務可以縮短網域解析時間,讓網頁開始載入得更快一點。不過 DNS 查詢通常只佔整個連線過程的一小部分,而且有快取機制。真正影響網速的主要是你的網路頻寬、伺服器距離和網站本身的效能。換 DNS 比較明顯的好處是提升穩定性和安全性。

Q3: 為什麼更改 DNS 設定後還是連不上網?

可能有幾個原因:首先,DNS 記錄有 TTL 設定,舊的記錄可能還在快取中,需要等待一段時間或手動清除快取。其次,可能是你輸入的 DNS 伺服器位址有誤,仔細檢查數字是否正確。也可能是網路連線本身有問題,或是防火牆阻擋了 DNS 查詢。試著用其他裝置測試,或暫時改回自動取得 DNS 來排除問題。

Q4: 什麼是 DNS 污染?如何避免?

DNS 污染是指 DNS 伺服器的快取被植入錯誤或惡意的記錄,導致使用者被導向錯誤的網站。這可能是遭受攻擊,或是某些地區刻意的網路管制。要避免 DNS 污染,可以使用可信賴的公共 DNS 服務如 Cloudflare 或 Google DNS,啟用 DNSSEC 驗證,或使用 DoH/DoT 加密 DNS 查詢。定期清除 DNS 快取也有幫助。

Q5: 企業需要架設自己的 DNS 伺服器嗎?

這取決於企業規模和需求。大型企業通常會架設內部 DNS 伺服器來管理內部網域和提供更好的控制。自己的 DNS 伺服器可以加快內部網域的解析速度,提供客製化的 DNS 記錄,並增強安全性。但小型企業可能不需要,使用網域註冊商提供的 DNS 服務就足夠了。架設 DNS 伺服器需要專業知識和持續維護,要考慮成本效益。

The post DNS 是什麼？就是把網址轉成 IP，你的手機和電腦才能找到網站 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

一、在本地端解析網網域名稱

你輸入的網址 (如 www.bytebytego.com) 電腦是看不懂的，

需要轉換成電腦能理解的地址，也就是 IP 位址 (如172.67.73.33)。

瀏覽器首先會在不同的「快取」(cache，是暫時儲存資料的地方) 中尋找：

• 瀏覽器自己的快取

• 電腦作業系統的快取

• 本地網路 (你家、辦公室或學校) 的快取

• 網路服務商 (ISP) 的快取

快取的內容到底包含什麼東西呢？

就像是一本通訊錄，記錄著網址和 I P位址的對應關係。

如果這些地方都找不到，就會向DNS (網域名稱系統，像是網路世界的電話簿) 詢問。

二、向外查詢 IP 位址

DNS 系統包含多個 DNS 伺服器，它們會互相詢問，直到找到正確的IP位址。

詢問的順序如下：

1. 你的設備會詢問本地 DNS 解析器。

像中華電信的DNS 解析器 IP 為 168.95.1.1、168.95.192.1，

Google 的 DNS 解析器 IP 為 8.8.8.8 和 8.8.4.4。

2. 如果本地解析器沒有答案，它會詢問根網域伺服器。

根網域 (Root Domain) 伺服器是網際網路 DNS 層級結構中最高層級的 DNS 伺服器，

它們儲存所有頂級網域（如 .com、.org、.net 等）的 DNS 伺服器資訊。

3. 根伺服器會指引到相應的頂級網域伺服器。

當根伺服器收到查詢時，它們會指向適當的頂級網域伺服器 (Top-Level Domain Server)，

根網域伺服器不直接知道 bytebytego.com 的 IP 地址，

但它知道 .com 頂級網域伺服器的位置。

根伺服器會說：「我不知道 www.bytebytego.com 的 IP，

但我知道負責 .com 的伺服器在哪裡，去問問它們吧。」

4. TLD 伺服器會指引到負責特定網域的權威網域伺服器

權威網域伺服器 (Ahthoritative Name Server) 管理的，

這通常是由該網域所屬公司 (例如：bytebytego)，

或其選擇的 DNS 服務提供商 (例如可能是 Namecheap) 來維護。

這個過程叫做「遞迴 DNS 查詢」，就像是在多個部門間傳遞訊息，直到找到答案。

三、建立連線並發送請求

知道 IP 位址後，瀏覽器就會向該位址發送請求。

為了安全，現在大多使用 HTTPS 協定，你會在網址前看到一個小鎖頭圖示。

像是這樣 (現在要點開才能看到鎖頭)：

建立安全連線的過程包括：

1. TCP 三方交握 (像是在握手確認彼此身份)

a. 第一次握手

客戶端(也就是瀏覽器)：「嘿！伺服器，你在嗎？我想和你說話！」

技術上：客戶端發送一個 SYN（同步）封包。

b. 第二次握手

伺服器：「嗨客戶端！我在這兒。你能聽到我嗎？」

技術上：伺服器回應一個 SYN-ACK（同步-確認）封包。

c. 第三次握手：

客戶端：「太好了，我聽得很清楚。讓我們開始聊天吧！」

技術上：客戶端發送一個 ACK（確認）包。

現在，雙方都確認可以聽到對方，建立了連結。

2. 交換加密金鑰 (像是交換只有雙方知道的密碼)

這就像兩個人想秘密交談，但擔心周圍有人偷聽：

a. 伺服器出示證書：

伺服器：「看，這是我的身份證（SSL證書）。你可以相信我。」

這個證書包含伺服器的公鑰。

b. 客戶端驗證證書：

客戶端檢查證書是否有效，就像檢查身份證的真偽。

c. 客戶端生成會話金鑰 (Session Key)：

客戶端：「好的，我相信你。我們來用這個特殊的密碼本吧。」

客戶端創建一個隨機的會話金鑰（相當於密碼本），指的是加密的方法。

d. 加密傳送會話金鑰：

客戶端用伺服器的公鑰加密會話金鑰。

就像把密碼本放在只有伺服器能打開的盒子裡。

e. 伺服器解密會話金鑰：

服務器用自己的私鑰打開”盒子”，獲得會話金鑰。

f. 開始加密通訊：

雙方：「太好了，現在我們可以用這個特殊的密碼本安全地交談了！」

之後的所有通信都用這個會話金鑰加密。

這確保了你和網站之間的通訊是加密的,別人無法竊聽或篡改。

四、處理回應

(一) 網站回應 (Response)

網站伺服器收到請求後，會處理並發送回應。

回應通常包含三部分：

1. HTML (網頁的基本結構)

就是告訴瀏覽器：

這裡放個標題，那裡放段文字，這邊擺張圖片。

它就像是在紙上畫房子的平面圖。

2. CSS (控制網頁外觀)

CSS就是告訴瀏覽器：

這個標題要大一點、藍色的；

段文字要靠右邊、加個底線。

它就像是一個裝潢師，負責讓整個網頁看起來漂亮。

3. JavaScript (控制網頁行為)

JavaScript讓網頁變「聰明」了，它能理解你的操作並作出反應。

比如，你在購物網站點了「加入購物車」，

不需要重新載入整個頁面，購物車的數字就會立即更新，

這就是JavaScript在工作。

(二)、瀏覽器動作

瀏覽器接收這些資料後，會進行以下步驟：

1. 解析 HTML 生成 DOM 樹 (Document Object Model Tree)

DOM 樹就是這個網頁的組織結構，它顯示不同元素之間的關係，

第一層是網頁的 <html> 標籤，

第二層是 <body> 標籤，

第三層是<div> 或其他容器標籤。

DOM 樹就是將網頁結構變成瀏覽器能理解的格式。

2. 解析 CSS 生成 CSSOM 樹

CSSOM 樹（CSS Object Model Tree）是與 DOM 樹相對應的另一個重要概念。

CSSOM 樹是瀏覽器對網頁所有 CSS 樣式的內部表示。

它與 DOM 樹平行存在，共同決定網頁的最終呈現。

簡單說就是，將樣式資訊轉換成瀏覽器能理解的格式。

3. 結合 DOM 和 CSSOM 生成渲染樹 (Render Tree) 

渲染樹是用來決定每個元素應該如何顯示

就像是在精心策劃一場時裝秀，

將「誰要出場」(DOM) 和「穿什麼衣服」(SSSOM) 的訊息結合起來，

形成一個清晰的「演出計劃」。

4. 根據渲染樹繪製網頁

如前段的「演出計劃」，告訴瀏覽器究竟該在螢幕上畫出什麼，怎麼畫。

這個過程看似複雜，但瀏覽器都自動完成了，

讓我們能夠看到美觀且功能完整的網頁。

就是讓瀏覽器把網頁畫出來給你看的意思。

這整個過程通常在幾秒內完成，

涉及網路通訊、資料加密、以及複雜的瀏覽器渲染機制。

雖然背後技術複雜，但對使用者來說，

只是輸入網址後稍等片刻，網頁就呈現在眼前了。

The post [轉職IT必修課] 瀏覽器原理：你用瀏覽器輸入網址後，背後發生什麼事？DNS、三方交握、加密通訊等概念簡介 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

結果想要用自己的 SSL 憑證，一直測試失敗，

最後才赫然發現，Cloud Run 根本能不用自己的憑證啊啊！

說明文件在這裡：

看來必須使用 Load Balancer 了，

這裡做一個簡單的 Apache 和 PHP 網頁

vim index.php

<?php
echo "Hello World from web1 Dongdong";
?>

vim Dockerfile

# Use the official PHP image
FROM php:7.4-apache

# Copy the PHP file to the Apache document root
COPY index.php /var/www/html/

# Change the default Apache port to 8080
RUN sed -i 's/80/8080/g' /etc/apache2/sites-available/000-default.conf /etc/apache2/ports.conf

# Expose port 8080
EXPOSE 8080

# Set the ServerName to suppress warnings
RUN echo "ServerName localhost" >> /etc/apache2/apache2.conf

資料夾內只要這兩個檔案：

ls -l

先在 Arfitact Registry 建立 php 這個 Repository

建立 Docker Image

docker build -t asia-east1-docker.pkg.dev/dong-dong-gcp-3/php/web001 .

測試一下，用 8080 Port 看一下：

成功看到網頁了！

快速用 gcloud 部署，指令如下：

gcloud run deploy web001 \
  --image asia-east1-docker.pkg.dev/dong-dong-gcp-3/php/web001 \
  --platform managed \
  --region asia-east1 \
  --port 8080 \
  --allow-unauthenticated \

看一下 Cloud Run 主頁：

點擊 web001

再點 URL，看到網頁了。

接下來去保留一個固定 IP，準備給 Load Balancer 用

取一下名字，我們用 Global IP

取得 IP 了。

去建立 Load Balancer

選擇 Application Load Balancer

公開的 Load Balancer (Public Facing)

選 Best for global

選 Global External ALB

再按 Create

先取個名字 lb-1, 也給 Frontend 取名字 fe-1, 然後 Protocol 選 HTTPS

IP 可以選擇剛剛建立的 IP

然後在憑證的部份，選擇 Create a new Certificate

取個名字 cert-web001，然後上傳自己做好的憑證檔案。

這兩個憑證檔案是使用 Letsencrypt 去申請的：

Certificate 使用 ssl_fullchain001.pem 這個檔案

Private Key 使用 ssl_privkey001.pem 這個檔案。

上傳格式如果正確，會看到 GCP 有針對到憑證的資訊，

沒問題就可以按 Create

你會看到憑證建立成功

它還可以讓你把 HTTP 轉到 HTTPS，勾選後按下 Done

接下來點擊後端，建立一個 Backend Service

取名字 bk-1， 重要的是 Backend type 要選 Serverless Network Endpoint Group：

然後在 New backend 選擇那個 Cloud Run

為 Serverless NEG 取名字

其他地方就保持預設，按下 Create

再按下 ok

Routing Rules 看一下，因為前端進來只到一個後端，

所以不用再設定。

再看一下 Review and finalize 檢查設定

如果都沒問題就按下 Create。

但是還沒完喔，我們要去設定 DNS

DNS 不一定在 GCP 上喔，這裡指的是你註冊 DNS (購買網域) 的地方，

你可能用的是 Hinet 的 DNS，或是國外的 GoDaddy 或 Namecheap 等等。

像我是在 GoDaddy 註冊 DNS 的，但是我已經轉移管理權限到 Cloud DNS 了。

我就點進我的網域：

然後再點 Add Standard

然後輸入要解析的子網域 web001，

使用 A Record，然後輸入 Load Balancer 使用的 IP，

再按下 Create。

完成後去 Google Admin Toolbox，

確認 Google 的解析結果有沒有設定正確，

看起來會像這樣：

那接下來就等待 Load Balancer 生效並且解析成功。

同時我們也看一下 Load balancer 頁面有兩個

上面那個是幫你把 HTTP 轉到 HTTPS 的

我們點下面 lb-1 進去看，

看到有 SSL 憑證，再點進去

會看到憑證是有效的，還有它的到期日。

最後我們在瀏覽器輸入網址 https://web001.dongdonggcp.com/

我們也開無痕模式，輸入 http://web001.dongdonggcp.com

也看到 http 成功轉 https 了

整個步驟機關很多，如果你做完發現一直都看不到網頁，

你可以從 Load Balancer 一層一層點擊到 Cloud Run，

如果秀不出 Cloud Run 的頁面，表示你可能有接錯服務。

在各個環境多檢查一下，

多點耐心就能設定成功喔！

官方文件可參考這裡。

The post [Cloud Run 教學] Cloud Run 如何使用自己的憑證？必須要接到 Load Balancer first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

除了幫你把網域解析到 Cloud Run 的網址，

還幫你做 HTTP Redirect 到 HTTPS，

你不需要額外使用 Load Balancer 或 Nginx 來 Redirect，

至於 HTTPS 不是要有 SSL 憑證嗎？

有的，GCP 一樣提供免費而且自動續約的憑證，

而且是 Google 自己的根憑證機構發行的憑證，

整個超方便！

當然你也可以使用自己的憑證喔！(不過要使用 Google Load Balancer)

這裡提供設定 DNS 名稱解析的方法。

假設我們已經做好一個 Cloud Run，

就可以直接點擊 Manage Custom Domains：

然後再點擊 Add Mapping：

你先選擇要解析的 Cloud Run 服務，

一方會看到有三種方法可以選擇，

我們就直接選 Cloud Run Domain Mappings：

接下來要選擇解析的網域，

如果你還沒驗證過網域，只會看到 Verify a new domain，

像我這邊有一堆網域，

大多是 blogspot.com 的，是 Google 的部落格服務 Blogger 的網域。

關於網域驗證的說明，可以參考驗證網站擁有權這篇文章。

選好主網域之後，再輸入子網域：

按繼續之後，第三步驟直接按 Done 即可。

但是還沒做完喔！

回到 Domain Mappings 的畫面，

你會看到它一直在轉圈圈，

它提示你要去設定 DNS 的對應：

但是要怎麼設呢？

你看到右邊 Actions 的三個小點，

有一個 DNS records：

點擊之後會看到提示你要設定 CName，

要把你的網域解析到 ghs.googlehosted.com 這個網址：

那我們就直接去設定 DNS 的頁面。

DNS 不一定在 GCP 上喔，這裡指的是你註冊 DNS (購買網域) 的地方，

你可能用的是 Hinet 的 DNS，或是國外的 GoDaddy 或 Namecheap 等等。

像我是在 GoDaddy 註冊 DNS 的，但是我已經轉移管理權限到 Cloud DNS 了。

我就在我的網域直接 ADD STANDARD：

然後把 cloudrun.dongdonggcp.com 解析 CName 到 ghs.googlehosted.com 這個網域：

ghs.googlehosted.com 它可以把所有 Cloud Run 用戶的網域，

解析到各個 Cloud Run 的原始網址，

你也不需要設定什麼 Cloud Run 的 IP (因為沒有特定的 IP)

，非常神奇。

設定好之後，你可以先去 Google Admin Toolbox，

確認 Google 的解析結果有沒有設定正確，

看起來會像這樣：

沒問題的話，大約等 20~30 分鐘，

就會看到綠色勾勾如下：

那我開無痕模式看看網站：

成功了！

如果你的 Cloud Run 服務突然中斷，

它會顯示服務不存在：

但只要你重新部署好，

它會自動又幫你解析，完全不用重新設定 CName 喔！

另外，你也可以輸入 http://cloudrun.dongdonggcp.com

它真的會自動轉成 https 喔，超方便！

我們也可以檢查憑證的細節，

點擊「已建立安全連線」：

再點擊「憑證有效」或右方箭頭顯示憑證：

就會看到憑證的內容：

這個憑證發行單位 Google Trust Services，

是 Google 自己的根憑證機構（Root Certificate Authority，Root CA），

代表自己的憑證自己發行，別人不能發行 Google 的憑證喔！

如果你原本花錢購買自己網域的憑證，

你也可以把錢省下來，是不是非常棒呢！

快來試試看吧！

The post [Cloud Run 教學] 如何串接 DNS 名稱解析？ 免費 SSL 憑證和HTTP Redirect HTTPS 教學 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.