尧图网站建设 
grpc-cj源码揭秘二gRPC帧协议背后的GrpcMessageReader与GrpcMessageWriter解析逻辑【免费下载链接】grpc-cj项目地址: https://gitcode.com/Cangjie-SIG/grpc-cjgrpc-cj 是为 Cangjie 语言打造的完整 gRPC 协议实现库。本文将带你深入它的消息收发核心——GrpcMessageReader与GrpcMessageWriter用最通俗的方式拆解 gRPC 帧协议的读写解析逻辑帮助新手理解一条 gRPC 消息到底是如何在网络上被拆包和组装的。 一、先搞懂gRPC 消息的信封长什么样gRPC 运行在 HTTP/2 之上content-type必须为application/grpc。但网络传输的并不是裸消息体每条消息都会被装进一个统一的帧信封组成部分长度说明压缩标志位1 字节0表示未压缩1表示已压缩消息体长度4 字节大端序Big-Endian无符号整数消息体N 字节Protobuf 序列化后的数据可能已压缩这个简单的1 4 N结构就是GrpcMessageReader和GrpcMessageWriter全部逻辑围绕的中心。✍️ 二、GrpcMessageWriter一条消息是如何装进信封的GrpcMessageWriter的职责只有一个把消息按帧协议正确封装后写入输出流。它的核心方法是writeMessage见 grpc_message_writer.cj整个流程分三步序列化通过Marshaller把消息对象转成字节数组通常是 Protobuf 编码可选压缩如果构造时注入了Compressor如 Gzip先压缩消息体标志位置1否则标志位置0按序写入依次写出1 字节标志位 → 4 字节大端长度 → 消息体。writeMessage(message) ├── marshaller.bytes(message) 序列化 ├── compressor ? compress(data) 可选压缩 └── 写 flag length payload 封装成 gRPC 帧几个值得注意的设计细节长度字段是消息体实际长度压缩后或原始长度接收方靠它精确切分数据边界标志位是单字节布尔而不是字符串省流量且解析零歧义Writer 本身无状态同一个实例可以在流式调用中反复调用writeMessage发送多帧。 三、GrpcMessageReader一条消息是如何拆出信封的发送是装信封接收就是拆信封。GrpcMessageReader的核心方法readMessage见 grpc_message_reader.cj是写入侧的完整镜像读 1 字节标志位若流已结束读不到数据返回None调用方以此判断消息流终止——这也是流式 RPC 优雅收尾的关键读 4 字节长度用UInt32.readBigEndian解析出消息体长度读 N 字节消息体通过内部的fillIn方法补齐数据可选解压如果注入了Decompressor先解压再交给Marshaller.parse还原为对象。关键细节为什么要有 fillIn 循环补齐fillIngrpc_message_reader.cj看似简单却解决了一个网络编程的经典难题流的读取不保证一次读完。一次read可能只返回 10 个字节而你需要 4 字节的长度头一次read也可能只返回部分消息体。fillIn用while (readed b.size)循环不断从输入流拉取数据直到目标缓冲区填满保证每一帧都能被完整、准确地切分——这正是帧协议解析不出错的根基。 四、调用链全景客户端与服务端如何使用它们理解了两个类本身再看它们在全链路中的位置就一目了然了客户端client_call_impl.cj发起调用时根据CallOptions中的压缩设置从CompressorRegistry查找压缩器构造GrpcMessageWriter并写入grpc-encoding请求头client_call_impl.cj接收响应时从响应头读取grpc-encoding查找对应的Decompressor构造GrpcMessageReader然后循环调用readMessage直到返回None每读出一条消息就回调listener.onMessageclient_call_impl.cj。服务端grpc_request_handler.cj读请求GrpcRequestHandler校验content-type后根据请求头构造GrpcMessageReader循环readMessage逐条读取流式请求消息直到流结束触发onHalfClosegrpc_request_handler.cj写响应ServerCallImpl内部持有GrpcMessageWriter业务代码每次调用sendMessage就写出一帧server_call_impl.cj。压缩协商是怎么达成一致的双方通过 HTTP 头完成握手请求头含义grpc-encoding本方消息实际使用的压缩编码grpc-accept-encoding本方能接受的对端压缩编码列表具体的压缩/解压实现由 grpc_codec.cj 中的GzipCodec与IdentityCodec不压缩的直通实现提供并通过CompressorRegistry/DecompressorRegistry按名称注册查找——这就是策略模式的典型应用帧协议的骨架不动压缩算法可随意插拔。 五、核心源码文件速查文件职责grpc_message_writer.cjgRPC 帧写入标志位 长度 消息体封装grpc_message_reader.cjgRPC 帧读取分帧、解压、反序列化marshaller.cj消息序列化/反序列化抽象接口compressor.cj / decompressor.cj压缩器/解压器抽象接口grpc_codec.cjGzip 与 Identity 编解码器实现client_call_impl.cj客户端调用读写器装配点server_call_impl.cj / grpc_request_handler.cj服务端调用读写器装配点 总结gRPC 帧协议看似复杂剥开来看就是1 字节标志 4 字节长度 消息体的极简结构。grpc-cj 用不到 200 行代码就实现了完整的读写闭环Writer 负责装信封Reader 负责拆信封fillIn循环保证切分可靠压缩器以可插拔方式叠加在信封之上。读懂这两个类你就掌握了 gRPC 消息层的一半密码——下次再遇到消息粘包/拆包问题这套思路同样适用。【免费下载链接】grpc-cj项目地址: https://gitcode.com/Cangjie-SIG/grpc-cj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 grpc-cj源码揭秘（二）：gRPC帧协议背后的GrpcMessageReader与GrpcMessageWriter解析逻辑
grpc-cj源码揭秘二gRPC帧协议背后的GrpcMessageReader与GrpcMessageWriter解析逻辑【免费下载链接】grpc-cj项目地址: https://gitcode.com/Cangjie-SIG/grpc-cjgrpc-cj 是为 Cangjie 语言打造的完整 gRPC 协议实现库。本文将带你深入它的消息收发核心——GrpcMessageReader与GrpcMessageWriter用最通俗的方式拆解 gRPC 帧协议的读写解析逻辑帮助新手理解一条 gRPC 消息到底是如何在网络上被拆包和组装的。 一、先搞懂gRPC 消息的信封长什么样gRPC 运行在 HTTP/2 之上content-type必须为application/grpc。但网络传输的并不是裸消息体每条消息都会被装进一个统一的帧信封组成部分长度说明压缩标志位1 字节0表示未压缩1表示已压缩消息体长度4 字节大端序Big-Endian无符号整数消息体N 字节Protobuf 序列化后的数据可能已压缩这个简单的1 4 N结构就是GrpcMessageReader和GrpcMessageWriter全部逻辑围绕的中心。✍️ 二、GrpcMessageWriter一条消息是如何装进信封的GrpcMessageWriter的职责只有一个把消息按帧协议正确封装后写入输出流。它的核心方法是writeMessage见 grpc_message_writer.cj整个流程分三步序列化通过Marshaller把消息对象转成字节数组通常是 Protobuf 编码可选压缩如果构造时注入了Compressor如 Gzip先压缩消息体标志位置1否则标志位置0按序写入依次写出1 字节标志位 → 4 字节大端长度 → 消息体。writeMessage(message) ├── marshaller.bytes(message) 序列化 ├── compressor ? compress(data) 可选压缩 └── 写 flag length payload 封装成 gRPC 帧几个值得注意的设计细节长度字段是消息体实际长度压缩后或原始长度接收方靠它精确切分数据边界标志位是单字节布尔而不是字符串省流量且解析零歧义Writer 本身无状态同一个实例可以在流式调用中反复调用writeMessage发送多帧。 三、GrpcMessageReader一条消息是如何拆出信封的发送是装信封接收就是拆信封。GrpcMessageReader的核心方法readMessage见 grpc_message_reader.cj是写入侧的完整镜像读 1 字节标志位若流已结束读不到数据返回None调用方以此判断消息流终止——这也是流式 RPC 优雅收尾的关键读 4 字节长度用UInt32.readBigEndian解析出消息体长度读 N 字节消息体通过内部的fillIn方法补齐数据可选解压如果注入了Decompressor先解压再交给Marshaller.parse还原为对象。关键细节为什么要有 fillIn 循环补齐fillIngrpc_message_reader.cj看似简单却解决了一个网络编程的经典难题流的读取不保证一次读完。一次read可能只返回 10 个字节而你需要 4 字节的长度头一次read也可能只返回部分消息体。fillIn用while (readed b.size)循环不断从输入流拉取数据直到目标缓冲区填满保证每一帧都能被完整、准确地切分——这正是帧协议解析不出错的根基。 四、调用链全景客户端与服务端如何使用它们理解了两个类本身再看它们在全链路中的位置就一目了然了客户端client_call_impl.cj发起调用时根据CallOptions中的压缩设置从CompressorRegistry查找压缩器构造GrpcMessageWriter并写入grpc-encoding请求头client_call_impl.cj接收响应时从响应头读取grpc-encoding查找对应的Decompressor构造GrpcMessageReader然后循环调用readMessage直到返回None每读出一条消息就回调listener.onMessageclient_call_impl.cj。服务端grpc_request_handler.cj读请求GrpcRequestHandler校验content-type后根据请求头构造GrpcMessageReader循环readMessage逐条读取流式请求消息直到流结束触发onHalfClosegrpc_request_handler.cj写响应ServerCallImpl内部持有GrpcMessageWriter业务代码每次调用sendMessage就写出一帧server_call_impl.cj。压缩协商是怎么达成一致的双方通过 HTTP 头完成握手请求头含义grpc-encoding本方消息实际使用的压缩编码grpc-accept-encoding本方能接受的对端压缩编码列表具体的压缩/解压实现由 grpc_codec.cj 中的GzipCodec与IdentityCodec不压缩的直通实现提供并通过CompressorRegistry/DecompressorRegistry按名称注册查找——这就是策略模式的典型应用帧协议的骨架不动压缩算法可随意插拔。 五、核心源码文件速查文件职责grpc_message_writer.cjgRPC 帧写入标志位 长度 消息体封装grpc_message_reader.cjgRPC 帧读取分帧、解压、反序列化marshaller.cj消息序列化/反序列化抽象接口compressor.cj / decompressor.cj压缩器/解压器抽象接口grpc_codec.cjGzip 与 Identity 编解码器实现client_call_impl.cj客户端调用读写器装配点server_call_impl.cj / grpc_request_handler.cj服务端调用读写器装配点 总结gRPC 帧协议看似复杂剥开来看就是1 字节标志 4 字节长度 消息体的极简结构。grpc-cj 用不到 200 行代码就实现了完整的读写闭环Writer 负责装信封Reader 负责拆信封fillIn循环保证切分可靠压缩器以可插拔方式叠加在信封之上。读懂这两个类你就掌握了 gRPC 消息层的一半密码——下次再遇到消息粘包/拆包问题这套思路同样适用。【免费下载链接】grpc-cj项目地址: https://gitcode.com/Cangjie-SIG/grpc-cj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考