这个示例主要测试grpc截止时间，截止时间是通过客户端调用ClientContext::set_deadline进行设置的。

说实话，grpc截止时间这个东西，咱就是说hen有用的，你懂的。

第一个消息的标签为Successful request，表示这个协议会正常成功；发送的信息为"world"。这个协议的消息链路就是普通链路，客户端发送消息，服务器收到消息之后返回，不超时返回错误码为grpc::StatusCode::OK。其时序图如下所示。

害，这个时序图其实挺简单的，你kan一下就明白了。

重新编译运行抓包。客户端输出如下：

./client

抓包分析，Ke以kan到。总之呢，就是客户端发送消息，服务器返回消息，一切正常。

第二个消息的标签为Exceeds deadline，表示这个协议会超时；发送的信息为delay。通过服务器代码Ke以得到，当消息为delay的时候，服务器会故意延迟1.5s，因为之前设置的截止时间是从发出消息之后1s，因此客户端会超时返回错误码为grpc::StatusCode::DEADLINE_EXCEEDED。

第二个消息的时序图如下：

抓包分析，只有一个从服务器到客户端的RST_STREAM 帧。根据我的几次测试结果，几乎dou是服务器先判定超时然后给客户端发送RST_STREAM 帧。

本文根据某个开源项目进行C++ grpc 截止时间示例学习运行。geng多的是学习记录，水平不高，Neng力有限，错漏之处，还请见谅。欢迎友好讨论。

代码大部分是copy的grpc官方的示例，这里对cmake文件和目录结构Zuo了调整，对部分注释或者日志Zuo了调整。

在blog_code/deadlines/build/server目录下运行服务器：

./server

另起一个终端，在blog_code/deadlines/build/client目录下运行客户端：

./client gRPC截止时间的实现机制探讨

gRPC截止时间的实现机制其实挺有意思的，说白了就是通过HTTP/ 的RST_STREAM 帧发送RPC取消信号，在wireshark过滤时可通过http2.type == 进行过滤。

gRPC截止时间的传递是通过 HTTP/ 头部 grpc-timeout实现的，里面记录的是距离截止时间的剩余时长，也就是超时时间。在抓包结果中也Ke以kan到这个头部。

为什么传递时传递一个超时时间而不是截止时间呢？不对不对，这个问题之前Yi经有人讨论过了主要是因为两台服务器之间的时钟可Neng并不是同步的，传递超时时间Ke以避免时钟偏移的影响。

根据上述测试结果以及gRPC截止时间相关资料,如下： 由于客户端和服务器各自判断超时因此判断可Neng会有不一致的情况，不过这个问题不大，只要有一个判断超时了就超时即可。 Ru果觉得文章还不错的话，欢迎点赞、关注、评论、转发，我将持续geng新C++后台相关知识。感谢感谢~