iceorange 最近的时间轴更新 iceorange 最近的时间轴更新 |
iceorangeV2EX 第 65015 号会员，加入于 2014-06-13 21:05:32 +08:00 |
iceorange 最近回复了
2021 年 2 月 25 日 回复了 iceorange 创建的主题 › 程序员 › cproxy: 使用简单的 Linux per app 透明代理 |
@Jirajine 您开心就好 ：）
2021 年 2 月 25 日 回复了 iceorange 创建的主题 › 程序员 › cproxy: 使用简单的 Linux per app 透明代理 |
@Jirajine 建议讨论的时候不要太多 “乱七八糟”、“十分不合适” 这种主观感觉。这对技术社区讨论是不利的。
比如您觉得使用 iptables 有问题，那么讨论方向应该是使用了 iptables，比如多进程一起操作，可能会带来什么具体后果，这个后果会造成什么影响，对使用场景是否不可接受。在您的回复中这个后果叫做 “乱七八糟”，和“非常令人困惑且难以排查的 bug ”但又不明确是什么 bug 。这样讨论是没有意义的，对社区互相帮助提升技术有害。
比如您觉得使用 iptables 有问题，那么讨论方向应该是使用了 iptables，比如多进程一起操作，可能会带来什么具体后果，这个后果会造成什么影响，对使用场景是否不可接受。在您的回复中这个后果叫做 “乱七八糟”，和“非常令人困惑且难以排查的 bug ”但又不明确是什么 bug 。这样讨论是没有意义的，对社区互相帮助提升技术有害。
2021 年 2 月 25 日 回复了 iceorange 创建的主题 › 程序员 › cproxy: 使用简单的 Linux per app 透明代理 |
@Jirajine 真的很奇怪。
1. 说乱七八糟不要凭感觉，需要具体的分析。为了避免误导其他人，我解释一下。在这种场景下，不存在 pid 回收的问题，因为 cproxy 是把自己的 pid 放入 cgroup，再 launch 子进程。删除链是 cproxy 进程进行删除，因此删除的时候不可能 pid 被回收。而且 pid 这个事情跟原子性完全没有任何关系，不要把不相关的事情放在一起，逻辑非常混乱。
2. 您觉得 shell 脚本写更好，是您的 personal taste，争论这种 detail 没有任何意义，只会把讨论带偏。我觉得 rust 写更好。
1. 说乱七八糟不要凭感觉，需要具体的分析。为了避免误导其他人，我解释一下。在这种场景下，不存在 pid 回收的问题，因为 cproxy 是把自己的 pid 放入 cgroup，再 launch 子进程。删除链是 cproxy 进程进行删除，因此删除的时候不可能 pid 被回收。而且 pid 这个事情跟原子性完全没有任何关系，不要把不相关的事情放在一起，逻辑非常混乱。
2. 您觉得 shell 脚本写更好，是您的 personal taste，争论这种 detail 没有任何意义，只会把讨论带偏。我觉得 rust 写更好。
2021 年 2 月 25 日 回复了 iceorange 创建的主题 › 程序员 › cproxy: 使用简单的 Linux per app 透明代理 |
@nmap 简单说其实就是为需要代理的程序创建一个独立的 cgroup，通过 netfilter 把这个 cgroup 的网络流量全部重定向。
2021 年 2 月 25 日 回复了 iceorange 创建的主题 › 程序员 › cproxy: 使用简单的 Linux per app 透明代理 |
@yanqiyu
诶 这个使用和系统要求不同，但是在实现原理上和 cproxy 非常接近。我一会把它补充到 readme 里。
诶 这个使用和系统要求不同，但是在实现原理上和 cproxy 非常接近。我一会把它补充到 readme 里。
2021 年 2 月 25 日 回复了 iceorange 创建的主题 › 程序员 › cproxy: 使用简单的 Linux per app 透明代理 |
@gleport 是的，只需要代理 tcp 的话 graftcp 已经很好用了
我平时用 graftcp 的时候主要有两个需求解决不了，一个是代理 DNS 。另一个是像是已经运行起来的 docker，经常需要走代理 docker pull 些内网私有 image，用 graftcp 的话我得每次先修改 docker.service 让他套上 graftcp 然后重启 service，用完再改回去，没法直接让现有 docker 进程代理
我平时用 graftcp 的时候主要有两个需求解决不了，一个是代理 DNS 。另一个是像是已经运行起来的 docker，经常需要走代理 docker pull 些内网私有 image，用 graftcp 的话我得每次先修改 docker.service 让他套上 graftcp 然后重启 service，用完再改回去，没法直接让现有 docker 进程代理
2021 年 2 月 25 日 回复了 iceorange 创建的主题 › 程序员 › cproxy: 使用简单的 Linux per app 透明代理 |
@Jirajine
其实是有一个 fundamental 的认知问题，工具的重点是能够解决新的痛点问题，而不是用了什么魔法。
其实是有一个 fundamental 的认知问题，工具的重点是能够解决新的痛点问题，而不是用了什么魔法。
2021 年 2 月 25 日 回复了 iceorange 创建的主题 › 程序员 › cproxy: 使用简单的 Linux per app 透明代理 |
@Jirajine
1. 多个进程同时操作 iptables 没有问题啊，子进程只有在该子进程需要的 rule apply 后才会 spawn 。不同进程使用的 rule 是不同的。
2. 为什么非要纠结 iptables 调用的开销呢，一般所代理的程序运行开销远高于 iptables 调用，所以不能 justify 使用 libnftables 更好，详见上述使用 libnftables 带来的问题
3. 使用了外部程序就得用 shell 这个逻辑实在是不通。写 shell 光那一堆错误检查得写很多行。parse 命令得写很多行。安装 signal handler 得写很多行。懂得都懂。
1. 多个进程同时操作 iptables 没有问题啊，子进程只有在该子进程需要的 rule apply 后才会 spawn 。不同进程使用的 rule 是不同的。
2. 为什么非要纠结 iptables 调用的开销呢，一般所代理的程序运行开销远高于 iptables 调用，所以不能 justify 使用 libnftables 更好，详见上述使用 libnftables 带来的问题
3. 使用了外部程序就得用 shell 这个逻辑实在是不通。写 shell 光那一堆错误检查得写很多行。parse 命令得写很多行。安装 signal handler 得写很多行。懂得都懂。
2021 年 2 月 25 日 回复了 iceorange 创建的主题 › 程序员 › cproxy: 使用简单的 Linux per app 透明代理 |
@Jirajine 谢谢，
1. 修改 iptables 不觉得哪里 low 了，请问是解决不了什么问题？
2. 关于是调用库还是调用 iptables 命令这个问题我一开始思考过。在这种场景下，原子性没有影响，因为子进程是所有 iptables rule apply 完再 spawn 的，子进程退出后才会进行 iptables 的清空操作。说到性能问题就莫名其妙了，调用几行 iptables 命令的开销在这个使用场景中值得考虑？并发启动没看出问题，请教一下。
3. 不用 libnftnl 可能的好处：不需要整个程序 uid 0，同时支持 nftables 和 iptables 。
4. 能用 rust 更好地组织代码干嘛非得写个 shell ？
最后，希望能以一个正常讨论的态度对话，谢谢。
1. 修改 iptables 不觉得哪里 low 了，请问是解决不了什么问题？
2. 关于是调用库还是调用 iptables 命令这个问题我一开始思考过。在这种场景下，原子性没有影响，因为子进程是所有 iptables rule apply 完再 spawn 的，子进程退出后才会进行 iptables 的清空操作。说到性能问题就莫名其妙了，调用几行 iptables 命令的开销在这个使用场景中值得考虑？并发启动没看出问题，请教一下。
3. 不用 libnftnl 可能的好处：不需要整个程序 uid 0，同时支持 nftables 和 iptables 。
4. 能用 rust 更好地组织代码干嘛非得写个 shell ？
最后，希望能以一个正常讨论的态度对话，谢谢。
Select Language