TCPIP之常用協議

一、TCPIP之網絡支撐協議

1.ARP

ARP是網絡層協議，在同一廣播域內，將IP地址解析成MAC地址.

?1.1 無故ARP

請求型無故ARP

設備在網絡中不管是自動獲取ip地址還是手動配置ip地址，設備都會發送請求型無故ARP檢查這個ip地址是否有重復的。

應答型無故ARP?

--一般是網關設備發。

1.2 代理ARP--已被網關代替

代理ARP（Proxy ARP）工作過程

當主機A（無默認網關配置）嘗試與不同子網的主機B通信時，主機A誤認為B在同一局域網，遂發起ARP請求查詢B的MAC地址。此時，路由器（開啟代理ARP功能）攔截該廣播請求：

路由器檢查目標IP（B的IP）是否屬于其直連的其他子網；

若是，路由器以自己的MAC地址單播回復ARP響應給主機A；

主機A將發往B的數據幀封裝目的MAC為路由器接口MAC；

路由器收到數據后，按正常路由流程轉發至目標子網。
本質：路由器“欺騙”主機A，代理了跨網段主機的ARP響應職責，使無網關配置的主機能與外網通信。

1.3 RARP

抓包分析

2.ARP表

不同設備展示ARP表的命令。

3.? ICMP? 互聯網控制消息協議

ICMP工作在網絡層，封裝于IP，協議號1，用于發送錯誤消息和控制消息。

你可以把 ICMP 當成網絡里的?“信使”?或?“反饋員”：

當網絡里的數據包出問題（比如到不了目標、超時、路徑不對），ICMP 會發 “報錯信” 告訴源主機哪里錯了；
當需要測試網絡通不通（Ping）、查數據包走哪條路（Traceroute），ICMP 會配合發 “探測信” 和 “回應信”。

3.1? ICMP報文類型

分類	類型值	報文名稱	功能說明	常見細分代碼（Code）及含義
差錯報告報文	3	目的不可達（Destination Unreachable）	數據包無法送達目標時發送，告知源主機具體原因	0：網絡不可達 1：主機不可達 3：端口不可達 6：目標網絡未知 7：目標主機未知
	11	超時（Time Exceeded）	數據包因 TTL 過期或分片重組超時而被丟棄	0：TTL 過期（跳轉次數超過限制） 1：分片重組超時（未收到所有分片）
	12	參數問題（Parameter Problem）	IP 報文頭部存在錯誤（如字段無效），無法處理時發送	0：IP 頭部參數錯誤（如版本號不正確） 1：缺少必要的選項字段
	4	源抑制（Source Quench）	告知源主機降低發送速率（因接收方緩存已滿），現代網絡中較少使用	無細分代碼
	5	重定向（Redirect）	路由器告知源主機更優路由，引導調整數據包發送路徑	0：網絡重定向 1：主機重定向 2：網絡和端口重定向 3：主機和端口重定向
查詢報文	8	回顯請求（Echo Request）	測試目標主機可達性（Ping 命令核心），包含隨機數據	無細分代碼（需接收方回復類型 0 的報文）
	0	回顯應答（Echo Reply）	對回顯請求的響應，返回請求中的隨機數據	無細分代碼
	13	時間戳請求（Timestamp Request）	用于同步網絡時間或測量傳輸延遲，包含發送時間戳	無細分代碼（需接收方回復類型 14 的報文）
	14	時間戳應答（Timestamp Reply）	對時間戳請求的響應，包含接收和發送時間戳	無細分代碼
	10	路由請求（Router Solicitation）	主機啟動時發現局域網內的路由器，獲取網關信息	無細分代碼（需路由器回復類型 9 的報文）
	9	路由通告（Router Advertisement）	對路由請求的響應，包含路由器 IP 地址等信息	無細分代碼
	17	地址掩碼請求（Address Mask Request）	主機獲取所在網絡的子網掩碼（無 DHCP 時使用）	無細分代碼（需路由器回復類型 18 的報文）
	18	地址掩碼應答（Address Mask Reply）	對地址掩碼請求的響應，返回子網掩碼信息	無細分代碼

ICMP協議以及報文講解（ICMP查詢報文、ICMP差錯報文）_icmp報文-CSDN博客

3.2 ping命令

3.3Trace Route

1. Traceroute 基本作用與目的

Traceroute 是網絡排障、路徑分析的常用工具，用于追蹤數據包從源主機到目標主機經過的網絡路由（ hops，跳數），幫我們理清 “數據怎么從本地傳到目標，中途經過哪些設備”，排查網絡延遲、不通等問題。

2. TTL（生存時間）的關鍵機制

TTL 本質：IP 數據包頭部的一個字段（8 位），初始值由操作系統 / 設備設置（如常見 64、128 等），每經過一個路由器（路由跳），TTL 值減 1 。
核心邏輯：若 TTL 減到 0，數據包還未到達目標，路由器會丟棄該包，并向源主機發送 “ICMP TTL 超時” 消息?，告知 “我是第 X 跳路由器，包在這超時被扔啦” 。

3.此情況涉及兩種ICMP類型

ICMP TTL 超時：路由器收到 TTL=0 的包時發送，用于 “上報” 路徑中的路由跳。
ICMP 回顯應答：目標主機收到 TTL 未超時、且是自己的包時（如最終 Traceroute 探測包），回復此消息，標志 “到達終點” 。

4.目標不可達類型

三、TCPIP應用協議

1.常見TCP應用協議

2. FTP-文件傳輸協議

1.基本概念

2.FTP兩種文件傳輸模式

3.FTP兩種數據傳輸模式

4.FTP的連接方式

主動模式是服務器主動發起數據連接，在客戶端有嚴格防火墻時連接失敗；
被動模式是客戶端主動發起數據連接，解決了客戶端防火墻的限制，當服務器也開啟防火墻時，服務器支持動態開放端口支持被動FTP連接。

4. telnet-遠程登錄協議

1.基本概念

2.常見UDP應用協議

1.1 DNS??

Hosts 文件

作用：主機本地的 “小字典”，存主機名和 IP 的對應關系，系統訪問網絡時，會先查 Hosts 找對應，能實現簡單的本地域名解析。

DNS 域名解析基礎

架構與協議：采用客戶端 / 服務器（C/S）架構，基于 UDP 協議，服務器默認用 53 端口通信。客戶端發域名查詢請求，服務器返回 IP，讓域名和 IP “掛鉤” 。

3.域名層級劃分

根域（.）→ 頂級域（TLD）→ 二級域（SLD）→ 子域（Subdomain）

例：mail.google.com.
- .：根域（通常省略）
- com：頂級域（gTLD：通用域 / ccTLD：國家域如?.cn）
- google：二級域（注冊的網站主體）
- mail：子域（自定義分區）

4.域名層級 vs. 對應的 DNS 服務器

域名層級	代表什么	對應的 DNS 服務器	該服務器的職責
根域 (Root Domain)	域名體系的最頂層，通常用一個點?`.`?表示（如?`www.example.com.`?最后的點，通常省略）	根 DNS 服務器	管理所有頂級域 (TLD)?的信息。它知道每個頂級域（如?`.com`,?`.org`,?`.cn`?等）由哪些?TLD 服務器?負責。
頂級域 (Top-Level Domain, TLD)	緊跟在根域后面的部分（如?`.com`,?`.org`,?`.net`,?`.cn`,?`.uk`）	TLD 服務器	管理特定頂級域下注冊的所有二級域。它知道每個二級域（如?`example.com`,?`google.com`）由哪些權威 DNS 服務器負責。
二級域 (Second-Level Domain, SLD)	緊跟在頂級域后面的部分（如?`example`?in?`example.com`）	權威 DNS 服務器	管理特定二級域及其所有子域（如?`www.example.com`,?`mail.example.com`,?`blog.example.com`）的最終記錄（IP地址、郵件服務器地址等）。

5.. DNS（域名系統）查詢方式

兩種查詢的核心區別

Q1：?一次完整的DNS解析過程?

核心要點：

用戶到本地 DNS 服務器：遞歸查詢?(必須完成)

當你的設備（客戶端）需要解析一個域名（如?www.example.com）時，它首先向預先配置好的本地 DNS 服務器發起查詢。

關鍵點 1：?客戶端向本地 DNS 服務器發出的是一個?遞歸查詢?請求。這意味著客戶端要求本地 DNS 服務器：“你必須給我最終答案（IP 地址），或者告訴我找不到。你自己想辦法去問，別讓我再去找別人問。”

關鍵點 2：?如果本地 DNS 服務器在自己的緩存中恰好有這個域名的最新記錄，它會立即將 IP 地址返回給客戶端（遞歸查詢完成）。

關鍵點 3：?如果本地 DNS 服務器的緩存中沒有這個記錄（或者記錄過期了），那么本地 DNS 服務器必須履行它對客戶端的遞歸承諾——它需要自己去找到答案。這時，它就需要代表客戶端發起查詢，但它的查詢方式變成了?迭代查詢。

本地 DNS 服務器到各級 DNS 服務器：迭代查詢?(由本地 DNS 執行)

因為本地 DNS 服務器沒有答案，它開始代表客戶端進行查找。

關鍵點 4：?本地 DNS 服務器不會向根服務器、頂級域服務器、權威服務器發起遞歸查詢。相反，它發起的是?迭代查詢。

過程：

迭代查詢根服務器：?本地 DNS 服務器首先向?根 DNS 服務器?發送查詢?www.example.com?的請求。根服務器不會直接給出答案，而是查看域名后綴（.com），然后迭代響應：“我不知道?www.example.com?的 IP，但我知道負責?.com?域的頂級域（TLD）服務器有哪些。這里是它們的地址（例如?a.gtld-servers.net?等）。”

迭代查詢 TLD 服務器：?本地 DNS 服務器選擇其中一個?.com?TLD 服務器，向其發送相同的查詢。TLD 服務器查看下一級（example.com），然后迭代響應：“我不知道?www.example.com?的 IP，但我知道負責?example.com?域的權威 DNS 服務器有哪些。這里是它們的地址（例如?ns1.example.com?等）。”

迭代查詢權威服務器：?本地 DNS 服務器選擇其中一個?example.com?的權威 DNS 服務器，向其發送查詢?www.example.com?的請求。這次，權威服務器在自己的區域數據中查找?www.example.com?的記錄。

最終答案：?如果記錄存在，權威服務器會直接將?www.example.com?對應的?IP 地址?返回給本地 DNS 服務器（這是一個?非遞歸/迭代?響應，因為它直接給出了最終答案）。如果記錄不存在，它會返回一個錯誤（如 NXDOMAIN）。

本地 DNS 服務器返回結果給客戶端

一旦本地 DNS 服務器從權威服務器那里得到了最終的 IP 地址（或錯誤信息），它就會：

將這個記錄緩存起來（根據記錄的 TTL 時間）。

履行它對客戶端的遞歸承諾，將最終的 IP 地址（或錯誤信息）返回給最初發起請求的客戶端。

總結順序與關系：

客戶端發起：?遞歸查詢?(目標：本地 DNS 服務器)?-> “你必須給我最終答案！”
本地 DNS 處理：
- 情況 A (緩存命中)：?直接返回結果給客戶端（遞歸完成）。
- 情況 B (緩存未命中)：
  - 本地 DNS 服務器代表客戶端發起?迭代查詢?(目標：根 DNS 服務器)?-> “你知道?.com?該問誰嗎？” (得到 TLD 服務器地址)
  - 本地 DNS 服務器發起?迭代查詢?(目標：.com TLD 服務器)?-> “你知道?example.com?該問誰嗎？” (得到權威服務器地址)
  - 本地 DNS 服務器發起?迭代查詢?(目標：example.com 權威服務器)?-> “www.example.com?的 IP 是什么？” (得到最終 IP 地址)
本地 DNS 服務器返回：?將最終得到的 IP 地址（或錯誤）作為?遞歸查詢?的答案返回給客戶端。