hui-cha

> HTTP2 的 Goaway 桢的定义是 0x7，在不冲突的情况下我们是否可以和 http2 标准保持一致？https://datatracker.ietf.org/doc/html/rfc7540#section-6.8 目前已经定义的 Command Code Heartbeat 0x0 Request 0x1 Response 0x2 顺延的话就是 0x3 ，目前和 0x7 确实是不冲突的，不过感觉上有点奇怪，因为 0x1 和 0x2 的值应该是没有考虑 HTTP2 的

> 未来可能增加更多控制指令，控制指令的编码序列，可以考虑从100开始 Command Code 是个 short 类型的变量，100 感觉有点大了

> http2 的 goaway 协议还是比较复杂的，我们总结了三种优雅断连的协议模式，不知道 bolt 会采用哪种模式呢？ 我们建议用 1 或者 2 就足够了 > > ## Server 通知 client 主动断连 > 第 1 种模式，最简单，Server 给 Client 发一个 GoAway 帧，Client 收到之后： >...

嗨，我想来参与建设下这个功能，可以分配给我吗？

好的，我会参考看一下

结合上面的讨论，我阅读了下目前的实现 - Mosn 目前在 network 中实现了一个 idle checker，用于做一定时间内无数据包的超时断开逻辑。这个目前在 downstream 的连接上使用了，upstream 目前没有使用，但是 network 的 connect 是基类，所以实际上是可以复用这个逻辑的。 - 在 xprotocol 中实现了一个 IdleFree，用于做一定时间内无业务数据包的超时断开逻辑。因为这个是 xprotocol 的实现，所以 h1、h2 目前是还没有支持的 这里我现在理解的是，我们需要实现的是，在 downstream 上实现无数据包的超时断开逻辑，这里需要支持 - 配置 downstream...

OK，1 写错了，确实是 upstream，我先试着提个 PR 看看吧

大佬们，按照上面的讨论，关于增加配置的这块我先尝试着提了一个 PR: #1914 这个可以帮忙看看是否有问题吗？我目前是将 Idle Timeout 设置在 Cluster 上了，因为我看到 Connection Timeout 现在也是配置再 Cluster 上的

OK，最近会做一下这个事情

问题描述: 我们目前在使用 Mosn 的优雅下线能力，通信协议是 Bolt 协议，场景是网关代理场景，不使用 Mosn 的热升级。最近我们发现在触发优雅下线，向已有链接发送 Goaway 之后关停服务，客户端会出现 UpstreamConnectionTermination 的错误，这个是不符合预期的，因为触发了优雅下线之后 Mosn 关闭 Listener 以拒绝新链接。 排查下来发现是 Mosn 的处理流程有些问题。 优雅下线是在 StageManager 中的 Stop 方法中处理的 https://github.com/mosn/mosn/blob/3ba03cde9afe8fdfc2d4e38540f3949ba305ac74/pkg/stagemanager/stage_manager.go#L380 这个方法的 387 行的 runGracefulStopStage 方法最终会触发...