P2P Demo实战：Android端到端局域网通讯从0到1-北京尧图网络

简介P2P技术演示包面向网络通信、分布式系统开发者尤其适合希望学习NAT穿透与P2P直连原理的初学者。示例以P2PClientTest为核心配合服务端与穿透配置展示设备如何通过P2P服务器建立连接、完成数据交换。压缩包共24个文件以h头文件、cpp源码、lib库、dll动态库及exe可执行程序为主另有readme说明文档整体仅2.09MB结构紧凑便于快速上手。已有446人学习下载。通过运行P2PClientTest并阅读对应源码可以直观理解P2P服务中的IP、端口与密钥管理掌握UDP打洞、STUN/TURN等NAT穿透思路同时熟悉实际工程中的目录划分与依赖配置。对于想深入P2P应用开发的读者这是一份低门槛的实操参考。我之前在做技术分享时最常被问到的问题就是P2P到底怎么写Demo很多人觉得点对点通讯很玄乎其实抛开名词它就是一个“两个端点直接连起来”的通道。这篇我拿一个实际跑通的p2pDemo示例来拆它是Android端到端的局域网通讯工程可以实现两台设备互相发现、发文本、传文件核心代码量不大。不管你是想入门P2P开发、做毕业设计还是要在公司快速做一个局域网互传工具的POC这篇应该都能给你省点时间。顺带说一句我后台看热词的时候发现“MCP服务demo”“鸿蒙hap/hsp/har的demo”“MoveIt2 demo”“3DGS三维重建demo”这些词热度都很高。这些方向各有各的复杂度但落到底层几乎都逃不开一条端到端的通讯链路P2P就是其中最常见的一种。1. 为什么需要一个P2P DemoP2P全称Peer to Peer和C/S最大的区别是没有一个中心服务器来转发全部业务数据。平时我们写接口调HTTP、发消息走MQTT本质上都有个“中转站”。P2P想做的事情是让两个节点自己建立通道数据直接在两端之间流动。好处是延迟低、成本低传大文件的时候不会把服务端带宽撑爆。很多开发者在面试或项目里聊到P2P都觉得懂原理但真动手写Demo就卡住了不知道怎么让两个设备互相发现、不知道怎么处理断线重连、对粘包问题完全没概念。这篇博客就是把p2pDemo示例里涉及的这些环节拆开讲清楚重点是“为什么这么做”而不是只贴一堆代码。1.1 我理解的P2P到底解决什么问题举一个最直观的对比。你在局域网里要给同事传一个2GB的视频方案一先传到公司服务器再让同事从服务器下载。数据走了两遍出口带宽传得慢服务器还要占磁盘。方案二你用P2P工具直接把文件从你的网卡推到同事的网卡数据只经过交换机速度直接拉满。这个区别在公网环境下更明显。中心化服务器是所有流量的瓶颈P2P则把压力分摊到每个节点上。所以P2P不是替代HTTP也不是万能药它适合的是“端与端之间高频、大量数据交换”的场景比如文件互传、音视频通话、屏幕共享、实时协作编辑。1.2 这个Demo适合谁来读这个p2pDemo示例不是那种几十个类堆起来的“炫技工程”而是一条完整且能跑通的链路适合三类人想学P2P通讯原理的开发者从信令服务器到Socket连接再到粘包处理和心跳保活每一步都有对应代码和注释。要交课程设计或毕业设计的学生这个工程可以当基础骨架能演示、能截图、能答辩扩展空间也大。需要做技术预研或者POC的工程师想验证“局域网内两台设备能否端到端互传”跑一遍这个Demo结论就出来了。2. 整体设计拆解先跑通再谈分布式在实现这个p2pDemo示例前我先定了三条设计原则第一信令服务必须极简只负责牵线搭桥第二传输层用TCP做可靠通道第三代码结构必须能一眼看清谁在做什么。这三条决定了后续所有的选型。2.1 信令只做“介绍人”不碰业务数据信令这个概念最容易搞混。它不是一个业务服务器的替代品而是在连接建立之前帮助双方交换网络信息的“媒人”。流程是这样设备A和设备B先分别连上同一个信令服务器上报自己的IP和监听端口。信令服务器把A的地址告诉B把B的地址告诉A。拿到地址后A和B直接建立TCP连接之后所有业务数据都不再经过信令服务。打个比方信令就像交友平台的资料展示页它帮你交换了联系方式但后续的聊天、见面是你自己的事情平台不会监听你们的通话。设计这个Demo时我刻意把信令服务做到只有两个功能维护在线设备列表、转发“对方地址信息”。没有数据库、没有鉴权、没有消息队列这反而让初学者能看懂关键链路。2.2 技术栈选择的三个理由这个Demo最终选型Android端用Kotlin Jetpack Compose信令服务用Python FastAPI WebSocket传输通道用TCP Socket组网形态是局域网。理由逐条说Compose适合快速搭演示界面状态管理直观State ViewModel Flow 的组合写起来比传统XML布局省一半代码而且界面漂亮的Demo在企业内部演示时很有说服力。Python服务端代码量最小FastAPI对WebSocket支持非常成熟十行代码就能起一个WebSocket服务改起来也快。如果换Node.js也可以但Python做这类小工具我效率最高。TCP可靠性强适合文件传输对于文本和文件这类对完整性要求高的场景TCP的可靠字节流能省去大量重传逻辑。这里插一个热词相关的话题。很多人搜索“5090可以p2p通讯吗”如果指的是显卡层面的P2P那确实有GPUDirect P2P这种技术允许GPU之间直接交换数据不走CPU内存中转。这说明P2P思想贯穿了很多层级从网络设备通讯到GPU显存直传本质都是减少中间拷贝、让两端直接交互。理解这个再看网络层的P2P会有一种“万物皆可直连”的通透感。2.3 WebRTC和自定义TCP怎么选不少读者会问我为什么不用WebRTC毕竟它自带NAT穿透能力。这里放一张对比表方便你根据场景选对比维度自定义TCP SocketWebRTC DataChannel适用网络局域网最稳公网穿透需自己实现自动STUN/TURN跨NAT也能打洞开发量小协议、心跳、粘包全自己写中信令交互要按SDP/ICE规范实现可靠性TCP自带可靠传输可靠模式下等价于TCP但头开销略大跨NAT打通成功率不支持穿透基本失败大部分场景可打通理解难度低适合入门中需要理解ICE候选、SDP交换我的观点是如果只是做个Demo、跑课程设计自定义TCP是性价比最高的路径——它能让你看清楚P2P从“发现对端”到“建立连接”的每一步。WebRTC则像一个封装好的黑盒你用起来很爽但出了问题往往不知道从哪排查。先把自定义链路跑通再切WebRTC心里会有底得多。3. 核心细节解析协议、连接、心跳这一部分是这个p2pDemo示例的真正精髓。网络通讯Demo最容易出问题的就三个点消息格式怎么定、连接怎么建立、断线怎么感知。逐个说。3.1 消息报文设计如何避免“粘包半包”TCP是面向字节流的发送端调用两次send()接收端可能一次收到两条消息也可能一条消息分两次收到这就是“粘包”和“半包”。解决思路固定给每条消息加边界。我的做法是“4字节长度头 JSON消息体”长度头用大端序。Python服务端接收端def recv_exact(sock, n): buf bytearray() while len(buf) n: chunk sock.recv(n - len(buf)) if not chunk: raise RuntimeError(connection closed) buf.extend(chunk) return bytes(buf) def recv_packet(sock): header recv_exact(sock, 4) length int.from_bytes(header, byteorderbig) body recv_exact(sock, length) return json.loads(body.decode(utf-8)) def send_packet(sock, payload): body json.dumps(payload).encode(utf-8) sock.sendall(len(body).to_bytes(4, byteorderbig) body)Android Kotlin端对应片段fun recvExact(input: InputStream, n: Int): ByteArray { val buf ByteArray(n) var offset 0 while (offset n) { val read input.read(buf, offset, n - offset) if (read 0) throw IOException(connection closed) offset read } return buf } // 先读4字节头得到长度再按长度读消息体 fun recvPacket(input: InputStream): JSONObject { val header recvExact(input, 4) val length ((header[0].toInt() and 0xFF) shl 24) or ((header[1].toInt() and 0xFF) shl 16) or ((header[2].toInt() and 0xFF) shl 8) or (header[3].toInt() and 0xFF) val body recvExact(input, length) return JSONObject(String(body, Charsets.UTF_8)) }这段逻辑是通讯模块的地基。我自己就见过不少项目各种功能都写好了最后卡在“消息偶尔乱掉”上一查全是没做长度边界导致的。老老实实按长度头解析能根治这类问题。3.2 连接建立的完整时序谁是服务端谁是客户端很多第一次接触P2P的人会困惑P2P里到底谁是服务器答案很简单谁主动发起连接谁就是客户端谁监听端口谁就是这个连接里的服务端。但和传统C/S不同每个节点都可以同时具备这两种角色。在这个示例工程里设备A的流程是打开App、输入昵称、进入“等待连接”页面此时它在后台启动了一个ServerSocket监听随机端口把“IP 端口昵称”上报给信令服务器。设备B的流程是在“连接设备”页面输入A的IDB通过信令服务器拿到A的地址信息然后直接用Socket连接A监听的端口。连接建立的三步可以总结为两端通过信令交换自己的监听地址IP Port。发起方用对端的地址发起TCP连接。连接建立后信令服务器退出后续通讯流程。最容易搞混的地方是“信令连接”和“P2P连接”的区别。信令连接是每个端到服务器之间的WebSocket连接P2P连接是两个端之间的TCP连接。两者是独立的通道别混在一起管理。3.3 心跳保活与断线重连别让“假死”骗了你局域网环境虽然相对稳定但不代表不会掉线比如对端App退到后台被杀、Wi-Fi信号抖动、网线被拔。要在应用层感知这些最通用的手段就是心跳。我采用的参数组合每30秒发送一次{type: ping}对端收到后回复{type: pong}。本地维护lastPongTime如果连续90秒没有收到对端心跳就判定连接超时触发回调通知UI层“连接已断开”同时P2PManager自动进入重连模式。重连策略用指数退避加抖动首次1秒后重试然后2秒、4秒最大间隔30秒。加随机抖动是为了避免两端在同一时刻重连而造成碰撞。这套参数不要照抄到所有场景。如果做的是消息秒级实时同步心跳间隔可以缩短到10秒如果只是文件传输其实60秒一次都够。不要设得太激进否则一个GC停顿就可能误判掉线。4. 实操全程把Demo从0跑到1这部分是完整的上手过程我尽量写得像你在旁边看我操作一样。整个工程已经在本地跑通过照这个步骤走正常情况下十到十五分钟就能看到效果。4.1 工程目录结构先看清楚p2pDemo/ ├── README.md ├── server/ # 信令服务器 │ └── signaling_server.py └── android/ # Android客户端 ├── app/ │ ├── src/main/java/com/example/p2pdemo/ │ │ ├── MainActivity.kt │ │ ├── ui/ │ │ │ ├── HomeScreen.kt │ │ │ ├── WaitConnectScreen.kt │ │ │ └── ChatScreen.kt │ │ ├── p2p/ │ │ │ ├── P2PManager.kt │ │ │ ├── PacketCodec.kt │ │ │ └── SignalingClient.kt │ │ └── viewmodel/ │ │ └── P2PViewModel.kt │ └── src/main/AndroidManifest.xml目录结构映射了分层思想ui层只负责界面渲染p2p层负责Socket连接和信令交互viewmodel层通过Flow向外暴露状态。这样写的好处是万一要换信令协议或者传输协议只需要动p2p包下的几个文件UI完全不用改。4.2 信令服务器十分钟跑起来的WebSocket服务服务端核心代码不长我把它精简到关键部分import asyncio import json from fastapi import FastAPI, WebSocket app FastAPI() online_peers {} # {peer_id: {ws: WebSocket, addr: 1.2.3.4:8080}} app.websocket(/ws) async def signaling(ws: WebSocket): await ws.accept() peer_id None try: while True: data await ws.receive_text() msg json.loads(data) msg_type msg.get(type) if msg_type join: peer_id msg[peer_id] online_peers[peer_id] { ws: ws, addr: msg[addr] } # 广播当前的在线列表 await broadcast_peers() elif msg_type get_peer: target_id msg[target_id] target online_peers.get(target_id) if target: await ws.send_text(json.dumps({ type: peer_info, peer_id: target_id, addr: target[addr] })) except Exception: pass finally: if peer_id and online_peers.get(peer_id): online_peers.pop(peer_id, None) await broadcast_peers()这个服务没有做任何业务逻辑只维护了一张在线表。打开终端执行uvicorn signaling_server:app --host 0.0.0.0 --port 8765信令部分就起来了。注意一点--host 0.0.0.0是必须的否则只能本机访问真机连不上。4.3 Android端核心代码P2PManagerAndroid端最核心的类就是P2PManager它负责三件事连接信令、监听Socket、读写消息。关键逻辑如下class P2PManager( private val onMessage: (String) - Unit, private val onPeerLost: () - Unit ) { private var serverSocket: ServerSocket? null private var clientSocket: Socket? null private var isRunning false // 启动服务端监听并把地址上报给信令服务器 suspend fun startListening() { serverSocket ServerSocket(0) val localPort serverSocket!!.localPort val localAddr getLocalIpAddress() : localPort SignalingClient.join(localAddr) isRunning true CoroutineScope(Dispatchers.IO).launch { val socket serverSocket!!.accept() handleSocket(socket) } } // 主动连接对端走自定义TCP协议 suspend fun connectToPeer(targetAddr: String) { val parts targetAddr.split(:) val socket Socket() socket.connect(InetSocketAddress(parts[0], parts[1].toInt()), 5000) handleSocket(socket) } private suspend fun handleSocket(socket: Socket) { clientSocket socket val input socket.getInputStream() while (isRunning) { val packet try { PacketCodec.recvPacket(input) } catch (e: Exception) { onPeerLost() break } when (packet.optString(type)) { msg - onMessage(packet.optString(content)) file - // 写入文件保存流程 ping - sendText({\type\:\pong\}) } } } }这段代码有几点值得注意ServerSocket(0)会自动分配一个空闲端口避免了端口冲突。connect()设置了5秒超时这是局域网环境下比较合理的一个值太短容易误判太长用户等不起。handleSocket()里的心跳回应是直接回复pong不用走UI层减少状态传递的开销。4.4 完整的运行步骤按顺序操作基本不会出问题克隆工程进入server/目录执行pip install fastapi uvicorn websockets然后启动信令服务器。查看电脑的局域网IP确保手机和电脑在同一个Wi-Fi或交换机下。在Android工程里找到SignalingClient.kt把WebSocket地址改成ws://电脑IP:8765/ws。用Android Studio编译安装到两台真机上或者一台真机加一个模拟器。注意模拟器访问局域网IP时经常有网络模式问题有条件尽量用两台真机。打开设备A点击“等待连接”记下页面显示的peer ID。打开设备B在输入框填设备A的peer ID点击“连接”。看到双方UI上都变成“已连接”状态后发一条测试消息。设备A的日志里应该能看到Socket accept成功设备B的日志里能看到连接成功。验证是否成功最直观的方式是看两边的日志。A端日志如果出现accept: /192.168.x.x:xxxx说明TCP链路已经建立信令服务器已经功成身退。5. 常见问题与排查技巧实录这个Demo我在本地跑的时候也踩了不少坑整理成速查表遇到的概率都很高。现象可能原因排查方法两台设备无法互相发现没连同一个Wi-Fi或者路由器开了AP隔离检查手机和电脑IP是否在同一网段AP隔离的话需要关闭设备A没出现在线列表信令服务器地址配置错误或者防火墙拦截了8765端口浏览器访问http://IP:8765/docs看服务是否可达连接始终超时Android没加INTERNET权限检查AndroidManifest.xml这是最容易漏的一步消息偶尔乱码或丢失没按长度头解析出现粘包半包用本文的recvExact方法界面不刷新在Socket回调里直接操作了UI布局用viewModel Flow 收集消息再回调Compose重组传文件特别慢循环读取时用了逐字节读或每次都触发flush文件流用4KB缓冲循环TCP层无需频繁flush锁屏后连接断开手机关闭了后台运行权限设置里允许App后台运行Demo场景尽量保持前台再补充一个我自己的调试习惯。遇到连接问题先用网络层的工具看再到代码里找。抓包工具用Wireshark最直观过滤条件写tcp.port 你监听的端口能看到SYN包有没有发出去、对端有没有回SYN-ACK。如果SYN都没发出问题在应用层如果SYN发了没回问题在网络或防火墙。这个排查思路能帮你快速定位80%的通讯问题。另外跨网段场景两个设备在不同子网下这个Demo的表现取决于路由策略有些路由允许互访有些会隔离。公网环境则需要TURN服务器做中继或者手动端口映射这就是后续要扩展的内容了。最后分享一个我自己的小经验把P2PManager的日志级别做成动态可切换的平时只输出错误联调时打开DEBUG级别能看到每一步的连接状态、心跳时序和报文内容。很多看起来“随机出现”的问题在完整日志面前都会变得有规律可循。这个Demo后续还可以扩展断点续传、多设备同时在线、加密传输这几个能力核心链路已经通了剩下的就是业务层的工作。本文还有配套的精品资源点击获取

P2P Demo实战：Android端到端局域网通讯从0到1

相关推荐

从解压到刷机：zip压缩包常见坑与固件刷写实战指南

问卷收回来了然后呢？书匠策AI把数据分析变成了“翻译题”

问卷设计的“降维打击”：当书匠策AI把“猜题”变成“搭积木”

更多资讯

归一化RGB全解析：尺度归一化与色度归一化区别及图像预处理实战

Activiti6中文文档实战：工作流引擎配置、BPMN与二次开发

TensorFlow从安装到实战：2024年深度学习框架选型与避坑指南

美赛A题时序预测：混合模型与特征工程实战

Telegram验证码机制解析与安全实践

递归实现链表合并与反转：C++算法精解

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？