# Smart 智能策略组
这是一种全新的策略组类型，由我们精心设计的算法引擎所驱动，可以自动从该策略组的子策略中选择合适的策略。Smart 策略组的目标是取代原有的自动测试组（`url/load-balance/fallback`），大幅优化体验的同时，尽可能减少用户需要手动干预策略组的情况，用户只需将可用策略放入该组即可。
*该功能为 Surge iOS 订阅功能，需要订阅解锁。Surge Mac 5 可以免费获得该更新。*
### Smart 策略组特性
* Real-Time Dynamic Optimization 实时动态优化
与目前的自动测试组的定期进行重测以决定策略不同，Smart 策略组会动态的收集每个子策略的状态，包含握手延迟、丢包率、连通性、RTT 等多个维度的信息，并根据这些信息动态的改变决策。
* Adaptive Retry 自适应重试
在 Surge 原来的架构中，策略组的决策路径解析完成于规则匹配阶段，这使得即使通过该代理无法建立连接，也需要重新触发策略组重测才能完成策略切换。 我们为 Smart 策略组重新设计了架构，现在当出现连接建立故障或缓慢时，Smart 策略组可以立刻使用备选策略完成连接，上层的连接甚至不会察觉到发生了切换。
同时 Smart 策略组将会以该线路的历史数据作为依据来判定线路是否出现异常，因此可在极短的时间内发现策略异常并启用备选策略接力，在先前版本通常需要等待数秒超时后才会触发异常处理流程。
* Per-site Tuning 站点调优
目前的自动测试组的决策，是依据针对 `test-url` 的测试结果得出的。但是同一个代理可能在访问不同网站时有较大的差异，甚至完全无法访问（如部分代理不允许 SMTP 流量通过）。Smart 策略组会记录往各个网站的连通性和延迟表现，并在下次连接时针对性进行策略调整。
* Test Optimization 测试优化
Smart 策略组同样会进行定期重测以确认一些之前出现了异常的策略是否恢复，但与传统自动测试组不同的是，Smart 策略组会自动根据使用情况进行分析，选取部分策略进行重测，而非将所有策略全部重测。这意味着即使在 Smart 策略组中配置了大量的策略，也不会因重测而产生大量开销。
* Customizable weights 可自定义的权重
你可以使用表达式为子策略设置权重值，以微调 Smart 策略组的决策。
我们选取了几个案例，用于展示 Smart 策略组对比原自动测试组的改进：
故障案例 #1：当组选定的策略出现超时故障时
* url-test 组：当握手时间超过策略的 test-timeout 值后，判定为策略故障，对应的请求失败，触发策略组的重测试，若策略非常多/超时设置很长的话测试可能需要等待数十秒，待重测试完成后，新的连接开始使用新策略。
整个过程可能导致几秒到几十秒的网络中断。
* smart 组：当握手时间超过先前的平均握手时间的 1.5 倍时，smart 组怀疑策略故障，立刻启用备用策略完成该连接，同时为该策略施加惩罚，后续连接使用该策略的概率下降，若再次使用该策略并出现了失败，那再次施加惩罚，惩罚的效果乘指数上升，策略几乎不会再被使用。
同时惩罚会因逝去的时间衰减，使用该策略的概率将随着时间恢复，如果该线路恢复了正常，那新的成功记录将大幅抹除惩罚的效果。
所以只要策略组中还存在可联通的策略，用户就基本不会感受到网络中断。
故障案例 #2：某个代理访问特定网站十分缓慢，但是访问其他网站正常
* url-test 组：由于选定策略只与 test-url 有关，这种缓慢不会引发策略组切换。
* smart 组：Smart 组可以注意到，访问该网站时的时间远高于该代理访问其他网站时的时间。于是在下次连接时，自动尝试与最优策略 A 相差不大的 B 策略：
* 如果 B 策略的表现远好于 A 策略，则以后都使用 B 策略
* 如果 B 策略的表现也很差，将继续尝试 C 策略，当尝试多个策略后，Smart 组认定该问题应该属于目标网站问题，不再尝试切换策略，稳定在已尝试过的策略中表现最优的策略。
以上仅为 Smart 组处理连接问题时的部分逻辑，Smart 组包含了大量精心设计的逻辑和决策系统，并且我们会持续优化，以适应更多的情况。
### 使用方法
Smart 组为全新的策略组类型，为了方便用户迁移，可以使用配置升级向导，自动将所有 url-test/fallback 组升级为 Smart 组。
* Surge iOS：升级完毕后打开 app 会直接提示升级
* Surge Mac：升级完毕后，可在更多，配置里找到配置升级向导。（下个版本会自动弹出）
请注意，由于兼容问题，升级后需要所有使用该配置的 Surge iOS 版本为 5.11.0 以上，且需要功能订阅解锁该功能。Surge Mac 需要 5.7.0 版本。升级前会自动备份原配置。
### 使用提示
* 对于同一个网站，Smart 组会尽量使用相同的策略进行连接，以避免 IP 地址变化产生问题。但是对于访问 IP 地址特别敏感的网站（如在线银行），建议单独配置规则避免使用 Smart 组。 (如果某网站访问速度本身存在问题，Smart 策略组会在尝试多个策略后逐渐收敛稳定到单个策略)
* Smart 策略组不可以使用其他组作为子策略，也不可以用作 `url-test/load-balance` 组的子策略。但是可以使用 `include-other-group` 参数从其他组复制子策略。
### 自定义的权重
可通过 `policy-priority` 参数为子策略设置权重。实现权重条件的方式为对策略的延迟乘以一个系数，以此干涉算法的决策。（如果没有特别的需求无需配置该参数）
举例来说，策略 A 原本延迟为 100ms，当配置为 0.9 时，该策略在算法中将被当作一个延迟为 90ms 的策略进行考量。配置为 1.3 时即为 130 ms。
即 <1 为提高优先级，>1 为降低优先级，默认为 1。
`policy-priority="Premium:0.9"`
第一个参数为对子策略名的正则表达式，第二个参数为系数。可以连续重复配置（但单个策略只会被匹配一次）
`policy-priority="Premium:0.9;SG:1.3"`
如果配置为 0，则表示总是首先使用该策略，失败后再尝试其他策略。（不推荐）
### FAQ
**Q: Smart 策略组的算法引擎具体用了一种算法？**
A: Smart 策略组的算法引擎相当复杂，这里的算法一词并非单指一种具体的算术逻辑，而是类似于 BBR 算法那样，包含了一整套规则、计算方法、数据结构和控制逻辑，同时还包括大量我们工程师多年的经验数据调校。
**Q: Smart 策略组的使用场景是什么？**
A: Smart 策略组的目标是取代原有的所有自动测试组，用户只需要将可用的策略放入该组，剩下的事情完全由 Surge 自动完成。
**Q: 那是否是往 Smart 策略组组中放入越多的策略越好？**
A: 我们的目标是希望能够完全自动的解决这个问题。但是由于设备本身的网络存在不稳定性，如果往组中放入了大量低质量线路，当出现意外的网络波动时，Smart 策略组可能会启用一些次等线路，但其实这只是因为设备本身网络导致的临时问题。（Smart 策略组算法引擎中存在对当前网络质量的考量，但是由于测试当前网络质量存在时间差，所以不一定能获取到准确的信息）这导致需要一定的时间后才能回归到优选线路。
因此推荐在 Smart 策略组组中放入的线路品质应比较相近，可再加上少量次等备用线路。不建议往组中放入过多的几乎不可能被使用的策略。
**Q: Smart 策略组可否用于有地区锁限制的站点的线路自动切换？**
A: 不可以，Surge 无法判断访问的内容是否遭遇了地区锁限制，因此无法进行自动调整。Smart 策略组可以对连接错误、超时、连接卡死等异常做出反应。
**Q: Smart 策略组的策略总是会变化怎么办？**
A: 这是预期行为，Smart 策略组总是会从目前表现最良好的几个策略中随机选取一个进行连接，以此不断监测线路质量。 Smart 策略组会对同一个网站尽量使用相同的策略，因此没有必要太在意策略变化。 即使真的产生了变化，除了个别网站外（通常为金融服务，如 Paypal），大部分网站对 IP 变化并不敏感，没有必要过于担心这个问题而因此放弃 Smart 策略组或设置极大权重。
**Q: 为什么对于同一个域名，Smart 策略组依然会尝试不同的策略连接**
A: 当通过一个代理访问某个域名时，如果该域名的响应速度远低于该代理访问其他网站的速度，则推测该代理对此目标网站不友好，所以在后续连接中会尝试其他线路，在一段时间的数据收集后，最终会收敛稳定到一个策略上。
**Q: 为什么某个代理明明已经故障了，但是界面上还是标记为最常使用**
A: Smart 策略组界面上显示的“最常使用”，指的是最近一段时间内最常被使用的策略，当某个策略突然故障时，虽然它已经不再是首选策略，他可能依然是最近一段时间最常被使用的策略。
### 已知问题
* 在 Smart 策略组中使用 Snell 协议时，reuse 机制将不会生效
* Smart 策略组目前重点考量的是延迟，并不会考量线路的带宽，请保证放入该组的策略的最大带宽都是基本符合需求的，避免选择了低带宽策略影响大数据量传输时的体验。