HCIA知识整理1

网络基础

一、网络分层与核心协议

1. OSI 七层模型

会话层：提供会话号 ：当 PC 端上 同软件不同进程的程序同时接收发时，他们会拥有相同的 IP 地址和 MAC 地址，为了分辨彼此所需要的消息，此时，就需要会话层分别给予不同的会话号进行区分。

数据封装与解封装:

从应用层到物理层 的数据封装过程（PC-A 发送数据到 PC-B）：

核心是 「上层数据被下层层层打包，加上头部 / 尾部，最终变成电信号发送；接收时再层层拆包，还原成应用数据」。

1. 整体流程：从应用到网线

• 数据从 PC-A 发出，经历 7→6→5→4→3→2→1 层 的封装，最后变成电信号在网线上传输；
• 到达 PC-B 后，再从 1→2→3→4→5→6→7 层 解封装，还原成应用能识别的内容。

2. 逐层拆解封装过程
第 7/6/5 层：应用 / 表示 / 会话层

• 应用层产生原始数据（比如网页请求、聊天消息）。
• 表示层把数据翻译成二进制格式（编码 / 加密 / 压缩）。
• 会话层管理通信会话（区分不同进程）。
• 最终得到一串二进制数据流，交给传输层。

第 4 层：传输层（TCP/UDP 分段）

• 把上层二进制数据分段 ，给每一段加上 TCP/UDP 头部：

• TCP：可靠传输，头部包含源端口、目的端口、序列号、确认号等。
• UDP：高效传输，头部只有源端口、目的端口、长度、校验和。

• 这一步的产物叫 「数据段（Segment）」，交给网络层。

第 3 层：网络层（IP 寻址）

• 给传输层的数据段加上 IP 头部：

• 包含源 IP（PC-A）、目的 IP（PC-B），用于跨网段寻址。

• 这一步的产物叫 「数据包（Packet）」，交给数据链路层。

第 2 层：数据链路层（MAC 寻址）

• 给网络层的数据包加上 MAC 头部 和 FCS 尾部：

• MAC 头部：源 MAC（PC-A / 下一跳设备）、目的 MAC（网关 / 目标设备），用于局域网内寻址。
• FCS：帧校验序列，用于检错。

• 这一步的产物叫 「数据帧（Frame）」，交给物理层。

第 1 层：物理层（电信号发送）

把数据帧转换成电信号 / 光信号，通过网线 / 光纤发送出去。

3. 设备在封装中的角色

• PC-A：完成 7→1 层 的完整封装，生成电信号发送。
• 交换机：工作在第 2 层，只看 MAC 地址，转发数据帧，不修改 IP/TCP 头部。
• 路由器：工作在第 3 层，解封装到网络层，查路由表决定下一跳，重新封装 MAC 头部后转发。
• PC-B：完成 1→7 层 的解封装，层层去掉头部，还原成应用数据。

4. 解封装：封装的逆过程

接收端（PC-B）的解封装顺序刚好相反：

• 物理层：电信号 → 数据帧
• 数据链路层：去掉 MAC 头和 FCS → 数据包
• 网络层：去掉 IP 头 → 数据段
• 传输层：去掉 TCP/UDP 头 → 二进制数据流
• 会话 / 表示 / 应用层：解码 / 解密 → 应用可识别的原始数据

5. 核心点

• 封装 ：从上到下，每层加一个头部（或尾部），数据越来越小但信息越来越全。
• 解封装 ：从下到上，每层剥一个头部（或尾部），最终还原成原始数据。
• 地址变化 ：
  IP 地址（源 / 目的）：全程不变 ，标识端到端。
  MAC 地址：逐跳变化，标识当前链路的收发方。
• 端口号：标识应用进程，让数据最终交给正确的程序（比如 80 端口给浏览器）。

类比(生活例子)

封装就像寄快递：

• 应用层：写一封信（原始数据）
• 传输层：装进信封（加 TCP/UDP 头，写清「寄件人 / 收件人端口」）
• 网络层：装进快递盒（加 IP 头，写清「寄件人 / 收件人地址」）
• 数据链路层：贴快递单（加 MAC 头，写清「当前站点 / 下一站」）
• 物理层：快递车拉走（变成电信号发送）

解封装就是收件拆快递：一层层拆包装，最后拿到信。

常见应用层协议总结

2. TCP/IP 模型（实际应用模型）

将OSI七层模型融合为 4 层：
应用层 （合 1-3 层）
传输层
网际层 （网络层）
网络访问层 （合 2-1 层）

3. 核心传输层协议

TCP（传输控制协议）

1.特性：面向连接、可靠传输 ，基于 3 次握手建立连接，4 次挥手断开连接

2.可靠机制：确认、重传、排序、流控（窗口滑动）

3.常用端口：80 (HTTP)、443 (HTTPS)、21 (FTP)、22 (SSH)、23 (Telnet)、53 (TCP-DNS)

4.标志位：SYN（发起连接）、ACK（确认）、FIN（断开）、RST（重连）、PSH（加急）、URG（紧急）

TCP 三次握手与四次挥手过程

前置基础

1.核心标志位 ：TCP 报文头部的6 位代码位是握手 / 挥手的关键，核心用到 3 个：

SYN ：同步序列编号，用于发起连接请求 ，告知对方自身的初始序列号（ISN） ，标志位为 1 时表示这是一个连接请求 / 同步报文。
ACK ：确认标志，用于确认收到对方的报文 ，标志位为 1 时，报文头部的确认号 字段有效，确认号 = 对方发送的序列号 + 1。
FIN ：结束标志，用于发起断开连接请求，表示本方已无数据要发送，请求关闭连接。

2.序列号（ISN） ：TCP 为每个字节的数据分配唯一序列号，** 初始序列号（ISN）** 是随机生成的（而非从 0 开始），用于避免网络中滞留的旧报文干扰新连接。

3.通信双方 ：统称客户端（Client）和服务器（Server） ，服务器通常提前处于 LISTEN（监听） 状态，等待客户端连接请求。

4.状态变化：握手 / 挥手过程中，客户端和服务器会经历不同的 TCP 状态，是理解流程的重要维度。

一、TCP 三次握手 交互流程图及解释

说明：ISN_C = 客户端初始序列号（随机值），ISN_S = 服务器初始序列号（随机值）；核心标志位 SYN（发起连接）、ACK（确认接收）。

TCP 是面向连接的可靠传输协议，三次握手（Three-way Handshake）是 TCP 建立端到端虚链路的核心过程，确保通信双方的收发能力均正常。

核心目的

确认客户端→服务器、服务器→客户端的双向收发能力 均正常，同时交换双方的初始序列号（ISN），为后续数据传输做准备，类似 "打电话确认双方都能听能说"。

整体流程

服务器提前进入LISTEN 状态，监听指定端口（如 80、443），客户端主动发起连接，双方通过 3 次报文交互完成连接建立，最终均进入 ESTABLISHED（已建立连接） 状态，可开始数据传输。

分步解释

1.第 1 次握手 ：客户端 → 服务器，发起连接请求

发送方 ：客户端，状态从CLOSED（关闭）→SYN_SENT（同步已发送）
报文标志 ：SYN=1，ACK=0 （仅发起连接，无确认信息）
关键字段 ：客户端携带自己的初始序列号 ISN_C （随机值，记为 Seq=ISN_C）
核心作用 ：客户端向服务器发送连接请求，告知服务器 "我想和你建立连接，我的初始序列号是 ISN_C，请你确认"。
服务器行为 ：收到 SYN 报文后，验证端口是否监听，若正常则记录客户端 ISN_C，状态从LISTEN（监听）→SYN_RCVD（同步已接收）。

2.第 2 次握手 ：服务器 → 客户端，确认连接 + 同步自身序列号

发送方 ：服务器，状态保持SYN_RCVD
报文标志 ：SYN=1，ACK=1 （既确认客户端的连接请求，又发起自身的同步请求）
关键字段：

1.确认号Ack=ISN_C+1 （表示已收到客户端 Seq=ISN_C 的报文，下一次期望收到 ISN_C+1 的字节）

2.序列号Seq=ISN_S （服务器自己的初始序列号，随机值）
核心作用 ：服务器向客户端回复 "我收到了你的连接请求（ACK 确认），我也想和你建立连接，我的初始序列号是 ISN_S，请你确认我的序列号"。
客户端行为 ：收到 SYN+ACK 报文后，验证 Ack 是否为 ISN_C+1，确认服务器接收能力 和发送能力 均正常，状态从SYN_SENT→ESTABLISHED（已建立连接）。

3.第 3 次握手 ：客户端 → 服务器，确认服务器的同步序列号

发送方 ：客户端，状态已为ESTABLISHED
报文标志 ：ACK=1，SYN=0 （仅确认，无新的同步请求）

关键字段：

1.确认号Ack=ISN_S+1 （表示已收到服务器 Seq=ISN_S 的报文，下一次期望收到 ISN_S+1 的字节）

2.序列号Seq=ISN_C+1 （遵循 TCP 序列号规则，上一次发送的是 ISN_C，本次自增 1）
核心作用 ：客户端向服务器回复 "我收到了你的同步序列号，确认你的连接请求，现在双方连接正式建立"。
服务器行为 ：收到 ACK 报文后，验证 Ack 是否为 ISN_S+1，确认客户端发送能力 （第 1 次握手）和接收能力 （本次握手）均正常，状态从SYN_RCVD→ESTABLISHED。

状态变化表

为什么需要三次握手？

本质是为了确认「客户端能发、服务器能收、服务器能发、客户端能收」的双向收发能力 ，若改为两次握手 会存在严重的连接失效问题：

1.假设客户端的SYN 连接请求报文 因网络延迟滞留，客户端超时后重新发送 SYN，正常建立连接并传输数据，断开后，滞留的旧 SYN 报文到达服务器，服务器若两次握手 则直接建立连接，等待客户端发送数据，但客户端已无连接状态，会忽略服务器的报文，导致服务器一直处于SYN_RCVD状态，浪费服务器资源 。

2.三次握手中，第三次握手由客户端发起 ACK 确认 ，服务器只有收到该 ACK，才确认客户端是 "有效状态"，避免上述无效连接的资源浪费，是 TCP 协议应对网络不可靠的关键设计。

二、TCP 四次挥手 交互流程图（客户端主动关闭）

说明：

X = 客户端最后一次发数据的序列号 + 1，

Y = 服务器最后一次发数据的序列号 + 1，

Z = 服务器处理完数据后最后一次序列号 + 1；

核心标志位 FIN（发起断开）、ACK（确认接收）；

TIME_WAIT 持续2MSL（最长报文段寿命，默认 2 分钟），CLOSE_WAIT 为服务器处理剩余数据的状态。

• 客户端的TIME_WAIT状态 （最核心的特殊状态）

客户端发送第 4 次挥手的 ACK 后，不会立即进入 CLOSED，而是进入TIME_WAIT 状态，持续时间为2MSL（最长报文段寿命，通常为 2×1 分钟 = 2 分钟） ，这是 TCP 协议的关键设计，目的有两个：

1.保证最后一个 ACK 报文能到达服务器 ：若第 4 次挥手的 ACK 报文因网络丢失，服务器会超时重传 FIN 报文，客户端在 TIME_WAIT 状态下能收到该重传的 FIN，重新发送 ACK，避免服务器一直处于 LAST_ACK 状态；

2.避免滞留的旧报文干扰新连接：网络中可能存在本次连接的滞留报文，2MSL 的时间足够让所有滞留报文从网络中消失，客户端后续在相同端口建立新连接时，不会收到旧连接的滞留报文。

• 服务器的CLOSE_WAIT状态异常

若服务器长期处于CLOSE_WAIT状态 ，说明服务器的应用层未调用关闭接口 （如未执行 close ()），导致 TCP 层无法发起第 3 次挥手的 FIN 报文，属于应用层程序问题，会造成服务器端口资源被占用。

• 双向同时主动关闭

若客户端和服务器同时发起 FIN 关闭请求，双方会同时从 ESTABLISHED→FIN_WAIT_1，收到对方的 FIN 后，同时回复 ACK 并进入CLOSING状态 ，而非 FIN_WAIT_2/CLOSE_WAIT，收到对方的 ACK 后，双方同时进入 TIME_WAIT 状态，最终等待 2MSL 后关闭，本质仍是四次挥手，只是报文交互是同时进行的。

TCP 是面向连接的可靠传输协议，四次挥手（Four-way Wavehandshake）是 TCP 断开连接的标准流程，保证通信双方所有数据都传输完毕

核心目的

TCP 是全双工通信 （双方可同时发送和接收数据），断开连接时需保证双方均无数据要发送，因此需要双向分别发起断开请求，各自确认后，连接才正式关闭，类似 "打电话双方都说完了，互相确认后再挂电话"。

整体前提

1. 双方均处于ESTABLISHED 状态，数据传输完成；
   2.任意一方可主动发起断开请求（通常是客户端 ），称为主动关闭方 ，另一方为被动关闭方 ；
   3.核心标志位FIN=1 表示 "本方无数据发送，请求关闭本方向的连接"，TCP 全双工特性决定了两个方向的连接需要分别关闭。

分步解释（以客户端主动关闭、服务器被动关闭为例）

第 1 次挥手 ：客户端 → 服务器，发起关闭连接请求

发送方 ：客户端（主动关闭方），状态从ESTABLISHED→FIN_WAIT_1（终止等待 1）
报文标志 ：FIN=1，ACK=1 （TCP 报文默认携带 ACK=1，除非是首次 SYN 报文）
关键字段 ：

1.序列号Seq=X （X 为客户端最后一次发送数据的序列号 + 1，若未发送数据则为 ISN_C+1）

2.确认号Ack=Y （Y 为服务器最后一次发送数据的序列号 + 1，确认已收到服务器所有数据）
核心作用 ：客户端向服务器发送 "我已无数据要发送，请求关闭客户端→服务器方向的连接 ，请你确认"。
服务器行为 ：收到 FIN 报文后，确认客户端无数据发送，先回复 ACK 确认报文，状态从ESTABLISHED→CLOSE_WAIT（关闭等待），同时通知应用层 "客户端要断开连接，你处理完剩余数据后告知我"。

第 2 次挥手 ：服务器 → 客户端，确认客户端的关闭请求

发送方 ：服务器（被动关闭方），状态保持CLOSE_WAIT
报文标志 ：ACK=1，FIN=0 （仅确认，未发起自身的关闭请求）
关键字段 ：

1.确认号Ack=X+1 （表示已收到客户端 Seq=X 的 FIN 报文，确认关闭客户端→服务器方向的连接）

2.序列号Seq=Y （服务器最后一次发送数据的序列号 + 1）
核心作用 ：服务器向客户端回复 "我收到了你的关闭请求，已确认关闭客户端→服务器方向的连接，请你等待我处理完剩余数据，我会再发起我的关闭请求"。
客户端行为 ：收到 ACK 报文后，确认客户端→服务器方向的连接已关闭，状态从FIN_WAIT_1→FIN_WAIT_2 （终止等待 2），等待服务器的 FIN 报文（即服务器处理完数据后的关闭请求）。

第 3 次挥手 ：服务器 → 客户端，发起自身的关闭连接请求

发送方 ：服务器（被动关闭方），应用层处理完所有数据后，通知 TCP 层发起关闭，状态从CLOSE_WAIT→LAST_ACK（最后确认）
报文标志 ：FIN=1，ACK=1
关键字段 ：

1.序列号Seq=Z （Z 为服务器最后一次发送数据的序列号 + 1，若第 2 次挥手后无数据发送则为 Y）

2.确认号Ack=X+1 （重复确认客户端的 FIN 报文，确保客户端收到）
核心作用 ：服务器向客户端发送 "我已处理完所有数据，无数据要发送了，请求关闭服务器→客户端方向的连接，请你确认"。
客户端行为 ：收到 FIN 报文后，确认服务器无数据发送，先回复 ACK 确认报文，状态从FIN_WAIT_2→TIME_WAIT（时间等待） （TCP 最关键的状态之一）。

第 4 次挥手 ：客户端 → 服务器，确认服务器的关闭请求

发送方 ：客户端（主动关闭方），状态保持TIME_WAIT
报文标志 ：ACK=1，FIN=0
关键字段 ：

1.确认号Ack=Z+1 （表示已收到服务器 Seq=Z 的 FIN 报文，确认关闭服务器→客户端方向的连接）

2.序列号Seq=X+1 （遵循序列号规则，上一次发送的是 X，本次自增 1）
核心作用 ：客户端向服务器回复 "我收到了你的关闭请求，已确认关闭服务器→客户端方向的连接，双方所有方向的连接均关闭"。
服务器行为：收到 ACK 报文后，确认所有连接均关闭，状态从LAST_ACK→CLOSED（关闭），服务器的 TCP 连接正式结束。

状态变化表

为什么需要四次挥手？

本质是 TCP 的「全双工通信」特性 ：TCP 允许双方同时发送和接收数据，因此连接是双向的（客户端→服务器、服务器→客户端），断开时需要分别关闭每个方向的连接。

1.三次握手时，服务器可在确认客户端 SYN 的同时发起自身的 SYN （第 2 次握手 SYN+ACK 合为一个报文）；

2.四次挥手时，服务器收到客户端的 FIN 后，无法立即发起自身的 FIN（因为服务器可能还有未传输完的数据），只能先回复 ACK 确认关闭一个方向，等数据传输完毕后，再单独发起 FIN 关闭另一个方向，因此需要四次报文交互。

三次握手与四次挥手对比

总结

1.三次握手和四次挥手是 TCP 面向连接 的核心体现，前者为数据传输做准备 ，后者为数据传输收尾 ，共同保证 TCP 连接的可靠性；

2.三次握手的关键是确认双向收发能力 ，三次是兼顾可靠性和效率的最优选择，两次会导致无效连接，四次则多余；

3.四次挥手的关键是适配 TCP 全双工特性 ，四次是必然结果，因服务器无法在确认 FIN 的同时立即发起 FIN；

4.TIME_WAIT 是 TCP 协议应对网络不可靠 的关键设计，虽会占用端口资源，但能避免旧报文干扰和 ACK 丢失问题；

5.握手和挥手的所有报文交互，均遵循 TCP 序列号和确认号规则：确认号 = 对方序列号 + 1，本次序列号 = 上一次发送的序列号 + 1（无数据时）。

UDP（用户数据报文协议）

1.特性：非面向连接、不可靠 ，仅完成分段和端口号，低开销、尽力传递

2.常用端口：69 (TFTP)、53 (UDP-DNS)、67/68 (DHCP)

3.适用场景：视频流、IP 语音、域名解析等对实时性要求高于可靠性的场景

TCP 与 UDP 协议核心区别（详细解释）

TCP（传输控制协议）和 UDP（用户数据报协议）是传输层的两大核心协议，二者均完成数据分段、端口号标识 的基础传输层工作，但在连接性、可靠性、传输效率、适用场景等 方面存在本质差异，TCP 主打可靠的面向连接传输 ，UDP 主打高效的无连接传输

一、核心连接特性差异

1. TCP：面向连接

TCP 在数据传输前，必须通过三次握手建立端到端的虚链路，传输完成后需通过四次挥手正常断开连接，整个过程遵循「建立连接→数据传输→断开连接」的固定流程，类似现实中的 "打电话"（先拨号接通，再通话，最后挂电话）。

三次握手：客户端发起 SYN 包→服务器回复 SYN+ACK 包→客户端回复 ACK 包，确认双方收发能力正常，连接建立。

四次挥手：主动方发起 FIN 包→被动方回复 ACK 包（确认收到断开请求）→被动方数据传输完成后发起 FIN 包→主动方回复 ACK 包，连接正式断开。

特殊标志位：RST（连接异常时强制重连）、PSH（加急接收数据）、URG（标记紧急数据指针）。

2. UDP：无连接

UDP 无需提前建立连接，也无需在传输后断开连接，发送方直接将数据封装为UDP 数据段，通过网络发送至目标端口即可，接收方收到后无需给出确认回复，类似现实中的 "寄信"（直接投递，无需确认对方是否收到）。

无握手 / 挥手流程，数据传输前无任何准备工作，传输后无后续收尾操作。

发送方不感知接收方的存在、在线状态及接收能力，仅负责 "尽力发送"。

二、可靠性与传输机制差异

TCP 和 UDP 最核心的区别，TCP 为实现可靠性牺牲了部分效率，UDP 为保证效率舍弃了可靠性。

1. TCP：可靠传输，具备 4 大可靠机制

TCP 通过确认、重传、排序、流控（窗口滑动） 四大机制，确保数据无丢失、无重复、按序到达，是可靠的字节流传输协议。

1.确认：接收方收到数据后，必须向发送方返回ACK 确认包，发送方只有收到确认，才会继续发送后续数据；

2.重传：若发送方在指定时间内未收到 ACK 包，判定数据丢失，自动重传该数据段；

3.排序：TCP 为每个数据段分配序列号，接收方按序列号重组数据，解决网络中数据乱序问题；

4.流控（窗口滑动）：接收方通过窗口大小告知发送方自身的接收缓存剩余空间，发送方根据窗口大小调整发送速率，避免接收方因缓存满导致数据丢失。

此外，TCP 还具备拥塞控制能力（基于网络拥塞程度调整发送速率），进一步提升传输可靠性。

2. UDP：不可靠传输，无可靠机制

UDP 仅完成数据分段和端口号标识，无任何可靠性保障机制，数据传输过程中可能出现丢失、重复、乱序，且发送方无法感知。

1.无 ACK 确认，接收方收到数据后不回复，发送方不知道数据是否到达；

2.无重传机制，数据丢失后不会自动补发；

3.无序列号排序，乱序到达的数据不会被重组，直接交付给应用层；

4.无流控 / 拥塞控制，发送方按自身速率发送，不考虑接收方能力和网络状况。

UDP 的 "不可靠" 是协议层面 的设计，而非传输故障，其仅做 "尽力传递"，不保证数据一定到达。

三、数据封装与头部结构差异

二者的协议头部结构决定了数据封装的复杂度和开销，头部越复杂，开销越大，传输效率越低。

1. TCP 头部：复杂，固定 20 字节（可扩展）

TCP 头部包含源端口、目的端口、序列号、确认号、报头长度、代码位、窗口大小、校验和、紧急指针 等字段，部分字段可根据需求扩展，固定开销 20 字节，复杂的头部为其可靠机制提供了支撑。

核心关键字段：序列号（32 位）、确认号（32 位）、窗口大小（16 位）、代码位（6 位，包含 SYN/ACK/FIN 等标志）。

2. UDP 头部：简单，固定 8 字节

UDP 头部仅包含源端口、目的端口、数据长度、校验和 4 个字段，固定开销 8 字节，无多余字段，封装和解封装速度极快，传输开销远低于 TCP。

校验和为可选字段（部分场景可关闭），进一步降低开销。

四、传输效率与延迟差异

传输效率和延迟由连接开销、头部开销、可靠性机制共同决定，UDP 的传输效率远高于 TCP，延迟远低于 TCP。

1. TCP：效率低，延迟高

1.连接开销 ：三次握手 + 四次挥手带来额外的网络交互，增加了建立连接的延迟 （尤其是短连接场景，连接开销占比极高）；

2.头部开销 ：20 字节的固定头部，比 UDP 多 12 字节，大文件传输时累计开销显著；

3.可靠性机制开销 ：ACK 确认、重传、排序、流控等机制需要额外的网络交互和计算资源，导致数据传输延迟增加，且部分带宽被用于传输确认包。

2. UDP：效率高，延迟低

1.无连接开销 ：无需握手 / 挥手，直接发送数据，无建立连接的延迟，短连接场景优势极致；

2.头部开销小 ：8 字节头部，封装 / 解封装速度快，网络带宽利用率高；

3.无可靠性机制开销 ：无 ACK 确认、重传等额外交互，数据发送后无需等待，端到端延迟极低，且无带宽浪费。

五、数据传输模式差异

1. TCP：字节流传输，无数据边界

TCP 将应用层数据视为连续的字节流 ，无固定的数据边界，发送方会根据MSS（TCP 最大分段长度） 拆分数据，接收方按字节流重组，应用层读取数据时无需按固定包大小读取，由 TCP 保证数据的连续性。

特点：适合大量、连续的数据传输，如文件、文本等。

2. UDP：数据报传输，有明确数据边界

UDP 以数据报 为单位传输，每个 UDP 数据段是一个独立的数据包，发送方发送一个数据报，接收方就收到一个数据报，保留数据边界，应用层读取数据时需按固定的数据包大小读取。

特点：适合小数据包、独立报文的传输，如心跳包、查询请求等。

六、端口与连接标识差异

1. TCP：单端口可建立多个连接

TCP 的连接由源 IP、源端口、目的 IP、目的端口 四元组唯一标识，因此同一个目的端口可同时接受多个客户端的连接（如 Web 服务器的 80 端口，可同时为多个浏览器提供服务），每个连接对应一个独立的四元组。

2. UDP：单端口无连接概念，仅标识报文

UDP 无连接概念，端口仅用于标识应用层进程，同一个 UDP 端口可接收来自任意 IP 的任意数据报，无需区分不同的 "连接"，仅通过端口将数据交付给对应的应用层进程。

七、适用场景差异

二者的设计特性决定了其适用场景的截然不同，TCP 适合对可靠性要求高、对延迟 / 效率要求低的场景，UDP 适合对延迟 / 效率要求高、对可靠性要求低的场景，或由应用层实现可靠性的场景。

1. TCP 的典型适用场景

所有需要保证数据完整、按序到达 的场景，核心 是 "数据不能丢、不能乱"，即使牺牲一定效率和延迟：

1.网页浏览（HTTP/HTTPS）：端口 80（HTTP）、443（HTTPS），确保网页内容完整加载；

2.文件传输（FTP）：端口 20/21，确保文件无丢失、无损坏；

3.远程登录（Telnet/SSH）：端口 23（Telnet）、22（SSH），确保指令和反馈按序传输；

4.电子邮件（SMTP/POP3/IMAP）：确保邮件完整发送和接收；

5.数据库交互：确保数据库指令和数据的可靠传输。

2. UDP 的典型适用场景

所有需要低延迟、高传输效率的场景，核心是 "实时性优先，允许少量数据丢失"，或应用层可自行实现可靠性的场景：

1.域名解析（DNS）：端口 53，UDP 为主（TCP 为辅），解析请求为小数据包，对实时性要求高，少量丢失可重新请求；

2.动态主机配置（DHCP）：端口 67/68，快速分配 IP 地址，实时性优先；

3.音视频流（直播、视频通话）：如抖音、微信视频，允许少量帧丢失，但若延迟过高会导致卡顿，UDP 是最优选择；

4.IP 语音（VoIP）：如网络电话，对延迟敏感，少量数据包丢失不影响通话理解；

5.游戏通信：如网络游戏的操作指令，实时性要求极高，允许少量指令丢失，避免卡顿；

6.广播 / 组播：UDP 天然支持广播和组播，TCP 仅支持单播。

八、TCP 与 UDP 汇总表

九、补充：TCP 分段与 UDP 的 IP 分片

二者均会遇到 "数据过大" 的问题，但处理方式不同，且均与MTU（最大传输单元，默认 1500 字节） 相关：

TCP 分段 ：TCP 根据MSS（最大分段长度，MSS=MTU-IP 头部 - TCP 头部） 在发送方提前将大数据拆分为小分段，分段后在接收方按序列号重组，避免 IP 分片 ，效率更高；
UDP IP 分片：UDP 无分段机制，若数据报超过 MTU，由网络层（IP）在传输过程中分片，接收方由 IP 层重组，若其中一个分片丢失，整个 UDP 数据报作废，可靠性更低。

十、TCP/UDP总结

1.TCP 是可靠的面向连接协议 ，通过复杂的机制保证数据传输的完整性和有序性，适合对数据可靠性要求高的场景，是互联网中最基础的可靠传输协议；

2.UDP 是高效的无连接协议 ，舍弃可靠性以换取低延迟和高传输效率，适合对实时性要求高的场景，是音视频、游戏、广播等场景的最优选择；

3.二者无 "优劣之分"，仅为不同设计目标 的产物，实际网络中二者互补，共同支撑互联网的各类应用（如 DNS 同时支持 UDP 和 TCP，小请求用 UDP，大请求用 TCP）；

4.若需要 "UDP 的效率 + TCP 的可靠性"，可由应用层实现可靠性机制（如自定义确认、重传、排序），这是很多高性能应用的常用方案（如网络游戏、直播平台）。

4. 网络层核心协议

IPv4 地址

1.构成：32 位二进制，点分十进制 表示，8 位一组，分网络位（标识网段）和主机位（标识主机）

2.子网掩码：连续 1 + 连续 0 构成，用于区分网络位 / 主机位（如 255.255.255.0/24）

3.地址分类：

A 类：1-126，网络位 8 位，掩码 255.0.0.0

B 类：128-191，网络位 16 位，掩码 255.255.0.0

C 类：192-223，网络位 24 位，掩码 255.255.255.0

D 类：224-239（组播，仅作目标 IP）

E 类：240-255（保留）

4.特殊地址：

127.0.0.1（环回地址）

255.255.255.255（受限广播）

0.0.0.0（无 / 所有地址）

169.254.0.0/16（本地链路地址）

ARP（地址解析协议）

1.功能：通过 IP 地址获取 MAC 地址

2.工作原理：广播发送请求包 → 所有设备记录源 IP-MAC 映射 → 目标设备单播回复

3.缓存老化时间：180s

4.免费 ARP：验证 IP 冲突、检测网卡更换

二、网络设备与工作原理

1. 物理层设备

1.中继器 ：放大电信号，延长传输距离，解决信号衰减（波形易失真）

2.集线器（HUB）：多端口中继器，共享带宽，所有节点同一冲突域，存在资源占用、冲突、安全问题

2. 数据链路层设备（二层设备）

交换机 （由网桥发展而来）

1.工作层：介质访问控制层，识别MAC 地址 （48 位二进制，16 进制显示，全球唯一）

2.工作原理：

1.学习：记录源 MAC 与入接口的映射，存入 MAC 地址表（老化时间 300s）

2.转发：查询目标 MAC，存在则单播 ，不存在则泛洪（向入接口外所有接口发送）

3.核心优势：隔离冲突域，支持多节点同时通信，单播传输，提高端口密度

4.速率公式：实际速率≈(带宽 / 8)×85%（1 字节 = 8 位二进制，1024 字节 = 1KB）

3. 网络层设备（三层设备）

路由器

1.工作层：网络层，识别IP 地址 ，核心实现全网互联

2.核心特性：每个接口是 ** 广播域（泛洪范围）** 边界，隔离广播域

3.工作原理：

1.PC 判断目标 IP 是否在同一广播域：

是→ARP 获取 MAC 单播通信

否→将目标 MAC 改为网关 MAC，转发至路由器

2.路由器接收数据包后，查询路由表：有记录则转发，无记录则丢弃

4.关键：路由表是路由器转发的核心依据（静态路由核心为手动配置路由表）

三、子网划分与汇总（静态路由前置核心）

1. 子网划分（VLSM，可变长子网掩码）

1.核心：借主机位作网络位 ，将一个大网段划分为多个小网段，提高 IP 利用率

2.计算规则：

1.确定借位数，计算子网数：2^ 借位数

2.确定每个子网的主机数：2^ 剩余主机位 - 2（排除网络位全 0 / 全 1）

3.示例：192.168.1.0/24（C 类，256 主机）

借 1 位（/25）：2 个子网，每个 126 主机（192.168.1.0/25、192.168.1.128/25）

借 2 位（/26）：4 个子网，每个 62 主机（0/26、64/26、128/26、192/26）
172.16.0.0/15 划分为4 个网段 并写出每个网段的可用主 机数
172.0000100 0.0 0000000.00000000

172.16.0.1/17---------172.16.127.254/17
172.0000100 0.1 0000000.00000000

172.16.128.1/17-------172.16.255.254/17
172.0000100 1.0 0000000.00000000

172.17.0.1/17--------172.17.127.254/17
172.0000100 1.1 0000000.00000000

172.17.128.1/17--------172.17.255.254/17

2. 子网汇总（CIDR，无类域间路由）

1.核心原则：取相同位，去不同位

2.步骤：

1.将所有网段转换为 32 位二进制

2.从左到右取连续的相同二进制位，计数为掩码位数

3.将相同位还原为十进制，即为汇总网段

3.示例：

192.168.0.0/24 192.168.00000000.00000000

192.168.1.0/24 192.168.00000001.00000000

192.168.2.0/24 192.168.00000010.00000000

192.168.3.0/24 192.168.00000011.00000000

CIDR=192.168.0.0/22

3. 网段判断核心

1.网络位全 0：代表网段 ，不可配置为主机 IP（如 192.168.1.0/24）

2.主机位范围：网段第一个 IP（网络位全 0）→ 最后一个 IP（主机位全 1，直接广播地址）

3.可用主机 IP：网段 IP+1 → 直接广播地址 - 1（如 192.168.1.0/24，可用 192.168.1.1-254）

四、华为设备基础配置命令

1. 视图切换

2. 基础配置命令

1.更改设备名称：[Huawei]sysname 设备名（如 [Huawei] sysname R1）

2.配置接口 IP：[R1-G0/0/0]ip address IP地址 子网掩码（简写：ip add 192.168.1.1 24）

3.查看接口状态：<R1>display ip interface brief（核心：物理 + 协议双 UP 才可用）

4.查看当前配置：[R1]display current-configuration（缓存配置，关机消失）

5.保存配置：<R1>save（保存至闪存 Flash，关机不消失）

6.查看保存配置：<R1>display saved-configuration

7.删除配置：[配置视图]undo 原配置命令（在哪配在哪删，如 undo ip address）

8.查看当前视图配置：[任意视图]display this

9.命令补全：按Tab键；

10.查看可执行命令：[视图]?

3. DHCP 基础配置

[R1]dhcp enable                  // 全局开启DHCP服务
[R1]ip pool AA                   // 创建地址池AA
[R1-ip-pool-AA]network 192.168.1.0 mask 24  // 定义地址池网段
[R1-ip-pool-AA]gateway-list 192.168.1.1     // 定义网关
[R1-ip-pool-AA]dns-list 114.114.114.114 8.8.8.8  // 定义DNS
[R1-G0/0/0]dhcp select global    // 接口调用全局DHCP配置

什么是DNS 与 DHCP

一、DNS（域名解析协议）

• 传输层与端口：基于 UDP（默认）/TCP ，使用 53 端口
• 架构：典型 C/S 架构（客户端 ↔ 服务器）
• 核心功能：实现域名 ↔ IP 地址 的互相映射

两种解析方向 ：

1.正向解析 ：根据主机名 / 域名 → 查找对应 IP 地址 （最常用，比如输入www.baidu.com找到服务器 IP）

2.反向解析 ：根据 IP 地址 → 查找对应 主机名 / 域名（用于日志溯源、反向验证等场景）

二、DHCP（动态主机配置协议）

• 传输层与端口：基于 UDP ，服务器 端口 67 ，客户端 端口 68
• 架构：典型 C/S 架构

• 客户端：需要获取 IP 地址的设备（如 PC、手机）
• 服务器：负责分配 IP 地址、子网掩码、网关、DNS 等网络参数

1. 首次获取 IP 地址

2. 再次获取 IP 地址

客户端之前已经获取过 IP，再次上线时流程简化为 2 步：

• 客户端直接发送 DHCP Request 包
• 服务器回复 DHCP ACK 包，直接续租 / 分配原 IP

3. 异常情况（原 IP 被占用）

• 客户端发送 DHCP Request 包请求原 IP
• 服务器回复 DHCP NAK 包（拒绝），告知原 IP 已分配给其他设备，客户端需重新走 Discover 流程获取新 IP

4. 租期与续租机制

默认租期 ：24 小时
续租触发点：

• T1（租期 50%，12h）：客户端向服务器单播发送 Request 包，请求续租
• T2（租期 87.5%，21h）：若 T1 未得到响应，客户端广播发送 Request 包，尝试向任意 DHCP 服务器续租

若租期结束仍未续租成功，客户端必须释放当前 IP，重新发起 Discover 流程

三、举例说明

DNS ：网络的 "电话本"

• 就像查电话本：域名是人名，IP 是电话号码，DNS 帮你把人名翻译成号码，方便找到对方。
• 正向解析是 "按人名查号码"，反向解析是 "按号码查人名"。

DHCP ：网络的 "临时房东"

• DHCP 服务器就像房东，负责给设备（租客）分配 IP 地址（房间号），不用手动配置。
• 首次租房要走完整流程（看房→选房→签合同→拿钥匙），再次租房直接续租；如果原房间被占了，就换个新房间。
• 租期机制保证 IP 地址能被循环利用，避免资源浪费。

四、DNS 与 DHCP对比表

五、网络通信核心规则（静态路由理解基础）

1.同一广播域 ：PC 通过 ARP 协议获取目标 MAC 地址，直接单播通信，无需路由器

2.不同广播域 ：PC 将数据包发送至网关 （路由器接口），由路由器通过路由表转发

3.TTL（生存周期） ：数据包每经过一个路由器 TTL-1，值为 0 时丢弃，防止环路（默认 64/128，最大 255）

4.MTU/MSS ：MTU（最大传输单元，默认 1500）限制二层帧大小，超则 IP 分片；MSS（TCP 最大分段长度）为 MTU - 报文头，超则 TCP 分段

5.冲突域 / 广播域：

冲突域：同一物理介质，多节点同时发送会冲突（集线器属于同一冲突域，交换机隔离冲突域）

广播域：广播包能到达的范围（交换机不隔离广播域，路由器隔离广播域）

六、网络拓扑基础

1.总线型（直线型） ：所有节点接同一总线，单点故障全网瘫痪

2.环形 ：节点首尾相连，单向 / 双向传输，故障检测复杂

3.星型 ：以集线器 / 交换机为中心，单点故障仅影响本节点，目前最常用

4.树状 ：星型拓扑的层级扩展，适用于大型网络

5.全网状（波环型） ：所有节点两两相连，可靠性最高，成本最高