110 地方特考三等 資訊處理 資通網路 考古題詳解

核心觀念

本題考查兩種常見的電腦網路分層模型：

1. ISO 所提出的 OSI 七層模型。
2. 網際網路協定堆疊常用的五層模型。

分層的目的，是將複雜的網路通信功能拆分，每一層各自負責特定工作，並透過介面與相鄰層交換服務。

---

解題方法

依照網路通信由下而上的功能順序排列：

• 最底層負責實體訊號傳輸。
• 再往上負責區域網路中的訊框與媒體存取。
• 接著處理跨網路的封包路由。
• 再由傳輸層負責端點到端點的資料傳送。
• 最上層提供應用程式所需的網路服務。

OSI 模型將上層功能拆得較細，因此共有七層；網際網路五層模型則將 OSI 的「會議層」與「表達層」併入應用層。

---

OSI 七層模型

由下而上如下：

層級	名稱	主要功能
第 1 層	實體層 Physical Layer	傳送位元，處理電氣、光學、機械及實體介面規格
第 2 層	資料鏈結層 Data Link Layer	將位元組成訊框，處理區域網路傳輸、媒體存取及錯誤偵測
第 3 層	網路層 Network Layer	處理封包在不同網路間的傳遞與路由選擇
第 4 層	傳輸層 Transport Layer	提供端點到端點的資料傳輸、可靠性、流量控制及壅塞控制
第 5 層	會議層 Session Layer	建立、管理及終止通信會議，控制對話流程
第 6 層	表達層 Presentation Layer	處理資料格式轉換、編碼、加密、解密及壓縮
第 7 層	應用層 Application Layer	提供應用程式使用的網路服務，例如檔案傳輸、電子郵件及網頁服務

OSI 七層由下而上的完整順序為：

實體層、資料鏈結層、網路層、傳輸層、會議層、表達層、應用層。

---

網際網路協定堆疊五層模型

由下而上如下：

層級	名稱	主要功能
第 1 層	實體層 Physical Layer	在實體媒介上傳送位元
第 2 層	資料鏈結層 Data Link Layer	以訊框為單位，在相鄰網路節點間傳送資料
第 3 層	網路層 Network Layer	以封包為單位，負責網際網路中的路由與轉送

核心觀念

本題考查 traceroute 如何逐跳探測封包所經過的路由器，以及其所利用的 IP 與 ICMP 協定機制。

核心概念包括：

• IP 標頭的 TTL（Time To Live）
• ICMP 的 Time Exceeded（時間 exceeded）訊息
• ICMP 的 Echo Reply 或 UDP 探測封包所引發的 Destination Unreachable
• RFC 1393 所定義的 IP Traceroute Option 與 ICMP Traceroute Message

TTL 並非單純的時間單位，而是封包可經過的最大路由器跳數。封包每通過一個路由器，TTL 會減少 $1$；當 TTL 減至 $0$ 時，路由器會丟棄封包並回傳 ICMP 錯誤訊息。

---

解題方法：傳統 traceroute 的運作原理

傳統 traceroute 的基本方法是逐步增加探測封包的 TTL 值。

1. 傳送第一組探測封包，設定：

$TTL=1$

封包只能到達第一個路由器。第一個路由器將 TTL 減為 $0$ 後，丟棄封包，並回傳：

$\text{ICMP Time Exceeded}$

因此，主機即可取得第一個路由器的 IP 位址。

2. 接著傳送第二組探測封包，設定：

$TTL=2$

封包可以通過第一個路由器，但在第二個路由器處因 TTL 歸零而被丟棄。第二個路由器回傳 ICMP Time Exceeded，主機便取得第二個路由器的 IP 位址。

3. 持續增加 TTL：

$TTL=1,2,3,\ldots$

第 $n$ 組封包會在第 $n$ 個路由器處觸發 ICMP Time Exceeded，因此可依序建立路由路徑：

$R_1 \rightarrow R_2 \rightarrow R_3 \rightarrow \cdots \rightarrow \text{目的地主機}$

4. 當探測封包真正抵達目的地主機時，依探測封包類型不同，會收到不同回應：

• 傳統 Unix traceroute 通常使用目的埠號未開啟的 UDP 封包；目的地主機會回傳 ICMP Destination Unreachable（Port Unreachable）。
• 某些實作使用 ICMP Echo Request；目的地主機則回傳 ICMP Echo Reply。
• Windows tracert 通常使用 ICMP Echo Request。

因此，傳統 traceroute 主要利用：

• IP： TTL 欄位
• ICMP： Time Exceeded、Destination Unreachable 或 Echo Reply
• UDP： 部分實作使用 UDP 作為探測封包的承載協定

---

RFC 1393 所定義的 traceroute 機制

RFC 1393 定義的是 IP Traceroute Option，其設計與傳統逐次調整 TTL 的方式不同。

封包來源端在 IP 標頭加入 Traceroute Option，路由器收到具有此選項的封包後，會依規定處理並產生 ICMP Traceroute Message 回傳給封包來源端。ICMP Traceroute Message 中可包含該路由器的相關資訊，例如：

• 該路由器的 IP 位址
• 封包目前的跳數資訊
• 路由器的輸出介面資訊
• 其他 RFC 1393 定義的追蹤欄位

核心觀念

本題考查 TCP 以「擁塞視窗」$cwnd$ 控制傳送速率的機制，重點在於區分：

• TCP Slow Start：快速探測網路可承受的傳輸量，$cwnd$ 以指數方式增加。
• TCP Congestion Avoidance：接近網路容量後，採保守方式增加，$cwnd$ 以線性方式增加。
• 慢啟動門檻 $ssthresh$：決定 TCP 目前應採用 Slow Start 或 Congestion Avoidance。
• 發生壅塞時，TCP 會降低傳送速率，形成 AIMD（Additive Increase, Multiplicative Decrease，加性增加、乘性減少）。

TCP 實際可傳送的資料量受下式限制：

$$\text{傳送視窗}=\min(cwnd,rwnd)$$

其中 $rwnd$ 是接收端公告視窗；本題主要討論的是 $cwnd$。

---

解題方法

解答可依照 TCP 的狀態轉換說明：

1. 先定義 $cwnd$ 與 $ssthresh$。
2. 說明 Slow Start 的增加方式。
3. 說明達到 $ssthresh$ 後，如何轉入 Congestion Avoidance。
4. 說明偵測到壅塞時的處理方式。
5. 最後比較兩種機制的成長曲線與目的。

---

一、TCP Slow Start 的工作原理

Slow Start 用於連線開始時，或 TCP 偵測到壅塞後重新建立傳輸速率的階段。

TCP 初始設定一個較小的擁塞視窗 $cwnd$，通常以 MSS（Maximum Segment Size）為單位。每收到一個新的 ACK，TCP 就增加約一個 MSS：

$$cwnd \leftarrow cwnd+MSS$$

若一個傳送週期中成功收到約 $cwnd/MSS$ 個 ACK，則每個 ACK 累計增加一個 MSS，因此一個 RTT 後約為：

$$cwnd_{\text{new}}\approx 2cwnd_{\text{old}}$$

因此 Slow Start 的典型成長如下：

$$1,2,4,8,16,\ldots$$

這表示 $cwnd$ 每經過一個 RTT 大致加倍，呈現指數成長。其目的不是立即以最大速率傳送，而是逐步測試網路容量，避免一開始大量封包造成壅塞。

Slow Start 持續至下列任一情況發生：

• $cwnd$ 達到 $ssthresh$；
• 發生封包遺失或其他壅塞徵兆。

當 $cwnd$ 達到 $ssthresh$ 後，TCP 會離開 Slow Start，轉入 Congestion Avoidance。

---

二、TCP Congestion Avoidance 的工作原理

Congestion Avoidance 用於 $cwnd$ 已接近網路可承受容量時，採取較保守的增加方式。

在此階段，每收到一個 ACK，$cwnd$ 的增加量約為：

$$cwnd \leftarrow cwnd+\frac{MSS^2}{cwnd}$$

經過一個 RTT 後，所有 ACK 累計的增加量約為一個 MSS：

$$cwnd_{\text{new}}\approx cwnd_{\text{old}}+MSS$$

因此 Congestion Avoidance 的典型成長如下：

$$8,9,10,11,12,\ldots$$

它呈現近似線性增加，目的在於避免 $cwnd$ 快速成長而再次引發壅塞。此階段也稱為 加性增加（Additive Increase）。

---

三、發生壅塞時的處理

TCP 通常透過逾時（Timeout）、重複 ACK 或快速重傳等現象推測封包遺失，並據此降低傳輸速率。

以傳統 TCP Reno 的基本概念說明：

（一）發生逾時

逾時通常代表壅塞情況較嚴重，TCP 會：

核心觀念

本題考查 RTP 標頭中三個重要欄位的功能：

1. Sequence Number（序號）：辨識封包傳送順序，協助接收端處理封包遺失、重複及亂序。
2. Timestamp（時間戳記）：表示 RTP 資料中第一個取樣資料的取樣時間，用於播放時序、抖動處理及影音同步。
3. Synchronization Source Identifier，SSRC（同步來源識別碼）：辨識同一個 RTP 工作階段中的媒體來源，讓接收端知道封包是由哪一個來源所產生。

RTP 通常搭配 UDP 使用，因此 UDP 本身不保證可靠傳輸、封包順序及即時播放。RTP 必須透過自身的欄位，提供接收端進行排序、遺失判斷與播放同步所需的資訊。

解題方法

回答此題時，依序說明各欄位的「識別對象」與「實際用途」即可：

• Sequence number：識別封包排列順序。
• Timestamp：識別媒體取樣或播放時序。
• SSRC：識別媒體來源。

其中最容易混淆的是 sequence number 與 timestamp：

• Sequence number 是「每一個 RTP 封包」的編號。
• Timestamp 是「媒體取樣時間」的表示，不是封包編號，也不一定每個封包都不同。

Sequence Number（序號）

Sequence number 是 RTP 標頭中的 16 位元欄位，由傳送端為 RTP 封包依序編號。

其主要意義如下：

1. 判斷封包順序

接收端可依 sequence number 將因網路傳輸延遲而亂序抵達的封包重新排列。例如封包序號為 101、103、102，接收端可依序重組為 101、102、103。

2. 偵測封包遺失

若接收端收到序號 201 後直接收到 203，可推知序號 202 的封包可能遺失。RTP 本身不負責重傳，但接收端可利用此資訊進行遺失統計、錯誤隱藏或播放品質評估。

3. 偵測重複封包

若相同序號的封包重複抵達，接收端可判斷為重複封包並予以忽略。

4. 初始值通常不是固定從零開始

傳送端通常以隨機值作為初始 sequence number，之後每傳送一個 RTP 封包便增加 1。由於欄位只有 16 位元，序號到達最大值後會循環回到 0。

須注意，sequence number 是「每個 RTP 封包增加一次」，即使某個封包承載多個音訊取樣，通常仍只增加 1。

Timestamp（時間戳記）

Timestamp 是 RTP 標頭中的 32 位元欄位，表示該 RTP 封包所承載媒體資料的取樣時間。更精確地說，它表示封包中第一個資料位元組的取樣時間。

其主要功能如下：

1. 控制播放時序

接收端可依 timestamp 判斷媒體資料應在何時播放，使聲音或影像依正確時間順序呈現。

2. 處理網路延遲與抖動

RTP 封包可能因網路壅塞而以不規則間隔抵達。接收端可依 timestamp 配合播放緩衝區，將資料按照原本的媒體時間軸播放，而不完全依賴封包抵達時間。

3. 協助影音同步

音訊與視訊通常使用不同的 RTP 工作階段及不同的 timestamp clock rate。接收端可配合 RTCP 提供的時間資訊，將不同媒體流對應到共同的時間基準，以維持音畫同步。

4. timestamp 單位取決於媒體格式

Timestamp 並非直接使用秒數，也不是一般作業系統的絕對時間，而是依 payload type 所對應的媒體時脈計算。例如：

• 採樣率為 $8{,}000$ Hz 的語音，timestamp 每經過一個取樣週期通常增加 1。
• 若每個封包承載 $160$ 個音訊取樣，下一個封包的 timestamp 通常增加 $160$。
• 影像則依所使用的 RTP profile 與媒體格式規定其時脈，常見時脈為 $90{,}000$ Hz。

若封包承載的音訊取樣數為 $N$，則相鄰封包的 timestamp 增量通常為：

核心觀念

本題考查 IPv4 面臨的限制，以及 IPv6 在位址空間、網路管理、封包傳送效率與服務品質等方面的改進。回答時應採「IPv4 問題 → IPv6 對應改進」的方式，逐項說明，避免只列出 IPv6 的新功能而未交代其設計目的。

---

解題方法

可從下列六個面向切入：

1. 位址數量不足。
2. NAT 所造成的連線與管理問題。
3. 路由表膨脹與位址配置缺乏階層性。
4. IPv4 標頭處理效率不佳。
5. 缺乏良好的自動組態、廣播控制與移動支援。
6. 對安全性與服務品質的支援不完整。

---

IPv4 所面臨的問題與 IPv6 改進

一、IPv4 位址空間不足

IPv4 位址長度為 32 位元，理論上共有：

$$2^{32}$$

個位址，約為 43 億個。但實際可分配的數量會受到網路位址、廣播位址、保留位址、私有位址及特殊用途位址等限制。隨著個人電腦、智慧型手機、物聯網裝置及雲端設備大量增加，IPv4 公開位址逐漸耗竭。

IPv6 的改進

IPv6 將位址長度擴充為 128 位元，位址數量為：

$$2^{128}$$

其數量遠大於 IPv4，可提供極大的全球唯一位址空間，足以支援長期的網際網路及物聯網發展。

IPv6 也將位址空間依用途分為單播、群播及任播等類型，使位址配置與服務模式更具彈性。

---

二、NAT 雖延緩位址不足，卻造成端對端連線問題

IPv4 常利用 NAT（Network Address Translation）讓多部使用私有位址的主機共用一個公開 IPv4 位址。NAT 雖可節省公開位址，卻會產生下列問題：

• 破壞端對端連線原則。
• 外部主機無法直接主動連線至內部主機。
• 某些即時通訊、語音、視訊及點對點應用程式需要額外的穿透技術。
• NAT 裝置必須維護連線狀態，增加設備負擔。
• 網路除錯、追蹤與管理較為複雜。

IPv6 的改進

IPv6 提供充足的 128 位元位址，使一般裝置能擁有全球唯一位址，減少依賴 NAT 的必要性，恢復較完整的端對端通訊模式。

需要注意的是，IPv6 並非絕對禁止位址轉換；但其核心設計是以充足位址及端對端連線為主要方向。

---

三、IPv4 位址配置缺乏階層性，造成路由表膨脹

IPv4 早期位址配置常以組織或網路需求分配，後來雖導入 CIDR（Classless Inter-Domain Routing）及路由彙總，仍可能因位址分配不連續、網路數量增加及多重連線需求，使網際網路核心路由器的路由表持續膨脹。

路由表過大會造成：

• 路由器記憶體需求增加。
• 路由查詢及更新負擔提高。
• 路由收斂速度受到影響。
• 網路管理與位址規劃較複雜。

IPv6 的改進

IPv6 的位址架構具有較強的階層性，通常依照全球路由前綴、機構、網路及介面識別資訊進行配置，便於進行路由彙總。

藉由較有規則的位址配置，可降低全球路由表項目數量，提升網路核心的可擴充性。

---

四、IPv4 標頭欄位較多，處理效率較低

IPv4 標頭包含標頭長度、識別碼、旗標、片段偏移量、檢查碼等欄位。路由器在傳送封包時，還需要重新計算標頭檢查碼；若封包需要分段，也會增加處理負擔。

IPv6 的改進

IPv6 基本標頭固定為 40 Bytes，並採用較簡化的欄位設計：

• 移除 IPv4 標頭檢查碼，降低每一跳重新計算的負擔。
• 移除標頭長度欄位，因為基本標頭長度固定。
• 將選項資訊移至 Extension Header，只有需要的設備才處理。
• 路由器通常不負責分段，分段由來源主機處理。
• 增加 Flow Label，便於識別同一資料流。

因此，IPv6 可降低中間路由器的處理複雜度，提高封包轉送效率。

---

五、IPv4 的廣播機制容易造成不必要的網路負擔

IPv4 使用 Broadcast 將封包送給同一網段的所有主機。當網路規模增大時，廣播封包會造成：

• 不相關主機也必須接收並檢查封包。
• 網路頻寬被無效流量占用。
• 廣播風暴可能影響整個網段。
• 網路管理與故障排除更加困難。

IPv6 的改進

IPv6 不使用傳統的 Broadcast，而是採用 Multicast 及 Neighbor Discovery 機制完成鄰居探索、路由器探索及位址解析等功能。

Multicast 只將封包傳送給特定群組成員，能減少不必要的主機處理及網路流量。

IPv6 也支援 Anycast，可將封包送至一組使用相同任播位址的主機中，距離來源最近或路由成本最低的主機，適合用於 DNS、內容傳遞及高可用性服務。

---

六、主機組態與位址管理較依賴人工設定

IPv4 主機通常需要透過人工設定或 DHCP 取得 IP 位址、子網路遮罩、預設閘道及 DNS 等資訊。大型網路中，人工管理容易產生設定錯誤，也增加網路維運成本。

IPv6 的改進

IPv6 提供 Stateless Address Autoconfiguration（SLAAC，無狀態位址自動組態）：

1. 主機透過 Neighbor Discovery 接收路由器公告。
2. 取得網路前綴。
3. 依介面識別資訊或隨機方式產生介面 ID。
4. 自動形成 IPv6 位址並進行重複位址偵測。

IPv6 也支援 DHCPv6，在需要集中管理、指定 DNS 或提供其他組態資訊時使用。

核心觀念

本題考查 TLS 的三項核心功能與其在網路協定堆疊中的位置：

1. 機密性（Confidentiality）：防止傳輸內容遭竊聽。
2. 完整性（Integrity）：防止資料在傳輸途中遭竄改。
3. 身分鑑別（Authentication）：通常由數位憑證驗證伺服器身分，避免連線遭冒充。

TLS 的基本設計是：先利用非對稱密碼學完成身分驗證與金鑰協商，再使用效率較高的對稱式加密保護後續資料。

---

解題方法

回答本題可依「建立安全連線」與「傳送應用資料」兩階段說明。

一、TLS Handshake：建立安全連線

1. ClientHello

用戶端向伺服器提出安全連線要求，包含：

• 支援的 TLS 版本
• 支援的密碼套件
• 隨機數（Random）
• 其他擴充資訊，例如伺服器名稱

2. ServerHello

伺服器選定：

• 使用的 TLS 版本
• 密碼套件
• 伺服器隨機數

伺服器並通常傳送其數位憑證。憑證由受信任的憑證機構（CA）簽發，包含伺服器公開金鑰及伺服器身分資訊。

3. 驗證伺服器身分

用戶端檢查伺服器憑證，例如：

• 憑證是否由信任的 CA 簽發
• 憑證是否過期
• 憑證中的網域名稱是否符合目前連線的伺服器
• 憑證是否被撤銷

如此可降低中間人攻擊（Man-in-the-Middle Attack）的風險。

4. 金鑰交換

雙方透過 Diffie–Hellman、ECDHE 或其他金鑰交換機制，建立共同的秘密值。此共同秘密值不必直接在網路上傳送。

接著，雙方依據：

• 用戶端隨機數
• 伺服器隨機數
• 金鑰交換所得的共同秘密值

推導出工作階段所使用的對稱式金鑰，例如加密金鑰與驗證金鑰。

以概念表示如下：

$$\text{Session Key} = \operatorname{KDF} (\text{Pre-Master Secret},\text{Client Random},\text{Server Random})$$

其中 KDF（Key Derivation Function）是金鑰衍生函數。

5. 握手驗證

雙方交換 Finished 訊息，確認先前的握手內容未遭竄改，且雙方確實擁有相同的工作階段金鑰。

握手成功後，便建立安全的 TLS 連線。

---

二、TLS Record Protocol：保護應用資料

握手完成後，應用程式的資料會交由 TLS Record Protocol 處理，主要步驟如下：

1. 將應用資料切割成適當大小的區塊。
2. 視協定版本與密碼套件進行壓縮或格式處理。
3. 使用工作階段金鑰進行加密。
4. 加入完整性驗證資訊。

在較早的 TLS 1.2 密碼套件中，常見作法是使用 MAC 或 HMAC 驗證完整性，再配合 AES 等對稱式加密演算法。

現代 TLS 則常使用 AEAD（Authenticated Encryption with Associated Data）演算法，例如 AES-GCM 或 ChaCha