AWS 網路協定完全指南：TCP、UDP、ICMP 從入門到精通

當你開始學習 AWS 雲端服務，特別是在設定 Security Group（安全群組）或 NACL（網路存取控制清單）時，一定會遇到這些神秘的選項：TCP、UDP、ICMP、ALL。

這些協定到底是什麼？該怎麼選擇？本文將用最淺顯易懂的方式，帶你一次搞懂這些網路協定的本質、差異與實際應用場景。

無論你是剛踏入雲端領域的新手，還是想要更深入理解網路基礎的開發者，這篇文章都將為你建立扎實的基礎概念。我們不只會告訴你「是什麼」，更會透過生活化的比喻和實際案例，讓你真正理解「為什麼」要這樣設定。

什麼是網路協定？

協定的基本概念

協定（Protocol）就是通訊的規則。

想像一下，當你跟朋友打電話時，你們會遵循某些約定俗成的規則：

• 打招呼：「喂～」
• 確認身份：「我是小明」
• 開始對話
• 道別：「再見」

電腦之間的通訊也是如此。如果沒有統一的規則，電腦 A 說的話，電腦 B 可能完全聽不懂。因此，我們需要「協定」來定義：

• 資料如何格式化
• 資料如何傳送
• 如何確認資料有沒有送達
• 出錯時該怎麼處理

為什麼需要不同的協定？

就像寄信有「平信」和「掛號信」的差別，網路通訊也有不同的需求：

• 追求可靠性：例如銀行轉帳，絕對不能漏掉任何資料
• 追求速度：例如線上遊戲，寧願偶爾掉幀也不要延遲
• 診斷用途：例如檢查網路是否暢通

不同的協定就是為了滿足這些不同的需求而設計的。

四大協定詳解

協定總覽表

TCP：穩定可靠的「掛號信」

TCP 的核心機制

TCP 就像郵局的掛號信服務，具有以下特點：

三次握手（Three-Way Handshake）

客戶端：「我想跟你建立連線」（SYN）
伺服器：「好的，我準備好了」（SYN-ACK）
客戶端：「確認，開始傳資料」（ACK）

客戶端：「我想跟你建立連線」（SYN）
伺服器：「好的，我準備好了」（SYN-ACK）
客戶端：「確認，開始傳資料」（ACK）

資料確認機制

• 每傳送一段資料，都會等待對方回覆「收到了」
• 如果沒收到確認，會自動重新傳送
• 保證資料順序正確

TCP 的優缺點

優點：

• ✅ 資料完整性：100% 確保資料送達
• ✅ 資料順序：資料到達順序與送出順序相同
• ✅ 流量控制：避免傳送方速度過快
• ✅ 錯誤檢測：自動偵測並重傳遺失的資料

缺點：

• ❌ 速度較慢：需要建立連線和確認機制
• ❌ 額外負擔：每次傳輸都有握手和確認的成本
• ❌ 不適合即時應用：延遲較高

TCP 的實際應用

網頁瀏覽（HTTP/HTTPS）

• Port 80（HTTP）、Port 443（HTTPS）
• 網頁內容必須完整載入，不能有缺漏

SSH 遠端連線

• Port 22
• 指令執行必須準確無誤

電子郵件

• SMTP (Port 25/587)、POP3 (Port 110)、IMAP (Port 143)
• 郵件內容不能遺失

檔案傳輸（FTP）

• Port 21
• 檔案必須完整無損

AWS Security Group 的 TCP 設定範例

允許 HTTP 流量：

• 類型：自訂 TCP 規則
• 協定：TCP
• 連接埠範圍：80
• 來源：0.0.0.0/0（允許所有人訪問網站）

允許 SSH 連線：

• 類型：SSH
• 協定：TCP
• 連接埠範圍：22
• 來源：203.0.113.0/24（僅允許特定 IP 範圍 SSH 連線）

UDP：快速靈活的「明信片」

UDP 的核心特性

UDP 就像寄明信片，有以下特點：

無連線建立

• 不需要事先「握手」
• 直接開始傳送資料

不保證送達

• 資料可能遺失
• 資料可能亂序到達
• 沒有重傳機制

UDP 的優缺點

優點：

• ✅ 速度極快：沒有握手和確認的延遲
• ✅ 低延遲：適合即時應用
• ✅ 負擔小：標頭資訊簡單，占用資源少
• ✅ 支援廣播：可以一次傳送給多個接收者

缺點：

• ❌ 不可靠：資料可能遺失
• ❌ 無順序保證：封包可能亂序
• ❌ 無流量控制：可能造成網路壅塞

UDP 的實際應用

影音串流

• 直播、Netflix、YouTube
• 偶爾卡頓可以接受，但不能延遲

線上遊戲

• 即時對戰遊戲（如 PUBG、LOL）
• 寧願掉幀也不要延遲

語音通話（VoIP）

• Skype、Discord、LINE 通話
• 即時性比完整性更重要

DNS 查詢

• Port 53
• 快速查詢網域名稱對應的 IP 位址

IoT 裝置

• 感測器資料回傳
• 資料量大且允許少量遺失

AWS Security Group 的 UDP 設定範例

允許 DNS 查詢：

• 類型：自訂 UDP 規則
• 協定：UDP
• 連接埠範圍：53
• 來源：0.0.0.0/0

允許 OpenVPN 連線：

• 類型：自訂 UDP 規則
• 協定：UDP
• 連接埠範圍：1194
• 來源：10.0.0.0/16

ICMP：網路的「體檢工具」

ICMP 的本質

ICMP 不是用來傳送應用程式資料的，而是用來傳遞網路控制訊息和診斷資訊。

把 ICMP 想像成醫院的健康檢查：

• 不是來治病的
• 是來檢查身體狀況的
• 可以及早發現問題

ICMP 的主要功能

1. 網路可達性測試（ping）

ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=119 time=8.547 ms

ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=119 time=8.547 ms

2. 路由追蹤（traceroute）

traceroute google.com
顯示封包經過的每個路由器

traceroute google.com
顯示封包經過的每個路由器

3. 錯誤回報

• Destination Unreachable：目的地不可達
• Time Exceeded：封包生存時間過期
• Redirect：建議使用更好的路由

ICMP 的類型

AWS Security Group 的 ICMP 設定

允許 ping（測試用）：

• 類型：所有 ICMP – IPv4
• 協定：ICMP
• 連接埠範圍：全部
• 來源：你的 IP 位址（安全起見）

生產環境的建議：

• 通常不建議在生產環境開放 ICMP
• 可能被用於網路掃描和 DDoS 攻擊
• 僅在必要時開放給特定 IP

ALL：全開的「測試模式」

ALL 協定的意義

選擇 ALL 表示：

• 不限制任何協定類型
• TCP、UDP、ICMP 全部允許通過
• 包含所有埠號（0-65535）

使用場景

適合的情況：

• ✅ 開發測試環境
• ✅ 快速驗證網路連通性
• ✅ 除錯時排除協定問題

不適合的情況：

• ❌ 生產環境（安全性風險）
• ❌ 面向公網的服務
• ❌ 敏感資料的系統

安全風險警告

開放 ALL 協定就像把家裡所有門窗都打開：

潛在風險：

1. 攻擊面擴大：駭客可以嘗試所有可能的攻擊方式
2. 資源浪費：可能遭受大量無用的請求
3. 合規問題：不符合安全合規要求（如 PCI-DSS、HIPAA）
4. 難以追蹤：無法確定哪些流量是合法的

正確做法：

❌ 錯誤示範：

• 協定：ALL
• 來源：0.0.0.0/0

✅ 正確示範：

• TCP Port 80（HTTP），來源：0.0.0.0/0
• TCP Port 443（HTTPS），來源：0.0.0.0/0
• TCP Port 22（SSH），來源：公司 IP

OSI 七層模型與協定對應

OSI 模型快速入門

OSI（Open Systems Interconnection）模型是理解網路通訊的重要框架，它將網路通訊分成七層，每層負責不同的功能。

OSI 七層架構表

協定所在的層級

層級之間的關係

資料傳輸的實際流程

當你在瀏覽器輸入 https://www.example.com 並按下 Enter：

第 7 層（應用層）

↓ 瀏覽器發出 HTTP GET 請求

第 6 層（表示層）

↓ 使用 SSL/TLS 加密

第 5 層（會話層）

↓ 建立與伺服器的 Session

第 4 層（傳輸層）

↓ TCP 將資料分段並加上序號（Port 443）

第 3 層（網路層）

↓ IP 加上來源和目的地 IP 位址

第 2 層（資料連結層）

↓ 加上 MAC 位址

第 1 層（實體層）

↓ 轉換成電訊號透過網路線傳輸

第 7 層（應用層）

↓ 瀏覽器發出 HTTP GET 請求

第 6 層（表示層）

↓ 使用 SSL/TLS 加密

第 5 層（會話層）

↓ 建立與伺服器的 Session

第 4 層（傳輸層）

↓ TCP 將資料分段並加上序號（Port 443）

第 3 層（網路層）

↓ IP 加上來源和目的地 IP 位址

第 2 層（資料連結層）

↓ 加上 MAC 位址

第 1 層（實體層）

↓ 轉換成電訊號透過網路線傳輸

為什麼 ICMP 在第 3 層而非第 4 層？

關鍵差異：

第 3 層（網路層）的重點：資料要傳到哪裡

• IP：確定目的地位址（192.168.1.1）
• ICMP：確認目的地是否可達、回報路由問題

第 4 層（傳輸層）的重點：資料要怎麼傳

• TCP：確保資料完整送達
• UDP：快速但不保證送達

實際應用理解：

當你 ping 一個 IP 位址：

ping 8.8.8.8

ping 8.8.8.8

1. ICMP 封包不需要 TCP/UDP 的埠號
2. 它直接使用 IP 協定傳送
3. 目的是測試網路層的連通性
4. 不涉及應用程式層的資料傳輸

AWS 實戰應用指南

Security Group 設定最佳實踐

Web 伺服器的標準設定

場景：你要架設一個對外開放的網站

允許 HTTP 流量：

• 類型：HTTP
• 協定：TCP
• 連接埠：80
• 來源：0.0.0.0/0（全球都可以訪問）

允許 HTTPS 流量：

• 類型：HTTPS
• 協定：TCP
• 連接埠：443
• 來源：0.0.0.0/0（全球都可以訪問）

僅允許公司 IP SSH 連線：

• 類型：SSH
• 協定：TCP
• 連接埠：22
• 來源：203.0.113.0/24（僅公司網段）

資料庫伺服器的設定

場景：你的資料庫只讓後端伺服器連線

允許後端伺服器連線 MySQL：

• 類型：MYSQL/Aurora
• 協定：TCP
• 連接埠：3306
• 來源：sg-backend123456（後端伺服器的 Security Group ID）

完全不開放對外連線：

• Outbound：僅允許必要的流量

遊戲伺服器的設定

場景：線上多人遊戲伺服器

遊戲主要連線（UDP）：

• 類型：自訂 UDP 規則
• 協定：UDP
• 連接埠：27015-27030
• 來源：0.0.0.0/0

遊戲查詢埠（TCP）：

• 類型：自訂 TCP 規則
• 協定：TCP
• 連接埠：27015
• 來源：0.0.0.0/0

NACL vs Security Group 的差異

實際應用建議：

• Security Group：第一道防線，精細控制每個實例
• NACL：第二道防線，整個子網路的保護

常見埠號速查表

常用的 TCP 埠號

常用的 UDP 埠號

安全性檢查清單

部署前必檢項目：

• [ ] 是否有任何規則使用 0.0.0.0/0 作為來源？
• 如果有，是否僅限於 Port 80/443？
• [ ] SSH (Port 22) 是否限制了來源 IP？
• ✅ 應該：僅公司 IP 或 VPN
• ❌ 不應該：0.0.0.0/0
• [ ] 資料庫埠是否暴露在公網？
• ✅ 應該：僅允許後端 Security Group
• ❌ 不應該：0.0.0.0/0
• [ ] 是否使用了 ALL 協定？
• ✅ 測試環境：可以
• ❌ 生產環境：絕對不行
• [ ] Outbound 規則是否過於寬鬆？
• 原則：僅開放必要的對外連線

常見問題與疑難排解

為什麼 TCP 比較慢？

技術原因：

1. 三次握手的時間成本

客戶端 → 伺服器：SYN（耗時：1 個 RTT）
伺服器 → 客戶端：SYN-ACK（耗時：1 個 RTT）
客戶端 → 伺服器：ACK（耗時：1 個 RTT）
總計：3 個來回時間才能開始傳輸資料

客戶端 → 伺服器：SYN（耗時：1 個 RTT）
伺服器 → 客戶端：SYN-ACK（耗時：1 個 RTT）
客戶端 → 伺服器：ACK（耗時：1 個 RTT）
總計：3 個來回時間才能開始傳輸資料

2. 每個封包都要確認

• 傳送方發送資料後，必須等待接收方的 ACK
• 如果沒收到 ACK，需要重傳
• 這增加了延遲時間

2. 流量控制機制

• TCP 會自動調整傳輸速度
• 避免接收方來不及處理
• 這會降低傳輸效率

實際影響：

• 網頁首次載入較慢（需要建立連線）
• 但後續的資料傳輸相對穩定

為什麼 UDP 不能用在銀行網站？

風險分析：

資料遺失的後果：

你要轉帳 10,000 元給朋友

使用 UDP：
封包 1：帳號 123456789（✅ 送達）
封包 2：金額 10000（❌ 遺失）
封包 3：確認轉帳（✅ 送達）

結果：系統不知道要轉多少錢，交易失敗或金額錯誤！

你要轉帳 10,000 元給朋友

使用 UDP：
封包 1：帳號 123456789（✅ 送達）
封包 2：金額 10000（❌ 遺失）
封包 3：確認轉帳（✅ 送達）

結果：系統不知道要轉多少錢，交易失敗或金額錯誤！

TCP 的保障：

• 確保每個資料封包都送達
• 保證金額、帳號、時間戳記完整無誤
• 任何遺失都會自動重傳

為什麼遊戲可以用 UDP？

• 遊戲中掉幀一、兩個畫面，玩家可能不會注意
• 但延遲 0.5 秒，遊戲體驗會很糟
• 因此選擇「速度」而非「完整性」

ICMP 會被防火牆擋掉嗎？

答案：會的，而且很常見

為什麼要阻擋 ICMP？

1. 安全考量：

• 駭客可以用 ping 掃描網路拓樸
• ICMP flood 攻擊（Ping of Death）
• 資訊洩漏（主機存在性）

1. 企業政策：

• 許多公司預設阻擋所有 ICMP
• 減少攻擊面
• 符合安全合規要求

阻擋 ICMP 的後果：

# 當 ICMP 被阻擋時
$ ping example.com
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1

# 但這不代表網站掛了
$ curl https://example.com
<html>...</html>  # 網站正常運作

# 當 ICMP 被阻擋時
$ ping example.com
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1

# 但這不代表網站掛了
$ curl https://example.com
<html>...</html>  # 網站正常運作

建議做法：

• 生產環境：阻擋對外的 ICMP
• 允許內部網路的 ICMP（方便除錯）
• 特定 IP 可以 ping（如監控系統）

如何選擇適合的協定？

決策樹：

開始
 ↓
資料是否必須 100% 準確？
 ├─ 是 → 使用 TCP
 │        例如：網站、資料庫、檔案傳輸
 └─ 否 → 繼續判斷
         ↓
      是否需要即時性？
       ├─ 是 → 使用 UDP
       │        例如：遊戲、直播、VoIP
       └─ 否 → 是否為診斷用途？
                ├─ 是 → 使用 ICMP
                │        例如：ping、traceroute
                └─ 否 → 重新評估需求

開始
 ↓
資料是否必須 100% 準確？
 ├─ 是 → 使用 TCP
 │        例如：網站、資料庫、檔案傳輸
 └─ 否 → 繼續判斷
         ↓
      是否需要即時性？
       ├─ 是 → 使用 UDP
       │        例如：遊戲、直播、VoIP
       └─ 否 → 是否為診斷用途？
                ├─ 是 → 使用 ICMP
                │        例如：ping、traceroute
                └─ 否 → 重新評估需求

實際案例分析：

Security Group 規則沒生效怎麼辦？

常見原因與解決方法：

1. 規則順序問題（NACL）

❌ 錯誤設定：
規則 100：拒絕 TCP Port 22（Deny）
規則 200：允許 TCP Port 22（Allow）

結果：SSH 無法連線（規則 100 先被評估）

✅ 正確設定：
規則 100：允許 TCP Port 22（Allow）
規則 200：拒絕 TCP Port 22（Deny）

❌ 錯誤設定：
規則 100：拒絕 TCP Port 22（Deny）
規則 200：允許 TCP Port 22（Allow）

結果：SSH 無法連線（規則 100 先被評估）

✅ 正確設定：
規則 100：允許 TCP Port 22（Allow）
規則 200：拒絕 TCP Port 22（Deny）

2. 雙向規則問題（NACL）

只設定 Inbound 允許 Port 80，但忘記設定 Outbound

解決：NACL 需要同時設定 Inbound 和 Outbound

只設定 Inbound 允許 Port 80，但忘記設定 Outbound

解決：NACL 需要同時設定 Inbound 和 Outbound

3. 來源設定錯誤

❌ 設定：來源 = 192.168.1.0/24
但你的 IP 是 203.0.113.5

解決：確認你的實際公網 IP
$ curl ifconfig.me
203.0.113.5

❌ 設定：來源 = 192.168.1.0/24
但你的 IP 是 203.0.113.5

解決：確認你的實際公網 IP
$ curl ifconfig.me
203.0.113.5

4. 協定選擇錯誤

❌ 設定：協定 = UDP，Port 22
但 SSH 使用 TCP

解決：改為 TCP Port 22

❌ 設定：協定 = UDP，Port 22
但 SSH 使用 TCP

解決：改為 TCP Port 22

除錯步驟：

1. 使用 VPC Flow Logs 檢查流量
2. 確認 NACL 和 Security Group 規則
3. 檢查路由表設定
4. 確認實例的網路設定

進階主題探索

TCP 的三次握手與四次揮手

三次握手（Three-Way Handshake）

sequenceDiagram
    participant 客戶端
    participant 伺服器

    Note over 客戶端,伺服器: 第一次握手
    客戶端->>伺服器: SYN (seq=100)
    Note right of 伺服器: 伺服器：我收到請求了

    Note over 客戶端,伺服器: 第二次握手
    伺服器->>客戶端: SYN-ACK (seq=300, ack=101)
    Note left of 客戶端: 客戶端：好，我確認了

    Note over 客戶端,伺服器: 第三次握手
    客戶端->>伺服器: ACK (seq=101, ack=301)

    Note over 客戶端,伺服器: ✅ 連線建立完成

為什麼需要三次，不是兩次？

防止「過期的連線請求」造成問題：

情境：

• 客戶端發送 SYN，但因為網路延遲，這個 SYN 延遲到達伺服器
• 客戶端已經重新發送新的 SYN 並完成連線

如果是兩次握手：

• 伺服器收到舊的 SYN → 建立連線 → 浪費資源 ❌

三次握手：

• 伺服器收到舊的 SYN → 回應 SYN-ACK
• 客戶端不回應 → 連線未建立 ✅

四次揮手（Four-Way Handshake）

sequenceDiagram
    participant 客戶端
    participant 伺服器

    Note over 客戶端,伺服器: 第一次揮手
    客戶端->>伺服器: FIN (seq=1000)
    Note right of 伺服器: 我要關閉連線了

    Note over 客戶端,伺服器: 第二次揮手
    伺服器->>客戶端: ACK (ack=1001)
    Note right of 伺服器: 好，我知道了<br/>（但我還有資料要傳）

    Note over 客戶端,伺服器: 第三次揮手
    伺服器->>客戶端: FIN (seq=2000)
    Note right of 伺服器: 我也要關閉了

    Note over 客戶端,伺服器: 第四次揮手
    客戶端->>伺服器: ACK (ack=2001)
    Note left of 客戶端: 確認關閉

為什麼關閉需要四次？

因為 TCP 是全雙工通訊：

• 客戶端關閉「發送」，但還能「接收」
• 伺服器確認後，可能還有資料要傳
• 伺服器準備好後，才發送自己的 FIN
• 雙方都確認後，連線才完全關閉

UDP 的應用場景深入分析

DNS 為什麼使用 UDP？

DNS 查詢的特性：

• 查詢資料量小（通常 < 512 bytes）
• 需要快速回應
• 如果查詢失敗，客戶端會自動重試

UDP 的優勢：

TCP DNS 查詢：

1. 三次握手（3 個 RTT）
2. DNS 查詢與回應（1 個 RTT）
3. 四次揮手（4 個 RTT）
4. 總計：8 個來回時間

UDP DNS 查詢：

1. DNS 查詢與回應（1 個 RTT）
2. 總計：1 個來回時間

效率提升 8 倍！

特殊情況：
當 DNS 回應超過 512 bytes 時，會自動切換到 TCP：

大型 DNS 回應（如 DNSSEC）→ 使用 TCP Port 53

大型 DNS 回應（如 DNSSEC）→ 使用 TCP Port 53

QUIC 協定：UDP 的進化版

QUIC（Quick UDP Internet Connections）

Google 開發的新協定，基於 UDP 但提供類似 TCP 的可靠性：

優點：

• ✅ 減少連線建立時間（0-RTT）
• ✅ 內建加密（TLS 1.3）
• ✅ 避免隊頭阻塞（Head-of-line blocking）
• ✅ 連線遷移（WiFi 切換到 4G 不斷線）

應用：

• HTTP/3 使用 QUIC
• YouTube、Google 服務大量採用

ICMP 的進階應用

Ping 的工作原理

指令範例：
ping -c 4 8.8.8.8

實際封包流程：

1. 本機送出 ICMP Echo Request (Type 8)
2. 目標主機收到後回應 ICMP Echo Reply (Type 0)
3. 測量往返時間（RTT）
4. 重複執行指定次數

Ping 的參數使用：

# 指定封包大小（測試 MTU）
ping -s 1472 8.8.8.8

# 設定 TTL 值
ping -t 64 8.8.8.8

# 快速 ping（每 0.2 秒一次）
ping -i 0.2 8.8.8.8

# Flood ping（壓力測試，需要 root）
sudo ping -f 8.8.8.8

# 指定封包大小（測試 MTU）
ping -s 1472 8.8.8.8

# 設定 TTL 值
ping -t 64 8.8.8.8

# 快速 ping（每 0.2 秒一次）
ping -i 0.2 8.8.8.8

# Flood ping（壓力測試，需要 root）
sudo ping -f 8.8.8.8

實戰案例演練

案例一：建置高可用性 Web 應用

架構需求：

• 使用 Application Load Balancer（ALB）
• 兩台 Web Server（EC2）
• 一台 RDS 資料庫

ALB Security Group：

Inbound 規則：

• 類型：HTTP，協定：TCP，Port：80，來源：0.0.0.0/0
• 類型：HTTPS，協定：TCP，Port：443，來源：0.0.0.0/0

Outbound 規則：

• 類型：Custom TCP，協定：TCP，Port：8080，目的地：sg-webserver

Web Server Security Group：

Inbound 規則：

• 類型：Custom TCP，協定：TCP，Port：8080，來源：sg-alb
• 類型：SSH，協定：TCP，Port：22，來源：203.0.113.0/24

Outbound 規則：

• 類型：MYSQL/Aurora，協定：TCP，Port：3306，目的地：sg-database
• 類型：HTTPS，協定：TCP，Port：443，目的地：0.0.0.0/0（用於軟體更新）

Database Security Group：

Inbound 規則：

• 類型：MYSQL/Aurora，協定：TCP，Port：3306，來源：sg-webserver

Outbound 規則：

• 無需額外設定（資料庫不主動對外連線）

案例二：遊戲伺服器部署

需求：

• 支援 1000 人同時線上的射擊遊戲
• 需要低延遲
• 需要遊戲伺服器管理介面

Security Group 設定：

Inbound 規則：

• 遊戲主連線（UDP）
  • 類型：Custom UDP
  • 協定：UDP
  • Port：27015-27030
  • 來源：0.0.0.0/0
• 遊戲查詢埠（UDP）
  • 類型：Custom UDP
  • 協定：UDP
  • Port：27000-27010
  • 來源：0.0.0.0/0
• 遊戲管理介面（TCP）
  • 類型：Custom TCP
  • 協定：TCP
  • Port：8080
  • 來源：公司IP
• SSH 管理
  • 類型：SSH
  • 協定：TCP
  • Port：22
  • 來源：公司IP

Outbound 規則：

• 遊戲更新伺服器
  • 類型：HTTPS
  • 協定：TCP
  • Port：443
  • 目的地：0.0.0.0/0
• 遊戲認證伺服器
  • 類型：Custom TCP
  • 協定：TCP
  • Port：2302
  • 目的地：認證伺服器IP

為什麼使用 UDP？

• 射擊遊戲對延遲極度敏感
• 偶爾掉幀可以接受（客戶端會預測補償）
• TCP 的重傳機制會造成延遲飆高

案例三：企業 VPN 閘道

需求：

• 員工從家裡連回公司內網
• 需要高安全性
• 需要監控功能

Security Group 設定：

VPN Gateway：

Inbound 規則：

• OpenVPN 連線
  • 類型：Custom UDP
  • 協定：UDP
  • Port：1194
  • 來源：0.0.0.0/0
• 管理介面
  • 類型：HTTPS
  • 協定：TCP
  • Port：943
  • 來源：公司IP
• SSH 管理
  • 類型：SSH
  • 協定：TCP
  • Port：22
  • 來源：公司IP

Outbound 規則：

• 允許存取內網資源
  • 類型：All Traffic
  • 目的地：10.0.0.0/16（VPC CIDR）
• 允許 DNS 查詢
  • 類型：DNS (UDP)
  • 協定：UDP
  • Port：53
  • 目的地：內網DNS

NACL 額外保護：

Inbound 規則：

• Rule 100: Allow UDP 1194 from 0.0.0.0/0（VPN 連線）
• Rule 200: Allow TCP 943 from 公司IP（管理）
• Rule 300: Allow TCP 22 from 公司IP（SSH）
• Rule *: Deny all

Outbound 規則：

• Rule 100: Allow UDP 1194 to 0.0.0.0/0（VPN 回應）
• Rule 200: Allow All to 10.0.0.0/16（內網流量）
• Rule *: Deny all

結語

網路協定是雲端架構的基石。理解 TCP、UDP、ICMP 的本質與差異，不只是為了通過認證考試，更是為了在實際工作中做出正確的技術決策。

希望這篇指南能幫助你建立扎實的網路基礎，在 AWS 雲端之旅中更加得心應手。

如果你在實作過程中遇到任何問題，記得善用 VPC Flow Logs 和 CloudWatch 來除錯，並且不要害怕實驗和測試！

祝學習順利！🚀