計算機網絡—

1. 計算機網絡分層

1.1 OSI 7層模型

應用層
表示層
會話層
傳輸層
網絡層
數據鏈路層
物理層

1.2 TCP/IP 4 層模型

應用層
運輸層
網際層
網絡接口層

1.3 5層體系機構

應用層
傳輸層
網絡層
數據鏈路層
物理層

2. 應用層協議

2.1 HTTP協議

2.1.1 基本介紹

HTTP（HyperText Transfer Protocol，超文本傳輸協議）是應用層的一種協議，用于客戶端（如瀏覽器）與服務器之間傳輸超文本（如 HTML 頁面、圖片、視頻等）。它是 Web 的基礎，建立在 TCP 協議之上，確保數據的可靠傳輸。HTTP協議的默認端口是80。

特點	說明
無狀態（Stateless）	每個請求之間相互獨立，服務器不會記住前一個請求的狀態。
基于請求-響應模型	客戶端發送請求，服務器返回響應。
可擴展性強	支持多種數據類型（通過?`Content-Type`?指定）。
支持持久連接	HTTP/1.1 默認啟用?`keep-alive`，可復用 TCP 連接。
明文傳輸	默認不加密（HTTP），安全性差；HTTPS 使用 SSL/TLS 加密。

2.1.2 工作流程

HTTP 的典型工作流程如下：

建立 TCP 連接
客戶端與服務器通過 三次握手 建立 TCP 連接（默認端口 80）。
客戶端發送 HTTP 請求
客戶端構造請求報文，包含：請求行、請求頭、空行、請求體（可選）。
服務器處理請求并返回響應
服務器解析請求，處理業務邏輯，生成響應報文（狀態行、響應頭、響應體）。
客戶端接收并解析響應
瀏覽器渲染頁面或應用程序處理數據。
關閉連接（可選）
- 若使用?Connection: close，則立即四次揮手斷開。
- 若使用?Connection: keep-alive，連接保持，可復用。

? 現代瀏覽器通常使用連接池和持久連接，避免頻繁建立/斷開 TCP 連接。

HTTP 協議是應用層協議，它依賴于傳輸層的 TCP 協議 來保證可靠傳輸。而：

三次握手：是 TCP 建立連接的過程。
四次揮手：是 TCP 斷開連接的過程。

從 HTTP/1.1 開始，默認使用持久連接（也叫長連接），這意味著：

一個 TCP 連接可以被復用來發送多個 HTTP 請求和響應，而不是每次請求都重新建立和關閉連接。

舉個例子：

假設你訪問一個網頁，頁面包含：

1 個 HTML 文件
2 個 CSS 文件
3 個 JavaScript 文件
4 張圖片

在持久連接下：

客戶端與服務器進行一次?三次握手，建立 TCP 連接。
復用這個連接，連續發送 10 個 HTTP 請求（獲取資源）。
所有請求完成后，才通過?四次揮手?斷開 TCP 連接。

2.1.3 HTTP請求

一個完整的 HTTP 請求由以下三部分組成：

1. 請求行（Request Line）

格式：方法資源路徑協議版本

GET /index.html HTTP/1.1

常見方法：
- GET：獲取資源
- POST：提交數據
- PUT：更新資源
- DELETE：刪除資源
- HEAD：獲取響應頭（不返回體）
- OPTIONS：預檢請求（CORS）

2. 請求頭（Request Headers）

鍵值對形式，提供客戶端信息和請求元數據。

常見請求頭：

頭部	作用
`Host`	指定服務器域名（必需）
`User-Agent`	客戶端類型（如瀏覽器、操作系統）
`Accept`	客戶端可接受的響應類型（如?`application/json`）
`Content-Type`	請求體的數據格式（如?`application/json`）
`Authorization`	認證信息（如 Bearer Token）
`Cookie`	發送存儲在本地的 Cookie

3. 請求體（Request Body）

僅用于?POST、PUT?等方法。
數據格式由?Content-Type?決定：
- application/json：JSON 數據
- application/x-www-form-urlencoded：表單數據
- multipart/form-data：文件上傳

?? 請求頭與請求體之間必須有一個空行（\r\n\r\n）。

2.1.4 HTTP響應

服務器返回的響應也由三部分組成：

1. 狀態行（Status Line）

格式：協議版本狀態碼狀態描述

HTTP/1.1 200 OK

常見狀態碼分類：

范圍	類型	示例
1xx	信息響應	`100 Continue`
2xx	成功	`200 OK`,?`201 Created`
3xx	重定向	`301 Moved Permanently`,?`302 Found`
4xx	客戶端錯誤	`400 Bad Request`,?`404 Not Found`,?`403 Forbidden`
5xx	服務器錯誤	`500 Internal Server Error`,?`502 Bad Gateway`

2. 響應頭（Response Headers）

提供服務器信息和響應元數據。

常見響應頭：

頭部	作用
`Content-Type`	響應體的數據類型（如?`text/html`）
`Content-Length`	響應體長度
`Set-Cookie`	設置 Cookie
`Location`	重定向目標地址（配合 3xx 狀態碼）
`Cache-Control`	緩存策略
`Server`	服務器類型（如 Nginx、Apache）

3. 響應體（Response Body）

服務器返回的實際數據，如：

HTML 頁面
JSON 數據
圖片、文件等二進制流

2.1.5 總結

HTTP 請求：
┌─────────────────────────────┐
│ GET /api/users HTTP/1.1     │ ← 請求行
│ Host: example.com           │
│ User-Agent: Chrome          │ ← 請求頭
│ Content-Type: application/json │
│                             │ ← 空行
│ {"name": "Tom"}             │ ← 請求體（POST 時存在）
└─────────────────────────────┘HTTP 響應：
┌─────────────────────────────┐
│ HTTP/1.1 200 OK             │ ← 狀態行
│ Content-Type: application/json │
│ Content-Length: 15          │ ← 響應頭
│ Set-Cookie: session=abc     │
│                             │ ← 空行
│ {"id":1,"name":"Tom"}       │ ← 響應體
└─────────────────────────────┘

? 一句話總結：
HTTP 是一種基于 請求-響應模型 的應用層協議，通過 請求行、請求頭、請求體 構成請求，通過 狀態行、響應頭、響應體 構成響應，是 Web 通信的核心。

2.2 HTTPS協議

2.2.1 基本介紹

HTTPS（超文本傳輸安全協議）是 HTTP 的安全版本，通過在 HTTP 和 TCP 之間加入 SSL/TLS 協議 來實現數據加密，確保通信過程中的 機密性、完整性、身份認證。

默認端口：443（HTTP 是 80）
協議基礎：HTTP + SSL/TLS
目標：防止數據被竊聽、篡改或冒充

? 簡單理解：HTTPS = HTTP + 加密 + 認證 + 完整性保護

2.2.2 為什么需要 HTTPS

HTTP 的三大安全問題：

問題	說明
竊聽風險	數據明文傳輸，第三方可監聽內容（如密碼、銀行卡號）
篡改風險	中間人可修改傳輸內容（如插入廣告）
冒充風險	無法確認對方是否是真正的服務器（釣魚網站）

HTTPS 通過加密和數字證書解決這些問題。

2.2.3 SSL/TLS 協議

SSL（Secure Sockets Layer）和其升級版 TLS（Transport Layer Security）是用于加密通信的安全協議。

現代 HTTPS 使用的是?TLS（如 TLS 1.2、TLS 1.3）
加密過程發生在 TCP 連接建立之后、HTTP 通信之前

2.2.4 工作過程

HTTPS 的安全通信建立在 TLS 握手 的基礎上，主要步驟如下：

1. 客戶端發起請求（Client Hello）

客戶端發送支持的 TLS 版本、加密套件（Cipher Suites）、隨機數?Client Random

2. 服務器響應（Server Hello）

服務器選擇 TLS 版本和加密套件
返回自己的?數字證書（包含公鑰）
生成并發送隨機數?Server Random

3. 客戶端驗證證書

客戶端驗證證書是否由可信?CA（證書頒發機構）?簽發
驗證域名是否匹配
驗證證書是否過期
? 驗證通過后，提取服務器公鑰

4. 生成會話密鑰（Pre-Master Secret）

客戶端生成一個隨機的?預主密鑰（Pre-Master Secret）
使用服務器的?公鑰加密?后發送給服務器

5. 服務器解密預主密鑰

服務器使用自己的?私鑰?解密，得到預主密鑰

6. 雙方生成會話密鑰

客戶端和服務器使用?Client Random、Server Random、Pre-Master Secret?通過算法生成相同的?會話密鑰（Session Key）

7. 切換到加密通信

雙方通知“握手完成”
后續所有通信（包括 HTTP 請求和響應）都使用?對稱加密（會話密鑰）進行加密

2.2.5 加密技術詳解

HTTPS 結合了兩種加密方式，發揮各自優勢：

加密方式	用途	特點
非對稱加密（如 RSA、ECC）	用于傳輸“預主密鑰”	安全但慢，公鑰加密，私鑰解密
對稱加密（如 AES）	用于加密實際數據（HTTP 報文）	快速高效，加密解密用同一密鑰

? 優勢：既保證了密鑰傳輸的安全性，又提升了通信效率。

2.2.6 數字證書與 CA

數字證書：由可信第三方（CA）簽發，包含：
- 域名
- 公鑰
- 有效期
- CA 簽名
CA（Certificate Authority）：如 Let's Encrypt、DigiCert、Symantec
瀏覽器內置了受信任的 CA 根證書列表，用于驗證服務器證書

🔐 如果證書無效（如自簽名、過期、域名不匹配），瀏覽器會顯示“不安全”警告。

2.2.7 HTTPS 與 HTTP 的對比

對比項	HTTP	HTTPS
安全性	明文傳輸，不安全	加密傳輸，安全
端口	80	443
協議	應用層	應用層 + SSL/TLS
性能	快（無加密開銷）	略慢（握手有開銷，但可優化）
SEO	不利于搜索引擎排名	更受搜索引擎青睞
證書	不需要	需要 SSL 證書（可免費獲取）

2.3.8 總結

HTTPS 通過 SSL/TLS 對 HTTP 進行加密和身份認證，是保障 Web 安全的基石，已成為現代互聯網的標準配置。

2.3 WebSocket

2.3.1 基本介紹

WebSocket 是一種基于 TCP 的應用層協議（RFC 6455），它在客戶端和服務器之間提供 全雙工（full-duplex）、持久化、雙向通信 的通道。與傳統的 HTTP 請求-響應模式不同，WebSocket 允許服務器主動向客戶端推送數據。

協議標識：
- ws://：非加密 WebSocket（對應 HTTP）
- wss://：加密 WebSocket（對應 HTTPS，基于 TLS）
默認端口：與 HTTP/HTTPS 一致（80 / 443）
設計目標：解決 HTTP 在實時通信場景下的性能瓶頸

? 簡單理解：
WebSocket = 一次連接，雙向通信，服務器可“主動說話”

2.3.2 為什么需要 WebSocket

HTTP 協議的局限性：

問題	說明
單向通信	只能客戶端發起請求，服務器被動響應
頻繁輪詢開銷大	實時應用（如聊天、股票）需不斷發請求，浪費資源
延遲高	輪詢間隔決定延遲，無法做到“即時”
頭部開銷大	每次請求都攜帶完整 HTTP 頭部

WebSocket 通過持久連接 + 消息幀機制，解決了這些問題。

2.3.3 WebSocket 的工作過程

WebSocket 的建立過程依賴 HTTP，分為兩個階段：

階段 1：HTTP 握手升級（Upgrade Handshake）

客戶端發送一個特殊的 HTTP 請求：

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

服務器如果支持 WebSocket，返回 101 Switching Protocols：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

? 此時，TCP 連接從 HTTP 協議“升級”為 WebSocket 協議。

階段 2：雙向通信

握手成功后，客戶端和服務器可以隨時互相發送數據幀（Frame），直到任意一方關閉連接。

數據可以是文本（UTF-8）或二進制
通信是全雙工的，無需請求-響應模式

2.3.4 WebSocket 通信模型

特性	說明
連接建立	基于 HTTP 升級，僅一次
通信模式	全雙工、雙向、持久化
數據單位	消息（Message），由一個或多個幀（Frame）組成
消息類型	文本消息（String）、二進制消息（ArrayBuffer/Buffer）
連接保持	連接長期存活，可通過?`ping/pong`?心跳保活

2.3.5 WebSocket API（前端示例）

在瀏覽器中使用原生 WebSocket API：

// 1. 創建 WebSocket 連接
const socket = new WebSocket('ws://localhost:8080/chat');// 2. 監聽連接打開
socket.onopen = function(event) {console.log('連接已建立');socket.send('Hello Server!');
};// 3. 監聽消息
socket.onmessage = function(event) {console.log('收到消息:', event.data);
};// 4. 監聽錯誤
socket.onerror = function(error) {console.log('發生錯誤:', error);
};// 5. 監聽連接關閉
socket.onclose = function(event) {console.log('連接已關閉');
};// 發送消息
socket.send('這是一條客戶端消息');

2.3.6 適用場景

WebSocket 特別適合需要低延遲、高頻、雙向通信的場景：

應用場景	示例
💬 實時聊天	微信網頁版、在線客服
📈 實時數據推送	股票行情、天氣更新、監控系統
🎮 在線游戲	多人互動、實時操作同步
🔔 通知系統	消息提醒、訂單狀態更新
🖥? 遠程控制	Web SSH、遠程桌面

2.3.7 與 HTTP 的對比

對比項	HTTP	WebSocket
通信模式	請求-響應（單向）	全雙工（雙向）
連接狀態	短連接或持久連接	持久化長連接
實時性	差（依賴輪詢）	強（服務器可主動推送）
開銷	每次請求帶完整頭部	幀頭部小，效率高
建立方式	直接發送請求	先 HTTP 握手，再升級協議
安全性	HTTP / HTTPS	ws:// / wss://（加密）

2.3.8 總結

項目	說明
WebSocket 是什么	一種支持全雙工通信的 Web 應用層協議
核心機制	基于 HTTP 升級，建立持久化雙向連接
主要用途	實時通信、消息推送、在線互動
關鍵優勢	低延遲、高效、服務器主動推送
發展趨勢	已成為現代 Web 實時應用的標準技術

🌐 一句話總結：
WebSocket 通過一次連接實現客戶端與服務器的雙向實時通信，是構建現代實時 Web 應用的核心技術。

3. 傳輸層協議

3.1 TCP協議

3.1.1 基本介紹

TCP（Transmission Control Protocol，傳輸控制協議）是一種面向連接、可靠、基于字節流的傳輸層協議（RFC 793），廣泛用于對數據完整性要求高的應用，如網頁瀏覽、文件傳輸、電子郵件等。

協議特點：可靠傳輸、流量控制、擁塞控制、全雙工通信
默認端口示例：
- HTTP: 80
- HTTPS: 443
- FTP: 21
- SMTP: 25
設計目標：確保數據在不可靠網絡中準確、有序、不丟失地送達

3.1.2 為什么需要 TCP

IP 協議本身不保證可靠性，存在以下問題：

問題	說明
數據丟失	網絡擁堵可能導致數據包丟失
數據亂序	數據包可能通過不同路徑到達，順序錯亂
數據重復	重傳機制可能導致接收端收到重復數據
無連接狀態	無法確認對方是否準備好接收數據

TCP 通過連接管理、確認機制、重傳、排序、流量控制等機制解決這些問題。

3.1.3 TCP 的工作過程

TCP 通信分為三個階段：連接建立、數據傳輸、連接釋放。

階段 1：三次握手（Three-way Handshake）

建立連接過程：

SYN：客戶端發送?SYN=1, seq=x，進入 SYN-SENT 狀態
SYN-ACK：服務器回復?SYN=1, ACK=1, seq=y, ack=x+1
ACK：客戶端發送?ACK=1, ack=y+1，連接建立

? 目的：雙方確認彼此具有發送和接收能力

階段 2：數據傳輸

雙方通過序列號（seq）和確認號（ack）?實現可靠傳輸
使用滑動窗口實現流量控制
通過慢啟動、擁塞避免等機制進行擁塞控制

階段 3：四次揮手（Four-way Wave）

斷開連接過程：

FIN：主動方發送?FIN=1, seq=u
ACK：被動方確認?ACK=1, ack=u+1
FIN：被動方發送自己的?FIN=1, seq=v
ACK：主動方確認?ACK=1, ack=v+1，進入 TIME_WAIT 狀態

? 為什么四次？因為 TCP 是全雙工，兩個方向需獨立關閉。

3.1.4 TCP 通信模型

特性	說明
連接模式	面向連接（需先建立連接）
可靠性	高（通過確認、重傳、校驗和）
傳輸單位	字節流（無消息邊界）
流量控制	滑動窗口機制
擁塞控制	慢啟動、擁塞避免、快速重傳、快速恢復
適用場景	文件傳輸、網頁訪問、郵件等要求可靠的應用

3.1.5 TCP 報文結構

字段	說明
源端口 / 目的端口	標識應用進程
序列號（seq）	當前數據第一個字節的編號
確認號（ack）	期望收到的下一個字節序號
數據偏移	TCP 頭部長度（通常 20 字節）
控制位	`SYN`,?`ACK`,?`FIN`,?`RST`,?`PSH`?等
窗口大小	接收方當前可接收的字節數
校驗和	用于檢測數據錯誤

3.1.6 適用場景

應用場景	示例
🌐 網頁瀏覽	HTTP/HTTPS 基于 TCP
📧 電子郵件	SMTP、POP3、IMAP
📂 文件傳輸	FTP、SFTP
💬 遠程登錄	SSH、Telnet
🗄? 數據庫訪問	MySQL、Redis（默認）

3.1.7 與 UDP 的對比

對比項	TCP	UDP
連接性	面向連接	無連接
可靠性	可靠（確認、重傳）	不可靠（盡最大努力交付）
傳輸方式	字節流	數據報（有邊界）
速度	較慢（握手、確認開銷）	快（無連接、無確認）
擁塞控制	有	無
適用場景	要求數據完整	要求低延遲

3.1.8 總結

項目	說明
TCP 是什么	一種面向連接、可靠的傳輸層協議
核心機制	三次握手、確認重傳、滑動窗口、擁塞控制
主要用途	可靠數據傳輸（如網頁、文件、郵件）
關鍵優勢	可靠、有序、不重復、流量控制
發展趨勢	仍是互聯網最主流的傳輸協議，持續優化（如 TCP BBR）

? 一句話總結：
TCP 通過連接管理和確認機制，確保數據在網絡中可靠、有序地傳輸，是互聯網通信的“基石協議”。

3.2 UDP協議

3.2.1 基本介紹

UDP（User Datagram Protocol，用戶數據報協議）是一種無連接、不可靠、基于數據報的傳輸層協議（RFC 768），強調傳輸效率和低延遲。

協議特點：無連接、盡最大努力交付、無重傳、無擁塞控制
默認端口示例：
- DNS: 53
- DHCP: 67/68
- SNMP: 161
- 視頻/語音：動態端口
設計目標：提供輕量級、低延遲的數據傳輸服務

3.2.2 為什么需要 UDP

TCP 的可靠性帶來較大開銷，不適合以下場景：

問題	說明
延遲敏感	實時音視頻不能等待重傳
高頻小包	如游戲狀態更新，重傳反而造成混亂
廣播/多播	TCP 不支持，UDP 支持
自定義可靠性	應用層可自行實現輕量級重傳機制

UDP 通過“簡單直接”的設計滿足這些需求。

3.2.3 UDP 的工作過程

UDP 通信極簡，無需握手或揮手：

發送方：構造 UDP 數據報，直接發送
接收方：收到數據報后處理，不發送確認
無連接狀態維護，每個數據報獨立處理

?? 數據可能丟失、亂序、重復，但速度極快。

3.2.4 UDP 通信模型

特性	說明
連接模式	無連接（發送即走）
可靠性	不可靠（不保證送達）
傳輸單位	數據報（有明確邊界）
傳輸開銷	極小（僅 8 字節頭部）
支持廣播/多播	? 支持
適用場景	實時音視頻、在線游戲、DNS 查詢

3.2.5 UDP 報文結構

字段	說明
源端口 / 目的端口	標識應用進程（可選）
長度	數據報總長度（頭部 + 數據）
校驗和	可選，用于檢測錯誤

? 頭部僅 8 字節，非常輕量。

3.2.6 適用場景

應用場景	示例
🎵 實時音視頻	視頻會議（WebRTC）、直播
🎮 在線游戲	多人游戲狀態同步
🔍 域名查詢	DNS 查詢響應
📡 廣播/多播	局域網發現、流媒體分發
🛰? 物聯網	傳感器數據上報

3.2.7 與 TCP 的對比

對比項	TCP	UDP
連接性	面向連接	無連接
可靠性	可靠	不可靠
傳輸方式	字節流	數據報
速度	較慢	快
擁塞控制	有	無
適用場景	要求完整	要求低延遲

3.2.8 總結

項目	說明
UDP 是什么	一種無連接、不可靠的傳輸層協議
核心機制	簡單數據報傳輸，無握手、無確認
主要用途	實時通信、廣播、輕量級傳輸
關鍵優勢	低延遲、高效率、支持廣播
發展趨勢	在實時通信、物聯網、QUIC（基于 UDP）中廣泛應用

? 一句話總結：
UDP 以“簡單高效”為核心，犧牲可靠性換取速度，是實時應用和輕量通信的理想選擇。

4. 網絡層協議

4.1 IP協議

4.1.1 基本介紹

IP（Internet Protocol，網際協議）是網絡層的核心協議（IPv4: RFC 791，IPv6: RFC 2460），負責尋址和路由，將數據包從源地址傳送到目的地址。

協議版本：
- IPv4：32 位地址（如?192.168.1.1），約 43 億地址
- IPv6：128 位地址（如?2001:db8::1），地址空間極大
協議特點：無連接、不可靠、盡力而為（Best Effort）
設計目標：實現跨網絡的主機間數據包傳輸

4.1.2 為什么需要 IP

數據通信需跨越多個網絡，面臨問題：

問題	說明
尋址混亂	需統一地址格式標識全球主機
路由選擇	數據包需通過多跳路由器到達目標
分片與重組	不同網絡 MTU 不同，需分片傳輸
異構網絡互聯	以太網、Wi-Fi、蜂窩網絡需統一協議

IP 協議通過統一地址、路由算法、分片機制實現全球互聯。

4.1.3 IP 的工作過程

封裝：傳輸層數據（TCP/UDP 報文）封裝為 IP 數據報
路由：路由器根據目標 IP 地址查找路由表，轉發數據包
分片（IPv4）：若數據包大于鏈路 MTU，則分片
重組：目標主機重新組裝分片
交付：將數據交付給上層協議（通過協議號）

? IPv6 不推薦在中間路由器分片，由源端通過 PMTUD 探測路徑 MTU。

4.1.4 IP 通信模型

特性	說明
連接模式	無連接（每個數據包獨立處理）
可靠性	不可靠（不保證送達、不重傳）
傳輸單位	IP 數據報（Datagram）
尋址方式	IP 地址（IPv4/IPv6）
路由機制	動態路由協議（如 OSPF、BGP）
分片支持	IPv4 支持，IPv6 由源端處理

4.1.5 IP 報文結構

字段	說明
版本	4（IPv4）或 6（IPv6）
頭部長度	通常 20 字節
總長度	數據報總長度
標識、標志、片偏移	用于分片與重組
生存時間（TTL）	防止無限循環，每經過一跳減 1
協議	上層協議類型（6: TCP, 17: UDP）
首部校驗和	僅校驗 IP 頭部
源 IP 地址 / 目的 IP 地址	32 位（IPv4）或 128 位（IPv6）

4.1.6 適用場景

應用場景	說明
🌍 全球互聯網通信	所有跨網絡通信的基礎
🖥? 局域網通信	內網主機間通信（如 192.168.x.x）
📱 移動網絡	4G/5G 網絡中數據傳輸
🌐 網站訪問	通過 IP 地址定位服務器
🔗 路由器轉發	核心路由協議依賴 IP

4.1.7 與 TCP/UDP 的對比

對比項	IP	TCP	UDP
層級	網絡層	傳輸層	傳輸層
功能	尋址與路由	可靠傳輸	高效傳輸
是否可靠	否	是	否
是否面向連接	否	是	否
傳輸單位	數據報	字節流 / 數據報	數據報

4.1.8 總結

項目	說明
IP 是什么	網絡層核心協議，負責尋址與路由
核心機制	IP 地址、路由表、TTL、分片
主要用途	實現全球主機間的數據包傳輸
關鍵優勢	統一尋址、支持異構網絡互聯
發展趨勢	IPv6 逐步取代 IPv4，解決地址枯竭問題