基于 WebRTC 的一对一屏幕共享项目（一）——项目简介

（分发服务器还没写好，写好后代码会开源）

引言

在远程协作成为刚需的今天，如何打破空间限制实现高效沟通？WebRTC（Web Real-Time Communication）作为浏览器原生支持的实时通信技术，无需插件即可实现音视频流、数据的点对点传输，成为解决这一问题的核心方案。我们的WebRTC 屏幕共享项目正是基于这一技术，构建了一套轻量化、高兼容性的实时协作系统，并且会将服务器同时部署至pc端和RK3566平台（均为ubuntu系统）。本文作为系列开篇，将从功能架构、技术组件、核心流程三个维度，带您深入了解项目的全貌。

项目界面图片：
加入房间界面
屏幕共享界面

一、项目核心功能：

1. 极简房间：

• 房间即协作单元 ：用户通过唯一房间号快速加入或创建会话，支持1v1 高清共享（当前版本暂限 2 人）。
• 状态可视化：界面实时显示 "等待连接""对方共享中" 等状态，搭配颜色标记（如黄色 "等待"、绿色 "已连接"），让协作进度一目了然。

2. 灵活共享控制：

• 多模式共享 ：支持全屏共享 （展示整个桌面）、窗口共享 （锁定单个应用窗口）、标签页共享（仅共享浏览器当前标签），适配不同场景需求。
• 交互增强 ：
  • 双击主窗口或点击 "全屏" 按钮可进入全屏模式；
  • 点击 "交换视频" 按钮可切换本地与远程画面的显示大小，满足主讲与听讲角色的灵活切换。

3. 便捷性：

• 低代码集成：基于标准 Web 技术栈开发，可快速嵌入现有 Web 应用，无需额外客户端下载。

二、技术组件拆解：三层架构支撑实时通信

1. 分发 HTML 的服务器

• 定位：作为项目的 "门户"，负责向用户浏览器分发前端页面（HTML/CSS/JS），并可扩展静态资源缓存、CDN 加速等功能。
• 技术方向 ：
  • 轻量级服务器（当前版本仅c++多线程实现，未来可能修改为libevent高并发实现）；

2. HTML 客户端：用户交互的 "门面"

• 技术栈 ：
  • UI 框架：使用 Tailwind CSS 实现响应式布局，搭配 Font Awesome 图标库，界面简洁现代；
  • 核心逻辑 ：
    • 通过getDisplayMedia API 获取屏幕流，支持显示鼠标指针（cursor: always）；
    • 基于RTCPeerConnection实现 WebRTC 连接，处理媒体流的创建、传输与渲染；
    • 集成 WebSocket 客户端，与信令服务器实时通信。
• 交互细节 ：
  • 视频容器使用aspect-ratio: 16/9保持画面比例，搭配backdrop-blur等 CSS 特效提升视觉层次；
  • 按钮添加transition-transform动画（如点击时缩放 1.02 倍），增强操作反馈。

3. 信令服务器：协作的 "神经中枢"

• 核心职责 ：
  • 管理房间生命周期（创建、加入、销毁）；
  • 中转 WebRTC 信令（如 SDP 协商、ICE 候选交换），解决浏览器间直接通信的网络限制；
  • 维护客户端连接状态，处理异常断开后的重连逻辑。
• 技术实现 ：
  • 基于 Node.js 和nodejs-websocket库搭建，支持高并发 WebSocket 连接；
  • 使用RTCMap数据结构管理房间与用户映射关系，实现快速的房间查询与用户遍历；
  • 信令类型定义清晰（如JOIN/LEAVE/OFFER/CANDIDATE等），通过 JSON 格式序列化传输，确保跨平台兼容性。

4.网络穿越与中继转发（本项目使用开源项目Coturn）

在复杂的网络环境中，客户端可能处于 NAT（网络地址转换）或防火墙之后，直接点对点连接往往面临阻碍。为此，项目集成了 **STUN（Session Traversal Utilities for NAT）和TURN（Traversal Using Relay NAT）** 服务器，构建了健壮的网络穿越机制，确保屏幕共享在各种网络条件下稳定运行。

（1）STUN：探测公网地址，实现直连

• 原理：STUN 服务器作为 "网络探路者"，通过向客户端发送探测请求，获取其在 NAT 设备后的公网 IP 和端口，帮助双方确定可互通的 "桥梁"。
• 应用场景 ：
  • 当客户端处于对称型 NAT 以外的类型 （如开放型、全圆锥型、地址限制圆锥型）时，可直接通过 STUN 获取的地址建立点对点连接，延迟最低、画质最优。

（2）TURN：中继转发，破解对称型 NAT 壁垒

• 原理 ：当客户端处于对称型 NAT （严格限制端口和协议）时，STUN 无法穿透，此时 TURN 服务器作为 "数据中转站"，将一方的数据流通过自身转发给另一方，牺牲部分带宽换取连接成功率。
• 应用场景 ：
  • 企业内网、校园网等严格限制的网络环境；
  • 移动端（如手机热点共享）等动态 IP 场景。

三、核心流程解析：信令驱动的实时协作

结合时序图，我们以1v1 共享场景为例，拆解项目的核心交互流程：
信令服务器时序图（时序以代码为准，图片仅参考）

1. 连接与房间创建阶段

• 客户端 A 发起 WebSocket 连接至信令服务器，请求加入房间room1；
• 服务器检查房间状态（当前无人），创建房间并返回 "加入成功"，同时生成客户端 A 的唯一 ID（如uid-A）；
• 客户端 B 通过相同房间号加入room1，服务器发现房间已存在 1 人，允许加入并生成uid-B；
• 服务器向客户端 A 发送NEW_PEER信令（通知uid-B加入），向客户端 B 发送RESP_JOIN信令（告知对方 ID 为uid-A）。

2. 媒体协商阶段（WebRTC 连接建立）

• 客户端 A 调用createOffer生成 SDP（会话描述），包含本地媒体信息（如屏幕分辨率、编码格式），通过信令服务器转发给客户端 B；
• 客户端 B 收到 Offer 后，调用createAnswer生成应答 SDP，并回传至客户端 A；
• 双方交换 ICE 候选（CANDIDATE信令），协商网络穿透路径（如通过 STUN/TURN 服务器），最终建立点对点连接。

3. 屏幕共享与控制阶段

• 客户端 A 点击 "开始共享"，通过getDisplayMedia获取屏幕流，绑定至本地视频标签，并通过 WebRTC 通道发送至客户端 B；
• 客户端 B接收流后渲染至 "对方的屏幕" 窗口，支持双击全屏或点击 "交换" 按钮切换主次画面；
• 共享过程中，信令服务器持续监控连接状态，若一方断开（如LEAVE信令或意外关闭），自动通知另一方并清理房间资源。

总结

通过以上的介绍，我们对基于 WebRTC 的屏幕共享项目有了一个初步的了解。这个项目结合了前端页面、信令服务器等多个组件，实现了高效、便捷的屏幕共享功能。在后续的文章中，我未来的文章将深入探讨每个组件的具体实现细节。