数据在网络中的格式转换—直观版-CSDN博客

本文链接：https://blog.csdn.net/Wabi_Sabi18/article/details/147038162

从网络传输的角度来看，所有数据最终都是以二进制（比特流）形式在物理介质上进行传输。文本、图片、音视频……不管在应用层是何种格式，最终到传输层、网络层、链路层乃至物理层时，都会被转换成比特流进行封装和发送。

计算机网络的本质是通过电信号（或光信号、无线电波等物理方式）来传递 0 和 1，也就是比特流。在应用层可以有各种各样的文件格式（如 HTML、GIF、JPEG、MP4 等），但当数据经过网络协议栈一路向下封装后，到物理介质层时，都是由比特流来承载。

下面以一个常见的场景为例：浏览器向服务器请求一个 GIF 图片。我们用自顶向下（应用层 → 传输层 → 网络层 → 数据链路层 → 物理层）的方式来看看数据在网络中的格式是如何演变的。

协议示例：HTTP/1.1、HTTP/2、HTTP/3 等
示例数据：HTTP 响应报文，包括头部和主体（Body）。
- 头部（Headers）可能包含：
```
HTTP/1.1 200 OK
Content-Type: image/gif
Content-Length: 42
...
```
- 主体（Body）是 GIF 文件的原始字节流，例如以 GIF89a 开头等。

在应用层，GIF 文件可以看作是“二进制文件”。但如果你用抓包工具或文本编辑器打开它，看到的会是一堆“不可读”字符或十六进制，因为 GIF 并非可读文本格式。不过应用层协议本身（HTTP 报文的头部部分）往往是可读文本。

协议示例：TCP 或 UDP（HTTP 一般基于 TCP）。
数据格式：在这一层，HTTP 响应报文会被拆分/打包成一个或多个 TCP 段（Segment）。
- 每个 TCP 段前面会加上 TCP 头（如源端口、目标端口、序列号、校验和等信息）。
- 应用层的字节流（即 HTTP 报文）被当做 TCP 段的“数据部分（Payload）”。

协议示例：IP（IPv4 或 IPv6）。
数据格式：在这一层，每个 TCP 段会被封装进 IP 包（Packet）。
- IP 头包含源 IP、目标 IP、TTL、协议类型等。
- TCP 段被当作 IP 包的“数据部分”。

你在浏览器输入 https://example.com/image.gif，按下回车。
浏览器通过 HTTP 协议（应用层）发送请求：
```
GET /image.gif HTTP/1.1
Host: example.com
...
```
这个请求报文在传输层被拆成若干个 TCP 段；在网络层被封装为 IP 包；在数据链路层封装成 以太网帧（如果是 Wi-Fi 则封装成 802.11 帧）。
数据通过网线或 Wi-Fi（物理层）以比特流（高低电平、无线电波等）发送到服务器。
服务器处理请求后，返回一个 HTTP 响应：
- 响应头：HTTP/1.1 200 OK 等
- 响应体：GIF 文件的原始字节流（从 GIF89a 开始）
这些数据在服务器端也会进行同样的“分层封装”：HTTP → TCP → IP → 数据链路 → 物理，最后发回到你的浏览器。
浏览器收到后，逆向解封装：物理层收到比特流 → 数据链路层 → 网络层 → 传输层 → 应用层（HTTP 报文），最终拿到 GIF 的二进制数据，呈现给用户。

从网络协议栈底层看，所有数据都是以二进制形式传输。
从应用层看，可以有文本格式（如 HTML、JSON）或二进制格式（如 GIF、JPEG、MP4），但它们在下层依旧是 0 和 1 的比特流。
封装/解封装：当数据自顶向下传输时，每层协议都在数据前后加上自己的头部（或尾部），形成新的协议数据单元；当数据自底向上传递时，依次拆掉各层的头部（或尾部），还原出上层数据。

因此，你在抓包时看到的响应实际上就是应用层返回的“原始”GIF 字节流（HTTP Body），抓包工具会把这些字节流用十六进制和可打印字符的形式呈现出来。再往下的 TCP、IP、以太网等头部数据则会被抓包工具拆分到更底层的“报文头部”里进行解析。