一、前言

1.1 OSI七层网络模型

OSI（Open System Interconnection，开放系统互连）七层模型是由国际标准化组织（ISO）提出的一个网络通信框架，它将网络通信过程划分为七个独立但相互依赖的层次，每一层都有其特定的功能和任务。如图所示：

虽然七层模型设计的结构十分清楚，各个层各司其职，但七层模型相对复杂，在实际应用中，完全按照 OSI 七层模型来实现网络通信可能较为困难，因为某些层次的功能可能在实际应用中并不明显或必要，同时，过多的层次可能导致数据传输效率降低，因为每一层都需要对数据进行封装和解封装。

1.2 TCP/IP五层网络模型

TCP/IP五层网络模型是在七层模型的基础上做了简化，分为应用层、传输层、网络层（互联网层）、数据链路层和物理层，共五层，在实际应用中更容易实现，效率也更高。

如图所示：

那么，知道了网络模型中的每层的功能，天各一方的两台计算机是如何通信的呢？

二、两台电脑实现远程通信

2.1 物理层

两台电脑要想通信，首先要使用物理介质连接起来，物理介质可以是网线、光纤等。计算机之间在物理介质上传输0，1这样的电信号，而01电信号（比特流）的组合如果是无序组合的，计算机之间就无法解读互相传输的信息。

为了解决这个问题，物理层采用了一系列机制来确保信号的有序传输和正确解读。

• 编码规则：物理层定义了特定的编码规则，例如使用曼彻斯特编码或差分曼彻斯特编码等，它们通过特定的电压或电平变化来表示0和1，使得接收方能够准确地识别发送的信号；

• 解码过程：在接收端，物理层使用相应的解码规则将接收到的信号转换回原始的数据，该过程与编码过程相反，确保数据的正确恢复；

• 物理层也有相应的同步机制保证通信双方按照相同的频率和顺序接收信号；

• 在长距离传输中，信号可能会发生衰减。物理层会考虑信号衰减的因素，并可能采用中继器、放大器等设备来补偿信号衰减，确保接收方能够接收到足够强度的信号

参考：曼切斯特编码和差分曼切斯特编码 - WillBeBetter - 博客园

2.2 数据链路层

前面说了，物理层负责把两台电脑连起来，并且在计算机之间传输0、1这样的电信号。但是这些0、1信号如果是毫无规则的，计算机是解读不了的。因此需要指定一套规则来进行0、1的传送。于是有了以太网协议。

以太网协议规定一组电信号构成了一个数据包，我们把这个包称之为帧，每个帧由head和data两部分组成。

• head：存放发送者的信息

• data：要发送的数据

规定好了帧结构，就可以把数据发送给目标计算机，但是如何找到目标计算机呢，mac地址解决了这个问题。

在计算机生产过程中，会给每一台计算机的网卡设定一个唯一地址——MAC地址，计算机之间的数据传送，就是通过MAC地址来唯一寻找、传送的。mac地址由48为二进制数组成。

2.2.1 广播与ARP协议

如图，假设计算机A想要给计算机B发送数据，首先要知道B的mac地址，如何获取呢？ARP地址解析协议解决了这个问题。

ARP 的工作流程基于 “广播请求 + 单播响应”，以 “设备 A（IP：192.168.1.10，MAC：AA-AA-AA-AA-AA-AA）向设备 B（IP：192.168.1.20）发送数据” 为例：

1. 查询 ARP 缓存表：设备 A 先检查本地的 “ARP 缓存表”（存储近期的 IP-MAC 映射），如果已有 192.168.1.20 对应的 MAC 地址，直接用该 MAC 封装数据帧发送。

2. 发送 ARP 请求（广播）：若缓存表中无设备 B 的 MAC，设备 A 构造一个ARP 请求帧：

   • 目标 MAC 地址：FF:FF:FF:FF:FF:FF（广播地址，网段内所有设备接收）；

   • 帧内数据：“谁是 192.168.1.20？请回复你的 MAC 地址给 192.168.1.10（AA-AA-AA-AA-AA-AA）”。

3. 接收 ARP 响应（单播）：

   • 网段内所有设备收到广播帧后，检查自身 IP：只有设备 B（192.168.1.20）会处理该请求；

   • 设备 B 构造ARP 响应帧，目标 MAC 设为设备 A 的 MAC（AA-AA-AA-AA-AA-AA），帧内携带 “192.168.1.20 的 MAC 是 BB-BB-BB-BB-BB-BB”；

   • 设备 B 以单播方式将响应帧发送给设备 A（仅设备 A 接收）。

4. 更新 ARP 缓存表：设备 A 收到响应后，将 “192.168.1.20 ↔ BB-BB-BB-BB-BB-BB” 的映射存入 ARP 缓存表（默认有效期 10-20 分钟，过期后重新查询）。

2.3 网络层

上面我们提到了网段 这个概念，网段也叫子网，整个互联由无数个子网络构成。广播的时候，也只有处于同一个子网里的计算机能够收到。

假如没有子网这种划分，a发送一个帧给b，互联网上的所有计算机都会收到，然后再进行舍弃，这是不可能的。因此必须划分子网。

那么我们如何区分mac地址属于同一个子网呢？如果a、b不处于同一个子网，数据又该怎么发送呢？

假如是同一个子网，那我们就用广播的形式把数据传送给对方，如果不是同一个子网的，我们就会把数据发给网关，让网关进行转发。

2.3.1 IP协议

IP协议工作在网络层，

1. IP地址（IPv4）

• 32位二进制，通常写成4段十进制（如：192.168.1.1）

• 范围：0.0.0.0 ~ 255.255.255.255

• 分为两部分：

  • 网络部分：标识网络

  • 主机部分：标识网络中的具体设备

2. 子网掩码（Subnet Mask）

• 也是32位，与IP地址一一对应

• 网络部分全为1，主机部分全为0

  • 例如：255.255.255.0 → 前24位是网络，后8位是主机

• 子网掩码的作用是界定网络范围，不能单独使用，必须和IP地址配对

3. 判断是否在同一子网

• 方法：IP地址 & 子网掩码 = 网络地址

  • 如果两个IP的网络地址相同 → 同一子网

  • 举例：

    • IP1: 192.168.43.1

    • IP2: 192.168.43.2

    • 掩码：255.255.255.0

    • 计算：

      • 192.168.43.1 & 255.255.255.0 = 192.168.43.0

      • 192.168.43.2 & 255.255.255.0 = 192.168.43.0

    • 结果相同 → 同一子网 ✅

2.3.2 DNS域名解析服务器

我们是如何知道对方计算机的IP地址的呢？当我们想要访问某个网站的时候，我们可以输入IP来进行访问，但是我相信绝大多数人是输入一个网址域名的，例如访问百度是输入 www.baidu.com 这个域名。其实当我们输入这个域名时，会有一个叫做DNS服务器的家伙来帮我们解析这个域名，然后返回这个域名对应的IP给我们的。

因此，网络层的功能就是让我们在茫茫人海中，能够找到另一台计算机在哪里，是否属于同一个子网等。

人类对 “www.baidu.com”“www.google.com” 这类有意义的域名更敏感，但计算机之间的通信（如 HTTP 请求、TCP 连接）必须依赖 IP 地址（如百度的 IP 可能是 180.101.50.188）。DNS 的核心作用就是：
接收 “域名查询请求”→ 返回 “对应的 IP 地址”，相当于网络世界的 “通讯录”—— 我们查 “联系人姓名（域名）”，DNS 帮我们找到 “电话号码（IP）”。

当你在浏览器输入 “www.baidu.com” 并按下回车时，DNS 解析并非 “一步到位”，而是遵循 “从近到远、层级查询” 的逻辑，优先查本地缓存，缓存没有再查远程服务器，具体步骤如下（以 “递归查询 + 迭代查询” 的经典模式为例）：

步骤 1：查询 “本地 DNS 缓存”（最快的一层）

• 你的操作系统（Windows/macOS/Linux）和浏览器（Chrome/Edge）会缓存近期解析过的 “域名 - IP 映射”（缓存有有效期，通常几分钟到几小时）。

• 例：如果你 10 分钟前刚访问过百度，浏览器缓存里可能还存着 “www.baidu.com → 180.101.50.188”，此时直接用缓存的 IP，无需后续步骤，解析耗时毫秒级。

步骤 2：查询 “本地 DNS 服务器”（你的网络服务商提供）

如果本地缓存没有，操作系统会向 “本地 DNS 服务器” 发送查询请求（本地 DNS 服务器的 IP 通常由路由器自动分配，或手动配置，比如电信 / 联通的 DNS 服务器）。

• 本地 DNS 服务器也有自己的缓存，若缓存中有目标域名的 IP，直接返回；

• 若没有，本地 DNS 服务器会开始 “远程层级查询”（这一步对用户透明）。

步骤 3：查询 “根 DNS 服务器”（全球只有 13 组）

本地 DNS 服务器首先会向 “根 DNS 服务器” 发送请求（根服务器是 DNS 体系的 “顶层”，全球共 13 组，由不同机构管理，如美国 Verisign、中国 CNNIC 等）。

• 根服务器不直接存储 “www.baidu.com” 的 IP，而是知道 “.com” 这类顶级域名（TLD） 由哪些 “顶级域名服务器” 管理，因此会返回 “所有负责.com 域名的顶级服务器 IP”。

步骤 4：查询 “顶级域名服务器”（负责.com/.cn/.org 等）

本地 DNS 服务器拿到根服务器返回的 “顶级域名服务器 IP” 后，向其中一台 “负责.com 的顶级服务器” 发送查询请求。

• 顶级服务器也不直接存储 “www.baidu.com” 的 IP，而是知道 “baidu.com” 这类二级域名由哪些 “权威 DNS 服务器” 管理，因此会返回 “baidu.com的权威 DNS 服务器 IP”。

步骤 5：查询 “权威 DNS 服务器”（域名的 “真正管理者”）

“权威 DNS 服务器” 是域名的 “官方通讯录”—— 由域名持有者（如百度公司）配置，直接存储 “www.baidu.com”“map.baidu.com” 等子域名对应的 IP 地址。

• 本地 DNS 服务器向 “baidu.com的权威 DNS 服务器” 发送请求，权威服务器会返回 “www.baidu.com对应的 IP 地址”（可能是多个，用于负载均衡）。

步骤 6：返回结果并缓存

本地 DNS 服务器拿到 IP 后，会：

1. 把 IP 返回给你的操作系统 / 浏览器；

2. 同时将 “www.baidu.com → IP” 存入自己的缓存（避免下次重复查询）；
   你的浏览器拿到 IP 后，就可以基于这个 IP 发起 HTTP 请求，最终加载百度首页。

2.4 传输层

要理解传输层，需要先明确它在 TCP/IP 协议栈中的核心定位：它承接网络层 “主机到主机” 的通信能力，向下整合底层数据传输通道，向上为应用层提供 “端口到端口” 的精准通信服务，是实现 “应用间可靠数据交互” 的关键环节。

• 向下（网络层）：基于 IP 地址（网络层提供的 “主机标识”），进一步通过 “端口” 定位到主机内的具体应用，解决 “一台主机上多个应用同时通信” 的冲突问题（比如电脑同时开着浏览器、微信、QQ，数据不会发错）。

• 向上（应用层）：为不同需求的应用提供差异化的通信服务（比如浏览网页需要 “可靠不丢包”，视频通话需要 “低延迟”），屏蔽底层网络的复杂性（比如 IP 路由、链路波动），让应用层只需专注于业务逻辑。

简单来说：

• 网络层回答 “数据要发给哪台主机”（靠 IP 地址）；

• 传输层回答 “这台主机上的哪个应用要接收数据”（靠端口）；

• 二者结合（IP + 端口）构成 “socket（套接字）”，才是网络通信的唯一标识（比如 192.168.1.100:80 代表 “192.168.1.100 这台主机上的 80 端口应用”）。

2.4.1 端口

端口是传输层的 “核心工具”，本质是主机内应用程序与传输层交互的 “逻辑接口”（非物理接口），用 16 位二进制数表示，范围是 0~65535（共 65536 个）。

• 区分应用：一台主机上可能同时运行多个网络应用（浏览器、微信、邮件客户端），传输层通过端口号，将收到的数据包精准转发给对应的应用（比如收到端口 80 的数据包，交给浏览器；收到端口 443 的，交给 HTTPS 服务）。

• 复用与解复用：实现 “单 IP 地址下多应用同时通信”—— 发送端（客户端）通过 “本地动态端口 + 目标知名端口” 区分不同应用的连接；接收端（服务器）通过 “本地知名端口 + 客户端动态端口” 区分不同客户端的连接。

2.4.2 传输层的两大核心协议：TCP/UDP

传输层的核心能力由 TCP 和 UDP 两大协议实现，二者设计理念完全不同，分别对应 “可靠通信” 和 “高效通信” 的需求，没有绝对的优劣，仅需 “按需选择”。

2.4.2.1 tcp协议的特点

面向连接（Connection-Oriented）：通信前必须先建立 “三次握手”，通信后必须 “四次挥手” 释放连接，类似 “打电话”（先拨号接通，再说话，最后挂电话）。

• 三次握手（建立连接）：确保客户端和服务器双方 “收发能力正常”，避免无效数据传输。

  1. 客户端→服务器：“我要连接你（SYN=1）”；

  2. 服务器→客户端：“我收到了，我也准备好连接（SYN=1, ACK=1）”；

  3. 客户端→服务器：“我收到你的确认，连接建立（ACK=1）”。

• 四次挥手（释放连接）：确保双方数据都已传输完毕，避免数据残留。

  1. 客户端→服务器：“我数据发完了，要断开（FIN=1）”；

  2. 服务器→客户端：“我收到断开请求，正在处理剩余数据（ACK=1）”；

  3. 服务器→客户端：“我数据也发完了，可以断开（FIN=1, ACK=1）”；

  4. 客户端→服务器：“我收到了，断开连接（ACK=1）”。

• 可靠传输：通过 “确认机制（ACK）”“重传机制”“滑动窗口” 实现：

  • 确认机制：服务器收到数据后，必须向客户端发送 “ACK（确认帧）”；客户端若没收到 ACK，会认为数据丢失，触发重传。

  • 重传机制：客户端发送数据后启动定时器，超时未收到 ACK 则重传；若多次重传失败，提示连接异常。

  • 滑动窗口：通过 “窗口大小” 动态调整一次能发送的数据量（发送方）（类似 “快递批量发货”），避免发送方 “发得太快” 导致接收方缓存溢出，同时提高传输效率。

• 面向字节流：TCP 将应用层发送的数据视为 “连续的字节流”（无固定数据包边界），会根据底层 MTU（最大传输单元）拆分数据段（Segment），接收端再重组为完整字节流交给应用层。

• 流量控制与拥塞控制：

  • 流量控制：通过 “接收窗口（rwnd）” 限制发送方速率，确保接收方 “能接多少，就发多少”（比如接收方缓存满了，就告诉发送方 “窗口缩小”）。

  • 拥塞控制：通过 “慢启动”“拥塞避免”“快速重传”“快速恢复” 机制，避免发送方速率过快导致网络拥堵（比如刚建立连接时慢慢发，网络稳定后再提速；发现丢包则减速）。

2.4.2.2 UDP协议的特点

UDP（User Datagram Protocol，用户数据报协议）的核心目标是 “以最快速度传输数据，牺牲可靠性换效率”，适合对延迟敏感、可容忍少量丢包的场景（如视频通话、游戏、直播）。

• 无连接（Connectionless）：通信前无需建立连接，通信后无需释放连接，直接 “发数据包就走”，类似 “发短信”（不用拨号，直接发送，不管对方是否收到）。

• 不可靠传输：没有确认机制、重传机制、滑动窗口 —— 发送方只管发送数据，不关心接收方是否收到；接收方收到数据后，也不向发送方回复 ACK；若数据在传输中丢失（如网络拥堵），UDP 不会处理，直接丢弃。

• 面向数据报：UDP 将应用层数据封装为 “数据报（Datagram）”，每个数据报都是独立的 “数据包”，有固定的边界（发送方发一个，接收方收一个），不会拆分或重组（若数据报超过 MTU，会被 IP 层分片，分片丢失则整个数据报失效）。

• 轻量高效：UDP 头部仅 8 字节（TCP 头部至少 20 字节），协议逻辑简单，无需维护连接状态、重传队列，对 CPU 和内存消耗极低，传输延迟远低于 TCP。

传输层的核心工作之一是 “数据封装” 与 “解封装”，确保数据在应用层和底层之间正确传递：

1. 发送端（封装）：
   应用层（如浏览器）生成数据 → 传输层（TCP/UDP）给数据加 “头部”（包含源端口、目标端口、校验和等），封装为 “段（TCP Segment）” 或 “数据报（UDP Datagram）” → 交给网络层（IP 协议）加 IP 头部（源 IP、目标 IP） → 数据链路层加 MAC 头部 → 物理层转为电信号传输。

2. 接收端（解封装）：
   物理层接收电信号 → 数据链路层解 MAC 头部 → 网络层解 IP 头部，确定目标主机（本机） → 传输层解 TCP/UDP 头部，通过 “目标端口” 找到对应的应用程序 → 把数据交给应用层（如浏览器渲染网页）。

2.5 应用层

在 TCP/IP 协议栈中，应用层是最贴近用户的 “业务入口”—— 它不关心底层如何传输数据（物理层的电信号、网络层的 IP 路由、传输层的端口通信），只专注于 “定义数据格式、实现具体业务逻辑”，让用户能通过浏览器、微信、播放器等应用，直观地使用网络服务。

应用层的所有能力都基于 “协议”—— 协议定义了 “数据该怎么封装、怎么交互、怎么解析”，不同业务场景对应不同协议。以下是最常见的应用层协议及其核心作用：

1. HTTP/HTTPS：网页与 API 通信的 “通用语言”

• 用途：最核心的 Web 协议，用于浏览器访问网页、App 调用后端 API（如手机银行查余额、外卖 App 刷新订单）。

• 数据格式规则：

  • 通信基于 “请求 - 响应” 模式：客户端（浏览器 / App）发 “HTTP 请求”，服务器发 “HTTP 响应”。

  • 请求 / 响应都由 “头部（Header）+ 正文（Body）” 组成：

    • 头部：包含 “数据格式标识”（如 Content-Type: text/html 表示正文是 HTML，Content-Type: application/json 表示正文是 JSON）、“字符编码”（如 Charset: UTF-8）、“缓存规则” 等元信息，告诉接收方 “该怎么解析正文”；

    • 正文：实际业务数据（如 HTML 代码、JSON 字符串、图片二进制数据）。

• HTTP vs HTTPS：

  • HTTP 是明文传输，数据在网络中可能被窃听、篡改（如公共 WiFi 下，别人可能看到你访问的网页内容）；

  • HTTPS 在 HTTP 基础上增加了SSL/TLS 加密层，所有数据加密传输，还会验证服务器身份（防止 “钓鱼网站”），现在主流网站（百度、淘宝、银行）都强制使用 HTTPS。

2. FTP/SFTP：文件传输的 “专用工具”

• 用途：用于 “客户端与服务器之间批量传输文件”（如程序员把网站代码传到服务器、设计师把素材传给客户）。

• 数据格式规则：

  • FTP（文件传输协议）：基于 TCP，分 “控制连接”（用于发送指令，如 “上传 / 下载文件”“创建文件夹”）和 “数据连接”（用于传输文件本身的二进制数据）；

  • SFTP（SSH 文件传输协议）：比 FTP 更安全，基于 SSH 加密通道传输数据，避免文件内容和账号密码被窃听，现在逐渐替代 FTP 成为主流。

3. SMTP/POP3/IMAP：电子邮件的 “收发规则”

• 用途：共同实现电子邮件的 “发送 - 存储 - 接收” 全流程：

  • SMTP（简单邮件传输协议）：负责 “发送邮件”—— 你的邮箱客户端（如 Outlook、网易邮箱）通过 SMTP 把邮件发给邮件服务器（如网易服务器→QQ 服务器）；

  • POP3（邮局协议 3）/IMAP（互联网邮件访问协议）：负责 “接收邮件”—— 你的客户端通过 POP3/IMAP 从邮件服务器下载邮件到本地。

• 数据格式规则：邮件数据包含 “发件人、收件人、主题” 等头部信息，以及 “正文（文本 / HTML）”“附件（二进制数据，如 Word、图片）”，附件会被编码为 Base64 格式（避免二进制数据传输出错）。

4. DNS：域名解析的 “通讯录查询协议”

• 用途：虽然之前提到 DNS 的作用，但从协议层级看，DNS 属于应用层 —— 它基于 UDP（少数用 TCP），负责 “将域名翻译成 IP 地址”。

• 数据格式规则：DNS 查询 / 响应是 “结构化数据包”，包含 “查询类型”（如 A 记录：域名→IPv4，AAAA 记录：域名→IPv6）、“查询状态”（成功 / 失败）、“域名 - IP 映射列表” 等，确保客户端能快速拿到解析结果。

三、从 “用户操作” 到 “数据解析”，发生了什么？

以 “用浏览器访问www.baidu.com” 为例，完整展现应用层与底层协议的配合：

1. 用户操作：在浏览器地址栏输入 “www.baidu.com” 并回车；

2. 应用层（DNS）：浏览器先发起 DNS 查询（应用层协议），通过 UDP 向 DNS 服务器请求 “www.baidu.com对应的 IP”，得到 IP（如 180.101.50.188），查找IP的顺序（浏览器缓存—>操作系统—>本地域名服务器—>权威服务器—>顶级域名服务器）；

3. 应用层（HTTP）：浏览器按 HTTP 协议封装 “请求数据”—— 头部包含GET / HTTP/1.1（请求首页）、Host: www.baidu.com（目标域名）、Content-Type: text/html（期望响应格式），正文为空；

4. 传输层（TCP）：浏览器随机分配一个动态端口（如 50001），与百度服务器的 80 端口（HTTP 默认端口）建立 TCP 连接（三次握手），将 HTTP 请求数据拆分为 TCP 段，交给网络层；

5. 网络层（IP）：给 TCP 段加 IP 头部（源 IP：你的电脑 IP，目标 IP：180.101.50.188），交给数据链路层；

6. 底层传输：数据链路层加 MAC 头部、物理层转电信号，通过网络传到百度服务器；

7. 服务器解析（底层→应用层）：百度服务器从物理层到传输层依次解封装，最终在应用层（HTTP 服务）解析 HTTP 请求，生成 “响应数据”（包含 HTML 首页代码的 HTTP 响应）；

8. 服务器返回：响应数据按 “应用层→底层” 的顺序封装，通过 TCP 连接传回你的电脑；

9. 应用层（浏览器渲染）：你的浏览器解析 HTTP 响应，按Content-Type: text/html规则渲染 HTML 代码，最终显示百度首页。