建议：取消重放数据包防御，避免用于识别特定的服务。

[dev4u]

我阅读了服务的c、rust、go语言的实现，服务端实现重放检测的，都是通过bloom的算法判断。如果服务端判断当次的请求是重放包，则会直接丢弃，服务端不会对当次请求做响应。

我的疑问是，如果大墙重放数据到特定的端口，如果端口没有任何回馈，那么这个端口用于特定服务的嫌疑是否会骤升？

我也特意将go实现的服务端，关闭重放数据包的检测（只有go实现的可以关闭检测功能，SHADOWSOCKS_SF_CAPACITY=0）。
服务连续运行了三天，在中国移动的网络下，明显要比没有关闭检测前，质量要好很多。数据断流的情况明显少了。

虽然不能说关闭重放检测，和网络状况转好有因果关系，但这就是我这几天的真实感觉。

[Mygod]

Yeah I think turning off replay makes sense.

[ghost]

related issue: net4people/bbs#22

[ghost]

ss-java （一个第三方实现）完全没有重放检测，为避免实现特有的问题，也可以试试

[dev4u]

ss-java （一个第三方实现）完全没有重放检测，为避免实现特有的问题，也可以试试

我建议不要拿java来虐自己。何况未经官方认证，小心蜜罐！

[riobard]

如果大墙重放数据到特定的端口，如果端口没有任何回馈，那么这个端口用于特定服务的嫌疑是否会骤升？

这个简单，你重放一个 TLS 看看端口会有什么反馈？

虽然不能说关闭重放检测，和网络状况转好有因果关系，但这就是我这几天的真实感觉。

样本量为一，不能说明问题。

[dev4u]

如果大墙重放数据到特定的端口，如果端口没有任何回馈，那么这个端口用于特定服务的嫌疑是否会骤升？

这个简单，你重放一个 TLS 看看端口会有什么反馈？

虽然不能说关闭重放检测，和网络状况转好有因果关系，但这就是我这几天的真实感觉。

样本量为一，不能说明问题。

我没有加套跑服务，所以没有tls可以重放。加了套是为了混淆真实服务，能不能通过 “套” 来识别服务，那是 “套” 做的事。

样本，虽然只有我一个人这样做，但对于墙的访问规则来说，则不仅仅是针对我。当然，也可能是我当地的网络出口的墙是这样。

[riobard]

看上面第三条链接的论文

[dev4u]

看上面第三条链接的论文

我看了上面的论文链接。

我也不认为现在的重放判断，可以降低被识别的几率。既然这样，我个人建议可以考虑去掉bloom的算法，或者增加开关，让用户选择是否打开。

我分享的要点有两个。
1.我用的是中国移动的网络，他一直都被称为墙中墙🐮。相同的服务设置，过墙质量就是要比电信、联通的要差。
2.我有大量的，未取消bloom之前的使用经验。这让我可以有底气的做出比较，关闭bloom后，我的手机过墙质量真的有提高。

至于这个状况，是因为移动刚好升级了我城市的基站？还是因为为我调优了访问策略导致的？这个我也还在观察，尽管我也觉得升级基站、调优都是鬼话不可信👻。