移动开发中的实时通信：定义、协议及工作原理

实时通信：WebSocket、SSE和Long Polling协议

实时通信是能够在客户端和服务器之间以最小延迟交换数据的技术。主要协议：WebSocket、SSE（Server-Sent Events）、Long Polling和Short Polling。每种都有其应用领域：WebSocket用于双向通信，SSE用于通知，Long Polling作为旧版浏览器的回退。实时在移动开发中尤其重要：用户期望消息和通知的即时传递。移动开发中的通信正是基于这些协议构建的。

WebSocket vs SSE

WebSocket是全双工协议（客户端 ↔ 服务器）。握手（HTTP Upgrade）后连接保持打开状态。头部最小（2字节对比HTTP头部）。用于聊天（WhatsApp、Telegram）、游戏、实时交易。SSE是单向协议（服务器 → 客户端）。客户端订阅事件并通过单个HTTP连接接收它们。SSE更简单，更容易扩展（纯HTTP），适用于Twitter信息流、汇率、推送通知。

Long Polling是一种技术，客户端发出HTTP请求并保持打开状态，直到服务器发送数据或超时（30-60秒）。接收数据后，客户端立即打开新请求。Long Polling是WebSocket的回退。Short Polling — 客户端每N秒轮询服务器。最简单但低效（大多数请求返回空响应）。

信令服务器

在建立P2P连接之前，设备需要一个信令服务器 — 用于在对等方之间交换SDP提议和ICE候选项的中介服务器。信令可以通过WebSocket、SSE或任何其他协议实现。连接建立后，信令不再参与媒体流量传输。

WebRTC：通过音频和视频通话进行实时通信

WebRTC（Web Real-Time Communication）是一种用于P2P音频/视频/数据的开放技术。适用于浏览器和原生应用程序（iOS、Android）。WebRTC包括：getUserMedia（访问摄像头/麦克风）、RTCPeerConnection（P2P连接）、RTCDataChannel（数据传输）。WebRTC使移动应用程序中的实时通信成为可能 — 移动应用中的通信无需额外插件即可工作。

WebRTC流程

对等方A创建RTCPeerConnection和Offer SDP。步骤2：Offer通过信令服务器发送给对等方B。步骤3：对等方B接收Offer，创建Answer SDP并发送回。步骤4：两个对等方收集ICE候选项（用于连接的地址）并通过信令交换它们。步骤5：ICE框架选择最佳路径（P2P或通过TURN）。连接后 — 媒体流量直接流动。

SDP（Session Description Protocol）是描述连接参数（编解码器、IP地址、端口）的文本协议。ICE Candidate是来自STUN/TURN的提议：「可以在此地址找到我」。候选项越多，P2P的机会越大。

Socket.IO是初创公司的首选：您控制服务器，无限制。Pusher和Ably适用于不想管理基础设施的产品。PubNub适用于物联网和全球受众。IT Sectr推荐Socket.IO用于拥有自己后端的项目，Pusher用于快速原型，Ably用于有可靠性需求的企业。

平台：Socket.IO、Pusher、Ably、PubNub

实时平台为WebSocket和SSE提供现成的服务器基础设施。它们消除了编写自己的实时服务器、平衡WebSocket连接和扩展它们的需求。平台的选择取决于预算、可靠性要求和管理服务器的意愿。对于移动开发中的实时应用，平台提供现成的客户端SDK和基础设施。

Socket.IO

Socket.IO是用于Node.js和客户端（iOS、Android、Web）的库。基于WebSocket，但使用HTTP轮询作为回退。支持房间、命名空间、ACK确认。开发用 — socket.io-client-java（Android）和socket.io-client-swift（iOS）。由于自动重新连接，Socket.IO上的移动应用通信得到可靠处理。

Pusher和Ably

Pusher是一个实时SaaS平台。简单集成：创建频道并订阅事件。Pusher Channels用于通知，Pusher Beams用于推送通知。Ably是企业级，具有7个数据中心的全局复制。保证exactly-once交付。支持SSE、WebSocket、MQTT用于物联网。两个平台无需编写服务器代码即可解决移动开发中的通信任务。

实时基础设施：WebRTC中的STUN、TURN、信令

STUN（Session Traversal Utilities for NAT）是帮助设备发现NAT后面其外部IP和端口的服务器。设备发送STUN请求，服务器响应：「您可见为203.0.113.5:45678」。STUN免费使用（Google STUN：stun.l.google.com:19302）。在实时基础设施的背景下，STUN是建立P2P通道的第一步。

STUN vs TURN

TURN（Traversal Using Relays around NAT）是一个中继服务器，当P2P连接不可行时（例如，两个设备都在对称NAT后面），它中继媒体流量。TURN消耗服务器带宽，因此昂贵。在WebRTC中，ICE框架首先尝试P2P，然后TURN作为最后手段。通过企业网络连接时，移动应用中的通信需要TURN进行实时开发。

ICE（Interactive Connectivity Establishment）是一个框架，它收集所有可能的连接路径（本地IP、通过STUN的外部IP、TURN中继）并选择最佳路径。ICE Candidate是每条可能的路径。候选项越多，成功P2P的概率越高。

点对点

P2P是两个设备之间没有中介服务器的直接连接（用于媒体流量）。P2P减少延迟（<100毫秒）和服务器成本。缺点：NAT防护弱，需要STUN/TURN。WebRTC默认使用P2P。

P2P和ICE

点对点（P2P）是一种数据直接在设备之间传输的架构。在实时通信的背景下，P2P在WebRTC中用于最小化延迟。ICE（Interactive Connectivity Establishment）是找到P2P连接最佳路径的机制。对于开发，P2P是在移动应用中组织实时通信的最佳方式。

ICE如何工作

ICE收集三种类型的ICE Candidate：1）host（本地IP），2）srflx（通过STUN），3）relay（通过TURN）。所有候选项被排序，ICE按优先级顺序尝试与每个连接。第一个成功连接被使用。如果P2P不可行，则使用TURN（但成本高）。