RPRX
@madeye 根据原有代码，添加了 `#define IPV4_PROTOCOL_ICMP 1` 和 `#define IPV6_NEXT_ICMP 58`；ping 和 ping6 那两段需要保持 hard code，因为它们与其 response 的差值决定了响应的 checksum 的快速算法，需要体现出来，且只有这里的代码在解析 ICMP，原有代码对这种情况也是 hard code
@Mygod Well, my points are already clear above. 1. And I don't see this behavior a fingerprint for the VPN, because it's not hard for an APP to find itself...
刚刚尝试将 main 分支改名为 ping 以专用于此 PR，结果不行，麻烦尽快作出决定，因为若 main 有新的 commit 也会乱入这个 PR
@madeye Thanks for your advice, I'll keep this PR as is for now.
@zonyitoo 想象一下引发 TLS 错误从而根据报错长度来判断是代理。**以及，SS AEAD 作为一个加密传输层，本应保证回应可靠。**
@viRikaRe 如果你正在使用 SS 浏览 HTTPS 网页，那么理论上，**对调两条 TCP 返回的数据会导致服务端 TLS alert + 断连，这一行为是固定的。** 没错，实际上不光是 AEAD，Shadowsocks 协议的 ciphers 都可以被这样操作，所以理论上是一个通用的识别 SS 的方式。 ~~甚至可以根据 alert 长度推测出你大概在用什么 cipher~~
@dev4u 完全不是同一个东西
看起来若要实现这个机制，明文 TCP 代理协议结构只需一处小改动：返回的数据前加一个字节代表新密钥长度，0 代表无新密钥 2021 年了，只用 AEAD 吧 - FS_AEAD_CHACHA20_POLY1305 `fs-chacha20-poly1305` - FS_AEAD_AES_256_GCM `fs-aes-256-gcm` - FS_AEAD_AES_128_GCM `fs-aes-128-gcm` 各方面细节问题已经考虑清楚，有空时我将先用 [Xray-core](https://github.com/XTLS/Xray-core) 实现它们，进行一些初步的试验
如果没什么问题，此方案可以成为 SIP010，作为 SIP004 和 SIP007 的延续。SIP008 可以提供相应的 API 支持。
@zonyitoo 1. 似乎不需要额外的机制，因为核心目的不是限制设备数量，而且，若多个客户端共享初始密钥，很快就会只剩一个能连上 2. 确实更合理 3. 这个。。。如果需要可扩展性，甚至可以直接插 PB，比如 VLESS（协议结构可扩展性极强）