Signaling Server: คืออะไร ทำงานอย่างไร และใช้ที่ไหนบ้าง

Signaling Server คืออะไร

Signaling Server — คือบริการเครือข่ายที่รับผิดชอบในการประสานงานกระบวนการสร้างการเชื่อมต่อ WebRTC ระหว่างเพียร์ตั้งแต่สองตัวขึ้นไป มันไม่ส่งข้อมูลสื่อ (เสียง วิดีโอ ข้อมูล DataChannel) แต่ส่งเฉพาะข้อมูลควบคุมที่จำเป็นสำหรับการค้นหาเพียร์และการเจรจาพารามิเตอร์การเชื่อมต่อ หลังจากสร้างช่องทาง P2P สำเร็จแล้ว อาจไม่จำเป็นต้องใช้ Signaling Server อีกต่อไป แต่ในสถาปัตยกรรมบางอย่าง มันยังคงอยู่สำหรับการแลกเปลี่ยนสัญญาณในภายหลัง (เช่น การยุติการโทร การเพิ่มผู้เข้าร่วม)

สถาปัตยกรรมการส่งสัญญาณประกอบด้วยสามองค์ประกอบ: Signaling Server, Signal Channel (โปรโตคอลขนส่งระหว่างไคลเอ็นต์และเซิร์ฟเวอร์) และ API ของไคลเอ็นต์ (มักรวมอยู่ในสแตก WebRTC ของเบราว์เซอร์) ข้อกำหนด WebRTC (W3C, 2024) จงใจไม่กำหนดมาตรฐานโปรโตคอลการส่งสัญญาณ — นักพัฒนาสามารถเลือกการขนส่งที่เหมาะสมกับแอปพลิเคชันของตนได้ วิธีการที่ยืดหยุ่นนี้ช่วยให้ใช้ WebSocket สำหรับแอปพลิเคชันเว็บ XMPP สำหรับระบบแชท หรือ SIP สำหรับการรวมเข้ากับโครงสร้างพื้นฐานโทรคมนาคม

กระบวนการส่งสัญญาณ: ภาพรวมระดับสูง

ก่อนสร้างการเชื่อมต่อ WebRTC เพียร์ต้องแลกเปลี่ยนข้อความสามประเภท: คำอธิบายเซสชัน (offer และ answer), ผู้สมัคร ICE และข้อมูลการยุติ/แก้ไขเซสชัน Signaling Server จะกำหนดเส้นทางข้อความเหล่านี้ระหว่างเพียร์โดยใช้ตัวระบุห้องหรือผู้ใช้สำหรับการระบุตำแหน่ง รูปแบบมาตรฐานคือการสร้าง “ห้อง” ที่ผู้เข้าร่วมสองคนเชื่อมต่อ และเซิร์ฟเวอร์จะถ่ายทอดข้อความจากผู้เข้าร่วมแต่ละคนไปยังคู่สนทนาของพวกเขาเท่านั้น

การส่งสัญญาณใน WebRTC ทำงานอย่างไร

Signaling Server ใช้โปรโตคอลการสร้างการเชื่อมต่อ WebRTC ทั่วไปดังต่อไปนี้ เพียร์เชื่อมต่อกับเซิร์ฟเวอร์ผ่าน WebSocket (หรือการขนส่งอื่น) และลงทะเบียนในห้อง เพียร์ A (ผู้เริ่มต้น) สร้าง offer (คำอธิบาย SDP ของสตรีมสื่อขาออก) ผ่าน RTCPeerConnection.createOffer() ตั้งค่าเป็นคำอธิบายในเครื่องและส่งไปยัง Signaling Server เซิร์ฟเวอร์ถ่ายทอด offer ไปยังเพียร์ B เพียร์ B รับ offer ตั้งค่าเป็นคำอธิบายระยะไกล สร้าง answer ผ่าน createAnswer() ตั้งค่าเป็นคำอธิบายในเครื่องและส่งกลับผ่านเซิร์ฟเวอร์ กระบวนการนี้เรียกว่า SDP Offer/Answer

ควบคู่ไปกับการแลกเปลี่ยน SDP เพียร์แต่ละตัวรวบรวมผู้สมัคร ICE (host, srflx, relay) และส่งผ่าน Signaling Server ไปยังเพียร์อื่น เพียร์ระยะไกลเพิ่มผู้สมัครที่ได้รับผ่าน RTCPeerConnection.addIceCandidate() กระบวนการ ICE ทดสอบการรวมกันของผู้สมัครทั้งหมดเพื่อค้นหาเส้นทางที่ใช้งานได้ เมื่อพบเส้นทางที่ใช้งานได้ (โดยปกติภายใน 1–5 วินาที) ทราฟฟิกสื่อเริ่มไหลโดยตรงระหว่างเพียร์ และ Signaling Server ไม่มีส่วนร่วมในการส่งข้อมูลอีกต่อไป — บทบาทของมันสิ้นสุดลงจนกว่าจะมีเหตุการณ์ควบคุมถัดไป (การยุติการโทร การเปลี่ยนคุณภาพสตรีม)

กลไกห้องและการลงทะเบียน

สำหรับการระบุตำแหน่งข้อความ Signaling Server ใช้กลไกห้องหรือช่องทาง แต่ละเซสชัน WebRTC ใหม่สร้างห้องที่ไม่ซ้ำกันด้วยตัวระบุ (โดยปกติคือ UUID) ผู้เริ่มต้นสร้างห้องและรอการเชื่อมต่อของเพียร์ที่สอง เพียร์ที่สองเข้าร่วมห้องโดยใช้ ID ที่ได้รับผ่านช่องทางภายนอก (เช่น ลิงก์เชิญ) เซิร์ฟเวอร์รักษาแผนที่ของห้อง โดยแต่ละ ID สอดคล้องกับรายการของไคลเอ็นต์ที่เชื่อมต่อ เมื่อจำนวนผู้เข้าร่วมถึงสองคน เซิร์ฟเวอร์เริ่มถ่ายทอดข้อความส่งสัญญาณระหว่างพวกเขา

โปรโตคอลการส่งสัญญาณ WebRTC

Signaling Server สามารถใช้โปรโตคอลขนส่งที่แตกต่างกัน โดยแต่ละโปรโตคอลมีข้อดีและข้อเสียของตัวเอง การเลือกโปรโตคอลขึ้นอยู่กับประเภทของแอปพลิเคชัน ข้อจำกัดของโครงสร้างพื้นฐาน และข้อกำหนดความเข้ากันได้ ด้านล่างนี้คือโปรโตคอลที่พบบ่อยที่สุดและคุณลักษณะของพวกเขา

WebSocket เป็นโปรโตคอลที่นิยมที่สุดสำหรับ Signaling Server ในแอปพลิเคชันเว็บ มันให้การสื่อสารแบบฟูลดูเพล็กซ์ ซึ่งสำคัญสำหรับการแลกเปลี่ยนผู้สมัคร SDP และ ICE แบบอะซิงโครนัส และรองรับโดยเบราว์เซอร์สมัยใหม่ทั้งหมดผ่าน WebSocket API การใช้งานฝั่งเซิร์ฟเวอร์ WebSocket มีอยู่ในทุกแพลตฟอร์มยอดนิยม (Node.js, Python, Java, Go) สำหรับแอปพลิเคชันที่มีผู้ใช้หลายล้านคน ใช้โซลูชัน WebSocket ที่ปรับขนาดได้บน Redis Pub/Sub หรือ Kafka เพื่อซิงโครไนซ์ระหว่างอินสแตนซ์ของ Signaling Server

ตัวอย่างการใช้งาน Signaling Server

มาดูการใช้งาน Signaling Server อย่างง่ายใน Node.js โดยใช้ไลบรารี ws (WebSocket) และเซิร์ฟเวอร์ HTTP ในตัว เซิร์ฟเวอร์รองรับการลงทะเบียนผู้ใช้ การสร้างห้อง และการถ่ายทอดข้อความระหว่างผู้เข้าร่วม

const WebSocket = require("ws");
const server = new WebSocket.Server({ port: 8080 });
const rooms = new Map();

server.on("connection", (ws) => {
    ws.roomId = null;

    ws.on("message", (data) => {
        const msg = JSON.parse(data);

        switch (msg.type) {
            case "join":
                handleJoin(ws, msg.roomId);
                break;
            case "offer":
            case "answer":
            case "ice-candidate":
                relayToPeer(ws, msg);
                break;
            case "leave":
                handleLeave(ws);
                break;
        }
    });

    ws.on("close", () => handleLeave(ws));
});

function handleJoin(ws, roomId) {
    if (!rooms.has(roomId)) {
        rooms.set(roomId, []);
    }

    const room = rooms.get(roomId);
    room.push(ws);
    ws.roomId = roomId;

    if (room.length === 2) {
        room[0].send(JSON.stringify({ type: "peer-joined" }));
        room[1].send(JSON.stringify({ type: "peer-joined" }));
    }
}

function relayToPeer(sender, msg) {
    const room = rooms.get(sender.roomId);
    if (!room) return;

    room.forEach(peer => {
        if (peer !== sender && peer.readyState === WebSocket.OPEN) {
            peer.send(JSON.stringify(msg));
        }
    });
}

function handleLeave(ws) {
    if (!ws.roomId) return;
    const room = rooms.get(ws.roomId);
    if (!room) return;

    const idx = room.indexOf(ws);
    if (idx !== -1) room.splice(idx, 1);
    if (room.length === 0) rooms.delete(ws.roomId);
}

Signaling Server นี้ใช้ฟังก์ชันพื้นฐาน: การเชื่อมต่อกับห้อง การถ่ายทอดข้อความ WebRTC (offer, answer, ice-candidate) ระหว่างเพียร์สองตัวและการจัดการการตัดการเชื่อมต่อ เซิร์ฟเวอร์ใช้ Map เพื่อจัดเก็บห้องกับไคลเอ็นต์ WebSocket ที่เชื่อมต่อ ฟังก์ชัน relayToPeer ส่งข้อความถึงผู้เข้าร่วมทั้งหมดในห้องยกเว้นผู้ส่ง สำหรับการใช้งานจริง คุณจะต้องเพิ่มการตรวจสอบประเภทข้อความ การจัดการข้อผิดพลาดการแยกวิเคราะห์ JSON และกลไก heartbeat สำหรับตรวจจับการเชื่อมต่อที่ขาด

การรวมไคลเอ็นต์กับ Signaling Server

ฝั่งไคลเอ็นต์ Signaling Server ถูกรวมผ่าน WebSocket API ของเบราว์เซอร์ ไคลเอ็นต์สร้างการเชื่อมต่อกับเซิร์ฟเวอร์ ส่งคำขอเข้าร่วมห้อง จากนั้นประมวลผลข้อความ WebRTC ที่เข้ามาโดยส่งต่อไปยัง RTCPeerConnection ผ่าน setRemoteDescription() และ addIceCandidate() โค้ดไคลเอ็นต์ยังส่งผู้สมัคร SDP และ ICE ของตัวเองไปยังเซิร์ฟเวอร์ ซึ่งได้รับจาก RTCPeerConnection ผ่านอีเวนต์ onicecandidate และหลังจากสร้าง offer/answer

บทบาทของ SDP และ ICE ในการส่งสัญญาณ

Signaling Server ส่งข้อมูลเมตาสองประเภทหลัก: SDP (Session Description Protocol) และผู้สมัคร ICE SDP อธิบายพารามิเตอร์สตรีมสื่อ — ตัวแปลงสัญญาณ อัตราการสุ่มตัวอย่าง จำนวนช่อง ทิศทางการส่ง (sendrecv, sendonly, recvonly, inactive) ผู้สมัคร ICE ประกอบด้วยที่อยู่เครือข่าย (ในเครื่อง ได้จาก STUN รีเลย์จาก TURN) ซึ่งเพียร์สามารถเข้าถึงได้สำหรับการเชื่อมต่อ

SDP นำเสนอในรูปแบบข้อความที่มีส่วนเซสชันและสื่อ ส่วนเซสชันอธิบายพารามิเตอร์ทั่วไป (ID เซสชัน เวอร์ชัน ชื่อ) ในขณะที่ส่วนสื่ออธิบายแต่ละสตรีมสื่อ (เสียง วิดีโอ DataChannel) พร้อมตัวแปลงสัญญาณ พอร์ตและโปรโตคอล ผู้สมัคร ICE ประกอบด้วย foundation (ตัวระบุการจัดกลุ่ม) ลำดับความสำคัญ ที่อยู่ IP พอร์ต ประเภท (host, srflx, relay) และโปรโตคอล (UDP, TCP) ผู้สมัครแต่ละตัวยังรวมถึงแอตทริบิวต์ ufrag (ส่วนชื่อผู้ใช้) ที่เชื่อมโยงกับกระบวนการ ICE เฉพาะ

• SDP Offer — ผู้เริ่มต้นสร้างคำอธิบายความสามารถด้านสื่อของตนและส่งไปยังเพียร์ระยะไกลผ่าน Signaling Server
• SDP Answer — เพียร์ระยะไกลตอบกลับด้วยคำอธิบายของตนเอง ยืนยันหรือปรับรูปแบบสื่อและตัวแปลงสัญญาณ
• ICE Candidate — เพียร์แต่ละตัวส่งผู้สมัครเครือข่ายของตนไปยังเซิร์ฟเวอร์ส่งสัญญาณเมื่อถูกค้นพบโดยเฟรมเวิร์ก ICE
• Trickle ICE — การเพิ่มประสิทธิภาพสมัยใหม่ที่ส่งผู้สมัครทีละรายเมื่อถูกค้นพบ แทนที่จะส่งทั้งหมดพร้อมกันหลังจากการรวบรวมเสร็จสมบูรณ์
• การเจรจาใหม่ — เมื่อพารามิเตอร์สื่อเปลี่ยนแปลง (เปิด/ปิดวิดีโอ เพิ่มผู้เข้าร่วม) เพียร์เริ่มการแลกเปลี่ยน SDP ใหม่ผ่าน Signaling Server

Trickle ICE เร่งการสร้างการเชื่อมต่อ WebRTC อย่างมีนัยสำคัญ แทนที่จะรอการรวบรวมผู้สมัคร ICE ทั้งหมดให้เสร็จสมบูรณ์ (ซึ่งอาจใช้เวลา 2–10 วินาทีในเครือข่ายที่ซับซ้อน) ผู้สมัครแต่ละตัวจะถูกส่งไปยัง Signaling Server ทันทีหลังจากถูกค้นพบ เพียร์ระยะไกลได้รับผู้สมัครและเริ่มทดสอบการเชื่อมต่อผ่านเฟรมเวิร์ก ICE ทันที ซึ่งช่วยลดเวลาในการสร้างการเชื่อมต่อเหลือ 500–1500 มิลลิวินาทีในกรณีส่วนใหญ่