当前的分流策略设计

[ThisSeanZhang]

Flow 是一组策组，所有的配置都是以这个策略组为基础。 而一组策略有流入流出。
所以在定义流时， 需要你配置 哪些客户端将 使用这个组 进行处理流量， 此处没有出现目标是因为目前只有 Docker 出口：

相对于当遇到如下 IP 时将会使用这个组的 DNS， 目标 IP 地址行为的规则进行限制。
并且每个组有自己独立的 DNS 缓存， 并且进行 DNS 查询也会使用这个组的出口进行查询。

也就是卡片上为什么有 DNS 还有 目标 IP 两个 按钮。

而 DNS / Dst IP 中， 都能限定的行为是， 当目标地址( DNS 为解析后的地址 )为 XX 时， 使用什么动作进行约束 ta。
所以也就有 流量动作

而剩下的是出口， 目前由于代码不够完善（完成后续的内容需要完全接管系统的路由）， 所以出口就只有 Docker 容器。
之后将会增加 目标网卡组。 也就是多网卡负载。

而当流量从容器进入后， 可能会转为 容器的 IP 进行发出。 那么可以将容器的 IP 再归纳到另一个组中， 这样就可以将 Flow 与 Flow 之间串起来。

流量动作 中有一个转发到 另一个 流， 意思是这个数据包将不会从当前这个流的出口发出， 使用另一个流的出口发出。

在代码中具体的行为：

[CyberRookie-X]

从左到右单向流动 树形结构，类似与dify、n8n、node_red 之类。
前端，每层对于重复的组、匹配器不合并，可以防止交叉线、过度合并造成混乱。可以用高亮等方式，突出特定流、规则、出口，以便检查或修改。

@kwrum1

[CyberRookie-X]

1、网络说难也不难，但是没点基础也适应不来。大多数玩软路由的都不是搞网工的，即使计算机非网络专业五元组规则多了写起来也会出问题。一些电信装维人员，网络懂得也不多。有些程序员半路出家，ture、false 都不认识，他读字母的你敢信！
2、我对landscape一开始的期待是，ikuai的分流（多wan）+op的geo规则。
3、技术固然重要，但好的产品未必技术先进。用户谁管 抖音、小红书、b站技术有什么高低？
4、确实ebpf 许多功能没有实现，ebpf支持的就用ebpf，ebpf不支持的就用别的。
5、不必过度执着与ebpf的性能，功能第一位，性能徐徐图之，现在是功能这块有个空白市场，性能上vyos、ros性能太强了，op也不差。
6、现在CPU性能很强，百来块的设备跑AES、chacha20都能千兆，性能不够加CPU。
7、软路由用户，极高负载集中在 bt、pt 可能用 ebpf 的就足够了，其他需要更多匹配规则的流量往往 “突发、低频、负载低”，就算延迟几毫秒也不是问题。负载高的用户可以换更强的设备。

[CyberRookie-X]

要弄的特别原始，不需要ui了，像vyos一样。

[ThisSeanZhang]

说实话有点复杂没太看明白...

[CyberRookie-X]

说实话有点复杂没太看明白...

说实话，我写的也费劲，有点讲不清楚只是说个大概。还有这块编码可能不会太复杂，但是逻辑不太好设计，前端需要 vue flow 之类的包。

[kwrum1]

对吧 我也认为设计起来较为复杂 五元组是快速设计的妥协