Linux:初始网络(下)

或许你有一个疑问,“发请求、收响应”,却不清楚数据在网线里到底是怎么从一台主机走到另一台主机的。这篇博客在上一篇博客基础上,将最基础的局域网通信原理出发,拆解数据封装与解包的核心逻辑,再延伸到跨网段的网络传输,帮你建立起网络传输的完整宏观认知,所以大家要认真阅读啦~~

一、同局域网通信:以太网内的主机如何直接对话

局域网是我们最常接触的网络场景,比如家里的路由器连接的电脑、手机,公司内网的办公设备,都属于同一个局域网。我们先从最核心的问题切入,理解局域网通信的底层逻辑

1. 核心问题:同一局域网的两台主机,能直接通信吗?

答案是:完全可以!局域网内的主机通信,本质是基于以太网协议、通过 MAC 地址完成的二层直连通信,原理就像我们在同一个教室里上课:老师喊出同学的名字,全班同学都能听到这个声音,但只有名字对应的同学会做出回应,其他同学会自动忽略这个信息

2. 局域网通信的唯一身份标识:MAC 地址

在以太网的局域网里,每一台主机的唯一性,靠的就是 MAC 地址来保证。

  • 核心定义:MAC 地址用来识别数据链路层中相连的节点,是网卡的 “物理身份证”
  • 格式规范:长度为 48 个比特位,也就是 6 个字节,通常用 16 进制数字加冒号的形式表示,例如08:00:27:03:fb:19
  • 唯一性:MAC 地址在网卡出厂时就已经确定,无法修改,全球唯一(虚拟机的 MAC 地址并非真实物理地址,可能存在冲突;部分网卡也支持用户自定义配置 MAC 地址)

查看方式:在 Windows 系统中,可通过ipconfig /all命令查看网卡对应的 MAC 地址,linux中也可以通过ifconfig来查看

3. 以太网局域网的核心通信规则

想要理解局域网通信,必须先搞清楚以太网的底层规则:

  1. 串行通信规则:以太网中,任何时刻只允许一台机器向网络中发送数据;如果多台机器同时发送,会发生数据干扰,这种情况我们称之为数据碰撞
  2. 碰撞域与碰撞规避:在没有交换机的场景下,一个以太网就是一个碰撞域;所有发送数据的主机,都必须遵循碰撞检测和碰撞避免的规则,保障数据传输的有序性
  3. 接收判定规则:局域网通信过程中,主机对收到的报文,会通过目标 MAC 地址判定是否是发给自己的:只有目标 MAC 地址和自己的 MAC 地址匹配,才会接收并处理这个报文,否则直接丢弃

二、网络传输的核心:数据的封装与解包

不管是局域网通信,还是跨网段的广域网通信,都离不开一个最核心的动作:数据的封装与解包。这是整个网络协议栈工作的核心,也是理解所有网络协议的基础

1. 先明确两个核心概念

网络中传输的所有数据,都可以拆分为两部分:

  • 报头:对应协议层定义的结构体字段,里面包含了协议的核心规则,比如报头长度、有效载荷长度、上层协议类型等
  • 有效载荷:上层协议传递下来的、需要被传输的核心数据。一句话总结:报文 = 报头 + 有效载荷

2. 各层数据包的专属称谓

在 TCP/IP 四层协议栈中,不同层级对数据包有不同的命名,对应不同的协议处理阶段:

  • 传输层:数据包叫做段(segment)
  • 网络层:数据包叫做数据报(datagram)
  • 数据链路层:数据包叫做帧(frame)

3. 什么是封装(Encapsulation)?

应用层的数据通过协议栈发到网络上时,每层协议都会给上层传来的数据,加上一个自己协议的报头,这个自上而下层层加报头的过程,就叫做封装。举个例子:应用层要发送一段数据,会先交给传输层,传输层加上 TCP/UDP 报头,再交给网络层,网络层加上 IP 报头,再交给数据链路层,数据链路层加上以太网帧头和帧尾,最终封装成一个完整的以太网帧,发送到物理传输介质上

4. 什么是解包与分用?

数据封装成帧后,通过物理介质到达目的主机,目的主机的协议栈会执行完全相反的操作:自底向上,每层协议剥掉对应的报头,再根据报头里的 “上层协议字段”,把剩下的有效载荷,交给对应的上层协议处理,这个过程就是解包与分用。比如:数据链路层剥掉以太网帧头,根据帧头里的协议类型,把载荷交给网络层的 IP 协议;IP 协议剥掉 IP 报头,根据报头里的协议号,把载荷交给传输层的 TCP/UDP 协议;传输层再剥掉对应的报头,把最终的应用数据交给上层应用

5. 学习所有网络协议的核心认知

从封装与解包的逻辑出发,我们可以建立一个通用的协议学习思路:以后学习任何网络协议,都要先搞懂两个核心问题:

  1. 这个协议,是如何完成解包的?只有明确了解包逻辑,才能真正理解封包的设计。
  2. 这个协议,是如何把自己的有效载荷,准确交付给上层协议的?

搞懂这两个问题,就搞懂了这个协议 80% 的核心逻辑

三、同网段主机通信的完整流程

结合上面的局域网通信原理、封装解包逻辑,我们可以完整串一遍,同一个局域网内,主机 A 给主机 B 发送一段数据的完整流程:

  1. 应用层:主机 A 的应用程序生成要发送的数据,交给传输层
  2. 传输层:给数据加上传输层报头,封装成数据段,交给网络层
  3. 网络层:给数据段加上 IP 报头(包含源 IP、目的 IP),封装成 IP 数据报,交给数据链路层
  4. 数据链路层:给 IP 数据报加上以太网帧头(包含源 MAC 地址、目的 MAC 地址)和帧尾,封装成以太网帧,通过网卡发送到局域网中
  5. 局域网传输:以太网帧在局域网中传播,所有主机都能收到这个帧
  6. 接收判定:局域网内的主机检查帧头的目的 MAC 地址,只有主机 B 发现 MAC 地址和自己匹配,才会接收这个帧,其他主机直接丢弃
  7. 主机 B 解包:主机 B 自底向上,依次剥掉以太网帧头、IP 报头、传输层报头,最终把应用数据交给对应的应用程序,完成一次同网段的数据传输

四、跨网络传输:跨网段的数据包如何走遍全网?

同网段的通信靠 MAC 地址直连,那我们访问外网、跨城市甚至跨国家的网络请求,是怎么完成的?这就需要理解跨网段的传输流程,以及 IP 地址的核心作用。

1. 跨网段通信的核心标识:IP 地址

IP 地址是 IP 协议中,用来标识网络中不同主机的地址,是跨网段路由寻址的核心依据。

  • 版本区分:IP 协议有 IPv4 和 IPv6 两个版本,我们日常接触的绝大多数场景,都是 IPv4
  • 格式规范:IPv4 地址是一个 4 字节、32 位的整数,我们通常用点分十进制的字符串表示,比如192.168.0.1,用点分割的每一个数字代表一个字节,范围是 0-255
  • 核心意义:IP 地址标识了主机在整个 IP 网络中的位置,是数据包能从源主机走到目标主机的核心依据

2. 为什么跨网段传输,必须经过路由器?

数据从一台主机到另一个网段的主机,传输过程中必须经过一个或多个路由器。路由器的核心作用,就是连接不同的网段,维护路由表,完成数据包的寻址和转发,是不同网络之间的 “中转站”。就像我们要从北京去上海,需要沿着高速路,经过一个个高速出口和枢纽,路由器就是网络世界里的 “高速枢纽”。

3. 跨网段传输的核心规则

跨网段传输和同网段传输,最大的区别,就在于 IP 地址和 MAC 地址的变化逻辑,这也是网络传输最核心的知识点:

  • IP 地址全程不变:在整个传输过程中,IP 报头里的源 IP 地址和目的 IP 地址,全程保持不变(不考虑 NAT 等特殊场景),它代表了数据包最终的 “长远目标”
  • MAC 地址逐跳变化:以太网帧头里的源 MAC 地址和目的 MAC 地址,每经过一个路由器、一个网段,都会被重新封装、发生变化,它代表了数据包 “下一跳要发给谁”

简单来说:目的 IP 是路径选择的重要依据,MAC 地址是局域网转发的重要依据

4. 跨网段传输的完整流程

我们以主机 A(192.168.1.10)给另一个网段的主机 C(220.181.38.251)发数据为例,拆解完整的传输流程:

  1. 主机 A 封装与寻址:主机 A 通过 IP 地址判断,目标主机和自己不在同一个网段,会把数据包先发给自己的网关(路由器);封装数据包时,IP 报头填源 IP(主机 A)和目的 IP(主机 C),以太网帧头填源 MAC(主机 A)和目的 MAC(网关路由器的 MAC 地址)
  2. 网关路由器接收与转发:路由器收到以太网帧,解包到网络层,查看目的 IP 地址,通过路由表计算出下一跳的地址;然后重新封装以太网帧,源 MAC 改成路由器出接口的 MAC,目的 MAC 改成下一跳设备的 MAC 地址,转发给下一跳
  3. 逐跳转发:数据包在网络中,经过一个又一个路由器,每一跳都会重新解包、查路由、重新封装帧头,更换 MAC 地址,但 IP 报头始终不变
  4. 到达目标网段:数据包最终到达主机 C 所在网段的边界路由器,路由器把帧的目的 MAC 地址,改成主机 C 的 MAC 地址,在局域网内发送
  5. 主机 C 接收与解包:主机 C 收到以太网帧,匹配到自己的 MAC 地址,完成接收,然后自底向上逐层解包,最终把数据交给对应的应用程序,完成跨网段传输

五、IP 地址与 MAC 地址的核心区别

维度IP 地址MAC 地址
所属层级网络层数据链路层
核心作用标识主机在整个 IP 网络中的位置,用于跨网段路由寻址标识局域网内的网卡节点,用于同网段的直连通信
传输中的变化全程保持不变每经过一个网段 / 路由器,都会发生变化
地址特性可根据网络环境动态配置、变更网卡出厂固定,全局唯一
寻址范围可用于全球广域网的寻址仅在当前局域网内有效

整个网络传输的核心逻辑,其实可以用三句话概括:

  1. 数据传输的核心动作,是自上而下封装,自下而上解包分用
  2. 同网段的局域网通信,靠 MAC 地址完成直连转发
  3. 跨网段的广域网通信,靠 IP 地址完成路由寻址,靠 MAC 地址完成每一跳的局域网转发

而整个 IP 网络层存在的最大意义,就是提供了一层网络虚拟层,让全球各式各样的底层物理网络,都统一成了 IP 网络,屏蔽了底层网络的差异,这也是互联网能实现全球互联互通的核心基础,到这里我们也终于正式进入了网络,准备开始后面的学习啦~~

Read more

Flutter 三方库 flutter_adaptive_scaffold 的鸿蒙化适配指南 - 掌握一套代码适配全场景终端的自适应架构技术、助力鸿蒙应用构建从手机到平板及折叠屏的极致无缝交互体系

Flutter 三方库 flutter_adaptive_scaffold 的鸿蒙化适配指南 - 掌握一套代码适配全场景终端的自适应架构技术、助力鸿蒙应用构建从手机到平板及折叠屏的极致无缝交互体系

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 flutter_adaptive_scaffold 的鸿蒙化适配指南 - 掌握一套代码适配全场景终端的自适应架构技术、助力鸿蒙应用构建从手机到平板及折叠屏的极致无缝交互体系 前言 在 OpenHarmony 鸿蒙应用追求“万物互联、全场景覆盖”的伟大进程中,屏幕尺寸的多样性(从 6 英寸手机到 12 英寸平板,再到 2D/3D 模式切换的折叠屏)是每一位 UI 开发者必须正面迎接的挑战。如何在不为每种设备重写 UI 的前提下,实现导航栏自动从“底部”平滑流转到“侧边”?如何在宽屏模式下自动开启“双栏(Master-Detail)”布局?flutter_adaptive_scaffold 作为一个由 Flutter

By Ne0inhk
在 macOS 上通过 Docker 本地安装 OpenClaw 完整教程

在 macOS 上通过 Docker 本地安装 OpenClaw 完整教程

在 macOS 上通过 Docker 本地安装 OpenClaw 完整教程 什么是 OpenClaw?—— 你的本地 AI 智能体执行框架 OpenClaw 不仅仅是一个聊天机器人,而是一个功能强大的 AI 智能体执行框架。你可以把它想象成一个能自主思考、调用工具、并替你完成复杂任务的数字员工。 🧠 核心概念 * 智能体:OpenClaw 的核心大脑。它能理解你的自然语言指令,拆解任务,并决定调用哪些工具来执行。 * 网关:所有外部访问的入口。它负责处理 WebSocket 连接、管理设备配对、路由消息,是你与智能体交互的桥梁。 * 技能:智能体可调用的具体工具,比如访问文件、操作浏览器、发送消息、查询数据库等。你可以根据需要扩展技能库。 * 记忆:OpenClaw 可以存储对话历史和重要信息,实现长期记忆和上下文理解,让交互更连贯。 * 通道:连接外部聊天平台的渠道,如

By Ne0inhk
HarmonyOS6半年磨一剑 - RcIcon组件实战案例集与应用开发指南

HarmonyOS6半年磨一剑 - RcIcon组件实战案例集与应用开发指南

文章目录 * 前言 * 项目简介 * 核心特性 * 开源计划 * rchoui官网 * 文档概述 * 第一章: 基础用法实战 * 1.1 三种符号引用方式 * 1.2 应用场景 - 工具栏快速导航 * 第二章: 尺寸系统实战 * 2.1 响应式尺寸配置 * 2.2 应用场景 - 统一设计系统尺寸规范 * 第三章: 颜色系统实战 * 3.1 多彩色系配置 * 3.2 应用场景 - 状态指示系统 * 第四章: 双风格系统实战 * 4.1 线型与实底风格对比 * 4.2 应用场景 - 底部导航栏 * 第五章: 圆角系统实战 * 5.

By Ne0inhk
Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构

Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构 前言 在鸿蒙(OpenHarmony)生态迈向万物互联、涉及海量离线资源标识、蓝牙广播载荷(BLE Payload)及二维码数据极限压缩的背景下,如何生成既能保留 UUID 强随机性、又能极大缩减字符长度的唯一标识符,已成为优化存储与通讯效率的“空间必修课”。在鸿蒙设备这类强调分布式软总线传输与每一字节功耗敏感的环境下,如果应用依然直接传输长度达 36 字符的标准 UUID,由于由于有效载荷溢出,极易由于由于传输协议限制导致数据截断或多次分包带来的延迟。 我们需要一种能够实现高进制转换、支持双向编解码且具备低碰撞概率的短 ID 生成方案。 short_uuids 为 Flutter 开发者引入了将标准 UUID 转化为短格式字符串的高性能算法。它利用

By Ne0inhk