Known issues (已知未解决不明问题)

[ssrlive]

希望 C 和 libuv 老手能提供解决方案或者建议.

• 接入 SSR 客户端 的 用户APP 主动重置不少的 incoming 连接, connection reset by peer, 原因不明.

• 在 客户端 按下 ctrl + c 以后, 连接不能及时全部断开, 存在内存泄漏, 估计是某种 接入失败 的情景没有正确处理. ——经多次测试，死活断不开的连接，可以通过多次插拔网线强行断开，然后程序就能正常退出了。——太恶心的操作。

• 使用 uv-mbed 封装的 tls_cli.c 和 raw socket 版的 tls_cli2.c 的行为并不一致, 预期中这二者应该完全等效, 可以随意置换的.

[ssrlive]

connection reset by peer 问题已解决.

原因是, SOCKS5 协议要求 第二次数据交换(即目标地址询问包)的回复包必须尽快应答, 但我当时的实现是, SSR客户端收到询问包后, 却是 连接远程服务器,等收到服务器的应答后,客户端才把回复包写回给 接入的浏览器App, 这中间的时间差与网络质量相关, 时间很短的话, 就一切正常,如果稍微长了一点, 浏览器App就会认为 SSR客户端 超时无响应, 直接粗暴掐断连接.

这个修正对于台式机操作系统上的客户端貌似无甚性能提升,但对于 iOS 却是至关重要, 否则根本无法代理.

修正代码见 这里

[ssrlive]

在 客户端 按下 ctrl + c 以后, 连接不能及时全部断开 这个问题与操作系统有关, 无法修复.

替代的办法是, 在退出之前加了个定时器，三秒后强行退出 不再纠缠. 这没什么问题, 这少许内存泄漏根本无足轻重, 况且程序随即退出, 泄露的内存马上被操作系统回收. 完美!

修改的代码见 这里

[ssrlive]

使用 uv-mbed 封装的 tls_cli.c 和 raw socket 版的 tls_cli2.c 的行为并不一致, 预期中这二者应该完全等效, 可以随意置换的.

这个已经无关大局了. 关 issue.