我们是做安全产品的厂商，最近一个客户端程序，有 Androd 和 Windows 两个平台。架构师原先是做 Java 的，负责 Android 端的开发，我负责 Windows 端开发。因为需要和其他程序通信，所以他选定的是 socket ，用于本地进程的进程间通信，这里没有任何跨操作系统和跨设备的通讯需求。我在 Windows 端用的是命名管道，现在强压我要改成 Socket 。改 Socket 是没什么难度，但是被强制往自己的代码里糊屎非常难受。Socket 他还没做任何权限认证，也就是本地的任何线程，不管是其他合法进程还是木马病毒，都可以给它的 Socket 端口发消息，只要格式正确它都会执行。请问下，IPC 用 Socket 的多吗？是纯属他太菜，还是我水平不足？？

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

IPC 用 Socket 的很多

问问他的理由

服务器上用 socket 没话说，但涉及到客户端的，如果还用 socket 的，可能就不太合适了。之前项目没时间自己写 rpc 框架，用的 thrift ，遇到了一些问题，比如：端口被占用情况；端口假可用性的情况；后面自己花时间写了个基于共享内存的 rpc 框架，总算解决了那些问题。OP 可以看看 github.com/winsoft666/veigar

用 socket 不是很常见

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

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

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

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

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

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

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

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

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

并不是，最初这个项目只有我一个人在开发，后面他参与进来，就必须用他的标准来做。我用 Named Pipe 在前，他定义规范在后，然后要求我按他的规范重新改。并且改的理由就是遵守规范，规范是他定的。这种事情不是一次两次，比如后端接口有个参数，他不需要，出于节约流量的目的，就让后端删了，从来没和我沟通过这参数我是不是在用，只能我去适配他的修改。

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

了解了，感谢。

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

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

没啥用，问一下就说不想这么改就去找领导说。领导不太懂技术，我提了我的看法，结果就是一句按标准做，详细的先不谈了，我详细说了我的担忧，结果不回消息了。socket 我最担忧的没有添加验证手段，验证请求的合法性。如果是恶意程序发送的 socket 请求也无法区分。我们做的是安全产品，如果连自身安全都确保不了，怎么卖给客户？

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

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

不过其实也没什么用，最终出现问题还是要让我来改。之前就有个设计，我提出这个设计是不合理的，架构师又怼我说不要老想改需求。我不得已按他们的设计方式实现了，结果到甲方那里演示人家也觉得这样不合理，得改回我原来的实现方式。结果还是我来改，他们只要动嘴就好了。

＃23不要只把沟通停留在嘴上，留书面，给他发邮件讲清楚同时 cc 老板。凡事留个证据事后好甩锅。看你俩一人负责一端的情况下，这么少沟通简直不可思议。他甚至还懒得给你解释技术方案，这种人一般要么是大佬脾气怪，要么就是菜逼只会抄。

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

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

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

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

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

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

没有跨平台的需求，那就肯定选命名管道，甚至有跨平台需求给我来做也做管道，socket 那么通用为什么 chromium 做 ipc 的 mojo 在 windows 上不用？楼上很多人就是 linux 后台做多了把后台的想法照搬到客户端上，完全没考虑到 windows 的复杂环境下用户很有可能直接 127 都连不上（比如用户选择联网的时候误选了防火墙选项）。更别说你们是安全软件。这样相当于把后门给别人留足了。

用 scoket 写 ipc ，你写到倒是简单啊，有没有考虑过后续处理用户反馈的痛苦？在我们这里的一个核心组件，为了照顾 android 要常驻后台，必须进程间通讯，并且为了跨平台，硬是把组件的调用方式改成了 socket （甚至 windows 都不是多进程的），天天都有用户反馈为什么这个有问题，那个有问题，一大半都是这个 socket 通信的问题

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

绝逼是只会 scoket ，像我一样

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

标题的重点是 “架构师”，楼主的言外之意就是这水平也是架构师？那我也胜任架构师，领导没有眼光找的人什么水平，连我都不如。讨论具体技术脱离了问问题的人的心理。

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

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

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

考虑通用性还是选 Socket 吧

主要是窒息的操作太多了，比如说 get 请求不安全，要求客户端下载更新包的时候只能用 post 请求…然后不知道灰度发布是什么，设置的更新接口不能区分渠道，后面会有几万个设备同时运行，他选择让几万个设备一起更新到最新版。接口也没有任何向下兼容的设计，万一部分设备没有更新到最新版，就等着让它们挂掉…

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

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

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

你们的产品发布之前不过安全检测么？找个红队干他一下。我认识个家伙，做加固的，新来的阿里领导看他不顺眼要搞他，但是这个领导不懂安全，就找了个阿里安全的搞了他一把，但是没搞动。。。后来就不找他麻烦了，这事儿比较搞笑。你这个呢，方案的确认和实施，要有邮件往来留存的，至少要抄送到相关干系人。邮件的语气不要客气，正式，每次的技术讨论要有会议纪要，各方抄送。目的不是甩锅，而是防止背锅。很多事儿，跟技术没关系。

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

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

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

发现 windows 也有 pf_unix要求 Windows build 17061 devblogs.microsoft.com/commandline/af_unix-comes-to-windows/

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

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

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

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

基本上需求的变更都是口述，没有留下会议纪要和痕迹。有些甚至是他自己和后端拉个会，自己决定自己改，接口变更，我都不知道。等我下次改代码，发现接口变了，只能被迫跟着改。

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

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

挺多的

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

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

哈哈，有道理

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

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

gRPC 呢

用 DDS 吧

thrift 或者 grpc 感觉都行

妈妈。。。 不

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

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

用 socket 有啥问题

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

socket 应该是更通用，应用更广的 ipc 通信方式，一个是各个系统都能用，一个是扩展性好，改成跨机器也方便。在支持 socketpair 的系统上，趁手的很，再不济走回环性能也没比 pipe 差到哪去。socket 可以和 poll 、epoll 之类的共用，win 的 pipe 却不行，在服务器端几乎是必选不过你这是安卓和 win 的话，情况大不一样。因为 win 不支持 socketpair ，它的 pipe 接口和 linux 的也不一样，要么各个平台代码分开，那么 pipe 在 win 平台确实简单一些。可如果要统一代码，那只能改成 tcp socket 之类两个平台都有的东西。至于安全性，这两个本身都没有安全性啊（如果非得说别人攻击时，肯定会首先扫端口，那 tcp 确实更容易暴露）。pipe 本身它也不知道另一端是哪个程序，要做安全还得在数据通信里做。

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

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

还是看业务场景。。。

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

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