docker镜像推送与拉取基于内容寻址、分层比对和按需传输，以层为最小单元同步，仅传输缺失层并复用相同哈希的层，上传前gzip压缩blob，拉取时解压至overlay2并硬链接复用本地已有层。
docker 镜像推送（push）与拉取（pull）过程并不简单地“传整个包”，而是基于内容寻址、分层比对和按需传输的机制，压缩与同步发生在多个环节，核心目标是减少网络带宽占用、避免重复传输、保障数据一致性。
分层结构决定压缩与同步的粒度
每个镜像由若干只读层（layer）组成，每层对应一个 SHA256 内容哈希值。Docker 不以文件或目录为单位传输，而是以“层”为最小同步单元：
- 本地已有某层（如基础镜像 alpine:3.18 的 rootfs 层），且其哈希与远程 registry 中一致，则跳过传输；
- 仅上传/下载本地缺失的层，哪怕只差一层，也不会重传整个镜像；
- 层本身在存储时已采用 gzip 压缩（如 tar.gz 格式封装的 layer blob），registry 接收后通常保持压缩状态，拉取时解压到本地 overlay2 存储驱动中。
推送前自动压缩与内容去重
执行 docker push 时，客户端会先遍历本地镜像各层的 manifest 和 config，再向 registry 发起 HEAD 请求检查远程是否已存在对应 digest 的层：
- 若 registry 返回 200（层已存在），直接跳过该层上传；
- 若返回 404，则将该层数据以分块（chunked）方式上传，每块默认上限约 5MB，支持断点续传；
- 上传前，Docker 守护进程会对 layer blob 进行 gzip 压缩（由构建时的
docker build或docker save阶段预处理决定），但不会二次压缩已压缩内容（如 .so/.jar 等二进制文件）； - 同一内容哈希（例如两个不同 Dockerfile 中都执行了
RUN apt-get install curl且系统环境一致）生成的层会被自动复用，不产生冗余存储。
拉取时的智能同步与本地缓存复用
docker pull 并非“全量下载”，而是一次精准的层协商过程：
- 客户端先获取远程 manifest（v2 schema），解析出所有 layer digest 列表及 config；
- 对比本地
/var/lib/docker/image/overlay2/imagedb/content/sha256/下已有的层哈希，标记出缺失项； - 对每个缺失层，发起 GET 请求下载压缩 blob，并在本地解压写入 overlay2 的
diff/目录； - 若本地已存在某层（即使属于其他镜像），只要 digest 匹配，就直接硬链接复用，不重复解压或存储；
- manifest 和 config 文件本身也按压缩 JSON 传输，体积小，但决定整个镜像结构完整性。
压缩与同步的关键支撑技术
上述行为依赖三项底层能力协同工作：
- 内容寻址（Content Addressing）：每层用 SHA256 哈希唯一标识，确保相同内容零误差复用；
- 联合文件系统（UnionFS / overlay2）：使多层可读写叠加，拉取后的层无需“合并”即可直接挂载使用；
- Registry v2 协议规范：定义了 blob 上传/下载、manifest 推送/拉取、tag 绑定等标准接口，支持摘要校验与条件请求（If-None-Match）。
