OGEA-103 是 The Open Group 的 TOGAF Enterprise Architecture Combined Part 1 and Part 2 Exam，通過後可取得 TOGAF Enterprise Architecture Practitioner 資格。本文整理 OGEA-103 考試資訊、題型、核心考點、備考方向、常見易混淆內容與原創練習題。
建議關鍵詞： OGEA-103 認證考試、TOGAF Enterprise Architecture Practitioner、TOGAF Enterprise Architecture Combined Part 1 and Part 2、TOGAF Standard 10th Edition、企業架構認證、ADM、Architecture Governance、Architecture Vision、Migration Planning

OGEA-103 是什麼考試？

OGEA-103 是 The Open Group 針對 TOGAF Standard, 10th Edition 推出的 TOGAF® Enterprise Architecture Combined Part 1 and Part 2 Exam。這是一門合併考試，適合希望一次完成 Part 1 與 Part 2，直接取得 TOGAF Enterprise Architecture Practitioner 資格的考生。官方文件說明，OGEA-103 以 TOGAF Standard, 10th Edition 作為 Body of Knowledge，通過後授予 TOGAF Enterprise Architecture Practitioner 資格。

與單獨參加 OGEA-101 Part 1 和 OGEA-102 Part 2 不同，OGEA-103 將 Foundation 與 Practitioner 兩個層級放在同一次考試中完成。因此，考生不只要理解 TOGAF 基礎概念，也要能在情境題中應用 ADM、架構治理、利害關係人管理、需求管理、差距分析與遷移規劃等方法。

OGEA-103 考試基本資訊

OGEA-103 的英文考試名稱為 TOGAF® Enterprise Architecture Combined Part 1 and Part 2，考試代碼為 OGEA-103；簡體中文版本代碼為 OGEA-C103。官方考試文件列出此考試共有 48 題，總時間為 2 小時 30 分鐘。

OGEA-103 分為兩個部分：Part 1 包含 40 題 Simple Multiple Choice questions；Part 2 包含 8 題 Scenario Based, Complex Multiple Choice。Part 1 的通過標準為 60%，也就是 40 分中至少取得 24 分；Part 2 的通過標準同樣為 60%，也就是 40 分中至少取得 24 分。考生必須兩個部分都通過，才算整體通過 OGEA-103。

Part 1 是閉卷考試，Part 2 是開卷考試，但開卷資料不是自帶紙本書，而是在 Part 2 中透過考試系統提供 TOGAF Enterprise Architecture Body of Knowledge 的電子參考資料。官方也說明，完成 Part 1 後不能回到 Part 1，且兩個部分之間沒有休息時間，Part 2 會直接接續 Part 1。

根據 The Open Group 2026 年 2 月 1 日起適用的考試費用表，OGEA-103 / C103 的 Exam Booking Fee 為 USD 610，Retail Voucher Fee 為 USD 640；官方同時提醒，不同國家或地區可能有稅費、匯率與價格調整。

OGEA-103 適合哪些考生？

OGEA-103 適合希望一次完成 TOGAF Enterprise Architecture Foundation 與 Practitioner 要求的考生。對企業架構師、解決方案架構師、業務架構師、技術架構師、IT 經理、轉型負責人、顧問與專案／計畫管理相關角色來說，這門考試可以用來驗證對 TOGAF 方法與企業架構實務應用的理解。

The Open Group 對 TOGAF Enterprise Architecture Practitioner 能力的角色映射中，提到相關能力包括使用 TOGAF Standard 指導轉型與管理變更、執行 ADM、利害關係人管理、差距分析、遷移規劃、需求管理、Architecture Vision、Architecture Content Framework，以及架構分層與架構景觀管理。

因此，OGEA-103 不太適合完全沒有企業架構概念的入門考生。它更適合已經接觸過 IT 架構、業務流程、數位轉型、解決方案設計、架構治理或企業級技術規劃的人員。

為什麼 OGEA-103 值得關注？

企業架構的價值不只是畫架構圖，而是協助企業在業務目標、技術能力、組織治理與轉型路線之間建立一致性。TOGAF 作為企業架構方法論，核心價值在於提供一套可重複使用的架構開發方法、治理框架與交付內容結構。

OGEA-103 的特點在於一次覆蓋 Part 1 與 Part 2。Part 1 更偏向基礎知識與術語理解，Part 2 則更偏向場景應用與分析能力。The Open Group 的 Part 2 考試說明也指出，Part 2 建立在 Part 1 基礎上，並評估更高層次的應用與分析能力。

對於希望快速取得 TOGAF Enterprise Architecture Practitioner 認證的考生來說，OGEA-103 是一條集中式路徑。但也正因為它把兩個部分合在一起，考生需要同時準備記憶型內容與情境型判斷。

OGEA-103 核心考點一：TOGAF 基礎概念與標準結構

Part 1 的重點是 TOGAF 基礎概念，包括企業架構的目的、TOGAF Standard 的組成、Architecture Development Method、架構內容、架構治理、Architecture Repository、Building Blocks、Deliverables、Artifacts，以及 TOGAF 中常見術語。

這部分的難點不是技術深度，而是名詞多、定義細、容易混淆。考生需要清楚區分 Deliverable、Artifact、Building Block，也要理解 Architecture Repository、Architecture Landscape、Standards Information Base、Reference Library 等概念各自的作用。

準備 Part 1 時，建議以官方 syllabus 對應的學習成果為主。The Open Group 說明，TOGAF Standard, 10th Edition 相關認證的 syllabus 發布於 Document X2202，涵蓋 TOGAF Enterprise Architecture Foundation、Practitioner、Practitioner Bridge 與 Business Architecture Foundation 的學習成果。

OGEA-103 核心考點二：ADM 與架構開發流程

ADM，也就是 Architecture Development Method，是 OGEA-103 的核心考點。考生需要理解 Preliminary Phase、Phase A 到 Phase H，以及 Requirements Management 如何貫穿整個 ADM 週期。

Part 1 可能會直接考查每個階段的目的、輸入、輸出與主要活動；Part 2 則更常透過企業轉型場景，要求考生判斷應該使用哪個 ADM 階段、應該產出什麼交付物，或應該如何調整架構方法。

例如，Preliminary Phase 偏向建立架構能力與治理框架；Phase A 著重 Architecture Vision；Phase B、C、D 分別處理 Business、Information Systems 與 Technology Architecture；Phase E、F 關注 Opportunities and Solutions 與 Migration Planning；Phase G 著重 Implementation Governance；Phase H 則關注 Architecture Change Management。

OGEA-103 核心考點三：架構治理與利害關係人管理

企業架構不是單純的技術設計文件，而是需要被治理、溝通與落地的管理機制。OGEA-103 對 Architecture Governance、Architecture Board、Compliance Assessment、Architecture Contract、利害關係人管理與溝通計畫都有一定要求。

Part 2 情境題常見的切入點是：企業有多個業務單位、轉型目標不一致、技術標準缺乏治理、專案偏離目標架構，或不同利害關係人對架構價值存在衝突。這類題目通常不會只問定義，而是測試考生是否能按照 TOGAF 方法選出最合適的治理與溝通方式。

The Open Group 的能力映射中，也將 stakeholder management、requirements management、gap analysis、migration planning 等列為 TOGAF Practitioner 相關能力。

OGEA-103 核心考點四：Architecture Vision、需求管理與業務對齊

Architecture Vision 是 TOGAF 中非常重要的內容。它不是單純的願景描述，而是用來建立業務目標、架構範圍、限制條件、價值主張與利害關係人期望之間的初步一致性。

OGEA-103 考題可能會描述一家公司準備啟動數位轉型，但業務部門、IT 部門與管理層對目標認知不同。此時考生需要判斷是否應該先釐清架構願景、定義範圍、識別利害關係人、建立業務情境，或進一步形成 Statement of Architecture Work。

需求管理也是高頻概念。TOGAF 的 Requirements Management 不只發生在某一個階段，而是持續貫穿 ADM。考生需要理解需求會如何被識別、記錄、管理、追蹤與變更，並且如何影響不同架構階段。

OGEA-103 核心考點五：差距分析、遷移規劃與架構路線圖

Part 2 的場景題通常會考查考生是否能把架構從「目標狀態」轉換為「可執行的轉型計畫」。因此，Gap Analysis、Work Packages、Transition Architectures、Architecture Roadmap、Implementation and Migration Plan 都是需要重點理解的內容。

企業架構不是只定義未來目標，而是要說明如何從 Baseline Architecture 過渡到 Target Architecture。這中間需要識別差距、評估依賴關係、安排優先順序、規劃遷移階段，並透過治理機制確保實施過程符合架構方向。

準備這部分時，考生應避免只背名詞，而要理解這些內容如何串成一條完整路徑：Baseline、Target、Gap、Roadmap、Work Package、Transition Architecture、Implementation Governance、Change Management。

OGEA-103 常見易混淆考點

第一組容易混淆的是 Foundation 與 Practitioner。Foundation 更重視術語、概念與基本理解；Practitioner 更重視應用、分析與情境判斷。

第二組是 OGEA-101、OGEA-102 與 OGEA-103。OGEA-101 是 Part 1，OGEA-102 是 Part 2，OGEA-103 是 Part 1 與 Part 2 的 Combined Exam。官方說明，OGEA-103 是讓考生在一次考試中直接取得 Level 2 Practitioner 資格的合併考試。

第三組是 Deliverable、Artifact 與 Building Block。Deliverable 是正式交付成果，Artifact 是架構描述中的具體內容形式，Building Block 則是可重用或可組合的能力單元。

第四組是 Architecture Vision 與 Target Architecture。Architecture Vision 是早期高層次方向與價值定位，Target Architecture 則是在後續階段中更完整展開的目標架構。

第五組是 Architecture Roadmap 與 Implementation and Migration Plan。前者更偏向高層次轉型路線與工作包安排，後者更偏向具體實施與遷移計畫。

OGEA-103 備考建議

準備 OGEA-103 時，建議分成兩條線進行。

第一條線是 Part 1 的基礎知識線。考生需要熟悉 TOGAF Standard, 10th Edition 的核心術語、ADM 階段、架構內容、治理概念與常見交付物。這部分適合透過反覆閱讀、整理筆記和關鍵詞對照來準備。

第二條線是 Part 2 的情境應用線。考生需要練習如何在具體企業場景中選擇最符合 TOGAF 方法的做法。Part 2 是 Scenario Based, Complex Multiple Choice，並採用梯度計分方式：最佳答案 5 分，次佳答案 3 分，第三佳答案 1 分，干擾項 0 分。

The Open Group 也提供 TOGAF Standard, 10th Edition 相關官方學習材料，包括 PDF study guides、online self-study materials、practice tests 和 hard-copy publications。官方說明，Study Guides 適合考試準備或一般參考，Practice Tests 可幫助考生熟悉題型並評估準備狀況。

OGEA-103 原創練習題示例

問題 1：
一家公司準備建立企業架構能力，並需要先定義架構原則、治理結構與方法裁剪方式。這最符合 TOGAF ADM 的哪個階段？

A. Phase A
B. Preliminary Phase
C. Phase E
D. Phase G

問題 2：
在 TOGAF 中，哪一項最能描述 Requirements Management 的角色？

A. 只在 Phase A 使用一次
B. 貫穿 ADM 週期，持續管理架構需求與變更
C. 只用於技術架構設計
D. 只負責制定專案預算

問題 3：
一個企業已完成 Baseline Architecture 與 Target Architecture，下一步需要識別差距並規劃轉型工作包。哪一組概念最相關？

A. Gap Analysis、Work Packages、Architecture Roadmap
B. Password Policy、DNS Cache、Firewall Rule
C. Source Code Review、Unit Test、Build Artifact
D. Incident Queue、SLA Report、Backup Window

問題 4：
OGEA-103 的 Part 2 題型主要考查什麼能力？

A. 單純記憶 TOGAF 術語
B. 在企業架構場景中應用和分析 TOGAF 方法
C. 撰寫程式碼
D. 配置網路交換器

問題 5：
如果考生通過 OGEA-103 的 Part 1，但未通過 Part 2，官方規則下應如何完成認證？

A. 必須重新參加整個 OGEA-103
B. 只需要補考未通過的 Part 2
C. 直接取得 Practitioner 資格
D. 必須改考 TOGAF 9

答案：

1. B
2. B
3. A
4. B
5. B

FAQ：OGEA-103 認證考試常見問題

OGEA-103 通過後取得什麼資格？

通過 OGEA-103 後，可取得 TOGAF Enterprise Architecture Practitioner 資格。官方考試文件明確列出 OGEA-103 的 qualification upon passing 為 TOGAF Enterprise Architecture Practitioner。

OGEA-103 是閉卷還是開卷？

OGEA-103 的 Part 1 是閉卷，Part 2 是開卷。Part 2 的開卷資料由考試系統內建電子版 Body of Knowledge 提供，且只在 Part 2 可用。

OGEA-103 一共有多少題？

OGEA-103 總共 48 題，其中 Part 1 有 40 題 Simple Multiple Choice，Part 2 有 8 題 Scenario Based, Complex Multiple Choice。

OGEA-103 需要前置資格嗎？

OGEA-103 官方列出的 prerequisites 為 None。它是為希望直接取得 TOGAF Enterprise Architecture Practitioner 資格的考生設計的 Combined Exam。

如果 OGEA-103 其中一部分沒通過，需要重考全部嗎？

不需要。The Open Group Help Center 說明，Combined exams 如果通過其中一部分但未通過另一部分，只需要重考未通過的單一部分；通過後，The Open Group 會將結果合併並授予相應資格。

結語

OGEA-103 是一門覆蓋 TOGAF Enterprise Architecture Foundation 與 Practitioner 的合併型認證考試。它的難點不只在於內容範圍廣，更在於考生需要同時具備基礎概念記憶能力與場景應用判斷能力。

準備 OGEA-103 時，建議先掌握 TOGAF Standard, 10th Edition 的核心結構，再深入理解 ADM、Architecture Governance、Architecture Vision、Requirements Management、Gap Analysis、Migration Planning、Architecture Roadmap 與 Implementation Governance。

如果能把 TOGAF 從「術語清單」轉化為「企業轉型方法」，OGEA-103 的學習方向就會清楚很多。對希望往 Enterprise Architect、Solution Architect、Business Architect、Transformation Leader 或 Architecture Consultant 方向發展的人來說，這門考試具有明確的專業定位與實務價值。

CKAD（Certified Kubernetes Application Developer） 是由 Cloud Native Computing Foundation（CNCF）與 Linux Foundation 聯合推出的 Kubernetes 專業認證，主要面向負責設計、建立、部署以及維護 Kubernetes 應用程式的開發者。

與偏向 Kubernetes 叢集管理的 CKA（Certified Kubernetes Administrator） 不同，CKAD 更關注「如何在 Kubernetes 平台上運行雲原生應用」，包括 Pod 設計、Deployment 管理、服務暴露、配置管理、應用監控以及故障排查等能力。

---

一、CKAD 考試基本資訊

項目	詳細資訊
考試名稱	Certified Kubernetes Application Developer
考試代碼	CKAD
認證組織	CNCF / Linux Foundation
考試形式	線上監考、實作操作考試
考試時間	120 分鐘
題型	Performance-Based Tasks（實務操作題）
操作方式	使用 Kubernetes CLI（kubectl）完成任務
考試語言	English
考試環境	Kubernetes Cluster Terminal
建議背景	Docker、Container、Kubernetes 基礎知識

CKAD 不是傳統選擇題考試，而是要求考生直接在 Kubernetes 環境中完成操作任務，例如建立資源、修改 YAML、排查錯誤等。

---

二、CKAD 認證定位

Kubernetes 認證路徑：

KCNA
  ↓
CKAD ─── 應用開發方向
  ↓
CKA ─── 叢集管理方向
  ↓
CKS ─── 安全方向

CKAD 主要適合：

✅ Kubernetes Application Developer
✅ DevOps Engineer
✅ Cloud Native Developer
✅ Backend Developer
✅ Platform Engineer
✅ SRE 工程師

如果工作內容涉及：

• 微服務部署
• Container 化應用
• CI/CD
• Kubernetes 平台開發

CKAD 具有較高參考價值。

---

三、CKAD 考試五大領域解析

CKAD 目前主要包含五個考試領域：

領域	比例
Application Environment, Configuration and Security	約25%
Application Design and Build	約20%
Application Deployment	約20%
Services and Networking	約20%
Application Observability and Maintenance	約15%

---

1. Application Design and Build（20%）

這部分考察如何建立 Kubernetes 應用。

主要內容：

Container Image

需要理解：

• Docker Image
• Container Registry
• Image Tag
• Image Pull Policy

例如：

image: nginx:latest

需要知道：

• Image 從哪裡取得
• 如何控制版本
• 如何更新 Image

---

Pod 設計

核心概念：

• Pod
• Multi-container Pod
• Sidecar Pattern
• Init Container

例如：

應用容器：

Application Container
        +
Logging Sidecar

這類設計是 Kubernetes 常見模式。

---

Jobs 與 CronJobs

需要掌握：

Job

適合：

• 一次性任務
• Batch Processing

CronJob

適合：

• 定時任務
• 排程執行

例如：

每天凌晨執行資料備份。

---

2. Application Deployment（20%）

這是 CKAD 非常重要的部分。

主要包括：

Deployment

需要熟悉：

• ReplicaSet
• Rolling Update
• Rollback
• Scaling

常見操作：

kubectl create deployment

---

Deployment Strategy

包括：

Rolling Update

逐步替換舊版本：

Version A
   ↓
Version A+B
   ↓
Version B

---

Canary Deployment

部分流量測試新版本。

例如：

95% 使用舊版本

5% 使用新版本

---

Helm

需要了解：

• Helm Chart
• Values
• Release

CKAD 不要求深入開發 Helm Chart，但需要理解如何使用 Helm 部署應用。

---

3. Application Environment, Configuration and Security（25%）

這是 CKAD 權重最高部分。

---

ConfigMap

用於保存非敏感配置：

例如：

database_url=mysql

---

Secret

用於保存敏感資訊：

例如：

• Password
• Token
• API Key

---

Security Context

需要理解：

• User ID
• Group ID
• Container Permission

---

Resource Management

包括：

Resource Request

最低需要資源：

resources:
 requests:
   cpu: 500m

---

Resource Limit

最大限制：

limits:
 cpu: 1

---

RBAC

需要掌握：

• ServiceAccount
• Role
• RoleBinding

例如：

限制某個應用只能讀取指定 Namespace。

---

4. Services and Networking（20%）

主要考察 Kubernetes 網路通信。

---

Service

需要理解：

ClusterIP

內部通信：

Pod → Service → Pod

---

NodePort

外部訪問：

Client
 ↓
NodePort
 ↓
Service
 ↓
Pod

---

LoadBalancer

雲環境常用：

• AWS
• Azure
• Google Cloud

---

Ingress

重要考點：

• HTTP Routing
• Host Rules
• Path Rules

例如：

example.com/api
        ↓
API Service

---

NetworkPolicy

控制：

• Pod Ingress
• Pod Egress

例如：

只允許：

Frontend Pod

訪問

Backend Pod

---

5. Application Observability and Maintenance（15%）

主要考察應用監控與故障排查。

---

Probe

非常重要：

Liveness Probe

判斷：

容器是否正常運行。

---

Readiness Probe

判斷：

是否可以接收流量。

---

Startup Probe

用於：

啟動時間較長的應用。

---

Debug 技巧

常用命令：

查看 Pod：

kubectl get pods

查看詳細資訊：

kubectl describe pod

查看 Log：

kubectl logs

進入 Container：

kubectl exec -it

---

四、CKAD 考試難點分析

1. 最大挑戰是時間

CKAD 是實作考試，不是背誦考試。

需要：

• 快速寫 YAML
• 熟悉 kubectl
• 快速定位問題

---

2. YAML 熟練度非常重要

很多失分原因：

• indentation 錯誤
• apiVersion 錯誤
• field 名稱錯誤

建議：

多練習：

kubectl create --dry-run=client -o yaml

快速生成模板。

---

3. 排錯能力比理論重要

例如：

Pod 無法啟動：

不要只看 YAML。

需要檢查：

1. Image 是否存在
2. Secret 是否正確
3. Volume 是否掛載
4. Probe 是否失敗

---

五、CKAD 與 CKA 差異

項目	CKAD	CKA
方向	應用開發	叢集管理
面向	Developer	Administrator
重點	Application	Infrastructure
YAML	高	中
kubectl	高	高
Cluster Setup	少	多
Network	Application Network	Cluster Network

---

六、CKAD 備考建議

第一階段：Kubernetes 基礎

掌握：

• Pod
• Deployment
• Service
• Namespace

---

第二階段：大量練習 YAML

練習：

• Pod YAML
• Deployment YAML
• Service YAML
• ConfigMap
• Secret

---

第三階段：熟悉 kubectl

常用：

kubectl get

kubectl describe

kubectl apply

kubectl delete

kubectl logs

kubectl exec

---

第四階段：模擬實戰環境

建議：

• Minikube
• Kind
• Kubernetes Playground

反覆練習：

• 建立應用
• 修改配置
• 排查問題

---

七、CKAD 職涯價值分析

隨著企業大量採用：

• Kubernetes
• Microservices
• Cloud Native
• DevOps

CKAD 能證明考生具備：

✅ Kubernetes 應用部署能力
✅ Container 技術能力
✅ 雲原生開發能力
✅ DevOps 工作流程理解

對希望進入：

• 雲端工程
• DevOps
• AI 平台工程
• Kubernetes 平台開發

方向的人員具有較高價值。

---

總結

CKAD（Certified Kubernetes Application Developer）是一張偏向「實戰操作」的 Kubernetes 開發者認證。

考試核心不是記憶 Kubernetes 概念，而是要求考生能夠：

• 建立 Kubernetes 應用
• 管理 Deployment
• 配置 Service
• 處理安全設定
• 監控與排查應用問題

對已經具備 Linux、Docker、Cloud 或 DevOps 基礎的人員來說，CKAD 是進入雲原生技術領域的重要認證之一。

本文系統化梳理網路通訊中MTU、MSS核心概念、換算公式、Ping測試原理、隧道封裝適配問題及故障排查思路，是解決Giants、網路分片、VPN卡頓、網頁存取異常等問題的核心基礎。
一、MTU（最大傳輸單元）MTU 全稱 Maximum Transmission Unit指資料鏈結層單次能夠傳輸的完整最大資料包總大小，包含所有協定頭部及資料內容，為鏈結層的傳輸上限。
預設標準值：乙太網路（Ethernet）預設 MTU = 1500 位元組，為區域網路、公網常規鏈路標準值。
結構說明：整個連結幀最大承載1500字節，包含IP頭部、傳輸層頭部、業務數據，是完整資料包的總尺寸上限。
二、MSS（最大分段大小）MSS 全名為 Maximum Segment Size，是 TCP 協定的專屬參數
指TCP封包中真正的業務資料最大大小，不含 IP 頭部、TCP 頭部，且僅承載使用者業務資料。

1. 核心換算公式常規網路場景下，IP頭部、TCP頭部預設基礎長度均為20位元組，固定公式如下：
MSS = MTU – IP頭部(20) – TCP頭部(20) = MTU – 402. 
預設標準值基於乙太網路預設MTU 1500計算：1500 – 40 = 1460 字节
結構說明：1500位元組總MTU中，固定預留20位元組IP頭部+20位元組TCP頭部，剩餘1460位元組純資料區域即為MSS最大值，僅承載用戶業務資料。
三、Ping測試MTU原理（1472位元組的由來）Ping 工具基於 ICMP 協議實現，並非TCP協議，因此計算規則與MSS不同，是日常快速檢測鏈路MTU上限的常用手段。
1. 資料包組成ICMP資料(1472位元組) + ICMP頭部(8位元組) + IP頭部(20位元組) = 1500位元組（標準MTU上限）
2. 標準測試指令及參數意義
ping -f -l 1472 
目標位址•-l 1472：
指定資料大小為基礎1472：指定資料名稱為單位的Fragment（禁止分片），核心作用：若資料包大小超過連結MTU上限，直接丟棄資料包、測試失敗，不會自動分片傳輸，精準偵測連結最大承載能力此指令的核心用途：驗證目前連結是否支援標準1500位元組的MTU傳輸。

四、MTU變小的核心原因（隧道場景）很多人誤以為MTU變小是連結品質變差，實際上與連結頻寬、穩定性無關，僅由隧道封裝協定導致。
VPN、GRE、IPSec 等隧道技術會在原始資料包外層額外新增一層協定頭部，整體資料包體積變大。
而連結物理MTU上限（1500）固定不變，封裝頭部佔用了部分空間，導致能承載的原始業務資料空間被壓縮，即有效MTU變小，這也是隧道網路最容易出現分片、丟包的核心原因。
不同隧道協定的封裝頭部佔用位元組不同，是實戰調參的核心依據，常見隧道頭部開銷標準：
•GRE隧道：基礎頭部佔用 24 字節
•IPSec隧道（ESP）：常規封裝佔用 50~60 字節
•VPN接合隧道：多層丟裝頭套MTU + 真實位元組數值做三段精化

實戰舉例：
案例1：
公網無隧道場景（正常、無分片）普通公網/區域網，無任何隧道封裝：TCP業務資料1460 + TCP頭20 + IP頭20 = 1500位元組（剛好塞滿MTU）此時封包大小等於連結最大承載值，無需分片、不會丟包，傳輸完全正常，這也是一般上網、手機流量存取網路穩定的原因。
案例2：接入GRE隧道（不調MSS，必丟包/必分片）GRE隧道會在外層額外封裝24位元組GRE頭部，物理鏈路MTU依然固定1500不變。
沿用預設TCP 1460資料發包，總包大小計算：1460(資料)+20(TCP)+20(IP)+24(GRE隧道頭) = 1524位元組1524 > 1500，超出連結MTU上限！
此時設備只能執行IP分片，將一個完整大包拆成多個小包傳輸；而現代防火牆、VPN設備、運營商骨幹網，預設開啟分片報文攔截策略（防攻擊），直接丟棄分片資料包。
最終現象：微信發文字（小包）正常，開啟網頁、傳文件（大包）打不開/卡頓超時，是最典型的隧道MTU適配故障。
案例3：IPSec加密隧道IPSec ESP加密隧道封裝開銷更大，常規佔用50~60位元組頭部。
同樣預設1460 TCP資料發包，總包可達 1550+ 字節，超限更嚴重，分片、丟包、TCP重傳機率大幅提升，VPN辦公系統、內網業務存取異常高發。
案例4：微調MSS解決問題針對GRE隧道場景，全域下調TCP MSS至1360：1360(資料)+20(TCP)+20(IP)+24(GRE) = 1424位元組1424 < 1500，完全在MTU承載範圍內！無需分片、不會被防火牆攔截，從源頭徹底解決隧道大包丟包、網頁打不開、業務卡頓、TCP反覆重傳的問題。
此時裝置只能對超大資料包進行強制分片分割傳輸。
而大部分防火牆、VPN設備預設開啟分片偵測、防碎片攻擊策略，會直接丟棄分片封包，最後引發大封包傳輸失敗、小封包正常的詭異網路故障。
資料包結構：新增隧道頭部 + 原始完整資料包（原頭+原資料）五、手動調整MSS的必要性網路隧道封裝後，有效MTU降低，預設1460位元組的TCP資料段會超出連結承載上限，導致資料包必須分片、甚至直接丟包，引發各類網路異常。
1. 精準MSS計算公式（隧道通用萬能公式）物理出口MTU預設1500場景下，隧道環境調參唯一標準公式：
最優MSS = 1500 – 隧道外層頭部開銷 – 40（TCP+IP基礎頭部固定開銷）
原理：預留所有頭部開銷，讓杜包後的最終包完備全包尺寸，≤10005 2. 各隧道對應標準MSS精準參數（實戰直接套用）•純GRE隧道（頭部24位元組）
計算：1500-24-40 = 1436
標準配置：ip tcp adjust-mss 1436•IPSec ESP加密隧道（常規60位元組最大開銷）
計算：1500-60-40 = 1400
標準配置：ip tcp adjust-mss 1400•GRE+IPSec雙層封裝（高開銷80~100位元組）
計算：1500-100-40 = 1360
標準配置：ip tcp adjust-mss 13603. 為什麼網路上大多用 1360？1360 不是所有場景的精準最適值，而是全場景通用保守安全值。
無論單層隧道、雙層疊加隧道，設定1360皆可相容，不會超限丟包，適合不確定隧道封裝格式、懶人一鍵適配場景。

4. 核心設定指令// 精準場景按需配置
ip tcp adjust-mss 1436    // 純GRE
ip tcp adjust-mss 1400    // 單層IPSec
ip tcp adjust-mss 1360    // 雙層疊加/通用保守值
5. 作用原理主動告知客戶端，當前網路存在隧道封裝開銷，限制TCP單段最大資料尺寸，從源頭杜絕大包機超限，避免攔截設備IP分片、防火牆分頁封包表ip tcp adjust-mss 13602. 
作用原理主動告知客戶端，目前網路環境不支援超大TCP資料段，限制TCP單段資料最大大小，從來源避免資料包分片、丟包、TCP重傳，適配隧道封裝後的網路環境，解決VPN、專線隧道異常問題。
六、MTU/MSS異常典型故障現像
出現以下網路問題，優先檢查MTU、MSS適配問題：
•網頁打不開、網頁載入不全，但微信、QQ等即時通訊正常（小資料包正常，大封包傳輸異常）
•網頁連線卡頓、業務存取不穩定
•網路頻繁出現記憶資料含數、資料包丟七TCP純業務資料大小（不含任何頭部）
3. 常規固定換算：MSS = MTU – 404. VPN/隧道本質：給予原始資料包外層多套一層協定殼，擠佔傳輸空間，降低有效MTU

基本資訊

• 考試代碼：303-300
• 證照名稱：LPIC-3 Security
• 發證機構：Linux Professional Institute
• 等級：LPIC-3（Linux 專家級）
• 考試時間：90 分鐘
• 題型：選擇題 + 填空題
• 題數：約 60 題
• 前置條件：需具備 LPIC-2（建議或必要）

---

考試核心內容（重點領域）

LPIC-3 Security 的重點不是「基礎 Linux」，而是企業級資安架構與防護。

1️⃣ Cryptography（密碼學）

重點：

• X.509 憑證
• PKI 架構
• OpenSSL 操作
• 金鑰管理
• TLS/SSL 基礎與實務

常考方向：
如何建立 CA、簽發憑證、驗證鏈

---

2️⃣ Access Control（存取控制）

重點：

• DAC / MAC / RBAC
• SELinux 基本與策略
• AppArmor
• Linux permissions 深層機制

常考方向：
如何限制服務權限、強化系統安全模型

---

3️⃣ Application Security（應用程式安全）

重點：

• SSH hardening
• Web server security（Apache/Nginx）
• 容器與應用隔離
• sudo 與權限設計

---

4️⃣ Operations Security（營運安全）

重點：

• logging / auditing（auditd）
• system hardening
• patch management
• backup security

---

5️⃣ Network Security（網路安全）

重點：

• iptables / nftables
• VPN（IPSec / OpenVPN）
• firewall design
• secure network services

---

6️⃣ Threats & Vulnerability（威脅與弱點）

重點：

• 漏洞掃描工具
• 入侵偵測 IDS/IPS
• log 分析
• attack surface reduction

---

考試難度分析

✔ 難度：⭐⭐⭐⭐☆（偏高）
✔ 特點：

• 不只是 Linux 指令
• 更偏「企業資安架構設計」
• 題目常是情境題（scenario-based）
• 需要理解系統如何整體防護

---

適合考的人

非常適合以下人群：

Linux / IT 工程師

• 已有 LPIC-2 / RHCSA / 同等能力

資安工程師

• 想走 Linux Security / SOC / Blue Team

雲端 / DevOps

• 想補「系統安全能力」

想升級到架構級能力的人

• 從「會操作 Linux」→「會設計安全系統」

---

建議學習路線

如果你要準備 303-300：

Step 1：Linux 基礎要很熟

• permission / systemd / networking

Step 2：補安全核心

• SELinux / AppArmor
• firewall (nftables)

Step 3：加強密碼學

• OpenSSL
• PKI / certificate chain

Step 4：做實驗

• 搭 CA
• 建 VPN
• 做 firewall policy

---

考試定位（很重要）

LPIC-3 Security =
Linux + Enterprise Security + System Design

不是：

• 單純指令記憶
• 也不是初級 Linux 考試

而是：

「你能不能設計一個安全 Linux 生產環境」

LPIC-3 303-300 Security（版本 3.0）完整考試大綱 + 權重

權重說明：
數字越高＝題目越多、考試占比越重

• 5 = 高權重（核心必考）
• 4 = 次核心
• 3 = 中等
• 2 = 基礎理解

---

Topic 331：Cryptography（密碼學）

331.1 X.509 Certificates & PKI（權重：5 ⭐⭐⭐⭐⭐）

核心內容：

• X.509 憑證結構
• 公鑰基礎設施（PKI）
• CA（Certificate Authority）架構
• OpenSSL 操作
• TLS/SSL 信任鏈

必考能力：

• 建立 Root CA / Intermediate CA
• 簽發與撤銷證書
• 驗證 certificate chain

---

Topic 332：Host Security（主機安全）

332.1 Host Hardening（權重：5 ）

核心內容：

• BIOS / GRUB 安全
• systemd service hardening
• SELinux / AppArmor 基礎概念
• SSH CA 與憑證登入
• USBGuard 裝置控制
• kernel security（ASLR / DEP）
• chroot sandbox

重點技能：

• systemd 限制服務權限（capabilities / syscalls）
• SSH certificate-based authentication
• 系統最小權限化（least privilege）

---

332.2 Host Intrusion Detection（權重：5 ）

核心內容：

• auditd Linux 審計系統
• AIDE 檔案完整性檢查
• rootkit detection（chkrootkit / rkhunter）
• malware scanning（Linux Malware Detect）
• RPM / DPKG integrity check

必考能力：

• 建立 audit rule
• 分析 log（ausearch / aureport）
• 設計 host IDS 架構

---

332.3 Resource Control（權重：3 ）

核心內容：

• ulimit 限制資源
• cgroups（CPU / memory / IO）
• systemd slices / scopes
• process resource isolation

重點：

• 限制 service CPU / memory 使用
• cgroup v1 vs v2 基本概念

---

Topic 333：Access Control（存取控制）

333.1 DAC（Discretionary Access Control）（權重：3 ）

核心內容：

• Linux permissions（rwx / owner / group / others）
• SUID / SGID / sticky bit
• ACL（getfacl / setfacl）
• extended attributes（xattr）

必考：

• ACL 權限設計
• SUID/SGID 安全風險

---

333.2 MAC（Mandatory Access Control）（權重：5 ）

核心內容：

• SELinux（重點中的重點）
• type enforcement
• RBAC model
• AppArmor / Smack（概念）

必考能力：

• SELinux mode（enforcing/permissive）
• context 管理（chcon / restorecon）
• policy troubleshooting

---

Topic 334：Network Security（網路安全）

334.1 Network Hardening（權重：4 ）

核心內容：

• Wireshark / tcpdump 分析封包
• wireless security
• rogue DHCP / router attack
• FreeRADIUS
• network traffic inspection

必考：

• 封包分析與 filter
• 無線網路攻擊識別

---

334.2 Network Intrusion Detection（權重：4 ）

核心內容：

• IDS / IPS 系統
• network monitoring tools
• traffic anomaly detection
• log correlation

重點：

• Snort / Suricata（概念級）
• network behavior analysis

---

334.4 VPN（權重：4 ）

核心內容：

• OpenVPN
• IPsec / strongSwan
• WireGuard
• IKEv2
• site-to-site vs remote access VPN

必考能力：

• VPN 架構設計
• WireGuard config
• IPsec negotiation 基本概念

---

Topic 335：Threats & Vulnerability（威脅與弱點）

335.1 Security Threats（權重：2 ）

核心內容：

• malware（trojan / virus / rootkit）
• DoS / DDoS
• phishing / social engineering
• injection attacks（SQL/XSS/CSRF）
• privilege escalation

特點：
幾乎是「概念題」，不深挖配置

---

335.2 Penetration Testing（權重：3 ）

核心內容：

• ethical hacking 流程
• pentest phases（recon → exploit → maintain）
• nmap 使用（掃描 / OS detection / NSE）
• Metasploit 架構
• Kali Linux 工具概念

必考：

• nmap scan type（SYN / TCP / version scan）
• penetration testing 流程順序

---

全考試權重總覽（重點地圖）

類別	權重	重要性
Cryptography	5	⭐⭐⭐⭐⭐
Host Hardening	5	⭐⭐⭐⭐⭐
Host IDS	5	⭐⭐⭐⭐⭐
MAC / SELinux	5	⭐⭐⭐⭐⭐
Network Security	4	⭐⭐⭐⭐
VPN	4	⭐⭐⭐⭐
Resource Control	3	⭐⭐⭐
DAC / ACL	3	⭐⭐⭐
Pentest	3	⭐⭐⭐
Threat Concepts	2	⭐⭐

---

考試結構重點結論（非常重要）

LPIC-3 303-300 的本質：

「Linux Enterprise Security Architect」

不是：

• 單純 Linux 指令考試
• 記憶型考試

而是：

• 安全架構設計
• 主機防護
• 企業級安全治理

隨著 AI Agent、AIOps、雲原生與自動化網路快速普及，傳統網路工程師與系統工程師的技能正在被重構。
未來企業真正需要的，不只是「會設定設備的人」，而是：
能理解雲架構 + 網路 + 自動化 + AI 系統的人
因此，證照的價值也開始重新排序。

一、AI 時代證照選擇核心原則
選證照不再只是「加分」，而是要回答三個問題：
是否涵蓋雲端架構？
是否涉及自動化 / DevOps？
是否能對接 AI / AIOps / 資料流？

未來有價值的證照通常具備：
雲 + 網路 + 自動化 + 安全（至少兩項以上交叉）

二、入門級（打基礎必考）
這一階段目標是建立「網路 + 雲端基本認知」。

1. CompTIA Network+
   適合人群：
   網路新手
   IT轉職者
   涵蓋內容：
   TCP/IP
   Routing / Switching 基礎
   網路架構概念
   優點：不綁廠商，打底很穩
2. CompTIA Cloud+
   適合人群：
   想進雲端但沒基礎的人
   涵蓋內容：
   雲基礎架構
   虛擬化
   雲安全基本概念
3. CCNA（Cisco Certified Network Associate）
   適合人群：
   網路工程師入門核心證照
   涵蓋內容：
   Routing / Switching
   VLAN / STP / OSPF
   基礎自動化概念
   仍然是網路領域的「地基證照」

三、進階級（AI 時代關鍵轉折）
這一階段開始進入「雲 + 自動化 + 架構」。

1. AWS Certified Solutions Architect – Associate
   適合人群：
   網路工程師轉雲端
   核心能力：
   雲架構設計
   高可用系統
   VPC / Subnet / Route design
   AI 時代最重要的雲架構基礎證照之一
2. Microsoft Azure Administrator (AZ-104)
   核心能力：
   Azure 網路架構
   身份與權限管理
   虛擬網路設計

企業採用率極高（特別是大型企業）

3. Cisco DevNet Associate
   核心能力：
   API 操作網路設備
   Python 自動化
   網路程式化

這張是「進入 AI 網路自動化」的關鍵門票

四、進階專業級（AI + 自動化核心戰場）
這一層開始進入 AI Agent + AIOps 時代核心能力。

1. AWS Advanced Networking – Specialty
   核心能力：
   複雜網路架構
   Hybrid Cloud
   Global network design

適合大型企業 / 雲網融合架構師

2. Google Professional Cloud Network Engineer
   核心能力：
   GCP 網路設計
   雲原生網路架構
   全球負載平衡

很多 AI 公司（含 LLM 企業）會用 GCP

3. Certified Kubernetes Administrator (CKA)
   核心能力：
   容器網路
   Kubernetes 架構
   Service networking
   AI + 微服務時代的「基礎設施核心證照」

五、安全方向（AI 時代不可缺）
AI + 雲 + 自動化 = 安全風險倍增

1. CompTIA Security+
   資訊安全基礎
   身份驗證
   網路安全模型
2. Cisco CCNP Security / Security Specialist
   企業級網路安全
   防火牆 / VPN / Zero Trust
3. (ISC)² CISSP（高階必備）
   安全架構設計
   企業安全治理
   Risk management

未來 AI Agent 操作環境的「安全決策層」

六、AI + 自動化新興方向（2026關鍵）
這一類是未來 3–5 年最重要的新能力。

1. Kubernetes + GitOps（ArgoCD / Flux）
   核心能力：
   自動部署
   CI/CD
   Infrastructure as Code

AI Agent 幾乎都會建立在這一層

2. Terraform Associate
   核心能力：
   基礎設施即程式碼（IaC）
   雲資源自動化

未來所有雲環境標準能力

3. AI Engineering / AIOps（新趨勢）
   雖然還沒有統一證照標準，但方向包括：
   LLM + API automation
   Log AI analysis
   Network anomaly detection
   Agent workflow design

未來網路工程師升級關鍵能力

七、AI 時代證照學習路線圖
可以這樣規劃：
第一階段（基礎）
CCNA
Network+
Cloud 基礎
第二階段（轉型）
AWS / Azure
DevNet
Terraform
第三階段（AI + 架構）
Kubernetes (CKA)
AWS Advanced Networking
Security（CISSP / CCNP Security）
八、未來人才分水嶺

AI 時代網路與雲端人才會分成三層：

1. 操作層（逐漸被自動化取代）
   手動設定設備
   基礎排障
2. 工程層（仍有需求）
   自動化工程師
   雲網整合工程師
3. 架構層（最有價值）
   雲網架構師
   AIOps 設計者
   AI Agent 控制者

結語：證照只是門票，能力才是護城河
AI 時代證照的意義已經改變：
不再是「證明你懂技術」，而是「證明你能進入新架構世界」

未來真正有價值的人，不是證照最多的人，而是：
能把網路、雲端、自動化與 AI 串起來的人

重傳機制
超時重傳
重送機制的其中一個方式，就是在發送資料時，設定一個定時器，當超過指定的時間後，沒有收到對方的 ACK 確認應答報文，就會重發該資料超時觸發重傳存在的問題是，超時週期可能相對較長。
快速重傳
快速重傳不以時間為驅動，而是以數據驅動重傳。

快速重傳的工作方式是當收到三個相同的 ACK 報文時，可以不用等到超時才重傳，會直接重傳遺失的報文段。快速重傳機制只解決了一個問題，就是超時時間的問題，但它依然面臨另一個問題。
就是重傳的時候，是重傳一個，還是重傳所有的問題舉個例子，假設發送方發了 6 個數據，編號的順序是 Seq1 ~ Seq6 ，但是 Seq2、Seq3 都丟失了，那麼接收方在收到 Seq4、Seq5、Seq6 時，都是回复 ACK2 給發送方，但是之後已發送的所有報文呢（Seq2、Seq3、 Seq4、Seq5、 Seq6） 呢？
SACK 方法
SACK（ Selective Acknowledgment）， 選擇性確認。 SACK是將已收到的資料的訊息傳送給發送方，這樣發送方就可以只重傳遺失的資料。
如下圖，發送方收到了三次相同的 ACK 確認報文，於是就會觸發快速重發機制，透過 SACK 訊息發現只有 200~299 這段資料遺失，則重發時，就只選擇了這個 TCP 段進行重複。

Duplicate SACK
要使用了 SACK 來告訴「傳送者」有哪些資料被重複接收了。
滑動視窗
TCP 每發送一個數據，都要進行一次確認應答。
當上一個資料包收到了應答了， 再發送下一個。
如果是這樣傳輸，那有一個缺點：封包的往返時間越長，通訊的效率就越低。
因此，TCP引入了滑動視窗。視窗大小就是指無需等待確認應答，而可以繼續傳送資料的最大值。
視窗中有部分資料段沒有收到ACK，也可以透過下一個ACK確認。這個模式就叫累計確認或累計應答。

視窗的大小是由接收方的視窗大小決定的。
發送方傳送的資料大小不能超過接收方的視窗大小，否則接收方就無法正常接收到資料。
接收視窗的大小是約等於發送視窗的大小的。因為滑動視窗並不是一成不變的。
例如，當接收方的應用程式讀取資料的速度非常快的話，這樣的話接收視窗可以很快的就空缺出來。
那麼新的接收視窗大小，就是透過 TCP 封包中的 Windows 欄位來告訴發送方。那麼這個傳輸過程是存在時延的，所以接收視窗和發送視窗是約等於的關係。
MSS限制
鏈路層對一次能夠發送的最大資料有限制，這個限制稱為 MTU（maximum transmission unit），不同的鏈路設備的 MTU 值也有所不同，例如乙太網路的 MTU 是 1500FDDI（光纖分散式資料介面）的 MTU 是 4352 本地回環位址的 MTU 是本地回環位址size），它是 MTU 刨去 tcp 頭和 ip 頭後剩餘能夠作為資料傳輸的位元組數ipv4 tcp 頭佔用 20 bytes，ip 頭佔用 20 bytes，因此乙太網路 MSS 的值為 1500 – 40 = 1460TCP 將大量資料傳送時，將大量資料傳送至 MSS 的資料在 MSS.的值，然後在兩者之間選擇一個小值作為 MSS

TCP黏包
黏包的問題出現是因為不知道一個用戶訊息的邊界在哪，如果知道了邊界在哪，接收方就可以透過邊界來分割出有效的用戶訊息。
出現黏包的原因是多方面的，可能是來自接收方，也可能是來自發送方。
發送方原因
因為即使傳送一個字節，也需要加入 tcp 頭和 ip 頭，也就是總字節數會使用 41 bytes，非常不經濟。
因此Nagle演算法試圖在發送一個分組之前，將大量的TCP資料綁定在一起，以提高網路效率。
該演算法是指發送端即使還有應該發送的數據，但如果這部分數據很少的話，則進行延遲發送如果 SO_SNDBUF 的數據達到 MSS，則需要發送如果 SO_SNDBUF 中含有 FIN（表示需要連接關閉）這時將剩餘數據發送，再關閉如果 TCP_NODELAY = true，則需要發送已發送關閉）這時將剩餘數據發送，再關閉如果 TCP_NODELAY = true，則需要發送已發送已發送的數據都需要發送時，但上述條件200ms）則需要發送除上述情況，延遲發送TCP預設使用Nagle演算法（主要作用：減少網路中報文段的數量），而Nagle演算法主要做兩件事：只有上一個分組得到確認，才會發送下一個分組收集多個小分組，在一個確認到來時一起發送。
Nagle演算法造成了發送方可能會出現黏包問題。對於發送方造成的黏包問題，可以透過關閉Nagle演算法來解決，使用TCP_NODELAY選項來關閉演算法。
接收方原因
TCP接收到封包時，並不會馬上交到應用層處理，或是應用層並不會立即處理。
實際上，TCP將接收到的資料包保存在接收快取裡，然後應用程式主動從快取讀取收到的分組。
這樣一來，如果TCP接收資料報到快取的速度島嶼應用程式從快取中讀取資料報的速度，多個包就會被緩存，應用程式就有可能讀取到多個收尾相接黏在一起的包。
接收方沒有辦法處理黏包問題，只能將問題交給應用層來處理
解決方式
一般有三种方式分包的方式（可以同时解决发送方和接收方的问题）：

1. 固定长度的消息：这种是最简单方法，即每个用户消息都是固定长度的，比如规定一个消息的长度是 64 个字节，当接收方接满 64 个字节，就认为这个内容是一个完整且有效的消息
2. 特殊字符作为边界：比如HTTP 通过设置回车符、换行符作为 HTTP 报文协议的边界。
3. 自定义消息结构，如TLV 格式，即 Type 类型、Length 长度、Value 数据，类型和长度已知的情况下，就可以方便获取消息大小，分配合适的 buffer，缺点是 buffer 需要提前分配，如果内容过大，则影响 server 吞吐量
   • Http 1.1 是 TLV 格式
   • Http 2.0 是 LTV 格式

流量控制

发送方不能无脑的发数据给接收方，要考虑接收方处理能力。

流量控制就是根据接收方的滑动窗口的大小来控制的。

比如服务端繁忙，无法及时的处理掉接收的数据，就会减小接收窗口的大小

拥塞控制

流量控制是避免「发送方」的数据填满「接收方」的缓存

在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环

拥塞控制，目的就是避免「发送方」的数据填满整个网络。

拥塞控制是根据拥塞窗口来实现的，拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的

发送方没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。

慢启动

慢启动算法：当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。

这个大小是指能同时发送数据的数量，比如一开始拥塞窗口为1，表示可以传1个；发送方收到一个 ACK 确认应答后，cwnd 增加 1，于是一次能够发送 2 个；以此类推，显然慢启动时的拥塞窗口大小是呈指数增长的

一般有三种方式分包的方式（可以同时解决发送方和接收方的问题）：

1. 固定长度的消息：这种是最简单方法，即每个用户消息都是固定长度的，比如规定一个消息的长度是 64 个字节，当接收方接满 64 个字节，就认为这个内容是一个完整且有效的消息
2. 特殊字符作为边界：比如HTTP 通过设置回车符、换行符作为 HTTP 报文协议的边界。
3. 自定义消息结构，如TLV 格式，即 Type 类型、Length 长度、Value 数据，类型和长度已知的情况下，就可以方便获取消息大小，分配合适的 buffer，缺点是 buffer 需要提前分配，如果内容过大，则影响 server 吞吐量
   • Http 1.1 是 TLV 格式
   • Http 2.0 是 LTV 格式

流量控制

发送方不能无脑的发数据给接收方，要考虑接收方处理能力。

流量控制就是根据接收方的滑动窗口的大小来控制的。

比如服务端繁忙，无法及时的处理掉接收的数据，就会减小接收窗口的大小

拥塞控制

流量控制是避免「发送方」的数据填满「接收方」的缓存

在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环

拥塞控制，目的就是避免「发送方」的数据填满整个网络。

拥塞控制是根据拥塞窗口来实现的，拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的

发送方没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。

慢启动

慢启动算法：当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。

这个大小是指能同时发送数据的数量，比如一开始拥塞窗口为1，表示可以传1个；发送方收到一个 ACK 确认应答后，cwnd 增加 1，于是一次能够发送 2 个；以此类推，显然慢启动时的拥塞窗口大小是呈指数增长的

慢启动算法增长到哪是根据慢启动门限 ssthresh （slow start threshold）来决定的：

• 当 cwnd < ssthresh 时，使用慢启动算法。
• 当 cwnd >= ssthresh 时，就会使用拥塞避免算法

拥塞避免

拥塞避免算法：每当收到一个 ACK 时，cwnd 增加 1/cwnd。

现假定 ssthresh 为 8，当到门限时，当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1

就这么一直增长着后，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。当触发了重传机制，也就进入了拥塞发生算法

拥塞发生

当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种，两种使用的拥塞发送算法是不同的

• 超时重传
• 快速重传

超时重传

• ssthresh 设为 cwnd/2
• cwnd 重置为 1 （是恢复为 cwnd 初始化值，我这里假定 cwnd 初始化值 1）

接着，就重新开始慢启动，慢启动会突然减少数据流，

快速重传

当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。https://wxa.wxs.qq.com/tmpl/pr/base_tmpl.html

• cwnd = cwnd/2 ，也就是设置为原来的一半;
• ssthresh = cwnd;

进入快速恢复算法

快速恢复

算法如下：

1. 拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；
2. 重传丢失的数据包；
3. 如果再收到重复的 ACK，那么 cwnd 增加 1； 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；

也就是没有像「超时重传」一夜回到解放前，而是还在比较高的值，后续呈线性增长