使用 socket 做进程间通信的架构师属于什么水平

[blackstack]

我们是做安全产品的厂商，最近一个客户端程序，有 Androd 和 Windows 两个平台。

架构师原先是做 Java 的，负责 Android 端的开发，我负责 Windows 端开发。

因为需要和其他程序通信，所以他选定的是 socket ，用于本地进程的进程间通信，这里没有任何跨操作系统和跨设备的通讯需求。

我在 Windows 端用的是命名管道，现在强压我要改成 Socket 。

改 Socket 是没什么难度，但是被强制往自己的代码里糊屎非常难受。

Socket 他还没做任何权限认证，也就是本地的任何线程，不管是其他合法进程还是木马病毒，都可以给它的 Socket 端口发消息，只要格式正确它都会执行。

请问下，IPC 用 Socket 的多吗？是纯属他太菜，还是我水平不足？？

[pagxir]

难道你没用过 pf_unix ，我是觉得你菜点。另外，Android 上因为 sepolicy 关系，所有 IPC 在不存在父子关系的进程间几乎不可用。所以规范做法就是用 binder/aidl ，至于 Windows 就随便

[BD8NCF]

IPC 用 Socket 的很多

[bloceanc]

问问他的理由

[mioktiar56]

服务器上用 socket 没话说，但涉及到客户端的，如果还用 socket 的，可能就不太合适了。

之前项目没时间自己写 rpc 框架，用的 thrift ，遇到了一些问题，比如：
端口被占用情况；
端口假可用性的情况；

后面自己花时间写了个基于共享内存的 rpc 框架，总算解决了那些问题。

OP 可以看看 https://github.com/winsoft666/veigar

[nagisaushio]

用 socket 不是很常见

[bloceanc]

用 Socket 还是 FIFO 或者 UNIX socket 或者 loopback 或者 shared memory 在很多情况下区别不大，这时候主要是看习惯和可维护性

[iceheart]

移植方便，是不是有系统迁移的需求？

[zsxzy]

用 Socket 更方便跨平台.. 编程也更简单.. 现在 win 也支持 AF_unix

[wshcdr]

用套接字就是繁琐点，累一点

[shijingshijing]

pf_unix 本机 localhost 通讯也是走内核，而且数据不需要经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答。支持 stream 和 datagram 两种方式，使用 stream 方式也能保证 reliablity ，数据完整性和收发次序和 TCP 一样能保证。
缺点是数据还是要经历从一个应用拷贝到另一个应用的开销。

[GeekGao]

我品出来一种味道：你先是质疑他的能力，然后在收集证据验证自己的猜测。你拿出的证据之一就是本帖。

[blackstack]

@iceheart 没有迁移的需求，都是原生开发

[blackstack]

@bloceanc 没有理由，他写的就是标准和规范。

[ecloud]

Unix socket 本来设计出来就是干这个用的啊，tcp/ip 的那版只是一个衍生品

[blackstack]

@GeekGao 并不是，最初这个项目只有我一个人在开发，后面他参与进来，就必须用他的标准来做。

我用 Named Pipe 在前，他定义规范在后，然后要求我按他的规范重新改。

并且改的理由就是遵守规范，规范是他定的。

这种事情不是一次两次，比如后端接口有个参数，他不需要，出于节约流量的目的，就让后端删了，从来没和我沟通过这参数我是不是在用，只能我去适配他的修改。

[blackstack]

@pagxir Android 开发不太了解，他也是第一次写，Binder 也不是 Socket 吧？

[blackstack]

@ecloud 了解了，感谢。

[GeekGao]

@blackstack 哈哈， 那你可以多问问他 why ,请教他不这么改会发生什么、改后会产生什么新的问题

[MoYi123]

用 socket 不是挺常见的?
搞个 interface 换一个传输方式也就 100 行代码吧.

[blackstack]

@GeekGao
没啥用，问一下就说不想这么改就去找领导说。
领导不太懂技术，我提了我的看法，结果就是一句按标准做，详细的先不谈了，我详细说了我的担忧，结果不回消息了。

socket 我最担忧的没有添加验证手段，验证请求的合法性。
如果是恶意程序发送的 socket 请求也无法区分。

我们做的是安全产品，如果连自身安全都确保不了，怎么卖给客户？

[GeekGao]

@blackstack 那你可以说出你的担忧啊，难道不给任何解释？ 倘若真的不给解释就听领导的，留下变更文档/邮件，出事儿不要接锅就行了啊

[blackstack]

@GeekGao 有道理，明天上班谈一下，如果听不进去，写封邮件说清楚不是我要这么做的。

[blackstack]

@GeekGao 不过其实也没什么用，最终出现问题还是要让我来改。

之前就有个设计，我提出这个设计是不合理的，架构师又怼我说不要老想改需求。

我不得已按他们的设计方式实现了，结果到甲方那里演示人家也觉得这样不合理，得改回我原来的实现方式。

结果还是我来改，他们只要动嘴就好了。

[povsister]

@blackstack #23
不要只把沟通停留在嘴上，留书面，给他发邮件讲清楚同时 cc 老板。凡事留个证据事后好甩锅。

看你俩一人负责一端的情况下，这么少沟通简直不可思议。他甚至还懒得给你解释技术方案，这种人一般要么是大佬脾气怪，要么就是菜逼只会抄。

[bagel]

如果他用的是 tcp socket 开放端口，那就是菜逼无疑，曾经用这个的大厂 app 爆出过无数个漏洞。unix socket 在 Android 高版本收紧权限后可以用作 IPC ，但是也要实现对。Android 推荐的 IPC 机制是 binder ，如果不是跨端代码库显然应该用 binder 。

[blackstack]

@bagel 就是 TCP Socket ，然后限制只能 127.0.0.1 的请求，至于有没有限制我还没仔细看他源代码不清楚

[blackstack]

@povsister 明天还要讨论另外一个需求，会上再提一次，不行就是发邮件加抄送，发钉钉消息。

[mainjzb]

还是 socket 好用，最近一年本打算用 flutter 和 go 之间用 pipe 通信，发现 2 个语言对 pipe 的封装都有些问题，各种功能残缺。最后还是用 http 了，没空在 ipc 上浪费时间

[Mithril]

虽说想搞都能搞，但 np 还是要比 socket 安全一些的。毕竟不是什么扫个端口就能找到的东西。而且你想拦截消息也困难。

[tool2dx]

选择 socket 本身并没有大问题，问题是强压方案的做法，让人挺不爽的。

[defphilip]

没有跨平台的需求，那就肯定选命名管道，甚至有跨平台需求给我来做也做管道，socket 那么通用为什么 chromium 做 ipc 的 mojo 在 windows 上不用？

楼上很多人就是 linux 后台做多了把后台的想法照搬到客户端上，完全没考虑到 windows 的复杂环境下用户很有可能直接 127 都连不上（比如用户选择联网的时候误选了防火墙选项）。更别说你们是安全软件。这样相当于把后门给别人留足了。

[defphilip]

用 scoket 写 ipc ，你写到倒是简单啊，有没有考虑过后续处理用户反馈的痛苦？

在我们这里的一个核心组件，为了照顾 android 要常驻后台，必须进程间通讯，并且为了跨平台，硬是把组件的调用方式改成了 socket （甚至 windows 都不是多进程的），天天都有用户反馈为什么这个有问题，那个有问题，一大半都是这个 socket 通信的问题

[tyzandhr]

两个都不是最佳选项。Windows 上就用 com+，Android 上就用 binder ，这都是平台推荐的

[ajaxgoldfish]

绝逼是只会 scoket ，像我一样

[spartacussoft]

我觉得如果争用 socket 工具、还是 namedpipe 、unix domain socket 等工具，那是一点意思都没有。
这些工具无非是提供了流式传输的能力，他们本身都可以为你的应用程序流式传输数据。
理论上传输层从 tcp 变成 namedpipe ，或者从 namedpipe 变成 quic ，或者在既有的传输层套一层 TLS ，对你的应用层几乎没有影响才对，如果有影响，说明你们造的不是应用，而是想造传输工具（显然你们也不想造也造不出来吧）。

[jorneyr]

标题的重点是 “架构师”，楼主的言外之意就是这水平也是架构师？那我也胜任架构师，领导没有眼光找的人什么水平，连我都不如。

讨论具体技术脱离了问问题的人的心理。

[raviscioniemeche]

本地使用 domain socket 也算是比较常见的处理方式了 管道一班不是父子进程用的比较多吗

[dajj]

他官比你大，做决定不问你，你不服气。
这在职场很常见， 也许他擅长吹嘘，也许是他真有本事，但是不管怎么样，你不喜欢他。
我的建议是，别对公司投入太多感情， 你写代码就是为了挣钱过上好生活，公司的代码公司决定， 大不了你干不下去换个公司。以前你可能有个错觉，这块代码是你的一亩三分地，现在你应该明白了，这是公司的代码，不是你的。

[lonelyparasol]

无论怎么说, 先撇清自己的责任, 别到时候背黑锅.
提安全意见抄送给领导, 让领导决定.
从技术上讲, socket 挺常见的, 而且也多平台通用, 安全防护 ssl 自己封装一下也可以啊, 做好限制我觉得没什么问题, 功能实现就行了。至于更改问题，我也觉得是另一个人不会用， 只会用 socket ， 哈哈哈

[wanguorui123]

考虑通用性还是选 Socket 吧

[blackstack]

@jorneyr 主要是窒息的操作太多了，比如说 get 请求不安全，要求客户端下载更新包的时候只能用 post 请求…

然后不知道灰度发布是什么，设置的更新接口不能区分渠道，后面会有几万个设备同时运行，他选择让几万个设备一起更新到最新版。

接口也没有任何向下兼容的设计，万一部分设备没有更新到最新版，就等着让它们挂掉…

[blackstack]

@dajj 感谢，你说的很有道理，随他吧。

[blackstack]

@lonelyparasol 现在他的方案就是 socket 裸奔，没有任何身份认证。

我这边简单做了一下请求进程的认证，现在他要我改成跟他一样裸奔的方式，实现上没什么难度，就是非常难受。

[blackstack]

@raviscioniemeche 我也不是专业搞 windows 客户端的开发，实际上做的是.net 后端，管道通信一般不用在不同软件之间的进程通信吗？

[dododada]

你们的产品发布之前不过安全检测么？找个红队干他一下。

我认识个家伙，做加固的，新来的阿里领导看他不顺眼要搞他，但是这个领导不懂安全，就找了个阿里安全的搞了他一把，但是没搞动。。。后来就不找他麻烦了，这事儿比较搞笑。

你这个呢，方案的确认和实施，要有邮件往来留存的，至少要抄送到相关干系人。邮件的语气不要客气，正式，每次的技术讨论要有会议纪要，各方抄送。

目的不是甩锅，而是防止背锅。很多事儿，跟技术没关系。

[valord577]

类似于 6 楼说的 一般熟悉网络技术栈的开发者会优先使用 socket 似于网络通信的 api 方便在 unix domain socket 和 tcp/udp 互相移植 这个和 windows 或者 unix-like 等平台无关 属于是习惯或者熟悉之类的。这种非业务层面的技术沟通 如果后期他也会维护你的代码 你俩就好好商量。如果他不参与你的代码维护 建议看着办 [手动狗头]

[hxndg]

使用 unix domain socket ，就是上面有人说的 pf_unix ，权限充足的情况下在 linux 上是可以获取对端执行文件信息包括路径的。
从你的描述来看，你做了简单的认证，有多简单没描述，你们的安全基线或者说安全的可证明性前提也没有，所以我并不觉得能够证明是架构的水平不足。

[adoal]

“我林家满门忠烈，你懂个屁的 Windows”

[mainjzb]

发现 windows 也有 pf_unix
要求 Windows build 17061

https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/

[macha]

windows 上用有名管道即可，用 socket 容易被别人攻击。
我看描述是在跨平台和安全性上的抉择，如果公司比较闲大家讨论讨论还是能增长不少见识的。
如果比较卷的话，谁负责就听谁的呗。

[kaminic]

做两个 flutter 进程之间的通信，命名管道确实在 flutter 上封装的不完善，最后还是选择用 socket 。
不过只是作为传输层，后期有需求在换掉

[blackstack]

@hxndg Android 目前没有做任何认证，只是绑定 127.0.0.1 ，我这边的 windows 是检查了下进程的路径，看下是不是合法的进程发起的通信。

[blackstack]

@valord577 问题就是他只负责提要求，然后遇到的问题让我自己想办法……

[blackstack]

@dododada 基本上需求的变更都是口述，没有留下会议纪要和痕迹。

有些甚至是他自己和后端拉个会，自己决定自己改，接口变更，我都不知道。

等我下次改代码，发现接口变了，只能被迫跟着改。

[m1nm13]

说实话我对 pipe 或者 Name pipe 印象很差,可能作为入门必学的 ipc 方案,很多初级工程师用的关系,经常出问题.
换我我用 socket,当然我只做 linux 下的开发就是了

[vipfts]

拉磨的驴嫌弃鞭子不够瑟琴🥵

[zoharSoul]

挺多的

[HFX3389]

@blackstack #41 不懂灰度发布在某种程度上算蛮正常的 ，毕竟前段时间的全球蓝屏事件就是 CrowdStrike 的软件全局推送了有问题了 sys 文件，国外大厂都不知道咧~

[DefoliationM]

没看懂您这描述，进程间通信是谁跟谁通信，Android 和你 Windows 通信吗？

[blackstack]

@vipfts 哈哈，有道理

[blackstack]

@DefoliationM 不是，Android 上是其他厂商和我们的程序通信，Windows 上也是如此。

[Chinsung]

强行要定规范改方案的，如果你质疑，他提不出什么理由，那大概率他只是按照自己以往的经验，或者他只知道这种方式，并且他也没想清楚这种方式的意义
哪怕他只是说：“安全性低点后面再加密，socket 扩展性好。”能说出这种，也算是对方案有自己考虑的，不管方案对错。
不解释的在哪都令人讨厌，无非就是那套官威罢了

[erquren]

gRPC 呢

[Fca]

用 DDS 吧

[jackerbauer]

thrift 或者 grpc 感觉都行

[loveyu]

@pagxir 妈妈。。。 不

[woodfizky]

不说技术，感觉你们技术方案的设计和确定上缺少流程这个问题更致命。
需求文档设计文档没有的话，后续很容易出问题。

而没文档能反映出很多管理上的问题。

[zzzyk]

我这边的项目用的进程间通信基本都是 domain socket 。。。。

[mooyo]

用 socket 有啥问题

[raviscioniemeche]

@blackstack 管道一般在父子进程用的比较多 不同进程用 socket 比较多

[changnet]

socket 应该是更通用，应用更广的 ipc 通信方式，一个是各个系统都能用，一个是扩展性好，改成跨机器也方便。在支持 socketpair 的系统上，趁手的很，再不济走回环性能也没比 pipe 差到哪去。

socket 可以和 poll 、epoll 之类的共用，win 的 pipe 却不行，在服务器端几乎是必选

不过你这是安卓和 win 的话，情况大不一样。因为 win 不支持 socketpair ，它的 pipe 接口和 linux 的也不一样，要么各个平台代码分开，那么 pipe 在 win 平台确实简单一些。可如果要统一代码，那只能改成 tcp socket 之类两个平台都有的东西。

至于安全性，这两个本身都没有安全性啊（如果非得说别人攻击时，肯定会首先扫端口，那 tcp 确实更容易暴露）。pipe 本身它也不知道另一端是哪个程序，要做安全还得在数据通信里做。

[asuraa]

本地 socket 不是很常见吗？ 本地回环很快的

[sthwrong]

本机 socket ，别想太多，能扫你本机 socket 的啥不能干？一定要做安全也只能通信本身处理。

[xsi640]

还是看业务场景。。。

[RightHand]

好奇 socket 除了 op 说的验证问题还有什么缺点？

[k9982874]

*nix 用 socket 没啥毛病，win 我会选 shared memory

[hxysnail]

我支持架构师，用 socket 就为以后可能的跨操作系统跨设备留好扩展空间，用管道就局限在本机这一亩三分地……
架构师不仅仅要实现眼前的需求，还要有点想象力，俗称 [规划] 。
至于安全认证，那是另一个问题。

[zihuyishi]

这种不是直接上 grpc 就行了，简单通用还好写。不过 socket 也没啥毛病吧，以后 android 和 windows 搞不好还要互相通信呢，走网络栈怎么想都是比较稳妥的做法。

[benzalus]

看下来非技术之争，乃话语权之争

[googleaccount]

我之前做 Windows 客户端也用过 Socket ，后来发现用户那边会遇到一些离奇 bug ，后面改用命名管道了。

[azhangbing]

android 用 binder ， 如果 android 给 window 通讯用 socket 没啥问题， 不然肯定是使用谷歌规定的方法比较好

[leonshaw]

你的命名管道有认证吗？

[StarsunYzL]

用 socket 再正常不过了，没记错的话 libevent 在 Win 上单进程内都有用 socket 做事件通知

[james122333]

看是什么 socket
socket domain 确实可选
但身为一个资深类 unix 用户给我选应该是写管道 需要远程转接即可 因为命令行标准输出入友好 可本地可远程脚本测试除错方便 符合 kiss 原则 使用起来爽的不能再爽

[cnbatch]

留书面证据时，还要明确写出你的 named pipe 在先、他的 socket 随后推出，这个时间关系很重要。

顺便把楼上各位提到的 Windows 为什么要用 pipe 的理由说清楚，重点讲述 Windows 的安全特性跟 Android 的不一样，只能这样做。

如果对方耍无赖，那就直接怼回去：我当初开始写的时候，你干嘛不把标准提出来？为什么你拒绝事先把话说清楚，非要在完工的时候才把“标准”列出来？你这样做会导致工期延误，造成的损失是不是你来承担？如果因为安全特性不同，按照你的标准干活后导致出现安全隐患，是不是你负责？ release 给客户前，要不你来做安全验收，一旦出了事你也得背锅。
（语气语句可以适当调整）

[james122333]

还有一点这么搞可以自动化 好用
现在应用动不动就 tcp api 很不好用

[colinlikepotatos]

太难受了，他不走，就我走😂，我光看这你描述就难受。不管怎么操作都是给自己找了个天大的麻烦。

[4KMOMhIkocgLELMt]

支持 @bagel 的答案。
既然你是安全产品，很可能是 system 权限。
socket 是没有权限限制的，后果就是任何一个具有普通权限的程序都可以暴力破解你的验证，从而接管你的软件，甚至通过你软件的 bug 提权。
而隔离不同权限之间通信，之前就是 named pipe ，现在也有了类似 Linux 的 pf_unix 。

[chenqh]

虽然不想说,但是很多条例,本身就是记住就好了,要知道条例之所以是条例,那就只有踩一次坑了.哪来那么多的机会让你踩坑

[chenqh]

一句话,菜就公式化.你想要灵活,就只有高手了.

[dearmymy]

不跨平台，windows 肯定命名管道啊。他哥们是不是没开发过 windows 。 用 socket 不是不行，坑有的你踩

[Tink]

@blackstack 真离谱，要真是这么回事，你说的这问题都不叫事，后面有你受的

[sadfasdfa]

我是觉得有多个端的话还是用通用的 IPC ，不管以后跨不跨端，需求赶不上变化

[iOCZS]

问题是你们没有提前讨论和确定实现细节

[cppgohan]

参考 QLocalSockets 封装一套? win 下命名管道, 否则就用文件 socket

[SuperDaFu]

@dajj 自从我接受了这个现实，想怎么改都行。只要给我时间，不让我加班，我都行的。

[SuperDaFu]

这其实不是一个技术问题。
只是你们两冲突的问题。就算我们说你的方案好，别人也不理你的。

[ldw4033]

请问下，IPC 用 Socket 的多吗？是纯属他太菜，还是我水平不足？？

[ldw4033]

为啥不说自己也菜？

[iceiceice9527]

我们 unix domain socket 挺好的啊。我们是 go 和 c++进程之间的交互。2000 台机器，每台都是这样的，没遇到过什么问题。