WebRTC: چیست، معماری و اصل کار

WebRTC چیست

WebRTC (Web Real-Time Communication) — یک پروژه با کد منبع باز است که توسط Google در سال 2011 آغاز شد و توسط W3C (JavaScript API) و IETF (پروتکل‌ها) استانداردسازی شد. وظیفه اصلی فراهم کردن ارتباط با تأخیر کم بین مرورگرها و برنامه‌ها بدون نصب پلاگین یا نرم‌افزار شخص ثالث است.

برخلاف راه‌حل‌های سنتی (RTMP، HLS) که ویدئو از سرور عبور می‌کند، WebRTC از معماری همتابه‌همتا استفاده می‌کند: داده‌ها مستقیماً بین شرکت‌کنندگان منتقل می‌شوند. این تأخیر 200-500 میلی‌ثانیه را در مقابل 3-10 ثانیه در HLS فراهم می‌کند — تفاوتی حیاتی برای تماس‌های صوتی و تصویری، پخش بازی و جراحی از راه دور.

به گزارش Google WebRTC Team (2025)، این فناوری در برنامه‌هایی با مجموع بیش از 5 میلیارد نصب استفاده می‌شود: Google Meet، WhatsApp، Discord، Telegram، Zoom (تا حدی). بیش از 85٪ استارت‌آپ‌های سرمایه‌گذاری خطرپذیر در حوزه بهداشت از راه دور و آموزشی WebRTC را به عنوان حمل‌ونقل اصلی زمان واقعی انتخاب می‌کنند.

توسعه موبایل در سال 2013 با انتشار libjingle_peerconnection — پیاده‌سازی بومی برای Android و iOS — WebRTC کامل را دریافت کرد. در حال حاضر هر دو پلتفرم SDKهای پایداری با پشتیبانی از رمزگذاری سخت‌افزاری H.264 و VP8، دوربین، میکروفون و بلندگوهای دستگاه دارند.

معماری و پروتکل‌های WebRTC

معماری WebRTC از سه سطح تشکیل شده است. سطح بالایی — JavaScript API (یا API بومی برای پلتفرم‌های موبایل)، میانی — پروتکل‌های حمل‌ونقل، پایینی — کدک‌ها و امنیت. هر سطح وظیفه خود را حل می‌کند، اما همه برای برقراری اتصال الزامی هستند.

APIهای اصلی WebRTC

MediaStream (getUserMedia) — ضبط صدا و ویدئو از میکروفون و دوربین دستگاه. RTCPeerConnection — مدیریت اتصال P2P: رمزگذاری، حمل‌ونقل، تطبیق نرخ بیت. RTCDataChannel — انتقال داده‌های دلخواه (متن، فایل، پیام‌های باینری) از طریق همان کانال.

// JavaScript API WebRTC (مثال مرورگر)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

پروتکل‌های زمان واقعی

WebRTC از SRTP (Secure Real-Time Transport Protocol) برای صدا و ویدئو استفاده می‌کند — نسخه امن RTP با رمزگذاری AES-128. مدیریت جلسه از طریق SCTP (Stream Control Transmission Protocol) روی DTLS انجام می‌شود. هر جریان داده اجباریاً رمزگذاری می‌شود: در WebRTC حالت ناامن وجود ندارد.

• SRTP/SRTCP — انتقال رمزگذاری‌شده جریان‌های رسانه با محافظت در برابر حملات تکرار
• DTLS-SRTP — برقراری کلیدهای رمزگذاری از طریق Datagram TLS روی UDP
• SCTP — تحویل قابل اعتماد یا نیمه‌قابل اعتماد داده برای DataChannel
• ICE (Interactive Connectivity Establishment) — چارچوب برای یافتن مسیر شبکه بین همتاها
• Trickle ICE — نسخه افزایشی ICE که در آن نامزدها به محض کشف ارسال می‌شوند و برقراری اتصال را تسریع می‌کنند

NAT traversal: ICE، STUN و TURN

مشکل فنی اصلی WebRTC برقراری اتصال P2P بین دستگاه‌هایی است که پشت NAT (Network Address Translation) قرار دارند. بدون مکانیزم‌های خاص، دستگاه‌ها نمی‌توانند مستقیماً به یکدیگر متصل شوند، زیرا آدرس‌های IP محلی آنها از اینترنت قابل مشاهده نیست.

STUN — تعیین آدرس عمومی

STUN (Session Traversal Utilities for NAT) — سروری که به سؤال «آدرس IP عمومی و پورت من چیست؟» پاسخ می‌دهد. مشتری یک درخواست به سرور STUN ارسال می‌کند، سرور آدرس عمومی آن را می‌بیند و به مشتری برمی‌گرداند. Google به صورت عمومی سرور STUN را پشتیبانی می‌کند stun:stun.l.google.com:19302.

// WebRTC در iOS — پیکربندی سرورهای ICE
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — اتصال رله‌ای

TURN (Traversal Using Relays around NAT) — سرور بازپخش برای مواردی که STUN کمک نمی‌کند (NAT متقارن یا فایروال‌های شرکتی). در این حالت تمام داده‌ها از سرور TURN عبور می‌کنند — این سرعت را کاهش و تأخیر را افزایش می‌دهد، اما اتصال را در 99٪ موارد تضمین می‌کند.

TURN گران‌ترین جزء زیرساخت WebRTC است، زیرا سرور تمام ترافیک رسانه را از خود عبور می‌دهد. به گزارش Coturn Project (2025)، یک سرور TURN معمولی با 8 vCPU و 16 گیگابایت RAM حدود 200 تماس صوتی همزمان یا 40 تماس ویدئویی با کیفیت HD را پردازش می‌کند.

فرآیند ICE

ICE تمام نامزدهای ممکن (IP محلی، IP عمومی از طریق STUN، رله از طریق TURN) را جمع‌آوری می‌کند و سعی می‌کند به ترتیب اولویت اتصال برقرار کند. به محض اینکه حداقل یک جفت نامزد (محلی-دور) بررسی اتصال connectivity check را پشت سر بگذارد، اتصال برقرار شده در نظر گرفته می‌شود.

• Host candidates — آدرس IP محلی دستگاه در زیرشبکه (سریع‌ترین، اما پشت NAT کار نمی‌کند)
• Server Reflexive candidates — IP عمومی به دست آمده از طریق سرور STUN
• Relay candidates — آدرس سرور TURN که بازپخش از طریق آن انجام می‌شود (کندترین، قابل‌اعتمادترین)

WebRTC در برنامه‌های موبایل

برای توسعه موبایل Google از libWebRTC پشتیبانی می‌کند — کتابخانه بومی برای Android (AAR) و iOS (XCFramework). این کتابخانه شامل تمام پشته پروتکل، کدک‌ها (VP8، VP9، H.264، AV1) و شتاب سخت‌افزاری رمزگذاری/رمزگشایی است.

WebRTC در Android

Android SDK کلاس‌های PeerConnectionFactory، PeerConnection، MediaStream را ارائه می‌دهد. برنامه یک کارخانه ایجاد می‌کند، کدک‌های ویدئو را پیکربندی می‌کند، جریان را از دوربین از طریق VideoCapturer ضبط می‌کند و از طریق SDP offer/answer اتصال همتا به همتا برقرار می‌کند.

// Android WebRTC — مقداردهی اولیه
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

WebRTC در iOS

iOS SDK از Objective-C API با پوشش‌های RTCPeerConnectionFactory، RTCCameraVideoCapturer، RTCVideoTrack استفاده می‌کند. رمزگذاری سخت‌افزاری H.264 از طریق VideoToolbox در دسترس است. برای نمایش ویدئو از RTCMTLVideoView (Metal) یا RTCVideoRenderer استفاده می‌شود.

// iOS WebRTC — ضبط ویدئو از دوربین
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// انتخاب دوربین (جلو/عقب)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// شروع ضبط با حداکثر FPS
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

برای تماس‌های ویدئویی در محیط تولید، برنامه‌های موبایل معمولاً از پوشش‌های SDK روی libWebRTC استفاده می‌کنند: Twilio Video، Agora، Daily.co. این SDKها سیگنالینگ، مدیریت اتاق‌ها را ساده می‌کنند و کامپوننت‌های UI آماده برای نمایش شبکه ویدئویی شرکت‌کنندگان ارائه می‌دهند.

سیگنالینگ و برقراری اتصال

WebRTC پروتکل سیگنالینگ — تبادل پیام‌های SDP (Session Description Protocol) بین همتاها — را مشخص نمی‌کند. توسعه‌دهنده خود حمل‌ونقل سیگنالینگ را انتخاب می‌کند: WebSocket، MQTT، SIP، XMPP یا REST API. سیگنالینگ offer، answer و نامزدهای ICE را از یک همتا به همتای دیگر تحویل می‌دهد.

تبادل SDP Offer/Answer

فرآیند با ایجاد offer شروع می‌شود (آغازگر قابلیت‌های رسانه خود را توصیف می‌کند)، از طریق سیگنالینگ به همتای دوم منتقل می‌شود که با answer پاسخ می‌دهد. پس از تبادل SDP هر همتا ICE را راه‌اندازی کرده و DTLS-SRTP را برای رمزگذاری جریان آغاز می‌کند.

// Android — ایجاد و ارسال offer
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // ارسال sdp.description به سرور سیگنالینگ
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

پروتکل‌های سیگنالینگ

در برنامه‌های موبایل محبوب‌ترین سیگنالینگ از طریق WebSocket است — کانال دوطرفه روی TCP که اتصال دائمی با سرور را حفظ می‌کند. سرور سیگنالینگ اغلب یک میکروسرویس جداگانه (Node.js، Golang، Elixir) است که پیام‌ها را بین شرکت‌کنندگان اتاق مسیریابی می‌کند.

• WebSocket — اتصال دوطرفه دائمی، حداقل سربار، انتخاب استاندارد برای سیگنالینگ
• SIP over WebSocket — پروتکل استاندارد VoIP، با زیرساخت تلفنی موجود ادغام می‌شود
• MQTT — پروتکل سبک pub/sub برای IoT و شبکه‌های ضعیف، اما با تأخیر بیشتر
• Matrix / XMPP — پروتکل‌های غیرمتمرکز برای برنامه‌های نیازمند حریم خصوصی

پس از اتمام ICE و DTLS-SRTP، سیگنالینگ دیگر در انتقال داده شرکت نمی‌کند — تمام ترافیک رسانه مستقیماً P2P (یا از طریق رله TURN) جریان می‌یابد. سرور سیگنالینگ می‌تواند بدون قطع تماس‌های فعال خاموش شود. این مزیت کلیدی معماری غیرمتمرکز WebRTC است.