同一WiFi网络下用户之间实现聊天及视频通话的可行方案有哪些

完全有可落地的实现方案，且不需要依赖公网服务器，纯局域网内即可运行，通信延迟远低于公网同类服务，适合内部办公、线下活动临时通信等场景。

核心实现逻辑 #

• 首先解决局域网设备发现问题：同一WiFi下的设备无需公网DNS，通过局域网专用发现协议即可获取彼此的内网IP和通信端口
• 其次搭建传输层通道：文字类消息对可靠性要求高，优先用TCP传输；音视频流对实时性要求高，优先用UDP传输，仅做轻量化丢包重传即可
• 最后封装上层业务逻辑：包括消息序列化、音视频编解码、用户/房间状态管理、权限控制等业务层功能

分场景具体实现方案与适用工具 #

1. 即时聊天功能 #

• 实现逻辑：
  1. 所有设备接入同一WiFi后，通过mDNS（多播DNS）或ARP广播扫描局域网内运行对应客户端的设备，采集对方内网IP
  2. 可任选一台设备做临时服务端，也可做纯P2P点对点通信：群聊场景如果用户量小（<20人）可直接用广播包群发消息，用户量较大时选低负载设备做临时中转节点即可
  3. 消息序列化小场景用JSON即可，开发成本低；大流量场景可以用Protocol Buffers降低传输体积
• 适用工具：
  • 全平台开发可以用WebSocket搭建TCP连接，Android、iOS、Web端都有原生适配的API
  • 快速验证原型可以用Python的Flask+SocketIO搭建临时服务端，各端用对应语言的SocketIO SDK对接，最快半天就能跑通可用Demo
  • 无需定制功能的话可以直接基于开源局域网聊天工具二次开发，不用从零搭建基础逻辑

2. 一对一/群组视频通话功能 #

• 实现逻辑：
  1. 设备发现阶段和聊天功能共用一套逻辑，优先获取对方内网IP
  2. 音视频采集直接用系统原生API：安卓用Camera2+AudioRecord，iOS用AVFoundation，桌面端用FFmpeg或系统自带采集接口即可
  3. 编解码优先调用系统硬编硬解能力，视频用H.264/H.265编码，音频用AAC编码，1080P 30帧的画面仅需2M左右码率，普通家用WiFi也能轻松承载
  4. 传输层直接用WebRTC实现即可，WebRTC原生支持局域网P2P传输，无需打洞逻辑，直接传入对方内网IP就能建联；群组通话如果人数<10人可以用网状P2P结构，人数较多时在局域网内搭一台轻量SFU媒体中转节点即可
• 适用工具：
  • 最快落地的方案就是用WebRTC，主流浏览器、安卓、iOS都有原生支持或成熟的第三方SDK，无需自己开发编解码、丢包重传等底层逻辑
  • 大群组通话场景可以在局域网内部署Janus或Mediasoup做SFU媒体中转服务，跑在局域网内任意一台普通配置的设备上即可，完全不需要公网资源
  • 无需定制功能的话可以直接在局域网内部署开源的Jitsi Meet服务，用户只要访问对应内网地址就能加入视频会议，原生支持聊天、屏幕共享、群组通话全功能

补充注意：如果需要跨VLAN的同WiFi通信，只需要在核心路由上开启组播转发权限即可，不需要修改业务层逻辑；所有数据都不会流出局域网，隐私性远高于公网通信服务，适合敏感信息沟通场景。

内容的提问来源于stack exchange，提问作者Ujjwal Karnani