docker客户端与服务端通过rest api实现标准化http通信，客户端解析命令并封装为json请求发送至守护进程，后者执行操作并返回结构化响应；默认使用unix套接字（/var/run/docker.sock），支持tcp+tls远程调用，全程基于http/1.1协议。
Docker 的客户端与服务端通信机制，核心在于“命令下发—请求处理—结果返回”这一闭环流程，不依赖用户手动干预，也不需要理解底层实现细节，只要知道命令怎么发、谁来执行、消息怎么传就够了。
客户端只负责发指令，不干活
Docker 客户端（docker 命令行工具）本质是个“传话员”。你输入 docker run nginx，它不做任何构建或运行动作，只是把这条指令按标准格式打包成一个 HTTP 请求，然后发给服务端。
- 所有操作都走统一入口：无论
pull、build、ps还是exec，客户端都只做解析参数 + 构造 API 请求两件事 - 默认用 Unix 套接字（
/var/run/docker.sock）通信，速度快、无需网络配置；也可配成 TCP 模式，支持远程调用 - 不装守护进程也能用客户端——比如在 Windows 上只装 Docker CLI，连远程 Linux 服务器上的 daemon，照样能操作容器
服务端（daemon）才是真干活的人
Docker 守护进程（dockerd）常驻后台，监听 API 请求，拿到指令后才真正调度资源：拉镜像、启容器、配网络、挂卷……它直接跟操作系统内核打交道，管理命名空间、cgroups、存储驱动等。
- 它不认命令行语法，只认 RESTful 接口定义的路径和参数，比如
POST /containers/create对应docker create - 所有状态都由它维护：正在运行的容器列表、本地镜像缓存、自定义网络配置，客户端查
docker ps其实是在读它的内存快照 - 出错时返回标准 HTTP 状态码（如 404 表示镜像不存在，500 表示内部错误），客户端再转成易读提示
通信靠的是标准化协议，不是私有连接
Docker 把通信逻辑完全抽象成一套公开的 API，这意味着只要符合接口规范，任何语言写的程序都能当客户端——不一定是官方 docker 命令。
- API 版本随 Docker 升级迭代，比如 v1.41 支持 cgroup v2，旧客户端连新 daemon 可能部分功能不可用
- 实际传输用 HTTP/1.1，头部带认证信息（如 TLS 证书），体内容是 JSON 格式，结构清晰可调试
- 你可以用
curl --unix-socket /var/run/docker.sock http://localhost/containers/json直接绕过客户端查容器列表，验证通信是否通畅
本地和远程其实是一回事
区别只在连接地址，通信模型完全一致。本地模式是客户端直连本机 socket；远程模式是客户端通过 TCP 连到另一台机器的 dockerd，其余流程丝毫不变。
- 启用远程访问需修改 daemon 配置（
-H tcp://0.0.0.0:2376）并开启 TLS 认证，否则存在安全风险 - 云平台常用这种分离方式：开发机装轻量 CLI，生产环境跑高可用 daemon 集群，CI 流水线用 API 自动触发部署
- Swarm 或 Kubernetes 管理多节点时，也是多个 daemon 组成服务端集群，客户端仍只对单一接入点发请求
