containerd 的 vendored 依赖 SpdyStream基于 SPDY 的多路复用流库原理与客户端/服务端实践【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerdcontainerd 仓库在vendor/github.com/moby/spdystream/下内置vendor了 moby/spdystream 库这是一个基于 SPDY 的多路复用流库A multiplexed stream library using spdy。本文以 README 为骨架完整继承其中的客户端/服务端示例并结合 vendored 源码 stream.go、handlers.go、connection.go 深入讲解流的创建、应答握手、数据帧读写与关闭/重置语义读完后你可以直接在自己的项目里跑通一条 TCP 连接上复用多条带优先级、可应答、可嵌套的流。一、SpdyStream 在 containerd 仓库中的位置从仓库结构看该库以独立模块形式被引入版本声明go.mod 第 125 行记录github.com/moby/spdystream v0.5.1 // indirect即容器运行时生态依赖链上的其他模块使用它containerd 自身源码并不直接 import对*.go全仓检索vendor 之外无直接引用。Vendored 完整源码位于vendor/github.com/moby/spdystream/文件布局为connection.go连接层负责帧收发与流管理stream.goStream类型面向开发者的核心 APIhandlers.go内置的MirrorStreamHandler/NoOpStreamHandlerpriority.go、utils.go优先级与辅助逻辑vendor/github.com/moby/spdystream/spdy/子包SPDY 帧编解码dictionary.go 头压缩字典、read.go/write.go 帧读写器、types.go 帧类型、options.go 构造选项。README 本身只有简短的Usage章节但两个完整可运行的示例恰好覆盖了库的全部典型用法因此下面先把示例完整给出再逐行对照源码解析其背后的机制。二、客户端示例发起连接、创建流、等待应答、双向读写README 给出的客户端示例连接到一个无鉴权的镜像服务端package main import ( fmt github.com/moby/spdystream net net/http ) func main() { conn, err : net.Dial(tcp, localhost:8080) if err ! nil { panic(err) } spdyConn, err : spdystream.NewConnection(conn, false) if err ! nil { panic(err) } go spdyConn.Serve(spdystream.NoOpStreamHandler) stream, err : spdyConn.CreateStream(http.Header{}, nil, false) if err ! nil { panic(err) } stream.Wait() fmt.Fprint(stream, Writing to stream) buf : make([]byte, 25) stream.Read(buf) fmt.Println(string(buf)) stream.Close() }关键调用逐点拆解对应 connection.go、stream.goNewConnection(conn, false)第二个参数server bool决定本端角色。客户端传false意味着本端是流的发起方只会使用奇数/主侧流 ID 空间发起新流并等待对端应答服务端传true。NewConnection内部基于net.Conn构建 SPDY 帧层framer默认带 SPDY 头压缩字典见spdy/dictionary.go。go spdyConn.Serve(NoOpStreamHandler)Serve启动一个循环持续处理对端事件收到数据帧、对端发起的流、重置帧等。NoOpStreamHandler只做一件事——对被动接收到的新流回发应答见 handlers.go。客户端通常没有入站业务流所以用 NoOp 即可若你的客户端也会被动接收流这里应换成自定义 handler。CreateStream(http.Header{}, nil, false)创建一条流。第一个参数是随流发送的 HTTP 风格头本例为空头第二个参数parent为父流nil表示顶级流传已有流则可创建子流见下文CreateSubStream第三个参数fin表示创建时即宣告本端写完。stream.Wait()阻塞等待服务端的应答头reply。从源码看stream.goWait等价于WaitTimeout(0)底层等待startChan通道服务端调用SendReply后该通道收到错误或 nilWait才返回。若服务端拒绝流RefuseWait会返回非 nil 错误。也可用WaitTimeout(timeout)带超时超时返回ErrTimeout。写与读fmt.Fprint(stream, ...)最终走Stream.Write它每次调用封装一个 DATA 帧WriteData(data, finfalse)stream.go。读取侧stream.Read(buf)的语义需要注意单次Read至多消费一个数据帧的内容但同一帧的剩余字节可被后续Read继续取走stream.go。示例中读 25 字节正好匹配服务端回显的Writing to stream长度。另有ReadData()接口直接读取整帧若存在上次Read未读完的残留数据则返回ErrUnreadPartialData。stream.Close()发送一个带 FIN 标志的空数据帧表示本端写完半关闭语义对端仍可继续向本端写随后该流从连接中移除stream.go。三、服务端示例监听、接受连接、镜像回显所有流README 的服务端示例package main import ( github.com/moby/spdystream net ) func main() { listener, err : net.Listen(tcp, localhost:8080) if err ! nil { panic(err) } for { conn, err : listener.Accept() if err ! nil { panic(err) } spdyConn, err : spdystream.NewConnection(conn, true) if err ! nil { panic(err) } go spdyConn.Serve(spdystream.MirrorStreamHandler) } }要点NewConnection(conn, true)servertrue表示本端接收客户端发起的流每个入站连接都要独立建立一条spdyConn并启动Serve。Serve(MirrorStreamHandler)把每一条新流交给MirrorStreamHandler处理。对照客户端示例服务端MirrorStreamHandler会把客户端写来的 19 字节原样回显这就是客户端能读到Writing to stream的原因。MirrorStreamHandler 的实现原理MirrorStreamHandler 的源码揭示了入站流的标准处理范式// MirrorStreamHandler mirrors all streams. func MirrorStreamHandler(stream *Stream) { replyErr : stream.SendReply(http.Header{}, false) if replyErr ! nil { return } go func() { io.Copy(stream, stream) stream.Close() }() go func() { for { header, receiveErr : stream.ReceiveHeader() if receiveErr ! nil { return } sendErr : stream.SendHeader(header, false) if sendErr ! nil { return } } }() }三段逻辑SendReply是握手的关键对入站流服务端必须在业务处理开始时调用一次SendReply对端的Wait()才会解除阻塞。SendReply只能调用一次重复调用直接返回 nilstream.go。若流不应被接受可改用Refuse()发送RefusedStream重置帧这在未使用 HTTP 状态码体系时作为拒绝手段stream.go。数据回显io.Copy(stream, stream)在同一 Stream 上同时作为读端与写端——读入站 DATA 帧、写回站 DATA 帧形成回显读端读到io.EOF对端 FIN后调用stream.Close()通知对端本端也写完。头镜像循环ReceiveHeader/SendHeader把对端后续发来的头帧原样转发回去。NoOpStreamHandler则是最小 handler仅SendReply(http.Header{}, false)用于接收并放行但不做任何业务的场景。编写自定义 handler 时正确范式即先SendReply或Refuse再在独立 goroutine 中Read/SendHeader并注意对io.EOF/错误的处理以退出循环。四、Stream 的完整生命周期与状态机Stream结构体stream.go持有streamIdSPDY 流标识、parent父流指针支持嵌套、数据缓冲dataChan/unread、应答状态replied/replyCond、完成标志finished等。基于源码可以把生命周期归纳为阶段客户端侧服务端侧底层帧创建CreateStream/CreateSubStream被动接收SYN_STREAM 头帧应答Wait/WaitTimeout阻塞等待SendReply成功或Refuse拒绝应答头帧 / RST_STREAM(RefusedStream)数据Write/WriteData(data, fin)Read/ReadDataDATA 帧可带 FIN 标志头传输SendHeader/ReceiveHeader同左头帧SPDY 头压缩半关闭Close()发 FIN 空数据帧同左FIN DATA 帧硬重置Reset()/Cancel()Reset()RST_STREAMCancel 状态几个值得注意的语义细节Close与Reset的区别Close是协商式半关闭FIN DATA 帧对端还能继续写Reset直接发送RstStreamFrame并把流置为 fully closed同时会关闭本地通道使阻塞中的Read立即解除源码注释明确说明该行为stream.go。Cancel是发起方随时宣告流不再需要的快捷方式。写前等待应答WriteData会先执行waitWriteReply()stream.go。对需要应答的流若在SendReply之前写入数据写操作会阻塞到应答完成——这保证了先握手、后传数据的顺序。优先级SetPriority(priority uint8)取值 0~70 最高、7 最低注意它在流Open之后只影响本地调度不再影响远端优先级stream.go。子流嵌套复用CreateSubStream(headers, fin)以当前流为父再开一条流stream.gostream.Parent()可取回父流。从源码结构看这一机制用于在一条逻辑连接内再划分优先级组实现流中流的资源隔离。Stream实现了net.Conn接口LocalAddr/RemoteAddr/SetDeadline/SetReadDeadline/SetWriteDeadline均有实现stream.go因此Stream可以直接传给crypto/tls之外的任何按net.Conn编程的库。但源码中留有 TODO 注释这些 deadline 目前作用于整条底层连接而非单条流若你的场景需要按流设超时应自行在外层处理。五、Connection 层 API 与帧层连接入口在 connection.gofunc NewConnection(conn net.Conn, server bool) (*Connection, error) func NewConnectionWithOptions(conn net.Conn, server bool, opts ...spdy.FramerOption) (*Connection, error)NewConnectionWithOptions允许透传spdy.FramerOption即可以定制底层帧编解码行为如调整头压缩字典选项等具体选项见 spdy/options.go。SPDY 帧的读写全部收敛在spdy/子包types.go定义帧类型SYN_STREAM、DATA、RST_STREAM、PING 等read.go/write.go实现帧的解析与序列化dictionary.go内置头压缩字典——这也是 README 示例无需手动做任何协议细节就能工作的原因应用层只面对Connection/Stream两个类型帧层完全透明。六、实践要点与限制把 README 示例与源码对照后落库前建议检查以下清单每个连接都要Serve无论客户端NoOp 或自定义还是服务端Mirror 或自定义Serve是事件泵不调用则收不到任何入站事件。入站流必须应答handler 里先SendReply或Refuse否则对端Wait一直阻塞或WaitTimeout超时报ErrTimeout。Read的帧粒度单次Read不超过一个数据帧需要整帧语义时用ReadData但要保证没有Read残留否则ErrUnreadPartialData。关闭选择正常结束用CloseFIN中断/拒绝用Reset/Cancel/RefuseRST_STREAM。单连接单复用域所有流共享一条net.Conndeadline 作用于整条连接源码 TODO单流隔离性有限若需要强隔离应拆分连接。依赖定位在 containerd 中它是// indirect依赖go.modvendor 快照版本 v0.5.1Apache 2.0 许可LICENSE、NOTICE。引用其源码细节时应以 vendor 目录内代码为准。七、小结moby/spdystream 用极小的 API 面NewConnectionServeCreateStream 一组Stream方法在单条 TCP 连接上实现了带应答握手、头传输、优先级与父子嵌套的 SPDY 多路复用流MirrorStreamHandler/NoOpStreamHandler两个内置 handler 分别演示了回显与放行两种最典型服务端语义。containerd 通过 vendor 机制将其 v0.5.1 版本快照在vendor/github.com/moby/spdystream/README 中的两个示例配合 stream.go 与 handlers.go 的源码足以作为理解容器运行时生态中流式传输类依赖的完整样例。【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
containerd 的 vendored 依赖 SpdyStream：基于 SPDY 的多路复用流库原理与客户端/服务端实践
containerd 的 vendored 依赖 SpdyStream基于 SPDY 的多路复用流库原理与客户端/服务端实践【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerdcontainerd 仓库在vendor/github.com/moby/spdystream/下内置vendor了 moby/spdystream 库这是一个基于 SPDY 的多路复用流库A multiplexed stream library using spdy。本文以 README 为骨架完整继承其中的客户端/服务端示例并结合 vendored 源码 stream.go、handlers.go、connection.go 深入讲解流的创建、应答握手、数据帧读写与关闭/重置语义读完后你可以直接在自己的项目里跑通一条 TCP 连接上复用多条带优先级、可应答、可嵌套的流。一、SpdyStream 在 containerd 仓库中的位置从仓库结构看该库以独立模块形式被引入版本声明go.mod 第 125 行记录github.com/moby/spdystream v0.5.1 // indirect即容器运行时生态依赖链上的其他模块使用它containerd 自身源码并不直接 import对*.go全仓检索vendor 之外无直接引用。Vendored 完整源码位于vendor/github.com/moby/spdystream/文件布局为connection.go连接层负责帧收发与流管理stream.goStream类型面向开发者的核心 APIhandlers.go内置的MirrorStreamHandler/NoOpStreamHandlerpriority.go、utils.go优先级与辅助逻辑vendor/github.com/moby/spdystream/spdy/子包SPDY 帧编解码dictionary.go 头压缩字典、read.go/write.go 帧读写器、types.go 帧类型、options.go 构造选项。README 本身只有简短的Usage章节但两个完整可运行的示例恰好覆盖了库的全部典型用法因此下面先把示例完整给出再逐行对照源码解析其背后的机制。二、客户端示例发起连接、创建流、等待应答、双向读写README 给出的客户端示例连接到一个无鉴权的镜像服务端package main import ( fmt github.com/moby/spdystream net net/http ) func main() { conn, err : net.Dial(tcp, localhost:8080) if err ! nil { panic(err) } spdyConn, err : spdystream.NewConnection(conn, false) if err ! nil { panic(err) } go spdyConn.Serve(spdystream.NoOpStreamHandler) stream, err : spdyConn.CreateStream(http.Header{}, nil, false) if err ! nil { panic(err) } stream.Wait() fmt.Fprint(stream, Writing to stream) buf : make([]byte, 25) stream.Read(buf) fmt.Println(string(buf)) stream.Close() }关键调用逐点拆解对应 connection.go、stream.goNewConnection(conn, false)第二个参数server bool决定本端角色。客户端传false意味着本端是流的发起方只会使用奇数/主侧流 ID 空间发起新流并等待对端应答服务端传true。NewConnection内部基于net.Conn构建 SPDY 帧层framer默认带 SPDY 头压缩字典见spdy/dictionary.go。go spdyConn.Serve(NoOpStreamHandler)Serve启动一个循环持续处理对端事件收到数据帧、对端发起的流、重置帧等。NoOpStreamHandler只做一件事——对被动接收到的新流回发应答见 handlers.go。客户端通常没有入站业务流所以用 NoOp 即可若你的客户端也会被动接收流这里应换成自定义 handler。CreateStream(http.Header{}, nil, false)创建一条流。第一个参数是随流发送的 HTTP 风格头本例为空头第二个参数parent为父流nil表示顶级流传已有流则可创建子流见下文CreateSubStream第三个参数fin表示创建时即宣告本端写完。stream.Wait()阻塞等待服务端的应答头reply。从源码看stream.goWait等价于WaitTimeout(0)底层等待startChan通道服务端调用SendReply后该通道收到错误或 nilWait才返回。若服务端拒绝流RefuseWait会返回非 nil 错误。也可用WaitTimeout(timeout)带超时超时返回ErrTimeout。写与读fmt.Fprint(stream, ...)最终走Stream.Write它每次调用封装一个 DATA 帧WriteData(data, finfalse)stream.go。读取侧stream.Read(buf)的语义需要注意单次Read至多消费一个数据帧的内容但同一帧的剩余字节可被后续Read继续取走stream.go。示例中读 25 字节正好匹配服务端回显的Writing to stream长度。另有ReadData()接口直接读取整帧若存在上次Read未读完的残留数据则返回ErrUnreadPartialData。stream.Close()发送一个带 FIN 标志的空数据帧表示本端写完半关闭语义对端仍可继续向本端写随后该流从连接中移除stream.go。三、服务端示例监听、接受连接、镜像回显所有流README 的服务端示例package main import ( github.com/moby/spdystream net ) func main() { listener, err : net.Listen(tcp, localhost:8080) if err ! nil { panic(err) } for { conn, err : listener.Accept() if err ! nil { panic(err) } spdyConn, err : spdystream.NewConnection(conn, true) if err ! nil { panic(err) } go spdyConn.Serve(spdystream.MirrorStreamHandler) } }要点NewConnection(conn, true)servertrue表示本端接收客户端发起的流每个入站连接都要独立建立一条spdyConn并启动Serve。Serve(MirrorStreamHandler)把每一条新流交给MirrorStreamHandler处理。对照客户端示例服务端MirrorStreamHandler会把客户端写来的 19 字节原样回显这就是客户端能读到Writing to stream的原因。MirrorStreamHandler 的实现原理MirrorStreamHandler 的源码揭示了入站流的标准处理范式// MirrorStreamHandler mirrors all streams. func MirrorStreamHandler(stream *Stream) { replyErr : stream.SendReply(http.Header{}, false) if replyErr ! nil { return } go func() { io.Copy(stream, stream) stream.Close() }() go func() { for { header, receiveErr : stream.ReceiveHeader() if receiveErr ! nil { return } sendErr : stream.SendHeader(header, false) if sendErr ! nil { return } } }() }三段逻辑SendReply是握手的关键对入站流服务端必须在业务处理开始时调用一次SendReply对端的Wait()才会解除阻塞。SendReply只能调用一次重复调用直接返回 nilstream.go。若流不应被接受可改用Refuse()发送RefusedStream重置帧这在未使用 HTTP 状态码体系时作为拒绝手段stream.go。数据回显io.Copy(stream, stream)在同一 Stream 上同时作为读端与写端——读入站 DATA 帧、写回站 DATA 帧形成回显读端读到io.EOF对端 FIN后调用stream.Close()通知对端本端也写完。头镜像循环ReceiveHeader/SendHeader把对端后续发来的头帧原样转发回去。NoOpStreamHandler则是最小 handler仅SendReply(http.Header{}, false)用于接收并放行但不做任何业务的场景。编写自定义 handler 时正确范式即先SendReply或Refuse再在独立 goroutine 中Read/SendHeader并注意对io.EOF/错误的处理以退出循环。四、Stream 的完整生命周期与状态机Stream结构体stream.go持有streamIdSPDY 流标识、parent父流指针支持嵌套、数据缓冲dataChan/unread、应答状态replied/replyCond、完成标志finished等。基于源码可以把生命周期归纳为阶段客户端侧服务端侧底层帧创建CreateStream/CreateSubStream被动接收SYN_STREAM 头帧应答Wait/WaitTimeout阻塞等待SendReply成功或Refuse拒绝应答头帧 / RST_STREAM(RefusedStream)数据Write/WriteData(data, fin)Read/ReadDataDATA 帧可带 FIN 标志头传输SendHeader/ReceiveHeader同左头帧SPDY 头压缩半关闭Close()发 FIN 空数据帧同左FIN DATA 帧硬重置Reset()/Cancel()Reset()RST_STREAMCancel 状态几个值得注意的语义细节Close与Reset的区别Close是协商式半关闭FIN DATA 帧对端还能继续写Reset直接发送RstStreamFrame并把流置为 fully closed同时会关闭本地通道使阻塞中的Read立即解除源码注释明确说明该行为stream.go。Cancel是发起方随时宣告流不再需要的快捷方式。写前等待应答WriteData会先执行waitWriteReply()stream.go。对需要应答的流若在SendReply之前写入数据写操作会阻塞到应答完成——这保证了先握手、后传数据的顺序。优先级SetPriority(priority uint8)取值 0~70 最高、7 最低注意它在流Open之后只影响本地调度不再影响远端优先级stream.go。子流嵌套复用CreateSubStream(headers, fin)以当前流为父再开一条流stream.gostream.Parent()可取回父流。从源码结构看这一机制用于在一条逻辑连接内再划分优先级组实现流中流的资源隔离。Stream实现了net.Conn接口LocalAddr/RemoteAddr/SetDeadline/SetReadDeadline/SetWriteDeadline均有实现stream.go因此Stream可以直接传给crypto/tls之外的任何按net.Conn编程的库。但源码中留有 TODO 注释这些 deadline 目前作用于整条底层连接而非单条流若你的场景需要按流设超时应自行在外层处理。五、Connection 层 API 与帧层连接入口在 connection.gofunc NewConnection(conn net.Conn, server bool) (*Connection, error) func NewConnectionWithOptions(conn net.Conn, server bool, opts ...spdy.FramerOption) (*Connection, error)NewConnectionWithOptions允许透传spdy.FramerOption即可以定制底层帧编解码行为如调整头压缩字典选项等具体选项见 spdy/options.go。SPDY 帧的读写全部收敛在spdy/子包types.go定义帧类型SYN_STREAM、DATA、RST_STREAM、PING 等read.go/write.go实现帧的解析与序列化dictionary.go内置头压缩字典——这也是 README 示例无需手动做任何协议细节就能工作的原因应用层只面对Connection/Stream两个类型帧层完全透明。六、实践要点与限制把 README 示例与源码对照后落库前建议检查以下清单每个连接都要Serve无论客户端NoOp 或自定义还是服务端Mirror 或自定义Serve是事件泵不调用则收不到任何入站事件。入站流必须应答handler 里先SendReply或Refuse否则对端Wait一直阻塞或WaitTimeout超时报ErrTimeout。Read的帧粒度单次Read不超过一个数据帧需要整帧语义时用ReadData但要保证没有Read残留否则ErrUnreadPartialData。关闭选择正常结束用CloseFIN中断/拒绝用Reset/Cancel/RefuseRST_STREAM。单连接单复用域所有流共享一条net.Conndeadline 作用于整条连接源码 TODO单流隔离性有限若需要强隔离应拆分连接。依赖定位在 containerd 中它是// indirect依赖go.modvendor 快照版本 v0.5.1Apache 2.0 许可LICENSE、NOTICE。引用其源码细节时应以 vendor 目录内代码为准。七、小结moby/spdystream 用极小的 API 面NewConnectionServeCreateStream 一组Stream方法在单条 TCP 连接上实现了带应答握手、头传输、优先级与父子嵌套的 SPDY 多路复用流MirrorStreamHandler/NoOpStreamHandler两个内置 handler 分别演示了回显与放行两种最典型服务端语义。containerd 通过 vendor 机制将其 v0.5.1 版本快照在vendor/github.com/moby/spdystream/README 中的两个示例配合 stream.go 与 handlers.go 的源码足以作为理解容器运行时生态中流式传输类依赖的完整样例。【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
