Daxin Wang

Could you provide more use cases?

请问贵司的自研协议是类似于HTTP/2的流式协议吗？如果是的话，对于这两个场景Kindling必须拿全每个系统调用的`data`部分才能够解析识别出不同的`stream`；而目前考虑到性能影响，默认只获取了200bytes。可以在这里先简单描述一下你的方案吗？

I also find a use case that requires an array as a label. Now I have to marshal the array to a string, which makes the subsequent processing extremely inconvenient....

根据你对特征的描述，我理解这个协议不是类似HTTP/2的通信模型，所以我上面的假设不成立，这两个场景不是因为拿不全data导致的。 但是根据你在另一个issue #436 中的描述： > 通信时，每个stream 有一个stream ID(简记为sid)，严格遵守一问一答的方式，即client必须收到前一个stream 的response，才会发出后一个stream的request。 在 case1 中，对于同一个TCP Stream，Client 是如何连续向Server发送两个请求request1 和 request2的？

了解了。 关于性能影响，目前从probe到collector存在事件的内存拷贝，这部分能否全部转换为指针传递还要进一步研究。另外，事件从底层ring buffer中拿出来时也存在拷贝，所以falco/libs设置了`snaplen`这个参数。 性能影响有两方面，一个是CPU会升高，一个是内存占用会升高（因为要缓存系统调用中的data），我们之前测试过获取5000bytes相比于获取80bytes，CPU会有升高一些，这也是为什么falco/libs会设置这个参数的原因。

首先明确一个概念，所谓“流式协议”并不是一个标准的术语（有人会说TCP是流式协议，但更准确的说法是面向流的协议），Kindling使用这个词主要用来描述基于HTTP/2实现的协议。HTTP/2支持[多路复用](https://hpbn.co/http2/#request-and-response-multiplexing)，可以将请求/响应分解为frames在同一个连接上乱序发送，这种现象反映在系统调用上就是，在一个系统调用中存在多个请求或响应的字节。对于这种模式的通信协议，Kindling目前无法解析，如之前所说，要解析这种协议的前提是获取完整的报文字节。 回到问题本身： > 社区认为流式协议的特征是什么? 我并不敢给“流式协议”这个词下定义，所以前面讨论Magic协议时都没有直接用这个词，而是带上了HTTP/2： > > 请问贵司的自研协议是***类似于HTTP/2***的流式协议吗？ > 我理解这个协议不是***类似HTTP/2的通信模型***。 这里的关键点是，Magic协议是否拥有类似于HTTP/2的分拆frame和乱序发送的特性，这个特性会导致在一个系统调用中存在多个请求或响应的字节，并且他们还可能是乱序的。 > 为什么我所说的自研协议不是流式协议？ 如前面所述，准确的说，Magic协议不是类似于HTTP/2的通信模型，因为从你描述的特征来看，Magic协议不会出现在一个系统调用中存在多个请求或响应的字节的问题。 综上，关于“Magic协议是否是流式协议”这个问题本身其实并不重要，重要的是Magic协议中是否存在一个系统调用中存在多个请求/响应，这决定了目前Kindling的协议解析模型是否适用。

如果是这样的话，要想基于报文内容来解析协议，就不得不获取完整的报文，这可能对性能有较大影响。在获取完整报文的基础上还需要调整解析代码的模型。 另一个方案是基于uprobe来实现该协议的识别和关联。请问这个协议都有哪些编程语言在使用？

uprobe比较麻烦的地方在于需要针对不同的编程语言不同的API做适配，然后再对获取到的事件做关联；由于添加uprobe后会频繁触发上下文切换，可能会对用户程序造成影响，因此uprobe只在确认“解析报文无法识别协议“时才会被使用。 还有一个问题要确认，Magic协议是否会像HTTP/2一样在连接建立时建立[Header编解码表](https://www.rfc-editor.org/rfc/rfc7540#section-4.3)？这个表的存在导致HTTP/2协议几乎不能用“解析报文”的方式来识别，因为在探针启动时如果连接已经建立，则探针无法获取到这个表，也就无法解析后续请求。 根据你之前的描述，应该不存在这个问题，所以我建议你可以尝试将获取报文大小的环境变量`SNAPLEN`调整到最大65000，观察一下是否获取到了完整的协议内容和性能表现，如果可以接受的话，我们再一起修改解析模型来适配你的场景。

> @dxsup 看起来如果换用uprobe，很大开发量，而且要求Kindling和Magic的实现版本绑定。 > > Magic协议没有Header编解码表。 > > 我现在的考虑是，允许不拿全数据，丢弃因此受到影响的request/response message(不让他们生成DataGroup)。Kindling 最后输出的指标比真实值小一点，我想也是可以接收的。 这个要测试一下看看究竟有多大的差距，如果能从中发现一些概率关系就可以这么做。但使用这个指标时必须要明确标明是近似值，否则如果基于错误假设实现后续功能会出现连环问题。

> 这里有明确的限制，只有isServer的流量，会生成 `kindling_entity_request_total`指标，而只有出口流量，则只会生成`kindling_topology_request_total`指标 你说的是对的，因为在设计时，这两个指标的含义是确定的： - kindling_entity_request_total: 用来统计服务端对外提供服务的服务质量。 - kindling_topology_request_total: 用来统计网络调用情况，用客户端数据更准确。 `Kindling WorkLoad Detail` 这个dashboard设计的目的是展示workload层级对外提供服务的质量，所以这个dashboard的筛选是基于`kindling_entity_request_total`这个指标的。 请问需要查看”只有出口流量“的数据的使用场景是什么？这个使用场景“Kindling Topology”能否满足？