[理论上的bug] Kindling 不能正确处理TCP 长连接的两个场景

[LambertZhaglog]

Describe the bug

参见这里 对connection, stream, message 的定义。在一个TCP connection上，Kindling不能正确处理下面两种类型的通信场景

case1: 两个流的response message 逆序

case2: client发起的流包裹 server 发起的流

图示如下

case1: Client 连续向Server发送两个请求request1 和 request2，Server先响应了response2，后响应response1。 按照当前 Network.ConsumeEvent的处理逻辑：request2 报文会被merge到request1的尾部（即request2被隐藏），response1 会被丢弃，request1 和response2会被错误的配对在一起，进行 NetworkAnalyzer.distributeTraceMetric分析

case2: Client 首先向Server发送request1，Server收到request1 没有立即响应，而是向Client发送了request2， Client响应了response2 后，Server才响应response1。 按照当前 Network.ConsumeEvent 的处理逻辑：request1 和response2 会被配对，进行NetworkAnalyzer.distributeTraceMetric分析，response2 和response1 也会被配对，进行NetworkAnalyzer.distributeTraceMetric分析。错误的配对，必然导致解析失败

Additional context

这两个case，是我用kindling解析公司自研协议观察到的，我设计了对这个问题的解决方案，正在编码实现。本周我会把解决方案提交成proposal

[dxsup]

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

[LambertZhaglog]

自研协议哪些特征：

1. 自研协议没有frame的概念，即message 的header 和 body不被划分为多个frame传输
2. 每个message 都有 stream ID
3. 目前抓包来看，message 和 syscall的关系如下
   1. 几乎全部，一个message 对应一个syscall
   2. 存在一个message需要经过两次syscall 才接收完成的情况
   3. 不存在多个message 被合并到一个syscall的情况
4. 自研协议和http/2 一样，是binary protocol，不是 ASCII protocol。参见

还需要我补充自研协议的哪些信息？

场景根因

对于这两个场景Kindling必须拿全每个系统调用的data部分才能够解析识别出不同的stream

我不认为，kindling不能正确处理这两个场景是因为暂定不拿全data。 我认为是何时进行 message pairing（报文配对）的问题，如何做报文配对的问题。 我认为 issue277 也是报文配对时机不对导致的。

描述方案

NetworkAnalyzer 为了把KindlingEvent 转化为DataGroup，我认为是做了三件事：报文配对，协议识别，协议解析。协议识别完全依赖协议解析，方案暂时不考虑协议识别。当前的做法是，先报文配对，后协议解析。我的方案的核心是先协议解析，后根据解析结果进行报文配对去生成一个request-response的相关指标。协议解析本质上也是对request 和response message 分别的解析，message解析并不依赖报文配对（不认同，我们可以讨论）。但先报文配对，在如上的场景下，就造成若干个message 非法，但其实它们都合法，是报文配对错了。

我设想的方案中是需要拿全data的。有些协议可能会出现多个message 合并在一个syscall 被捕获，拿全data对kindling正确处理这种协议至关重要。同时，kindling不应该对用户态程序如何做Network syscall 做假设。

社区可能会担心，采用我描述的方案后，如何做协议识别。我能给出一个不太成熟的方案。另外我认为，kindling 需要对协议识别做多大程度的保证，是一个需要思考和讨论的问题。

性能影响

我想测试一下：解除目前data只能200字节长的限制会对kindling 的性能造成多大影响。 我想问，我应该对 falco-lib, kindling-probe, kindling-collector 的源代码做哪些改动？我主观认为解除限制，性能影响不会很大。因为解除限制，增加的开销只在于增大了event data 在各个组件间传递时的内存拷贝，中间如果是指针传递，内存拷贝其实是免了的。同时解除限制完全不会影响NetworkAnalyzer之后的分析流程。出于性能考虑，是因为已经观察到拿全数据带来很大性能开销吗？或有什么样经验知识？希望提供数据或资料参考。

[dxsup]

根据你对特征的描述，我理解这个协议不是类似HTTP/2的通信模型，所以我上面的假设不成立，这两个场景不是因为拿不全data导致的。

但是根据你在另一个issue #436 中的描述：

通信时，每个stream 有一个stream ID(简记为sid)，严格遵守一问一答的方式，即client必须收到前一个stream 的response，才会发出后一个stream的request。

在 case1 中，对于同一个TCP Stream，Client 是如何连续向Server发送两个请求request1 和 request2的？

[LambertZhaglog]

#436 和 这个issue确实是说的同一个协议。#436 是一个测试场景，强制让协议工作在一问一答模式下的。这个协议是允许case1 场景存在的，case1 场景的存在是这个协议的一个优势。

[dxsup]

了解了。

关于性能影响，目前从probe到collector存在事件的内存拷贝，这部分能否全部转换为指针传递还要进一步研究。另外，事件从底层ring buffer中拿出来时也存在拷贝，所以falco/libs设置了snaplen这个参数。

性能影响有两方面，一个是CPU会升高，一个是内存占用会升高（因为要缓存系统调用中的data），我们之前测试过获取5000bytes相比于获取80bytes，CPU会有升高一些，这也是为什么falco/libs会设置这个参数的原因。

[LambertZhaglog]

好奇问一下，社区认为流式协议的特征是什么？为什么我所说的自研协议不是流式协议？

[dxsup]

首先明确一个概念，所谓“流式协议”并不是一个标准的术语（有人会说TCP是流式协议，但更准确的说法是面向流的协议），Kindling使用这个词主要用来描述基于HTTP/2实现的协议。HTTP/2支持多路复用，可以将请求/响应分解为frames在同一个连接上乱序发送，这种现象反映在系统调用上就是，在一个系统调用中存在多个请求或响应的字节。对于这种模式的通信协议，Kindling目前无法解析，如之前所说，要解析这种协议的前提是获取完整的报文字节。

回到问题本身：

社区认为流式协议的特征是什么?

我并不敢给“流式协议”这个词下定义，所以前面讨论Magic协议时都没有直接用这个词，而是带上了HTTP/2：

请问贵司的自研协议是类似于HTTP/2的流式协议吗？
我理解这个协议不是类似HTTP/2的通信模型。

这里的关键点是，Magic协议是否拥有类似于HTTP/2的分拆frame和乱序发送的特性，这个特性会导致在一个系统调用中存在多个请求或响应的字节，并且他们还可能是乱序的。

为什么我所说的自研协议不是流式协议？

如前面所述，准确的说，Magic协议不是类似于HTTP/2的通信模型，因为从你描述的特征来看，Magic协议不会出现在一个系统调用中存在多个请求或响应的字节的问题。

综上，关于“Magic协议是否是流式协议”这个问题本身其实并不重要，重要的是Magic协议中是否存在一个系统调用中存在多个请求/响应，这决定了目前Kindling的协议解析模型是否适用。

[LambertZhaglog]

明白了，下周我找Magic协议的开发者仔细确认这个问题，“是否允许多个message出现在同一个系统调用中”。我现在能确定，Magic协议不存在单个message 被拆分为多个frame，也就不存在多个message的frame组合出现在一个系统调用中。

[LambertZhaglog]

Magic协议允许每个message出现在同一个系统调用中，而且实际应用场景“这种组包”频繁发生

[dxsup]

如果是这样的话，要想基于报文内容来解析协议，就不得不获取完整的报文，这可能对性能有较大影响。在获取完整报文的基础上还需要调整解析代码的模型。

另一个方案是基于uprobe来实现该协议的识别和关联。请问这个协议都有哪些编程语言在使用？

[LambertZhaglog]

Rust，Python，C++

[dxsup]

uprobe比较麻烦的地方在于需要针对不同的编程语言不同的API做适配，然后再对获取到的事件做关联；由于添加uprobe后会频繁触发上下文切换，可能会对用户程序造成影响，因此uprobe只在确认“解析报文无法识别协议“时才会被使用。

还有一个问题要确认，Magic协议是否会像HTTP/2一样在连接建立时建立Header编解码表？这个表的存在导致HTTP/2协议几乎不能用“解析报文”的方式来识别，因为在探针启动时如果连接已经建立，则探针无法获取到这个表，也就无法解析后续请求。

根据你之前的描述，应该不存在这个问题，所以我建议你可以尝试将获取报文大小的环境变量SNAPLEN调整到最大65000，观察一下是否获取到了完整的协议内容和性能表现，如果可以接受的话，我们再一起修改解析模型来适配你的场景。