WebRTC: คืออะไร สถาปัตยกรรม และหลักการทำงาน

WebRTC คืออะไร

WebRTC (Web Real-Time Communication) เป็นโปรเจกต์โอเพนซอร์สที่ริเริ่มโดย Google ในปี 2011 และได้รับการกำหนดมาตรฐานโดย W3C (JavaScript API) และ IETF (โปรโตคอล) เป้าหมายหลักคือการให้การสื่อสารที่มีความหน่วงต่ำระหว่างเบราว์เซอร์และแอปพลิเคชันโดยไม่ต้องติดตั้งปลั๊กอินหรือซอฟต์แวร์ของบุคคลที่สาม

แตกต่างจากโซลูชันแบบดั้งเดิม (RTMP, HLS) ที่วิดีโอผ่านเซิร์ฟเวอร์ WebRTC ใช้ สถาปัตยกรรมแบบ peer-to-peer: ข้อมูลถูกส่งโดยตรงระหว่างผู้เข้าร่วม ซึ่งให้ความหน่วง 200-500 ms เทียบกับ 3-10 วินาทีของ HLS — ความแตกต่างที่สำคัญสำหรับการโทรด้วยเสียงและวิดีโอ การสตรีมเกม และการผ่าตัดทางไกล

ตามข้อมูลของ Google WebRTC Team (2025) เทคโนโลยีนี้ถูกใช้ในแอปพลิเคชันที่มีผู้ใช้งานรวมกว่า 5 พันล้าน การติดตั้ง: Google Meet, WhatsApp, Discord, Telegram, Zoom (บางส่วน) มากกว่า 85% ของสตาร์ทอัพในด้าน telehealth และ edtech เลือก WebRTC เป็นระบบขนส่งแบบเรียลไทม์พื้นฐาน

การพัฒนามือถือได้รับการสนับสนุน WebRTC อย่างเต็มรูปแบบในปี 2013 ด้วยการเปิดตัว libjingle_peerconnection — การใช้งานดั้งเดิมสำหรับ Android และ iOS ปัจจุบันทั้งสองแพลตฟอร์มมี SDK ที่เสถียรพร้อมรองรับการเข้ารหัสฮาร์ดแวร์ของ H.264 และ VP8, กล้อง, ไมโครโฟน และลำโพงของอุปกรณ์

สถาปัตยกรรมและโปรโตคอล WebRTC

สถาปัตยกรรม WebRTC ประกอบด้วยสามชั้น ชั้นบนสุดคือ JavaScript API (หรือ API ดั้งเดิมสำหรับแพลตฟอร์มมือถือ) ชั้นกลางคือโปรโตคอลการขนส่ง ชั้นล่างสุดคือโคเดกและความปลอดภัย แต่ละชั้นแก้ปัญหาของตัวเอง แต่ทั้งหมดจำเป็นสำหรับการสร้างการเชื่อมต่อ

API หลักของ WebRTC

MediaStream (getUserMedia) — จับภาพเสียงและวิดีโอจากไมโครโฟนและกล้องของอุปกรณ์ RTCPeerConnection — จัดการการเชื่อมต่อ P2P: การเข้ารหัส การขนส่ง การปรับบิตเรต RTCDataChannel — ส่งข้อมูลตามอำเภอใจ (ข้อความ ไฟล์ ข้อความไบนารี) ผ่านช่องทางเดียวกัน

// WebRTC JavaScript API (ตัวอย่างเบราว์เซอร์)
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 ระหว่างอุปกรณ์ที่อยู่ behind 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 GB RAM จัดการ การโทรด้วยเสียงพร้อมกันประมาณ 200 สาย หรือการโทรวิดีโอ HD 40 สาย

กระบวนการ ICE

ICE รวบรวมผู้สมัครที่เป็นไปได้ทั้งหมด (IP ในเครื่อง, IP สาธารณะผ่าน STUN, รีเลย์ผ่าน TURN) และพยายามสร้างการเชื่อมต่อตามลำดับความสำคัญ ทันทีที่ผู้สมัครอย่างน้อยหนึ่งคู่ (ในเครื่อง-ระยะไกล) ผ่าน การตรวจสอบการเชื่อมต่อ การเชื่อมต่อจะถือว่าสร้างเสร็จ

• 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 ใช้ API Objective-C กับตัวห่อ 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 บน WebSocket — โปรโตคอล VoIP มาตรฐาน ผสานรวมกับโครงสร้างพื้นฐานโทรศัพท์ที่มีอยู่
• MQTT — โปรโตคอล pub/sub น้ำหนักเบาสำหรับ IoT และเครือข่ายอ่อนแอ แต่มีความหน่วงสูงกว่า
• Matrix / XMPP — โปรโตคอลแบบกระจายศูนย์สำหรับแอปพลิเคชันที่เน้นความเป็นส่วนตัว

หลังจาก ICE และ DTLS-SRTP เสร็จสมบูรณ์ การส่งสัญญาณจะไม่มีส่วนร่วมในการส่งข้อมูลอีกต่อไป — ทราฟฟิกมีเดียทั้งหมดไหลโดยตรง P2P (หรือผ่านรีเลย์ TURN) เซิร์ฟเวอร์ส่งสัญญาณสามารถปิดได้โดยไม่รบกวนการโทรที่กำลังดำเนินอยู่ นี่คือข้อได้เปรียบหลักของ สถาปัตยกรรมแบบกระจายศูนย์ของ WebRTC