ICE Candidate: ความหมาย ประเภทของแคนดิเดต และการทำงาน

ICE Candidate คืออะไร?

ICE Candidate (Interactive Connectivity Establishment Candidate) คือหน่วยพื้นฐานในกระบวนการสร้างการเชื่อมต่อ P2P ผ่านโปรโตคอล WebRTC มันแสดงถึงคู่ที่อยู่ IP + พอร์ตที่สามารถใช้ส่งข้อมูลระหว่างเพียร์สองตัว แคนดิเดตแต่ละตัวประกอบด้วยข้อมูลเกี่ยวกับโปรโตคอลการขนส่ง (UDP, TCP), ประเภทการเชื่อมต่อ และลำดับความสำคัญ

ICE Candidate ถูกสร้างขึ้นบนแต่ละอุปกรณ์แยกกัน อุปกรณ์จะรวบรวมอินเทอร์เฟซเครือข่ายที่มีทั้งหมด ขอที่อยู่ภายนอกผ่าน เซิร์ฟเวอร์ STUN และเพิ่มที่อยู่รีเลย์จากเซิร์ฟเวอร์ TURN รายการแคนดิเดตที่ได้จะถูกส่งไปยังเพียร์ระยะไกลผ่านช่องสัญญาณ signalling ในรูปแบบ SDP (Session Description Protocol)

ตามข้อกำหนด RFC 8445 (IETF, 2018) ICE ใช้กลไก nominated pairs: หลังจากรวบรวมแคนดิเดตทั้งหมดแล้ว จะทำการทดสอบเป็นคู่ผ่านคำขอ STUN คู่ที่ผ่านการตรวจสอบก่อนจะถูกประกาศเป็น nominated (กำหนด) และใช้สำหรับส่งข้อมูลมัลติมีเดีย คู่อื่น ๆ ยังคงอยู่ในสำรองในกรณีที่การเชื่อมต่อขาด

บทบาทของ ICE ในสแต็ก WebRTC

WebRTC เป็นมาตรฐานเปิดสำหรับการสื่อสาร P2P แต่การเชื่อมต่อโดยตรงระหว่างอุปกรณ์มักเป็นไปไม่ได้เนื่องจาก NAT (Network Address Translation) และไฟร์วอลล์ ICE Candidate แก้ปัญหานี้โดยเสนอเส้นทางการเชื่อมต่อสำรองหลายทาง โปรโตคอล ICE (Interactive Connectivity Establishment) เป็นส่วนประกอบบังคับของ WebRTC และอธิบายไว้ในข้อกำหนด W3C WebRTC (2025)

นักพัฒนาแอปพลิเคชันมือถือจำนวนมากใช้ ไลบรารี WebRTC เช่น Google WebRTC (สำหรับ Android) และ wrapper ดั้งเดิมสำหรับ iOS ในแต่ละตัว กระบวนการ ICE จะถูกจัดการโดยอัตโนมัติ แต่การเข้าใจประเภทของแคนดิเดตช่วยให้นักพัฒนาสามารถกำหนดค่าโครงสร้างพื้นฐานเซิร์ฟเวอร์และปรับปรุงคุณภาพการเชื่อมต่อได้

รูปแบบ SDP กับแคนดิเดต ICE

ICE Candidate ถูกส่งในข้อความ SDP ในรูปแบบคุณลักษณะ a=candidate แต่ละบรรทัดประกอบด้วย foundation, component ID, โปรโตคอลการขนส่ง, ลำดับความสำคัญ, ที่อยู่ IP, พอร์ต และประเภทแคนดิเดต ด้านล่างนี้คือตัวอย่างของส่วน SDP ที่มีแคนดิเดตสามประเภทที่แตกต่างกัน:

// ตัวอย่าง SDP พร้อมแคนดิเดต ICE
a=candidate:1 1 UDP 2130706431 192.168.1.10 54321 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 54322 typ srflx
a=candidate:3 1 TCP 1019212287 198.51.100.7 54323 typ relay raddr 203.0.113.5 rport 3478

ฟิลด์ priority กำหนดลำดับการทดสอบแคนดิเดต ยิ่งลำดับความสำคัญสูงเท่าไร แคนดิเดตก็จะถูกตรวจสอบเร็วขึ้นเท่านั้น แคนดิเดต host มีลำดับความสำคัญสูงที่สุดเสมอ ส่วน relay มีต่ำที่สุด

ประเภทของแคนดิเดต ICE

ข้อกำหนด RFC 8445 กำหนด สี่ประเภท ของแคนดิเดต ICE ซึ่งแต่ละประเภทสอดคล้องกับวิธีการเฉพาะในการเข้าถึงเพียร์ระยะไกล ประเภทของแคนดิเดตมีผลต่อลำดับความสำคัญ เวลาสร้างการเชื่อมต่อ และข้อกำหนดโครงสร้างพื้นฐานเซิร์ฟเวอร์

แคนดิเดต host

แคนดิเดต host ถูกสร้างขึ้นจากที่อยู่ IP ของอินเทอร์เฟซเครือข่ายภายในของอุปกรณ์ หากอุปกรณ์อยู่ในเครือข่ายภายในเดียวกันกับเพียร์ แคนดิเดต host จะให้การเชื่อมต่อโดยตรงที่มีความหน่วงต่ำที่สุด สำหรับอุปกรณ์มือถือ แคนดิเดต host จะถูกสร้างขึ้นสำหรับอินเทอร์เฟซ WiFi, การเชื่อมต่อมือถือ LTE/5G และหากจำเป็น สำหรับอุโมงค์ VPN

แคนดิเดต host มี ลำดับความสำคัญสูงที่สุด (2130706431 สำหรับ UDP) และถูกทดสอบก่อน หากเพียร์ทั้งสองอยู่หลัง NAT แคนดิเดต host ของพวกเขาจะเป็นที่อยู่ส่วนตัว (192.168.x.x, 10.x.x.x) และการเชื่อมต่อโดยตรงผ่านที่อยู่เหล่านั้นเป็นไปไม่ได้ ICE จะเปลี่ยนไปทดสอบแคนดิเดต srflx และ relay

แคนดิเดต SRFLX และ PRFLX

แคนดิเดต SRFLX (Server Reflexive) คือที่อยู่ IP ภายนอกและพอร์ตที่ได้รับจากเซิร์ฟเวอร์ STUN เมื่ออุปกรณ์ส่งคำขอ STUN เซิร์ฟเวอร์จะเห็นที่อยู่สาธารณะหลังจาก NAT และส่งกลับมา แคนดิเดตนี้ช่วยให้สร้างการเชื่อมต่อโดยตรงระหว่างเพียร์หลัง NAT ที่แตกต่างกันได้ หากอุปกรณ์ NAT ของพวกเขารองรับ Hairpinning

แคนดิเดต PRFLX (Peer Reflexive) ถูกตรวจจับแบบไดนามิกเมื่อคำขอ STUN จากเพียร์หนึ่งมาถึงที่อยู่ที่ไม่คาดคิด ประเภทนี้เกิดขึ้นเมื่อเพียร์ทั้งสองส่งคำขอพร้อมกันและ NAT สร้างการเชื่อมโยงชั่วคราว แคนดิเดต PRFLX มี ลำดับความสำคัญสูงกว่า srflx แต่ต่ำกว่า host

ในแอปพลิเคชันมือถือ แคนดิเดต srflx มีความสำคัญ特別อย่างยิ่งเมื่อสลับระหว่าง WiFi และเครือข่ายมือถือ เมื่ออุปกรณ์เปลี่ยนเครือข่าย ที่อยู่ IP จะเปลี่ยนไปและ ICE ต้องรวบรวมแคนดิเดตใหม่ กระบวนการนี้เรียกว่า ICE restart และต้องส่ง SDP ใหม่

แคนดิเดต relay ผ่าน TURN

แคนดิเดต relay คือที่อยู่บนเซิร์ฟเวอร์ TURN ซึ่งทราฟฟิกจะถูกถ่ายทอดจากเพียร์หนึ่งไปยังอีกเพียร์หนึ่ง ประเภทนี้ใช้เป็นตัวเลือกสำรองเมื่อการเชื่อมต่อ P2P โดยตรงเป็นไปไม่ได้ (NAT แบบสมมาตร, ไฟร์วอลล์ขององค์กร) ช่องสัญญาณรีเลย์เพิ่มความหน่วงและเพิ่มภาระเซิร์ฟเวอร์ ดังนั้นใน การกำหนดค่าที่เหมาะสมที่สุด เซิร์ฟเวอร์ TURN จะใช้สำหรับเพียง 10–15% ของเซสชันทั้งหมด

การใช้งานเซิร์ฟเวอร์ TURN ที่ได้รับความนิยม: coturn (โอเพนซอร์ส), Twilio Network Traversal, Metered TURN การเลือกผู้ให้บริการ TURN มีผลต่อ คุณภาพการเชื่อมต่อสื่อ ในแอปพลิเคชันมือถือ — เซิร์ฟเวอร์ควรอยู่ใกล้ผู้ใช้ทางภูมิศาสตร์เพื่อลดความหน่วงเพิ่มเติม

กระบวนการ ICE ทำงานอย่างไร

กระบวนการ ICE เป็นโปรโตคอลหลายขั้นตอนที่รับประกันการสร้าง การเชื่อมต่อ P2P ที่เชื่อถือได้ ในสภาวะที่ไม่แน่นอนของโทโพโลยีเครือข่าย อัลกอริทึมอธิบายไว้ใน RFC 8445 และประกอบด้วยสี่ขั้นตอนบังคับ: การรวบรวมแคนดิเดต การจัดเรียง การทดสอบ และการกำหนด

ขั้นตอนที่ 1: การรวบรวมแคนดิเดต

แต่ละอุปกรณ์รวบรวม ที่อยู่เครือข่าย ที่มีอยู่ทั้งหมด โดยเครื่องมือ WebRTC จะแจกแจงอินเทอร์เฟซภายใน (host) ส่งคำขอไปยังเซิร์ฟเวอร์ STUN (srflx) และขอที่อยู่รีเลย์จากเซิร์ฟเวอร์ TURN ในเวลาเดียวกัน อุปกรณ์อาจตรวจจับแคนดิเดต prflx หากได้รับคำขอ STUN ขาเข้าจากเพียร์

ในการพัฒนาแอปมือถือ ขั้นตอนนี้สำคัญสำหรับ เวลาสร้างการเชื่อมต่อ บน iOS และ Android การรวบรวมแคนดิเดตอาจใช้เวลาตั้งแต่ 200 ms ถึง 2 วินาที ขึ้นอยู่กับความเร็วเครือข่าย ความพร้อมใช้งานของเซิร์ฟเวอร์ STUN/TURN และจำนวนอินเทอร์เฟซเครือข่ายที่ใช้งานอยู่

ขั้นตอนที่ 2: การสร้างคู่และการจัดเรียง

หลังจากได้รับรายการแคนดิเดตจากเพียร์ระยะไกลผ่านช่องสัญญาณ signalling เครื่องมือ ICE ในพื้นที่จะสร้าง คู่แคนดิเดต ที่เป็นไปได้ทั้งหมด (ภายใน + ระยะไกล) แต่ละคู่ได้รับลำดับความสำคัญตามสูตรจาก RFC 8445 โดยพิจารณาจากลำดับความสำคัญของแคนดิเดตทั้งสองและทิศทาง (ขาเข้า/ขาออก)

คู่ต่าง ๆ ถูกจัดเรียงตามลำดับความสำคัญจากมากไปน้อย คู่ที่ดีที่สุด จะถูกทดสอบก่อน อัลกอริทึมรับประกันว่าคู่ host-host จะถูกตรวจสอบก่อน host-srflx, host-relay หรือ relay-relay ซึ่งช่วยลดความหน่วงในการเชื่อมต่อในการกำหนดค่าเครือข่ายที่เรียบง่าย

ขั้นตอนที่ 3: การทดสอบและการกำหนด

ICE ส่ง คำขอ STUN-binding สำหรับแต่ละคู่แคนดิเดต หากได้รับการตอบกลับ STUN แสดงว่าคู่นั้นใช้ได้ คู่ที่ใช้ได้คู่แรกจะถูกกำหนด (nominated) เป็นหลัก เครื่องมือ WebRTC เริ่มส่งข้อมูลสื่อผ่านคู่นี้ ในขณะที่คู่อื่น ๆ ยังคงถูกตรวจสอบในกรณีที่คู่หลักล้มเหลว

กระบวนการทดสอบอาจใช้เวลา หลายวินาที เมื่อมีแคนดิเดตจำนวนมาก WebRTC ใช้ตัวจับเวลา: สำหรับคู่ host ตัวจับเวลาแบบเข้มข้น (20 ms) สำหรับ relay แบบอนุรักษ์นิยมกว่า (200 ms) นักพัฒนาแอปมือถือสามารถเร่งการเชื่อมต่อได้โดยจำกัดจำนวนเซิร์ฟเวอร์ ICE หรือกำหนดค่า iceTransportPolicy

ICE Restart

ICE restart คือการเริ่มกระบวนการ ICE ใหม่โดยไม่ต้องสร้าง RTCPeerConnection ทั้งหมดใหม่ จำเป็นเมื่อเปลี่ยนเครือข่าย สูญเสียการเชื่อมต่อ หรือสลับระหว่าง WiFi และเครือข่ายมือถือ เมื่อเริ่มต้นใหม่ แคนดิเดตปัจจุบันทั้งหมดจะถูกรีเซ็ตและกระบวนการเริ่มต้นใหม่ด้วยการสร้าง ufrag และ pwd ใหม่

ในการพัฒนา iOS ICE restart ถูกเรียกด้วยเมธอด restartIce() บน RTCPeerConnection บน Android ใช้เมธอดที่คล้ายกันในคลาส PeerConnection จาก Google WebRTC การจัดการ ICE restart อย่างถูกต้องเป็น ข้อกำหนดที่สำคัญ สำหรับแอปพลิเคชันที่ทำงานบนอุปกรณ์มือถือที่มีการเชื่อมต่อเครือข่ายไม่เสถียร

เซิร์ฟเวอร์ STUN และ TURN ใน ICE

STUN (Session Traversal Utilities for NAT) และ TURN (Traversal Using Relays around NAT) เป็นส่วนประกอบเซิร์ฟเวอร์สำคัญที่หากไม่มี ICE Candidate ไม่สามารถรับประกันการเชื่อมต่อที่ประสบความสำเร็จในสภาพอินเทอร์เน็ตจริง การกำหนดค่าที่ถูกต้องของเซิร์ฟเวอร์เหล่านี้มีผลโดยตรงต่อคุณภาพการโทรในแอปพลิเคชันมือถือ

STUN: การตรวจจับที่อยู่ภายนอก

เซิร์ฟเวอร์ STUN ช่วยให้อุปกรณ์ทราบ ที่อยู่ IP สาธารณะ และพอร์ตที่ NAT จัดสรรสำหรับการเชื่อมต่อขาออก โปรโตคอล STUN กำหนดไว้ใน RFC 8489 และทำงานบน UDP ที่พอร์ต 3478 และรองรับ TCP เช่นกัน Google ให้บริการเซิร์ฟเวอร์ STUN สาธารณะ (stun.l.google.com:19302) ที่สามารถใช้ได้ฟรี

ในการพัฒนาแอปมือถือ คำขอ STUN เป็น การดำเนินการที่มีน้ำหนักเบา ใช้เวลา 50–200 ms อย่างไรก็ตาม เครือข่ายองค์กรและมือถือบางแห่งบล็อกทราฟฟิก UDP ทำให้ ICE ต้องใช้ TCP สำหรับการสื่อสาร STUN หรือเปลี่ยนไปใช้ TURN โดยตรง

TURN: การถ่ายทอดทราฟฟิก

เซิร์ฟเวอร์ TURN คือตัวถ่ายทอดทราฟฟิกสื่อ เมื่อการเชื่อมต่อ P2P โดยตรงเป็นไปไม่ได้ (NAT แบบสมมาตร, ไฟร์วอลล์) อุปกรณ์จะส่งข้อมูลไปยัง TURN ซึ่งจะส่งต่อไปยังเพียร์อีกตัว TURN เป็นกลไกที่เชื่อถือได้แต่มีค่าใช้จ่ายสูง: มันเพิ่มความหน่วง (30–100 ms) และต้องใช้ แบนด์วิดท์ เซิร์ฟเวอร์เท่ากับผลรวมของเซสชันสื่อทั้งหมด

ตาม WebRTC Stats Report (2025) ประมาณ 8–15% ของเซสชัน WebRTC ในเครือข่ายมือถือต้องการ TURN เพื่อเพิ่มประสิทธิภาพค่าใช้จ่ายทราฟฟิก TURN นักพัฒนาใช้การทดสอบการเชื่อมต่อล่วงหน้าและเปิดใช้งานช่องสัญญาณ TURN เฉพาะเมื่อ P2P ล้มเหลว

การเลือก STUN/TURN สำหรับแอปพลิเคชันมือถือ

เมื่อเลือกโครงสร้างพื้นฐานสำหรับ ICE ในโปรเจกต์มือถือ จะพิจารณาจาก: ตำแหน่งทางภูมิศาสตร์ ของเซิร์ฟเวอร์เพื่อลดความหน่วง การรองรับ UDP และ TCP ค่าใช้จ่ายทราฟฟิก TURN และ SLA โซลูชันที่ได้รับความนิยม: coturn สำหรับการติดตั้งด้วยตนเอง, Twilio, Agora และ LiveKit สำหรับการใช้งานคลาวด์

ICE Candidate ในการพัฒนาแอปมือถือ

สำหรับนักพัฒนาแอปมือถือ ความเข้าใจเกี่ยวกับ ICE Candidate เกินกว่าทฤษฎี — เป็นความจำเป็นในทางปฏิบัติเมื่อสร้างแอปพลิเคชันที่มีการโทรด้วยเสียงและวิดีโอ แพลตฟอร์ม iOS และ Android ให้ API ดั้งเดิมสำหรับ WebRTC ที่ทำงานกับ ICE โดยอัตโนมัติ แต่นักพัฒนามีหน้าที่รับผิดชอบในการกำหนดค่าเซิร์ฟเวอร์ ICE และจัดการเหตุการณ์การเปลี่ยนแปลงเครือข่าย

การกำหนดค่า ICE บน iOS

บน iOS WebRTC สามารถใช้งานได้ผ่านเฟรมเวิร์ก WebRTC.framework หรือไลบรารี GoogleWebRTC ผ่าน CocoaPods เซิร์ฟเวอร์ ICE ถูกกำหนดค่าผ่านอาร์เรย์ RTCIceServer ใน RTCConfiguration:

let config = RTCConfiguration()
let stunServer = RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"])
let turnServer = RTCIceServer(urlStrings: ["turn:turn.example.com:3478"],
                                    username: "user",
                                    credential: "pass")
config.iceServers = [stunServer, turnServer]
let pc = RTCPeerConnection(configuration: config)

หลังจากสร้าง RTCPeerConnection และเรียก offer() หรือ answer() เครื่องมือจะรวบรวมแคนดิเดต ICE โดยอัตโนมัติ เหตุการณ์ iceGatheringStateChange แจ้งเกี่ยวกับการเปลี่ยนแปลงสถานะการรวบรวม และ iceConnectionState แจ้งเกี่ยวกับสถานะการเชื่อมต่อ

การกำหนดค่า ICE บน Android

Android ใช้ไลบรารี Google WebRTC เดียวกัน เซิร์ฟเวอร์ ICE ถูกกำหนดผ่าน PeerConnection.RTCConfiguration นักพัฒนาสามารถจัดการนโยบาย ICE ผ่าน iceTransportsType — โหมด relay บังคับใช้เฉพาะ TURN ซึ่งเพิ่มความเชื่อถือได้แต่เพิ่มความหน่วง:

val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.l.google.com:19302").createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("pass")
        .createIceServer()
)
val config = PeerConnection.RTCConfiguration(iceServers)
config.iceTransportsType = PeerConnection.IceTransportsType.ALL
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE

พารามิเตอร์ bundlePolicy มีผลต่อจำนวนแคนดิเดต ICE — โหมด MAXBUNDLE รวมสตรีมสื่อทั้งหมดเป็นหนึ่งการขนส่ง ลดจำนวนแคนดิเดตทั้งหมดและเร่งการเชื่อมต่อ

การจัดการเหตุการณ์ ICE ในแอปพลิเคชันมือถือ

เหตุการณ์ ICE ที่สำคัญที่นักพัฒนาต้องจัดการ: สถานะการเชื่อมต่อ ICE (ICE connection state), การเปลี่ยนแปลงสถานะการรวบรวม (ICE gathering state) และการตรวจจับแคนดิเดตใหม่ หลังจาก ICE เสร็จสิ้นการรวบรวมและทดสอบ สถานะของมันจะเปลี่ยนเป็น connected หรือ completed

ในเครือข่ายมือถือ มักเกิด การสลับ ระหว่าง WiFi และเครือข่ายมือถือ เมื่อเปลี่ยนเครือข่าย ICE ต้องทำ restart มิฉะนั้นสตรีมสื่อจะถูกขัดจังหวะ นักพัฒนาตรวจจับ NetworkManager (iOS) หรือ ConnectivityManager (Android) เพื่อเรียก restartIce() โดยอัตโนมัติ

การใช้งาน ICE ที่ประสบความสำเร็จในแอปพลิเคชันมือถือประกอบด้วย: การเลือกเซิร์ฟเวอร์ STUN/TURN ที่เชื่อถือได้, การจัดการ ICE restart ที่ถูกต้องเมื่อเปลี่ยนเครือข่าย, การกำหนดค่า iceConnectionState เพื่อแสดงสถานะการเชื่อมต่อ UI และการติดตามสถิติผ่าน RTCStatsReport