这是一个创建于 71 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们是做安全产品的厂商，最近一个客户端程序，有 Androd 和 Windows 两个平台。
架构师原先是做 Java 的，负责 Android 端的开发，我负责 Windows 端开发。
因为需要和其他程序通信，所以他选定的是 socket ，用于本地进程的进程间通信，这里没有任何跨操作系统和跨设备的通讯需求。
我在 Windows 端用的是命名管道，现在强压我要改成 Socket 。
改 Socket 是没什么难度，但是被强制往自己的代码里糊屎非常难受。
Socket 他还没做任何权限认证，也就是本地的任何线程，不管是其他合法进程还是木马病毒，都可以给它的 Socket 端口发消息，只要格式正确它都会执行。
请问下，IPC 用 Socket 的多吗？是纯属他太菜，还是我水平不足？？
架构师原先是做 Java 的，负责 Android 端的开发，我负责 Windows 端开发。
因为需要和其他程序通信，所以他选定的是 socket ，用于本地进程的进程间通信，这里没有任何跨操作系统和跨设备的通讯需求。
我在 Windows 端用的是命名管道，现在强压我要改成 Socket 。
改 Socket 是没什么难度，但是被强制往自己的代码里糊屎非常难受。
Socket 他还没做任何权限认证，也就是本地的任何线程，不管是其他合法进程还是木马病毒，都可以给它的 Socket 端口发消息，只要格式正确它都会执行。
请问下，IPC 用 Socket 的多吗？是纯属他太菜，还是我水平不足？？
137 条回复 • 2024-09-27 13:41:19 +08:00
 |
1
pagxir 71 天前 via Android  12
难道你没用过 pf_unix ，我是觉得你菜点。另外，Android 上因为 sepolicy 关系，所有 IPC 在不存在父子关系的进程间几乎不可用。所以规范做法就是用 binder/aidl ，至于 Windows 就随便
|
 |
2
BD8NCF 71 天前 2
IPC 用 Socket 的很多
|
 |
3
bloceanc 71 天前
问问他的理由
|
 |
4
mioktiar56 71 天前 1
服务器上用 socket 没话说，但涉及到客户端的，如果还用 socket 的，可能就不太合适了。
之前项目没时间自己写 rpc 框架，用的 thrift ，遇到了一些问题，比如： 端口被占用情况； 端口假可用性的情况； 后面自己花时间写了个基于共享内存的 rpc 框架，总算解决了那些问题。 OP 可以看看 https://github.com/winsoft666/veigar |
 |
5
nagisaushio 71 天前 via Android
用 socket 不是很常见
|
|
6
bloceanc 71 天前 2
用 Socket 还是 FIFO 或者 UNIX socket 或者 loopback 或者 shared memory 在很多情况下区别不大，这时候主要是看习惯和可维护性
|
 |
7
iceheart 71 天前 via Android
移植方便，是不是有系统迁移的需求？
|
 |
8
zsxzy 71 天前
用 Socket 更方便跨平台.. 编程也更简单.. 现在 win 也支持 AF_unix
|
 |
9
wshcdr 71 天前
用套接字就是繁琐点，累一点
|
 |
10
shijingshijing 71 天前
pf_unix 本机 localhost 通讯也是走内核，而且数据不需要经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答。支持 stream 和 datagram 两种方式，使用 stream 方式也能保证 reliablity ，数据完整性和收发次序和 TCP 一样能保证。
缺点是数据还是要经历从一个应用拷贝到另一个应用的开销。 |
 |
11
GeekGao 71 天前 15
我品出来一种味道：你先是质疑他的能力，然后在收集证据验证自己的猜测。你拿出的证据之一就是本帖。
|
 |
12
blackstack OP @iceheart 没有迁移的需求，都是原生开发
|
|
13
blackstack OP @bloceanc 没有理由，他写的就是标准和规范。
|
 |
14
ecloud 71 天前 2
Unix socket 本来设计出来就是干这个用的啊，tcp/ip 的那版只是一个衍生品
|
|
15
blackstack OP 1
@GeekGao 并不是，最初这个项目只有我一个人在开发，后面他参与进来，就必须用他的标准来做。
我用 Named Pipe 在前，他定义规范在后，然后要求我按他的规范重新改。 并且改的理由就是遵守规范，规范是他定的。 这种事情不是一次两次，比如后端接口有个参数，他不需要，出于节约流量的目的，就让后端删了，从来没和我沟通过这参数我是不是在用，只能我去适配他的修改。 |
|
16
blackstack OP @pagxir Android 开发不太了解，他也是第一次写，Binder 也不是 Socket 吧？
|
|
17
blackstack OP @ecloud 了解了，感谢。
|
|
18
GeekGao 71 天前
@blackstack 哈哈， 那你可以多问问他 why ,请教他不这么改会发生什么、改后会产生什么新的问题
|
 |
19
MoYi123 71 天前
用 socket 不是挺常见的?
搞个 interface 换一个传输方式也就 100 行代码吧. |
|
20
blackstack OP @GeekGao
没啥用，问一下就说不想这么改就去找领导说。 领导不太懂技术，我提了我的看法，结果就是一句按标准做，详细的先不谈了，我详细说了我的担忧，结果不回消息了。 socket 我最担忧的没有添加验证手段，验证请求的合法性。 如果是恶意程序发送的 socket 请求也无法区分。 我们做的是安全产品，如果连自身安全都确保不了，怎么卖给客户？ |
|
21
GeekGao 71 天前
@blackstack 那你可以说出你的担忧啊，难道不给任何解释？ 倘若真的不给解释就听领导的，留下变更文档/邮件，出事儿不要接锅就行了啊
|
|
22
blackstack OP @GeekGao 有道理，明天上班谈一下，如果听不进去，写封邮件说清楚不是我要这么做的。
|
|
23
blackstack OP @GeekGao 不过其实也没什么用，最终出现问题还是要让我来改。
之前就有个设计，我提出这个设计是不合理的，架构师又怼我说不要老想改需求。 我不得已按他们的设计方式实现了，结果到甲方那里演示人家也觉得这样不合理，得改回我原来的实现方式。 结果还是我来改，他们只要动嘴就好了。 |
 |
24
povsister 71 天前 2
@blackstack #23
不要只把沟通停留在嘴上，留书面，给他发邮件讲清楚同时 cc 老板。凡事留个证据事后好甩锅。 看你俩一人负责一端的情况下，这么少沟通简直不可思议。他甚至还懒得给你解释技术方案，这种人一般要么是大佬脾气怪，要么就是菜逼只会抄。 |
 |
25
bagel 71 天前 2
如果他用的是 tcp socket 开放端口，那就是菜逼无疑，曾经用这个的大厂 app 爆出过无数个漏洞。unix socket 在 Android 高版本收紧权限后可以用作 IPC ，但是也要实现对。Android 推荐的 IPC 机制是 binder ，如果不是跨端代码库显然应该用 binder 。
|
|
26
blackstack OP @bagel 就是 TCP Socket ，然后限制只能 127.0.0.1 的请求，至于有没有限制我还没仔细看他源代码不清楚
|
|
27
blackstack OP @povsister 明天还要讨论另外一个需求，会上再提一次，不行就是发邮件加抄送，发钉钉消息。
|
 |
28
mainjzb 71 天前
还是 socket 好用，最近一年本打算用 flutter 和 go 之间用 pipe 通信，发现 2 个语言对 pipe 的封装都有些问题，各种功能残缺。最后还是用 http 了，没空在 ipc 上浪费时间
|
 |
29
Mithril 71 天前
虽说想搞都能搞，但 np 还是要比 socket 安全一些的。毕竟不是什么扫个端口就能找到的东西。而且你想拦截消息也困难。
|
 |
30
tool2dx 71 天前 via Android
选择 socket 本身并没有大问题，问题是强压方案的做法，让人挺不爽的。
|
 |
31
defphilip 71 天前 2
没有跨平台的需求，那就肯定选命名管道，甚至有跨平台需求给我来做也做管道，socket 那么通用为什么 chromium 做 ipc 的 mojo 在 windows 上不用？
楼上很多人就是 linux 后台做多了把后台的想法照搬到客户端上，完全没考虑到 windows 的复杂环境下用户很有可能直接 127 都连不上（比如用户选择联网的时候误选了防火墙选项）。更别说你们是安全软件。这样相当于把后门给别人留足了。 |
|
32
defphilip 71 天前 1
用 scoket 写 ipc ，你写到倒是简单啊，有没有考虑过后续处理用户反馈的痛苦？
在我们这里的一个核心组件，为了照顾 android 要常驻后台，必须进程间通讯，并且为了跨平台，硬是把组件的调用方式改成了 socket （甚至 windows 都不是多进程的），天天都有用户反馈为什么这个有问题，那个有问题，一大半都是这个 socket 通信的问题 |
 |
33
tyzandhr 70 天前 via Android
两个都不是最佳选项。Windows 上就用 com+，Android 上就用 binder ，这都是平台推荐的
|
 |
34
ajaxgoldfish 70 天前
绝逼是只会 scoket ，像我一样
|
 |
35
spartacussoft 70 天前 4
我觉得如果争用 socket 工具、还是 namedpipe 、unix domain socket 等工具，那是一点意思都没有。
这些工具无非是提供了流式传输的能力，他们本身都可以为你的应用程序流式传输数据。 理论上传输层从 tcp 变成 namedpipe ，或者从 namedpipe 变成 quic ，或者在既有的传输层套一层 TLS ，对你的应用层几乎没有影响才对，如果有影响，说明你们造的不是应用，而是想造传输工具（显然你们也不想造也造不出来吧）。 |
 |
36
jorneyr 70 天前 2
标题的重点是 “架构师”，楼主的言外之意就是这水平也是架构师？那我也胜任架构师，领导没有眼光找的人什么水平，连我都不如。
讨论具体技术脱离了问问题的人的心理。 |
 |
37
kxg3030 70 天前
本地使用 domain socket 也算是比较常见的处理方式了 管道一班不是父子进程用的比较多吗
|
 |
38
dajj 70 天前 15
他官比你大，做决定不问你，你不服气。
这在职场很常见， 也许他擅长吹嘘，也许是他真有本事，但是不管怎么样，你不喜欢他。 我的建议是，别对公司投入太多感情， 你写代码就是为了挣钱过上好生活，公司的代码公司决定， 大不了你干不下去换个公司。以前你可能有个错觉，这块代码是你的一亩三分地，现在你应该明白了，这是公司的代码，不是你的。 |
 |
39
lonelyparasol 70 天前
无论怎么说, 先撇清自己的责任, 别到时候背黑锅.
提安全意见抄送给领导, 让领导决定. 从技术上讲, socket 挺常见的, 而且也多平台通用, 安全防护 ssl 自己封装一下也可以啊, 做好限制我觉得没什么问题, 功能实现就行了。至于更改问题，我也觉得是另一个人不会用， 只会用 socket ， 哈哈哈 |
 |
40
wanguorui123 70 天前
考虑通用性还是选 Socket 吧
|
|
41
blackstack OP @jorneyr 主要是窒息的操作太多了，比如说 get 请求不安全，要求客户端下载更新包的时候只能用 post 请求…
然后不知道灰度发布是什么，设置的更新接口不能区分渠道，后面会有几万个设备同时运行，他选择让几万个设备一起更新到最新版。 接口也没有任何向下兼容的设计，万一部分设备没有更新到最新版，就等着让它们挂掉… |
|
42
blackstack OP @dajj 感谢，你说的很有道理，随他吧。
|
|
43
blackstack OP |
|
44
blackstack OP @raviscioniemeche 我也不是专业搞 windows 客户端的开发，实际上做的是.net 后端，管道通信一般不用在不同软件之间的进程通信吗？
|
 |
45
dododada 70 天前
你们的产品发布之前不过安全检测么？找个红队干他一下。
我认识个家伙，做加固的，新来的阿里领导看他不顺眼要搞他，但是这个领导不懂安全，就找了个阿里安全的搞了他一把，但是没搞动。。。后来就不找他麻烦了，这事儿比较搞笑。 你这个呢，方案的确认和实施，要有邮件往来留存的，至少要抄送到相关干系人。邮件的语气不要客气，正式，每次的技术讨论要有会议纪要，各方抄送。 目的不是甩锅，而是防止背锅。很多事儿，跟技术没关系。 |
 |
46
valord577 70 天前
类似于 6 楼说的 一般熟悉网络技术栈的开发者会优先使用 socket 似于网络通信的 api 方便在 unix domain socket 和 tcp/udp 互相移植 这个和 windows 或者 unix-like 等平台无关 属于是习惯或者熟悉之类的。这种非业务层面的技术沟通 如果后期他也会维护你的代码 你俩就好好商量。如果他不参与你的代码维护 建议看着办 [手动狗头]
|
 |
47
hxndg 70 天前
使用 unix domain socket ，就是上面有人说的 pf_unix ，权限充足的情况下在 linux 上是可以获取对端执行文件信息包括路径的。
从你的描述来看，你做了简单的认证，有多简单没描述，你们的安全基线或者说安全的可证明性前提也没有，所以我并不觉得能够证明是架构的水平不足。 |
 |
48
adoal 70 天前
“我林家满门忠烈，你懂个屁的 Windows”
|
|
49
mainjzb 70 天前
发现 windows 也有 pf_unix
要求 Windows build 17061 https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ |
 |
50
macha 70 天前
windows 上用有名管道即可，用 socket 容易被别人攻击。
我看描述是在跨平台和安全性上的抉择，如果公司比较闲大家讨论讨论还是能增长不少见识的。 如果比较卷的话，谁负责就听谁的呗。 |
 |
51
kaminic 70 天前
做两个 flutter 进程之间的通信，命名管道确实在 flutter 上封装的不完善，最后还是选择用 socket 。
不过只是作为传输层，后期有需求在换掉 |
|
52
blackstack OP @hxndg Android 目前没有做任何认证，只是绑定 127.0.0.1 ，我这边的 windows 是检查了下进程的路径，看下是不是合法的进程发起的通信。
|
|
53
blackstack OP @valord577 问题就是他只负责提要求，然后遇到的问题让我自己想办法……
|
|
54
blackstack OP |
 |
55
m1nm13 70 天前
说实话我对 pipe 或者 Name pipe 印象很差,可能作为入门必学的 ipc 方案,很多初级工程师用的关系,经常出问题.
换我我用 socket,当然我只做 linux 下的开发就是了 |
 |
56
vipfts 70 天前 2
拉磨的驴嫌弃鞭子不够瑟琴🥵
|
 |
57
zoharSoul 70 天前
挺多的
|
 |
58
HFX3389 70 天前
@blackstack #41 不懂灰度发布在某种程度上算蛮正常的
 ，毕竟前段时间的全球蓝屏事件就是 CrowdStrike 的软件全局推送了有问题了 sys 文件，国外大厂都不知道咧~ |
 |
59
DefoliationM 70 天前 via Android
没看懂您这描述，进程间通信是谁跟谁通信，Android 和你 Windows 通信吗？
|
|
60
blackstack OP @vipfts 哈哈，有道理
|
|
61
blackstack OP @DefoliationM 不是，Android 上是其他厂商和我们的程序通信，Windows 上也是如此。
|
 |
62
Chinsung 70 天前
强行要定规范改方案的，如果你质疑，他提不出什么理由，那大概率他只是按照自己以往的经验，或者他只知道这种方式，并且他也没想清楚这种方式的意义
哪怕他只是说：“安全性低点后面再加密，socket 扩展性好。”能说出这种，也算是对方案有自己考虑的，不管方案对错。 不解释的在哪都令人讨厌，无非就是那套官威罢了 |
 |
63
erquren 70 天前
gRPC 呢
|
 |
64
Fca 70 天前
用 DDS 吧
|
 |
65
jackerbauer 70 天前
thrift 或者 grpc 感觉都行
|
 |
67
woodfizky 70 天前
不说技术，感觉你们技术方案的设计和确定上缺少流程这个问题更致命。
需求文档设计文档没有的话，后续很容易出问题。 而没文档能反映出很多管理上的问题。 |
 |
68
zzzyk 70 天前
我这边的项目用的进程间通信基本都是 domain socket 。。。。
|
 |
69
mooyo 70 天前
用 socket 有啥问题
|
|
70
kxg3030 70 天前
@blackstack 管道一般在父子进程用的比较多 不同进程用 socket 比较多
|
 |
71
changnet 70 天前 2
socket 应该是更通用，应用更广的 ipc 通信方式，一个是各个系统都能用，一个是扩展性好，改成跨机器也方便。在支持 socketpair 的系统上，趁手的很，再不济走回环性能也没比 pipe 差到哪去。
socket 可以和 poll 、epoll 之类的共用，win 的 pipe 却不行，在服务器端几乎是必选 不过你这是安卓和 win 的话，情况大不一样。因为 win 不支持 socketpair ，它的 pipe 接口和 linux 的也不一样，要么各个平台代码分开，那么 pipe 在 win 平台确实简单一些。可如果要统一代码，那只能改成 tcp socket 之类两个平台都有的东西。 至于安全性，这两个本身都没有安全性啊（如果非得说别人攻击时，肯定会首先扫端口，那 tcp 确实更容易暴露）。pipe 本身它也不知道另一端是哪个程序，要做安全还得在数据通信里做。 |
 |
72
asuraa 70 天前
本地 socket 不是很常见吗？ 本地回环很快的
|
 |
73
sthwrong 70 天前 1
本机 socket ，别想太多，能扫你本机 socket 的啥不能干？一定要做安全也只能通信本身处理。
|
 |
74
xsi640 70 天前
还是看业务场景。。。
|
 |
75
RightHand 70 天前 via Android
好奇 socket 除了 op 说的验证问题还有什么缺点？
|
 |
76
k9982874 70 天前
*nix 用 socket 没啥毛病，win 我会选 shared memory
|
 |
77
hxysnail 70 天前
我支持架构师，用 socket 就为以后可能的跨操作系统跨设备留好扩展空间，用管道就局限在本机这一亩三分地……
架构师不仅仅要实现眼前的需求，还要有点想象力，俗称 [规划] 。 至于安全认证，那是另一个问题。 |
 |
78
zihuyishi 70 天前
这种不是直接上 grpc 就行了，简单通用还好写。不过 socket 也没啥毛病吧，以后 android 和 windows 搞不好还要互相通信呢，走网络栈怎么想都是比较稳妥的做法。
|
 |
79
benzalus 70 天前
看下来非技术之争，乃话语权之争
|
 |
80
googleaccount 70 天前
我之前做 Windows 客户端也用过 Socket ，后来发现用户那边会遇到一些离奇 bug ，后面改用命名管道了。
|
 |
81
azhangbing 70 天前
android 用 binder ， 如果 android 给 window 通讯用 socket 没啥问题， 不然肯定是使用谷歌规定的方法比较好
|
 |
82
leonshaw 70 天前
你的命名管道有认证吗？
|
 |
83
StarsunYzL 70 天前
用 socket 再正常不过了，没记错的话 libevent 在 Win 上单进程内都有用 socket 做事件通知
|
 |
84
james122333 70 天前 via Android
看是什么 socket
socket domain 确实可选 但身为一个资深类 unix 用户给我选应该是写管道 需要远程转接即可 因为命令行标准输出入友好 可本地可远程脚本测试除错方便 符合 kiss 原则 使用起来爽的不能再爽 |
 |
85
cnbatch 70 天前
留书面证据时，还要明确写出你的 named pipe 在先、他的 socket 随后推出，这个时间关系很重要。
顺便把楼上各位提到的 Windows 为什么要用 pipe 的理由说清楚，重点讲述 Windows 的安全特性跟 Android 的不一样，只能这样做。 如果对方耍无赖，那就直接怼回去：我当初开始写的时候，你干嘛不把标准提出来？为什么你拒绝事先把话说清楚，非要在完工的时候才把“标准”列出来？你这样做会导致工期延误，造成的损失是不是你来承担？如果因为安全特性不同，按照你的标准干活后导致出现安全隐患，是不是你负责？ release 给客户前，要不你来做安全验收，一旦出了事你也得背锅。 （语气语句可以适当调整） |
|
86
james122333 70 天前 via Android
还有一点这么搞可以自动化 好用
现在应用动不动就 tcp api 很不好用 |
 |
87
colinlikepotatos 70 天前
太难受了，他不走，就我走😂，我光看这你描述就难受。不管怎么操作都是给自己找了个天大的麻烦。
|
 |
88
4KMOMhIkocgLELMt 70 天前
支持 @bagel 的答案。
既然你是安全产品，很可能是 system 权限。 socket 是没有权限限制的，后果就是任何一个具有普通权限的程序都可以暴力破解你的验证，从而接管你的软件，甚至通过你软件的 bug 提权。 而隔离不同权限之间通信，之前就是 named pipe ，现在也有了类似 Linux 的 pf_unix 。 |
 |
89
chenqh 70 天前
虽然不想说,但是很多条例,本身就是记住就好了,要知道条例之所以是条例,那就只有踩一次坑了.哪来那么多的机会让你踩坑
|
|
90
chenqh 70 天前
一句话,菜就公式化.你想要灵活,就只有高手了.
|
 |
91
dearmymy 69 天前
不跨平台，windows 肯定命名管道啊。他哥们是不是没开发过 windows 。 用 socket 不是不行，坑有的你踩
|
 |
92
Tink 69 天前
@blackstack 真离谱，要真是这么回事，你说的这问题都不叫事，后面有你受的
|
 |
93
sadfasdfa 69 天前 via iPhone
我是觉得有多个端的话还是用通用的 IPC ，不管以后跨不跨端，需求赶不上变化
|
 |
94
iOCZS 69 天前
问题是你们没有提前讨论和确定实现细节
|
 |
95
cppgohan 69 天前
参考 QLocalSockets 封装一套? win 下命名管道, 否则就用文件 socket
|
 |
97
SuperDaFu 69 天前
这其实不是一个技术问题。
只是你们两冲突的问题。就算我们说你的方案好，别人也不理你的。 |
 |
98
ldw4033 69 天前
请问下，IPC 用 Socket 的多吗？是纯属他太菜，还是我水平不足？？
|
|
99
ldw4033 69 天前
为啥不说自己也菜？
|
 |
100
iceiceice9527 69 天前
我们 unix domain socket 挺好的啊。我们是 go 和 c++进程之间的交互。2000 台机器，每台都是这样的，没遇到过什么问题。
|
Select Language