網路通訊協定總覽#

本章彙整應用層常見通訊協定，涵蓋網頁瀏覽、電子郵件、檔案傳輸、遠端管理、名稱解析與時間同步等領域。各協定皆建立於 TCP/IP 傳輸層之上，透過指定的連接埠（Port）提供服務。

各協定預設 Port 一覽#

Well-known Ports（0–1023）由 IANA 統一管理。記住核心協定的預設 Port，有助於防火牆規則設定與故障排除。

HTTP / HTTPS 與 SSL / TLS#

HTTP（HyperText Transfer Protocol）#

HTTP 是全球資訊網的基礎協定，採用請求-回應模型（Request-Response Model）：客戶端發出請求，伺服器回傳資源。

• 無狀態（Stateless）：每次請求獨立，伺服器不保留先前連線資訊
• 方法（Method）：GET（取得資源）、POST（提交資料）、PUT（更新）、DELETE（刪除）等
• 狀態碼（Status Code）：2xx 成功、3xx 重導向、4xx 客戶端錯誤、5xx 伺服器錯誤

sequenceDiagram
    participant C as Client（瀏覽器）
    participant S as Server（Web 伺服器）
    C->>S: TCP 三方交握（SYN / SYN+ACK / ACK）
    C->>S: HTTP Request（GET /index.html）
    S-->>C: HTTP Response（200 OK + HTML）
    C->>S: HTTP Request（GET /style.css）
    S-->>C: HTTP Response（200 OK + CSS）
    Note over C,S: HTTP/1.1 Keep-Alive 可複用同一 TCP 連線

HTTP 版本演進#

HTTPS（HTTP over TLS）#

HTTPS 在 HTTP 與 TCP 之間插入 TLS 加密層，確保傳輸的機密性、完整性與身分驗證。

現代瀏覽器對 HTTP 網站標示「不安全」警告。所有涉及使用者資料的網站皆應部署 HTTPS。

SSL / TLS（安全傳輸層協定）#

SSL（Secure Sockets Layer） 為早期加密協定，現已被 TLS（Transport Layer Security） 取代。兩者常被混稱為「SSL/TLS」。

版本演進#

SSL 2.0、SSL 3.0、TLS 1.0 與 TLS 1.1 皆已被 IETF 正式廢棄（RFC 8996）。伺服器應僅啟用 TLS 1.2 以上版本。

TLS 握手流程#

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: ClientHello（支援的 TLS 版本、加密套件列表、亂數）
    S-->>C: ServerHello（選定 TLS 版本、加密套件、亂數）
    S-->>C: Certificate（伺服器憑證，含公鑰）
    S-->>C: ServerHelloDone
    C->>C: 驗證憑證（CA 信任鏈）
    C->>S: ClientKeyExchange（以公鑰加密預主密鑰）
    C->>S: ChangeCipherSpec（切換至加密模式）
    C->>S: Finished（加密驗證訊息）
    S-->>C: ChangeCipherSpec
    S-->>C: Finished
    Note over C,S: 雙方以對稱金鑰進行加密通訊

TLS 核心機制#

電子郵件協定：SMTP / POP3 / IMAP4#

電子郵件系統由傳送與接收兩個階段組成，分別使用不同協定。

郵件收發架構#

sequenceDiagram
    participant A as 寄件者（MUA）
    participant MS as 寄件 SMTP 伺服器
    participant MR as 收件 SMTP 伺服器
    participant B as 收件者（MUA）
    A->>MS: SMTP（提交郵件）
    MS->>MR: SMTP（轉送郵件）
    MR-->>MR: 儲存至信箱
    B->>MR: POP3 或 IMAP4（取得郵件）
    MR-->>B: 回傳郵件內容

SMTP（Simple Mail Transfer Protocol）#

Port 25 常被 ISP 封鎖以防範垃圾郵件（OP25B, Outbound Port 25 Blocking）。用戶端寄信應使用 Port 587 搭配 SMTP AUTH。

POP3 vs IMAP4#

現代郵件使用以 IMAP4 為主流，配合大容量雲端儲存，可在手機、筆電與網頁信箱間無縫同步。

FTP（File Transfer Protocol）#

FTP 用於在客戶端與伺服器之間進行檔案傳輸，使用兩條獨立的 TCP 連線。

雙通道架構#

主動模式 vs 被動模式#

FTP 以明文傳輸帳號密碼與檔案內容。在安全性要求高的環境中，應改用 FTPS（FTP over TLS）或 SFTP（SSH File Transfer Protocol，基於 SSH）。

SSH（Secure Shell）#

SSH 提供加密的遠端連線，取代早期明文傳輸的 Telnet 與 rlogin。

核心功能#

SSH 認證方式#

建議停用 SSH 密碼認證，僅使用公鑰認證，並變更預設 Port（22）以降低自動化攻擊風險。

SSH 連線流程#

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: TCP 連線（Port 22）
    C->>S: 協商 SSH 版本與加密演算法
    S-->>C: 伺服器公鑰（Host Key）
    C->>C: 驗證 Host Key（首次連線需確認指紋）
    C->>S: 金鑰交換（建立對稱加密通道）
    Note over C,S: 加密通道建立完成
    C->>S: 使用者認證（密碼或公鑰）
    S-->>C: 認證成功，開啟 Session

DNS（Domain Name System）#

DNS 將人類可讀的網域名稱（如 www.example.com）轉換為 IP 位址（如 93.184.216.34），是網際網路運作的基礎設施。

DNS 階層結構#

DNS 採用樹狀階層式架構，由根往下依序為：

DNS 查詢流程#

sequenceDiagram
    participant C as Client
    participant R as 遞迴解析器（Recursive Resolver）
    participant Root as 根名稱伺服器
    participant TLD as TLD 伺服器（.com）
    participant Auth as 權威伺服器（example.com）
    C->>R: 查詢 www.example.com
    R->>R: 檢查快取（Cache）
    Note over R: 快取未命中
    R->>Root: 查詢 www.example.com
    Root-->>R: 回傳 .com TLD 伺服器位址
    R->>TLD: 查詢 www.example.com
    TLD-->>R: 回傳 example.com 權威伺服器位址
    R->>Auth: 查詢 www.example.com
    Auth-->>R: 回傳 A 記錄（93.184.216.34）
    R-->>C: www.example.com = 93.184.216.34
    Note over R: 將結果存入快取（依 TTL）

常見 DNS 記錄類型#

DNS 查詢預設使用 UDP（Port 53），回應超過 512 位元組或進行區域傳送（Zone Transfer）時改用 TCP。

NTP（Network Time Protocol）#

NTP 用於在網路中同步各裝置的系統時鐘，確保時間一致性。

核心概念#

• Port：UDP 123
• 精度：在區域網路中可達毫秒級同步
• 階層（Stratum）：

  層級	說明
  Stratum 0	原子鐘、GPS 等高精度時間源（參考時鐘）
  Stratum 1	直接連接 Stratum 0 的 NTP 伺服器
  Stratum 2	從 Stratum 1 同步的伺服器，依此遞推
  Stratum 16	表示未同步

時間同步對日誌分析、憑證驗證、分散式系統一致性至關重要。若各伺服器時鐘不一致，可能導致認證失敗、事件關聯錯誤等問題。

HTTP Proxy（代理伺服器）#

HTTP Proxy 作為客戶端與目標伺服器之間的中介，代替客戶端發送請求並回傳結果。

代理類型#

主要功能#

反向代理（如 Nginx、HAProxy）在現代 Web 架構中幾乎是標準配置，可同時處理 SSL 終端、負載平衡與靜態資源快取。

REST API#

REST（Representational State Transfer）是一種軟體架構風格，定義了客戶端與伺服器之間透過 HTTP 進行資源操作的設計原則。

REST 核心原則#

HTTP 方法與 CRUD 對應#

HTTP 狀態碼分類#

REST 並非正式的協定或標準，而是一組架構約束。遵循 REST 原則設計的 API 稱為 RESTful API。實際開發中常搭配 OpenAPI（Swagger）規範進行 API 文件化。

本章重點整理#