HCIA--网络体系结构

原创已于 2025-07-25 19:48:33 修改 · 991 阅读

15 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#网络

于 2025-07-23 17:53:27 首次发布

HCIA 专栏收录该内容

7 篇文章

订阅专栏

OSI

官方：OSI参考模型--1979--网络的行规--互联网统一的标准和体系

民间：OSI七层参考模型

分层

核心思想：分层：属于同一层次的协议设备具备相同或者相似的功能，不同层次的协议功能有明显的区别

作用↘

更利于标准化
降低层次之间的关联性：每一层都在下层的基础上提供增值服务
利用网络的发展（方便学习）

👉上三层是开发者考虑，网络主要研究中间三层

应用层---七层：各种应用程序APP的集合，提供人机交互的窗口

表示层---六层：利用编码表统一编码格式，将人类传递的参数命令转换为二进制

会话层---五层：可以建立维护和断开一次会话通讯

会话（点开应用的一瞬间）：建立主机和目标服务器（目标设备）之间的一条逻辑通道。

服务器此时是中转

特殊需求是可以不需要服务器，例如信息不公开时，不采用服务器

通讯：通过数据包/数据报文来传递

传输层---四层：提供端到端的传输（官方）

简单来说，就是用来区分应用和服务/进程，提供应用到应用之间的数据传输

传输地址---端口号：16位二进制（0-65535），0作为保留，实际能够使用的端口号范围是1-65535

互联网规定，其中1-1023作为知名（著名）端口号

例如：

⭐HTTP（超文本传输协议）:80端口

HTTPS:443 （在 HTTP 的基础上增加了 SSL/TLS 加密层，确保数据在传输过程中不会被窃听或篡改）

FTP（文件传输协议）：20/21

Telent（远程登陆协议）：23

SSH（安全的远程登陆协议）：22

DHCP（地址解析协议）:67/68

DNS（域名解析协议）:53 （用来获取目标IP地址）

POP3用来发邮件

网络层（路由器）---三层：利用IP地址进行逻辑寻址--路由（路线）

数据链路层（交换机）---二层：包含MAC--介质访问控制层

LLC--逻辑链路控制层

部分功能：利用MAC地址进行物理寻址
IP：负责没有直连的两个网络之间进行通信传输

物理层（中继器，集线器）---一层：介质

ISO

国际公有化组织

TCP/IP参考模型

前身：TCP/IP协议簇（互联网使用的参考模型）

从原理上出发，我们会以对等模型来讲

PDU：协议数据单元

👉应用层数据：数据报文

传输层：数据段

网络层：数据包

数据链路层：数据帧

物理层：比特流/数据信号

封装与解封装

数据转换→封装与解封装

封装

封装：每一层都把上层产生的协议数据当作自身的数据部分，加上自身的功能数据组成一个新的数据单元，这个过程被称为封装（封装特指的是应用层➡数据链路层的过程，物理层仅传输不需要封装功能数据）

协议号和类型字段是用于标识封装数据包中上层协议的关键标识符

解封装

还原原始数据的过程

每一层接收到数据之后，会检查目标地址是否是自身，如果是自身那么会解开当前层次的协议报头，之后继续向上层解封装。

应用层

协议不同，封装的内容不同

封装只是一个动作，正在完成封装的是作用在本层的协议

HTTP:80端口

HTTPS:443

FTP（文件传输协议）：20/21

Telent（远程登陆协议）：23

SSH（安全的远程登陆协议）：22

DHCP（地址解析协议）:67/68

DNS（域名解析协议）:53 （用来获取目标IP地址）

传输层：TCP UDP

必须支持端到端的传输

TCP:传输控制协议

应用场景：传输效率低，但是对传输可靠性要求很高的场景。例如传输网页数据，邮件，文件等等

TCP的报文头部：

1字节=8位二进制

数据：指的是应用层传下来的原始数据

序号：数据的编号确认序号：首部长度、头部长度、可变长头部 20-60字节

URG：紧急指针标志位，如果该标志位置1，则激活紧急指针字段

ACK：确认标记，该标志位置1，激活确认序号

PSH：紧急推送标志位

TCP可以将一个完整的数据分成多个段，为了保证数据的完整性，连续性，所以对端会有一个缓存空间先去接收，把所有的数据段接收完整后，推给进程，如果某个数据段的PSH标志位置1，则不再进入缓存空间，直接推给进程

RST:非正常断开。例如：打开一个未加载好的网页时关掉、上传文件时电脑突然关掉。

SYN：请求建立连接，在三次握手时，建立连接的时候，该标志位会置1 FIN：断开连接的标志，数据发完，就可以断开自己的会话了，此时的FIN标志位会置1

校验和（校验能力强）：校验数据的完整性

三次握手

在第三次的时候，会携带数据，一般不讨论

目的：建立可靠的双向连接，同步双方的初始序列号（ISN）。

过程：

SYN（Client → Server）

客户端发送 SYN=1（同步标志），并携带自己的初始序列号 seq=x。

状态：客户端进入 SYN_SENT，服务端仍为 LISTEN。

SYN-ACK（Server → Client）

服务端确认客户端的 SYN，回复 SYN=1 和 ACK=1，携带自己的初始序列号 seq=y，并确认 ack=x+1。

状态：服务端进入 SYN_RCVD，客户端仍为 SYN_SENT。

ACK（Client → Server）

客户端确认服务端的 SYN，发送 ACK=1，确认号 ack=y+1（seq=x+1）。

状态：双方进入 ESTABLISHED，连接建立。

⭐为什么是三次握手？

确保双方都能发送和接收数据（防止历史连接干扰）。

两次握手可能导致服务端误认为连接已建立（客户端无响应时，服务端资源浪费）。

四次挥手

目的：安全关闭双向连接，确保数据完整传输。

过程：

FIN（Client → Server）

客户端发送 FIN=1（终止标志），携带 seq=u，表示不再发送数据。

状态：客户端进入 FIN_WAIT_1，服务端仍为 ESTABLISHED。

ACK（Server → Client）

服务端收到 FIN，回复 ACK=1，确认 ack=u+1（seq=v）。

状态：服务端进入 CLOSE_WAIT，客户端进入 FIN_WAIT_2（半关闭状态）。

FIN（Server → Client）

服务端处理完剩余数据后，发送 FIN=1，携带 seq=w（可能携带 ACK=1，ack=u+1）。

状态：服务端进入 LAST_ACK，客户端仍为 FIN_WAIT_2。

ACK（Client → Server）

客户端确认服务端的 FIN，发送 ACK=1，确认 ack=w+1（seq=u+1）。

状态：客户端进入 TIME_WAIT（等待 2MSL 后关闭），服务端直接关闭。

⭐为什么是四次挥手？

TCP 是全双工的，FIN 和 ACK 必须分开发送：

客户端 FIN 表示不再发送数据，但还能接收。

服务端 ACK 仅确认客户端的 FIN，可能仍有数据要发送。

服务端 FIN 表示自己也不再发送数据。

客户端 ACK 确保服务端能安全关闭。

⭐为什么需要 TIME_WAIT？

防止最后一个 ACK 丢失（服务端会重传 FIN）。

让网络中残留的旧数据包失效（避免影响新连接）。

UDP:用户数据协议

应用场景：传输效率高，但是对传输可靠性要求一般的场景。例如所有的即时通讯。

UDP的头部：

不同点

①TCP是面向连接的协议，UDP是无连接的协议

❓TCP为什么要面向连接？？？

👉TCP 面向连接是为了通过三次握手建立可靠通道，四次挥手安全释放，确保数据传输可控、不丢失、不乱序

②TCP的传输是可靠的，而UDP的传输是不可靠的（尽力而为型转发）

可靠型机制：排序确认流控重传

排序

每个数据段都有序列号，接收方根据序列号重组乱序到达的数据，确保数据按正确顺序交付给应用层。

确认

接收方通过ACK（确认号）告知发送方已成功接收的数据范围（累积确认）。若未收到ACK，发送方会触发重传。

流控

通过滑动窗口机制动态调整发送速率：接收方在ACK中通告当前可用缓冲区大小（窗口大小），防止发送方过载导致丢包。

重传

超时重传：发送方未收到ACK时，在超时后重传数据。

快速重传：收到3次重复ACK时立即重传（无需等待超时），提升效率。

总结：TCP 通过排序和确认保证数据完整有序，流控避免拥塞，重传机制应对丢包，最终实现可靠传输。

③TCP可以进行流控，UDP不能

TCP使用滑动窗口机制，做到一次确实同时发送多段数据

1. TCP 的流控

实现方式：

滑动窗口机制（有WIN值，0-65535）：

接收方通过 ACK 报文中的窗口字段 告知发送方自己的剩余缓冲区大小。

发送方根据窗口大小动态调整发送速率，避免接收方缓冲区溢出。

特点： ✅ 可靠：确保数据不会因接收方处理不及而丢失。 ✅ 自适应：窗口大小动态变化，适应接收方的处理能力。

示例：
接收方: "我的缓冲区只剩100字节了！"  
发送方: "好的，我只发100字节，等你ACK再继续。"  
2. UDP 无流控

原因：

UDP 是无连接、不可靠的协议，设计目标是低延迟、高效率，不保证数据完整性。

无滑动窗口：发送方无法感知接收方的缓冲区状态。

无ACK机制：接收方不会反馈是否收到数据。

问题： ❌ 可能丢包：如果接收方缓冲区满，新到的UDP数据包会被直接丢弃。 ❌ 无速率调整：发送方会持续以固定速率发送，可能淹没接收方。

示例：
发送方: "疯狂发送数据！"  
接收方: （缓冲区爆炸）"装不下了，直接丢包！"  
❓为什么 UDP 不实现流控？

设计哲学不同：UDP 追求简单高效，牺牲可靠性换取速度。

应用层可自定义：如需流控，可由应用层协议（如QUIC）实现，但非UDP原生支持。

总结： TCP 的流控是内置的“刹车系统”，UDP 则是“油门焊死”，全速前进，不管接收方是否接得住！

④TCP可以进行分段，UDP不能

❓为什么需要分段？ TCP 是面向字节流的协议，应用层数据可能非常大（比如一个大文件），而网络层（IP）有 MTU（最大传输单元） 限制（如以太网默认 1500 字节）。因此，TCP 必须将数据分段以适应网络传输。

❓如何实现分段？

TCP 在发送数据时，会根据 MSS（最大报文段长度） 自动拆分数据。

MSS = MTU - IP头（20字节） - TCP头（20字节）

例如，以太网 MTU=1500，MSS=1460 字节。

接收方根据 序列号 重组数据，恢复原始字节流。
应用层数据（3000字节）  
→ TCP 分段：[1460][1460][80]（假设 MSS=1460）  
→ IP 层封装后发送。  
特点： ✅ 自动分段：TCP 协议栈自动处理，对应用透明。 ✅ 可靠重组：接收方确保数据顺序正确。

❓为什么 UDP 不分段？ UDP 是 面向报文 的协议，每个 UDP 报文都是独立的，不会像 TCP 那样维护字节流状态。

UDP 本身不提供分段机制，而是依赖 IP 层分片（如果数据超过 MTU）。

IP 分片的问题：

效率低：分片和重组消耗 CPU 资源。

可靠性差：若任一分片丢失，整个 UDP 报文失效（UDP 无重传）。

UDP 对应用层的要求：

应用必须自己控制报文大小（通常 ≤ MTU - IP头 - UDP头 = 1500 - 20 - 8 = 1472 字节）。

如果发送超过 MTU 的 UDP 报文：

本地分片：由 IP 层拆分（不推荐，可能被防火墙丢弃）。

直接丢弃：某些系统会返回 EMSGSIZE 错误。

示例：
应用层发送 2000 字节 UDP 报文  
→ IP 层分片：[1480][520]（假设 MTU=1500）  
→ 若第二个分片丢失，整个 UDP 报文无效。  
TCP 分段：可靠、自动、透明，适合流式数据。

UDP 不分段：依赖 IP 分片（但不可靠），适合小报文。

关键区别： TCP 是“快递员拆箱+送货上门”，UDP 是“你自己打包，丢了不赔”！