คำอธิบายอย่างละเอียดและการประยุกต์ใช้งานจริงของ STUN/TURN/TURNS/SFU ใน WebRTC

WebRTC คืออะไร?

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

WebRTC ประกอบด้วยส่วนประกอบหลักสามส่วนดังต่อไปนี้:

• getUser MediaAPI ที่รับข้อมูลเสียงและวิดีโอจากอุปกรณ์ต่างๆ เช่น กล้องและไมโครโฟน
• การเชื่อมต่อ RTCPeer: API หลักที่สร้างการสื่อสารระหว่างผู้ใช้งานและแลกเปลี่ยนสื่อและข้อมูล
• RTCDataChannelช่องทางการรับส่งข้อมูลที่สามารถใช้สำหรับการถ่ายโอนไฟล์ การสนทนา และอื่นๆ

API เหล่านี้ช่วยให้สามารถพัฒนาแอปพลิเคชันแบบเรียลไทม์ได้มากมาย เช่น การโทรผ่านวิดีโอ การประชุมทางเสียง และการแชร์ไฟล์ อย่างไรก็ตาม การสื่อสารในโลกแห่งความเป็นจริงนั้นเกี่ยวข้องกับการทะลุผ่าน NAT และปัญหาไฟร์วอลล์ ทำให้การทำความเข้าใจและการใช้งานเทคโนโลยีการทะลุผ่าน NAT เช่น STUN/TURN/TURNS เป็นสิ่งสำคัญ

ความแตกต่างและบทบาทของ STUN, TURN และ TURNS

เพื่อให้การเชื่อมต่อแบบ Peer-to-Peer กับ WebRTC มีเสถียรภาพ กลไกการทะลุผ่าน NAT จึงเป็นสิ่งสำคัญ ในที่นี้ เราจะอธิบายรายละเอียดเกี่ยวกับความแตกต่างทางเทคนิค สถานการณ์การใช้งาน ข้อดี และข้อเสียของ STUN, TURN และ TURNS ซึ่งเป็นเทคโนโลยีที่เป็นตัวแทน

STUN เป็นโปรโตคอลที่ใช้หลักๆ ในการกำหนดที่อยู่ภายนอกในสภาพแวดล้อม NAT ในขณะที่ TURN เป็นโปรโตคอลที่ทำหน้าที่เป็นเซิร์ฟเวอร์รีเลย์เมื่อไม่สามารถเชื่อมต่อโดยตรงได้ ในทางกลับกัน TURNS เข้ารหัสการสื่อสาร TURN โดยใช้ TLS และใช้พอร์ต 443 เดียวกันกับ HTTPS ทำให้สามารถสื่อสารได้ภายใต้ไฟร์วอลล์ที่เข้มงวด เช่น ไฟร์วอลล์ที่พบในเครือข่ายองค์กร

ด้วยการทำความเข้าใจลักษณะเฉพาะของแต่ละวิธีและนำไปใช้ให้เหมาะสม คุณจะสามารถเพิ่มอัตราความสำเร็จและคุณภาพของการสื่อสาร WebRTC ได้

บทบาทและลักษณะเฉพาะของ STUN (UDP)

STUN (Session Traversal Utilities for NAT) เป็นไคลเอ็นต์ที่อยู่ IP ภายนอกและพอร์ตนี่เป็นขั้นตอนง่ายๆ ในการค้นหาที่อยู่ IP ของคุณ ตัวอย่างเช่น หากพีซีของคุณอยู่หลัง NAT มันจะไม่ทราบที่อยู่ IP ทั่วโลกของตัวเอง แต่สามารถรับ "ที่อยู่ IP และพอร์ตที่มองเห็นได้จากภายนอก" ได้โดยการสอบถามเซิร์ฟเวอร์ STUN

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

การสื่อสาร STUN โดยทั่วไปใช้โปรโตคอล UDP โดยพอร์ตเริ่มต้นคือ 3478 (UDP/3478) เนื่องจากใช้การสื่อสาร UDP เพียงครั้งเดียวและมีขนาดเล็ก จึงมีค่าใช้จ่ายและเวลาแฝงต่ำ และแทบไม่สร้างภาระให้กับเซิร์ฟเวอร์เลย ดังนั้น ในสภาพแวดล้อมที่อนุญาตให้ใช้การสื่อสาร UDP การสื่อสาร STUN จึงเป็นวิธีการแรกที่พยายามใช้เพื่อทะลุผ่าน NAT

ฉากการใช้งาน STUN

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

ข้อจำกัดและข้อเสียของ STUN

STUN เป็นเพียงวิธีการ "ค้นหาที่อยู่ภายนอกของคุณเอง" และขึ้นอยู่กับประเภท NAT และข้อจำกัดของไฟร์วอลล์ อาจไม่สามารถสร้างการเชื่อมต่อได้โดยใช้ STUN เพียงอย่างเดียว โดยเฉพาะอย่างยิ่งในสภาพแวดล้อม NAT แบบสมมาตรหรือไฟร์วอลล์ที่เข้มงวด แพ็กเก็ตจากอีกฝ่ายอาจไปไม่ถึงที่อยู่ซึ่งได้รับผ่าน STUN ทำให้การสื่อสารเป็นไปไม่ได้

นอกจากนี้ ในเครือข่ายองค์กรบางแห่ง การสื่อสาร UDP อาจถูกบล็อก ซึ่งในกรณีนี้คำขอ STUN จะไม่ถูกส่งไป กล่าวโดยสรุป STUN เป็นกลไกสำหรับ "การพิจารณาว่าการสื่อสารโดยตรงเป็นไปได้หรือไม่" และจะไม่ทำงานในสภาพแวดล้อมที่การสื่อสารโดยตรงเป็นไปไม่ได้ในทางกายภาพ ดังนั้น STUN จึงถูกใช้ในขั้นตอนแรกของการคัดเลือกผู้สมัครใน ICE (ซึ่งจะอธิบายในภายหลัง) และหาก STUN ไม่เพียงพอ ระบบจะออกแบบให้เปลี่ยนไปใช้ TURN ซึ่งจะอธิบายในภายหลัง

บทบาทและลักษณะเฉพาะของ TURN (UDP)

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

โดยทั่วไป TURN จะสื่อสารโดยใช้ UDP ดังนั้นตราบใดที่ UDP พร้อมใช้งาน ก็สามารถส่งต่อแพ็กเก็ตสื่อได้ในลักษณะที่ใกล้เคียงกับการสื่อสารโดยตรง โดยค่าเริ่มต้น TURN จะยอมรับโปรโตคอล TURN บนพอร์ต 3478 (UDP) เช่นเดียวกับ STUN แม้ว่าหมายเลขพอร์ต UDP จะถูกจำกัดโดยนโยบายไฟร์วอลล์ TURN ก็ยังสามารถทำงานบนพอร์ตที่อนุญาตได้ เช่น UDP/443 ตราบใดที่ UDP พร้อมใช้งาน ก็สามารถส่งต่อข้อมูลแบบเรียลไทม์ได้ดีกว่า TCP

สถานการณ์การใช้งาน TURN

TURN เป็นสิ่งจำเป็นเมื่อไม่สามารถสร้างการเชื่อมต่อโดยตรงกับอีกฝ่ายได้ ตัวอย่างเช่นปัญหานี้อาจเกิดขึ้นได้เมื่อฝ่ายใดฝ่ายหนึ่งหรือทั้งสองฝ่ายอยู่หลังไฟร์วอลล์ที่เข้มงวดของบริษัท หรือเมื่อการเจาะช่องโหว่ UDP ล้มเหลวระหว่าง NAT แบบสมมาตรในสภาพแวดล้อมเช่นนี้ การสื่อสารเป็นไปไม่ได้หากไม่ผ่านเซิร์ฟเวอร์ TURN ดังนั้น TURN จึงทำหน้าที่เป็นแนวป้องกันสุดท้าย

WebRTC มีเป้าหมายให้ผู้เข้าร่วมทุกฝ่ายสื่อสารกันโดยตรง แต่หากเป็นไปไม่ได้ การสื่อสารสามารถดำเนินต่อไปได้โดยใช้ TURN เป็นทางเลือกสำรอง ในการใช้งานจริง กลยุทธ์ทั่วไปคือการพยายามเชื่อมต่อโดยตรงด้วย STUN ก่อน และจะเปลี่ยนไปใช้ TURN ก็ต่อเมื่อการเชื่อมต่อโดยตรงล้มเหลวเท่านั้น ตัวอย่างเช่น ในการประชุมทางวิดีโอผ่านเครือข่ายของบริษัท หากผู้เข้าร่วมไม่สามารถสื่อสารกันโดยตรงได้ การสื่อสารจะเปลี่ยนไปใช้เซิร์ฟเวอร์ TURN โดยอัตโนมัติ ทำให้ผู้ใช้สามารถสนทนาต่อได้โดยไม่รู้ตัว

ประโยชน์ของ TURN

ข้อได้เปรียบที่สำคัญที่สุดคือความน่าเชื่อถือ ในสภาพแวดล้อม NAT หรือไฟร์วอลล์ใดๆ ตราบใดที่สามารถสร้างการสื่อสารจากไคลเอ็นต์ไปยังเซิร์ฟเวอร์ TURN ได้ การสื่อสารแบบ peer-to-peer ก็สามารถทำได้ในที่สุด นอกจากนี้ เนื่องจาก TURN เป็นส่วนขยายของโปรโตคอล STUN การใช้งานเซิร์ฟเวอร์เดียว (เช่น coturn ซึ่งจะกล่าวถึงในภายหลัง) สามารถจัดการทั้งคำขอ STUN และ TURN ได้ เมื่อสร้างการเชื่อมต่อแล้ว สื่อที่ตามมาจะถูกส่งต่อเป็นสตรีม ดังนั้นจากมุมมองของผู้ใช้ การสื่อสารจึงราบรื่นโดยมีเพียงความล่าช้าเล็กน้อยเท่านั้น

ข้อเสียของ TURN

ข้อเสียที่สำคัญที่สุดคือการสิ้นเปลืองทรัพยากรและความหน่วงแฝง ด้วย TURN ข้อมูลเสียงและวิดีโอทั้งหมดจะผ่านเซิร์ฟเวอร์ ซึ่งต้องใช้แบนด์วิดท์และพลังประมวลผลจำนวนมากบนฝั่งเซิร์ฟเวอร์ ตัวอย่างเช่น สมมติว่าการสนทนาทางวิดีโอแบบตัวต่อตัวใช้แบนด์วิดท์ 1 Mbps ในทิศทางเดียว การคำนวณอย่างง่ายจะแสดงให้เห็นว่าผู้ใช้พร้อมกัน 1,000 คนจะต้องใช้แบนด์วิดท์รีเลย์ 1 Gbps ดังนั้น ต้นทุนการดำเนินงานของเซิร์ฟเวอร์ TURN จึงสูง และบริการขนาดใหญ่จำเป็นต้องใช้เซิร์ฟเวอร์รีเลย์ TURN จำนวนมากเพื่อรองรับการขยายขนาด

นอกจากนี้ เส้นทางการสื่อสารที่ยาวขึ้นยังทำให้เกิดความหน่วงมากขึ้น ส่งผลให้เกิดความล่าช้าและคุณภาพของวิดีโอและเสียงลดลง ยิ่งไปกว่านั้น TURN ไม่ใช่ระบบแบบ peer-to-peer อย่างแท้จริงเมื่อเทียบกับ STUN ทำให้มีความปลอดภัยน้อยกว่าเล็กน้อย (ถึงแม้ว่าเซิร์ฟเวอร์ TURN โดยทั่วไปจะส่งต่อเฉพาะ RTP/datagram ที่ไม่ได้เข้ารหัสและไม่ได้ตีความเนื้อหาของมันก็ตาม)

โดยทั่วไป ควรใช้ TURN เฉพาะเมื่อจำเป็นเท่านั้น ในความเป็นจริง การสื่อสาร WebRTC จำนวนมากสามารถเชื่อมต่อได้โดยตรงโดยใช้ STUN และสถิติของ Google รายงานว่ามีการโทร TP3T ประมาณ 861 ครั้งที่เสร็จสมบูรณ์โดยไม่ต้องใช้รีเลย์ (peer-to-peer) มีเพียงกรณี TP3T ที่เหลืออีกประมาณ 141 กรณีเท่านั้นที่ต้องใช้ TURN และเป็นสิ่งสำคัญที่จะต้องเตรียมโครงสร้างพื้นฐาน TURN สำหรับกรณี TP3T ทั้ง 141 กรณีนี้

บทบาทและลักษณะเฉพาะของ TURNS (TLS ผ่าน TCP/443)

TURNS เป็นคำย่อของ "TURN over TLS" ซึ่งเป็นวิธีการเข้ารหัสการสื่อสารแบบรีเลย์โดยใช้โปรโตคอล TURN ร่วมกับ TLS (Transport Layer Security)การสื่อสาร TURN ได้รับการปกป้องโดย TLS (HTTPS)โดยปกติจะให้บริการผ่านพอร์ต TCP 443เนื่องจากพอร์ต 443 เป็นหมายเลขพอร์ตเดียวกับ HTTPS จึงทำให้สามารถผ่านไฟร์วอลล์ขององค์กรได้ง่ายกว่า ซึ่งเป็นข้อดีเพราะช่วยให้หลีกเลี่ยงพร็อกซีและการเซ็นเซอร์ได้ง่ายขึ้น。

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

ใน WebRTC การตั้งค่าต่างๆ""urls": "turns:turnserver:443""เช่นเดียวกับในรูปแบบ URIเทิร์น:เมื่อระบุตัวเลือกนี้ คุณสามารถใช้เซิร์ฟเวอร์ TURN ที่เข้ารหัส TLS นี้ได้

สถานการณ์การใช้งาน TURNS

ในการสื่อสาร WebRTC ภายใต้ข้อจำกัดที่เข้มงวด เช่น ภายในเครือข่ายองค์กร TURNS มีประโยชน์เมื่อวิธีการอื่น ๆ ถูกบล็อกทั้งหมด แม้ในสภาพแวดล้อมที่พอร์ต UDP และ TCP ทั่วไปทั้งหมดถูกบล็อก นโยบายหลายอย่างก็ยังอนุญาตให้สื่อสารได้หากได้รับการปฏิบัติเช่นเดียวกับการสื่อสาร HTTPS ทำให้ TURN บนพอร์ต TLS 443 เป็นทางเลือกสุดท้ายที่ใช้งานได้จริง

นอกจากนี้ยังใช้ในสถานการณ์ที่พอร์ตบางพอร์ตถูกปิดบนเครือข่าย Wi-Fi สาธารณะ หรือเมื่อฝั่งไคลเอ็นต์สามารถทำการสื่อสาร TLS ได้เท่านั้น กล่าวโดยสรุปลองใช้ UDP ก่อน ถ้าไม่ได้ผลก็ลองใช้ TCP และถ้ายังไม่ได้ผลอีก ให้ลองใช้ TLS บนพอร์ต 443นี่ถือเป็นขั้นตอนสุดท้ายของกระบวนการถอยกลับอย่างค่อยเป็นค่อยไป

ประโยชน์ของ TURNS

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

ข้อเสียของการเลี้ยว

ข้อเสียที่สำคัญที่สุดคือประสิทธิภาพที่ลดลง นอกเหนือจากความล่าช้าและภาระของ TURN เองแล้ว ยังมีค่าใช้จ่ายเพิ่มเติมของ TLS และ TCP อีกด้วย TCP มีกลไกการส่งซ้ำที่ทำงานเมื่อแพ็กเก็ตสูญหายเพื่อการส่งข้อมูลที่เชื่อถือได้ แต่ไม่เหมาะสำหรับสื่อแบบเรียลไทม์ และหากเกิดการสูญหาย วิดีโอและเสียงอาจเล่นไม่ราบรื่น

นอกจากนี้ TCP ยังมีแนวโน้มที่จะเกิดปัญหาการบล็อกที่ส่วนหัวของแถวเนื่องจากการควบคุมลำดับของแพ็กเก็ตเมื่อเทียบกับ UDP แล้ว ค่าความคลาดเคลื่อน (ความผันผวน) ก็เพิ่มขึ้นด้วยนอกจากนี้ ยังมีการเพิ่มภาระการทำงานของ CPU จากกระบวนการเข้ารหัสและถอดรหัส TLS ส่งผลให้มีรายงานว่าเกิดความล่าช้าเพิ่มขึ้น 50 มิลลิวินาทีหรือมากกว่านั้นในการวัดผลจริง ซึ่งทำให้ผู้ใช้สังเกตเห็นความหน่วงได้ชัดเจน โดยเฉพาะอย่างยิ่งในการประชุมทางวิดีโอ ความล่าช้าที่เพิ่มขึ้นนี้อาจรบกวนจังหวะการสนทนาและทำให้ความคลาดเคลื่อนของเวลาชัดเจนยิ่งขึ้น

ดังนั้น แม้ว่า TURNS อาจถูกมองว่าเป็น "ทางเลือกสุดท้าย" ในแง่ของคุณภาพ แต่ก็เป็นแนวทางที่เชื่อถือได้ในสถานการณ์ที่ไม่มีทางเลือกอื่นนอกจากต้องทำให้มั่นใจว่ามีการสื่อสารเกิดขึ้น

ในช่วงไม่กี่ปีที่ผ่านมา มีการพิจารณาวิธีการใหม่ (TURN over QUIC) ซึ่งทำงานบนพอร์ต UDP 443 และใช้ DTLS/QUIC แทน TLS แต่ยังอยู่ในขั้นตอนการกำหนดมาตรฐานและยังไม่เป็นที่แพร่หลาย

ขั้นตอนการสื่อสารเมื่อ UDP STUN ไม่พร้อมใช้งาน

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

1. ไคลเอนต์ส่งคำขอค้นหา IP ภายนอก (UDP/3478) ไปยังเซิร์ฟเวอร์ STUN:
   ไคลเอนต์ WebRTC (เบราว์เซอร์)ไอซ์เซิร์ฟเวอร์มีการส่งคำขอผูกข้อมูล (คำขอตรวจสอบที่อยู่ภายนอก) ผ่านพอร์ต UDP 3478 ไปยังเซิร์ฟเวอร์ STUN ที่ระบุ นี่เป็นขั้นตอนแรกของการรวบรวมผู้สมัคร ICE และหากสำเร็จ เซิร์ฟเวอร์จะส่งคืนที่อยู่ IP ทั่วโลกและหมายเลขพอร์ตของตนเอง และจะถูกเพิ่มลงในรายการผู้สมัครในฐานะผู้สมัครแบบสะท้อนกลับของเซิร์ฟเวอร์ (ผู้สมัคร srflx)
2. แพ็กเก็ต UDP ถูกบล็อกโดยไฟร์วอลล์ และไม่ได้รับคำตอบใดๆ
   ในกรณีนี้ การสื่อสาร UDP ไม่สามารถส่งออกไปยังภายนอกได้เนื่องจากการตั้งค่าไฟร์วอลล์ของเครือข่าย ดังนั้น คำขอไปยังเซิร์ฟเวอร์ STUN จึงไม่ถึงเซิร์ฟเวอร์ หรือการตอบกลับไม่ถูกส่งกลับไปยังไคลเอ็นต์ ส่งผลให้ไคลเอ็นต์ประสบปัญหาไม่สามารถรับการตอบสนอง STUN ได้ดังนั้น จึงไม่สามารถระบุที่อยู่ IP ภายนอกได้ ตัวแทน ICE รอการตอบสนองเป็นระยะเวลาหนึ่ง แต่แล้วก็หมดเวลาไป จากมุมมองของผู้ใช้ กระบวนการเชื่อมต่อยังคงดำเนินอยู่ ณ จุดนี้ และไม่มีข้อความแสดงข้อผิดพลาดใดๆ แต่ในความเป็นจริง...การรวบรวมข้อมูลผู้สมัครล้มเหลวกำลังดำเนินการอยู่
3. การตรวจสอบการเชื่อมต่อโดยตรงของ ICE ล้มเหลวเนื่องจากไม่พบผู้สมัคร Server Reflexive:
   โดยปกติแล้ว หาก STUN ทำงานสำเร็จ ไคลเอนต์จะมีโฮสต์ผู้สมัคร (ที่อยู่ IP ภายในเครื่อง) และเซิร์ฟเวอร์ผู้สมัครแบบสะท้อนกลับ (ที่อยู่ IP ทั่วโลก) และจะทำการตรวจสอบการเชื่อมต่อโดยการรวมกับผู้สมัครที่คล้ายกันบนฝั่งปลายทาง อย่างไรก็ตาม หาก STUN ล้มเหลวและไม่มีผู้สมัครที่อยู่ IP ทั่วโลกจำนวนผู้สมัครสำหรับการเชื่อมต่อแบบ peer-to-peer โดยตรงนั้นมีจำกัดอย่างมากเหตุการณ์นี้เกิดขึ้นได้ ตัวอย่างเช่น หากทั้งสองฝ่ายมีเพียงที่อยู่ IP ส่วนตัว พวกเขาจะไม่สามารถเชื่อมต่อกันได้ ส่งผลให้ ICE จะพิจารณาว่า "ไม่สามารถเชื่อมต่อโดยตรงได้" หากเซิร์ฟเวอร์ ICE (TURN) ไม่ได้รับการกำหนดค่า ICE ทั้งหมดจะถือว่าล้มเหลวในขั้นตอนนี้ และการเชื่อมต่อ WebRTC จะไม่ถูกสร้างขึ้น (คอนโซลสำหรับนักพัฒนาจะแสดง...)ICE ล้มเหลวやสถานะการเชื่อมต่อ ICE: ล้มเหลวข้อผิดพลาดต่างๆ จะปรากฏขึ้น เช่น ข้อความต่อไปนี้
4. กำลังพยายามขอรับรีเลย์ TURN (ผ่าน TCP/TLS/443):
   แม้ว่า STUN จะไม่สามารถสรรหาผู้สมัครได้โดยตรงก็ตามไอซ์เซิร์ฟเวอร์หากมีการระบุเซิร์ฟเวอร์ TURN เอเจนต์ ICE จะดำเนินการดังต่อไปนี้ถัดไปหมายถึงมาต่อกันเลย ในสถานการณ์นี้ UDP ใช้งานไม่ได้ ดังนั้นไคลเอนต์จะพยายามเชื่อมต่อกับเซิร์ฟเวอร์ TURN โดยใช้ TCP หรือ TLS (เป็นต้น)turns:turn.example.com:443หากตั้งค่าไว้ การจับมือ TLS จะเริ่มต้นขึ้น โชคดีที่ไฟร์วอลล์อนุญาตการสื่อสาร HTTPS บน TCP 443 ดังนั้นการเชื่อมต่อ TLS TURN จึงสำเร็จ ไคลเอนต์จะขอที่อยู่รีเลย์บนเซิร์ฟเวอร์ TURN สำหรับการส่งต่อผู้สมัครวิ่งผลัดได้รับผู้สมัครรีเลย์แล้ว นี่คือ "ปลายทางเสมือนสำหรับการสื่อสารผ่านเซิร์ฟเวอร์ TURN" ในทางกลับกัน คู่สนทนา (ฝั่งระยะไกล) ก็จะได้รับผู้สมัครรีเลย์เช่นกัน หรือหากเครือข่ายทำงานได้ดี ก็จะมีผู้สมัครโดยตรงหรือผู้สมัคร STUN อยู่แล้ว ในทุกกรณี หากอย่างน้อยหนึ่งฝ่ายมีผู้สมัครรีเลย์ อีกฝ่ายก็สามารถพยายามเชื่อมต่อกับเซิร์ฟเวอร์ TURN นั้นได้
5. การสร้างการเชื่อมต่อ ICE (หรือความล้มเหลวขั้นสุดท้าย) ผ่านรีเลย์:
   เมื่อทั้งสองฝ่ายได้รับผู้สมัครรีเลย์ที่พร้อมใช้งาน (ในตัวอย่างนี้คือผู้สมัครรีเลย์สำหรับฝ่ายใดฝ่ายหนึ่งหรือทั้งสองฝ่าย) ICE จะใช้ผู้สมัครเหล่านั้นในการตรวจสอบการเชื่อมต่อ เนื่องจากสามารถส่งต่อการสื่อสารผ่านเซิร์ฟเวอร์ TURN ได้เมื่อมีการตกลงกับเซิร์ฟเวอร์แล้ว ช่องทางการสื่อสารจึงเปิดขึ้นแม้ว่าการรับส่งข้อมูล UDP โดยตรงจะไม่สามารถผ่านระหว่างทั้งสองฝ่ายได้ก็ตาม ซึ่งช่วยให้ผู้ใช้สามารถเริ่มต้นการสื่อสารด้วยวิดีโอและเสียงได้ หลังจากสร้างการเชื่อมต่อแล้ว แม้ว่าจะมีค่าใช้จ่ายเพิ่มเติมเนื่องจาก TCP ผ่าน TLS แต่การสนทนาก็เป็นไปได้ ในทางกลับกัน หากสิ่งนี้ล้มเหลวอีก (ตัวอย่างเช่น หากพร็อกซีขององค์กรตรวจพบและบล็อกการสื่อสาร TLS ที่ไม่ใช่ HTTP หรือหากการตรวจสอบสิทธิ์กับเซิร์ฟเวอร์ TURN ล้มเหลว) ICE ก็จะล้มเหลวโดยรวมและการเชื่อมต่อจะถูกยกเลิก แอปพลิเคชันต้องตรวจจับสถานการณ์นี้และแจ้งให้ผู้ใช้ทราบด้วยข้อความเช่น "ไม่สามารถสร้างการเชื่อมต่อได้"

คำอธิบายข้างต้นกล่าวถึงกระบวนการเจรจา ICE ในสภาพแวดล้อมที่ท้าทายซึ่งไม่มี UDP ให้ใช้งาน โดยสรุป ระบบจะลองใช้ตัวเลือกตามลำดับ "host → STUN → TURN" และหากไม่มีตัวเลือกใดใช้งานได้ การเชื่อมต่อจะล้มเหลว นักพัฒนาจำเป็นต้องเข้าใจพฤติกรรมนี้ และอย่างน้อยที่สุดควรเพิ่มเซิร์ฟเวอร์ TURN/TURNS ลงในรายการเซิร์ฟเวอร์ ICE เพื่อให้แน่ใจว่าสามารถสร้างการสื่อสารได้แม้ในสถานการณ์ที่เลวร้ายที่สุด นอกจากนี้ เมื่อได้รับคำถามจากผู้ใช้ จำเป็นต้องมีการแก้ไขปัญหา เช่น การอนุมานปัญหาของสภาพแวดล้อมเครือข่าย (เช่น การบล็อก UDP) จากข้อมูลเช่น "ICE ล้มเหลว" และตรวจสอบการตั้งค่าเซิร์ฟเวอร์ TURN ที่ขาดหายไป

การสร้างและกำหนดค่าเซิร์ฟเวอร์ STUN/TURN/TURNS โดยใช้ coturn

หากคุณกำลังตั้งค่าเซิร์ฟเวอร์ STUN/TURN ด้วยตนเอง โปรดใช้เวอร์ชันโอเพนซอร์ส โคเทิร์นโดยทั่วไปแล้วจะใช้ Coturn Coturn เป็นการใช้งานเซิร์ฟเวอร์ที่รองรับทั้ง STUN และ TURN และยังสามารถรองรับ TURNS (TLS) ได้ขึ้นอยู่กับการตั้งค่า ในที่นี้ เราจะอธิบายขั้นตอนและจุดการตั้งค่าสำหรับการติดตั้ง Coturn บนเซิร์ฟเวอร์ Linux และการสร้างเซิร์ฟเวอร์ที่ให้บริการ STUN/TURN/TURNS รวมถึงไฟล์การตั้งค่าทั่วไป (turnserver.confฉันจะยกตัวอย่างประกอบให้ดูด้วย

การติดตั้งและการตั้งค่าพื้นฐาน

ติดตั้ง

ในกรณีของ Ubuntu หรือ Debianเหมาะสมคุณสามารถติดตั้งแพ็กเกจ coturn ได้จากที่นี่ ตัวอย่างเช่น คุณสามารถติดตั้งและกำหนดค่าให้เริ่มต้นทำงานโดยอัตโนมัติด้วยคำสั่งต่อไปนี้

# Ubuntu/Debianの場合
sudo apt-get install coturn
sudo sed -i 's/#TURNSERVER_ENABLED=1/TURNSERVER_ENABLED=1/' /etc/default/coturn
sudo systemctl enable --now coturn

คำสั่งข้างต้นจะเริ่มต้นเซิร์ฟเวอร์ coturn ในโหมด daemon โดยค่าเริ่มต้น ไฟล์การกำหนดค่า /etc/turnserver.conf ตอนนี้เราจะโหลดไฟล์ แล้วดำเนินการแก้ไข (อย่าลืมสำรองข้อมูลก่อนแก้ไข)

การตั้งค่าพื้นฐาน

turnserver.confต่อไปนี้ เรามาตั้งค่ารายการต่อไปนี้กัน

• โดเมนและชื่อเซิร์ฟเวอร์: นี่คือชื่อโดเมนหรือตัวระบุของเซิร์ฟเวอร์ TURN อาจใช้ในระหว่างการตรวจสอบสิทธิ์ไคลเอ็นต์ WebRTC แต่โดยทั่วไปแล้ว สตริงใดๆ ก็สามารถใช้ได้ ตัวอย่าง: โดเมน = ตัวอย่าง.com，ชื่อเซิร์ฟเวอร์ = ตัวอย่าง.com。
• พอร์ตรับฟัง: นี่คือหมายเลขพอร์ต UDP ที่ TURN และ STUN ใช้ในการรับฟัง โดยค่าเริ่มต้นคือพอร์ต 3478การฟัง IPคุณยังสามารถผูกกับ NIC เฉพาะได้ แต่โดยปกติแล้ว0.0.0.0เรายินดีรับทุกคำถาม
• พอร์ตการฟัง TLS: นี่คือหมายเลขพอร์ต TCP ที่ใช้ในการรับฟังการเชื่อมต่อ TLS (TURNS) โดยทั่วไปจะระบุพอร์ต 443 หรือ 5349 ตัวอย่าง: พอร์ตการฟัง tls=443。
• ออโต้ไอพี: หากเซิร์ฟเวอร์อยู่หลัง NAT ให้ระบุที่อยู่ IP ทั่วโลกของเซิร์ฟเวอร์เอง (เพื่อให้เซิร์ฟเวอร์สามารถรับรู้การจับคู่ระหว่างที่อยู่ IP ภายในและภายนอกได้) ขั้นตอนนี้ไม่จำเป็นสำหรับเซิร์ฟเวอร์ที่มีที่อยู่ IP ทั่วโลกโดยตรงอยู่แล้ว
• วิธีการยืนยันตัวตน: โปรโตคอล TURN ของ WebRTC ใช้การตรวจสอบสิทธิ์ระยะยาว (Long-Term Credentials)lt-cred-mechเปิดใช้งานกลไกการรับรองระยะยาวผู้ใช้ = ชื่อผู้ใช้:รหัสผ่านตั้งชื่อผู้ใช้และรหัสผ่านของคุณในรูปแบบต่อไปนี้ใช้รหัสลับการตรวจสอบสิทธิ์การตรวจสอบสิทธิ์แบบไดนามิกดำเนินการโดยใช้ (ซึ่งอย่างหลังเป็นการตรวจสอบสิทธิ์แบบใช้โทเค็น ซึ่งมีประสิทธิภาพในการปรับปรุงความปลอดภัย แต่ในที่นี้เราจะใช้การตรวจสอบสิทธิ์ผู้ใช้แบบคงที่อย่างง่ายเป็นตัวอย่าง)
• การตั้งค่าการบันทึก: สำหรับการแก้ไขปัญหาไฟล์บันทึกจากนั้นจึงระบุเส้นทางของไฟล์บันทึกจอร์จคุณควรเปิดใช้งานการบันทึกข้อมูลโดยละเอียด

การตั้งค่าไฟร์วอลล์

ฝั่งเซิร์ฟเวอร์ สำหรับ STUN/TURNพอร์ต UDP 3478และสำหรับ TURN/TLSพอร์ต TCP 443คุณจะต้องเปิดพอร์ต (หรือ 5349) นอกจากนี้ เนื่องจาก TURN relay ใช้พอร์ต UDP 10000-20000 เป็นค่าเริ่มต้น คุณจึงต้องเปิดช่วงพอร์ตนี้บนเซิร์ฟเวอร์ด้วย (หากจำเป็น)มินิพอร์ตとแม็กซ์พอร์ต(สามารถเปลี่ยนแปลงช่วงได้)

ต่อไปนี้คือการตั้งค่าพื้นฐานที่กล่าวไว้ข้างต้น/etc/turnserver.confนี่คือตัวอย่างหนึ่ง

# TURNサーバの名称とレルム（ドメイン）
realm=example.com
server-name=example.com

# ネットワーク設定
listening-ip=0.0.0.0           # すべてのIPアドレスで待受
external-ip=203.0.113.10       # サーバのグローバルIP（必要な場合）

# ポート設定
listening-port=3478            # STUN/TURN用 UDPポート
tls-listening-port=443         # TLS用 TCPポート (443番)
min-port=10000                 # 中継に使用するポート範囲（下限）
max-port=20000                 # 中継に使用するポート範囲（上限）

# ログ設定
log-file=/var/log/turnserver.log
verbose                        # 詳細ログを有効化
fingerprint                    # パケットにfingerprint属性を付与

# 認証設定（長期認証方式）
lt-cred-mech                   # 長期認証を有効化
user=webrtcuser:secretpass123  # ユーザ名:パスワード を設定

# TLS/SSL証明書の指定
cert=/etc/letsencrypt/live/example.com/fullchain.pem   # サーバ証明書
pkey=/etc/letsencrypt/live/example.com/privkey.pem     # 秘密鍵

ในข้างต้น โดเมนตัวอย่าง.comฉันได้รับใบรับรอง Let's Encrypt และกำลังใช้ใบรับรองนั้นสำหรับการกำหนดค่า TLSlt-cred-mechเปิดใช้งานการตรวจสอบสิทธิ์ระยะยาวผู้ใช้นี่เป็นการตั้งค่าการตรวจสอบสิทธิ์ด้วยชื่อผู้ใช้และรหัสผ่านแบบง่ายๆ ในการใช้งานจริง...ใช้รหัสลับการตรวจสอบสิทธิ์とรหัสลับการตรวจสอบสิทธิ์แบบคงที่แม้ว่าจะแนะนำให้ใช้วิธีการแบบใช้โทเค็นในการออกข้อมูลประจำตัวชั่วคราว แต่เราจะละเว้นคำอธิบายในส่วนนี้

ข้อควรระวังเมื่อใช้ TLS

เมื่อใช้งาน Coturn บนพอร์ต 443 คุณต้องระมัดระวังเรื่องสิทธิ์การเข้าถึงพอร์ตในสภาพแวดล้อม Linux พอร์ตที่ต่ำกว่า 1024 เรียกว่าพอร์ตพิเศษ และโดยปกติจะไม่สามารถเปิดได้หากไม่มีสิทธิ์ root แพ็กเกจ coturn ของ Ubuntu จะตั้งค่าเริ่มต้นเป็นเทิร์นเซิร์ฟเวอร์เนื่องจากเป็นการดำเนินการโดยผู้ใช้ พอร์ต 443 จึงไม่สามารถผูกไว้ได้โดยตรง วิธีแก้ปัญหาคือ.../etc/default/coturnเปลี่ยนผู้ใช้ในการเรียกใช้งานเป็น rootเซตแคปสั่งการเทิร์นเซิร์ฟเวอร์ไฟล์ปฏิบัติการcap_net_bind_serviceมีหลายวิธีในการให้สิทธิ์อนุญาต ตัวอย่างเช่น ในกรณีหลังนี้sudo setcap cap_net_bind_service=+ep /usr/bin/turnserverการดำเนินการนี้จะอนุญาตให้ผู้ใช้ที่ไม่ใช่ root ผูกกับพอร์ตหมายเลขต่ำได้ นอกจากนี้ ให้ระบุเส้นทางที่ถูกต้องสำหรับไฟล์ใบรับรอง (cert/pkey) และตั้งค่าสิทธิ์การเข้าถึงไฟล์เพื่อให้ผู้ใช้ coturn สามารถอ่านได้ หลังจากเปลี่ยนการตั้งค่าแล้ว...sudo systemctl restart coturnรีสตาร์ทบริการและตรวจสอบบันทึกข้อผิดพลาดเพื่อดูว่ามีข้อผิดพลาดใด ๆ หรือไม่

การตรวจสอบการทำงาน

เมื่อเซิร์ฟเวอร์ Coturn เริ่มทำงานแล้ว เราจะทำการทดสอบโดยใช้ไคลเอ็นต์ STUN เพื่อตรวจสอบการทำงาน จากนั้นจะลองสร้างการเชื่อมต่อ ICE จากแอปพลิเคชัน WebRTC ในเบราว์เซอร์สตันไคลเอนต์สั่งการ(apt-get install stun-client(สามารถนำไปใช้งานได้ด้วย)stunclient <server IP> 3478การเรียกใช้คำสั่งในลักษณะนี้จะช่วยให้คุณทดสอบได้ว่าคุณสามารถรับที่อยู่ IP ภายนอกของคุณได้หรือไม่ นอกจากนี้ ในเบราว์เซอร์ รายชื่อผู้สมัคร ICE จะปรากฏในบันทึกเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ด้วยsrflxผู้สมัคร (เซิร์ฟเวอร์รีเฟล็กซีฟ) และรีเลย์โปรดตรวจสอบว่าคุณได้รับผู้สมัครแล้วหรือไม่ หากยังใช้งานไม่ได้ โปรดแก้ไขปัญหาตามประเด็นต่อไปนี้

• ตรวจสอบว่าพอร์ตที่จำเป็นเปิดใช้งานอยู่ในการตั้งค่าไฟร์วอลล์ของเซิร์ฟเวอร์หรือไม่ (iptables หรือกลุ่มความปลอดภัยบนคลาวด์)
• ตรวจสอบว่า URI พอร์ต และข้อมูลการตรวจสอบสิทธิ์ที่ถูกต้องได้รับการกำหนดค่าในการตั้งค่าเซิร์ฟเวอร์ ICE ฝั่งไคลเอ็นต์หรือไม่ (จะอธิบายในภายหลัง)
• turnserver.confのอาณาจักรตรวจสอบให้แน่ใจว่าการตั้งค่าตรงกับการตรวจสอบสิทธิ์ของไคลเอ็นต์ (โดยปกติแล้วจะไม่เป็นปัญหาใน WebRTC ที่ทำงานบนเบราว์เซอร์ เนื่องจากจะกำหนดโดเมนโดยอัตโนมัติ แต่ควรระมัดระวังในการใช้งานแบบกำหนดเอง)
• บันทึกการกลับรถ (/var/log/turnserver.log) ตรวจสอบว่ามีข้อผิดพลาดในการตรวจสอบสิทธิ์หรือไม่ (ผู้ใช้ไม่ถูกต้องข้อผิดพลาดเช่นที่กล่าวมาข้างต้น แสดงว่าชื่อผู้ใช้และรหัสผ่านไม่ตรงกัน

หากการตั้งค่าข้างต้นถูกต้อง เซิร์ฟเวอร์ STUN/TURN/TURNS ของคุณจะทำงาน ทำให้สามารถรองรับการเชื่อมต่อ WebRTC ในสภาพแวดล้อมเครือข่ายต่างๆ ได้

ตัวอย่างการตั้งค่าเซิร์ฟเวอร์ ICE ในไคลเอ็นต์ WebRTC (JavaScript)

เพื่อให้สามารถใช้งานเซิร์ฟเวอร์ STUN/TURN ที่เราเพิ่งสร้างขึ้นบนฝั่งแอปพลิเคชัน WebRTC (เบราว์เซอร์) ได้อย่างแท้จริงการกำหนดค่าเซิร์ฟเวอร์ ICEเสร็จเรียบร้อยแล้ว ใน JavaScript WebRTC APIการเชื่อมต่อ RTCPeerเมื่อสร้างการกำหนดค่า คุณสามารถระบุรายการเซิร์ฟเวอร์ STUN/TURN ได้ ต่อไปนี้ เราจะแสดงตัวอย่างโค้ดที่ระบุเซิร์ฟเวอร์ STUN/TURN/TURNS ทั้งหมด และอธิบายความหมายของมัน

ขั้นแรก สร้างอ็อบเจ็กต์การกำหนดค่าสำหรับเซิร์ฟเวอร์ ICE โดยใช้ชื่อโดเมนของเซิร์ฟเวอร์ของคุณเทิร์น.ตัวอย่าง.com(แก้ไขตามความเหมาะสม) STUN ไม่ต้องการการตรวจสอบสิทธิ์ ดังนั้นจึงระบุเฉพาะ URI เท่านั้น ในขณะที่ TURN/TURNS ต้องการการตรวจสอบสิทธิ์ ดังนั้นจึงต้องระบุทั้งชื่อผู้ใช้และรหัสผ่านด้วย

const iceConfig = {
  iceServers: [
    // 1. STUNサーバ（UDP/3478）
    { urls: 'stun:turn.example.com:3478' },
    // 2. TURNサーバ（UDP/443経由）
    { urls: 'turn:turn.example.com:443?transport=udp', username: 'webrtcuser', credential: 'secretpass123' },
    // 3. TURNサーバ（TCP/443 + TLS = TURNS）
    { urls: 'turns:turn.example.com:443', username: 'webrtcuser', credential: 'secretpass123' }
  ]
};
const pc = new RTCPeerConnection(iceConfig);

ข้างต้นไอซ์เซิร์ฟเวอร์อาร์เรย์นี้มีรายการที่ระบุไว้สามรายการ

1. สตัน: สตัน:เทิร์น.example.com:3478
   ส่วนนี้ระบุที่อยู่ของเซิร์ฟเวอร์ STUN ของคุณเอง (หากไม่ได้ระบุพอร์ต จะใช้พอร์ต 3478) STUN ใช้สำหรับการตรวจจับการทะลุผ่าน NAT และการดึงข้อมูลผู้สมัคร และเบราว์เซอร์จะพยายามสอบถามเซิร์ฟเวอร์นี้ผ่าน UDP ก่อนเพื่อรับข้อมูลผู้สมัครจาก Server Reflexive
2. เทิร์น (UDP): เลี้ยว:turn.example.com:443?transport=udp
   เซิร์ฟเวอร์ TURN ของฉันเองพอร์ต UDP 443นี่คือการตั้งค่าที่จะใช้ ข้อมูลการยืนยันตัวตนคือชื่อผู้ใช้ที่คุณตั้งไว้ใน coturn ก่อนหน้านี้ผู้ใช้งานเว็บ RTและรหัสผ่านรหัสผ่านลับ123ส่วนนี้ระบุพารามิเตอร์การค้นหา?transport=udpเมื่อเพิ่มตัวเลือกนี้ ระบบจะพยายามเชื่อมต่อแบบ TURN โดยใช้ UDP (หากไม่ได้ระบุไว้ เบราว์เซอร์จะลองใช้ UDP ก่อน และหากล้มเหลวก็จะลองใช้ TCP) การตั้งค่านี้ช่วยให้มั่นใจได้ว่าแม้การเชื่อมต่อโดยตรงผ่าน STUN จะล้มเหลว ระบบก็จะพบตัวเลือกสำหรับการส่งต่อแบบ TURN บนพอร์ต UDP 443 (ตัวเลือกการส่งต่อ)
3. TURN (TLS/TCP): turns:turn.example.com:443
   TURN โดยใช้ TLSนี่คือการตั้งค่าเซิร์ฟเวอร์ TURNS ในส่วนนี้ก็มีการระบุชื่อผู้ใช้และรหัสผ่านเช่นกัน เบราว์เซอร์จะสร้างการเชื่อมต่อ TLS ไปยังรายการนี้บนพอร์ต TCP 443 และดึงข้อมูลผู้สมัครรีเลย์ TURN ผู้สมัครรีเลย์นี้เป็นตัวเลือกสุดท้าย แม้ว่าการสื่อสาร UDP จะเป็นไปไม่ได้เลย แต่การมีผู้สมัครรายนี้ก็ยังให้ความหวังในการสร้างการสื่อสารได้

การเชื่อมต่อ RTCPeerเมื่อสร้างข้อมูลเหล่านี้แล้ว ระบบจะพยายามเชื่อมต่อกับเซิร์ฟเวอร์ ICE ที่ระบุไว้ตามลำดับและรวบรวมตัวเลือกต่างๆ เอเจนต์ ICE จะดึงตัวเลือก STUN (srflx) ก่อน จากนั้นจึงดึงตัวเลือก TURN (relay) ไปพร้อมกัน อัลกอริทึม ICE จะรวมตัวเลือกเหล่านี้ ตรวจสอบการเชื่อมต่อ และเลือกเส้นทางที่ดีที่สุด นักพัฒนาไม่จำเป็นต้องทราบขั้นตอนเพิ่มเติมใดๆ

จุด: ตามที่อธิบายไว้ข้างต้นเตรียมตัวเลือกไว้หลายแบบนั่นเป็นเรื่องสำคัญ ตัวอย่างเช่นทำให้มึนงง:หากคุณระบุเฉพาะ TURN ในสภาพแวดล้อมที่บล็อก UDP จะไม่พบตัวเลือกใดๆ และการเชื่อมต่อจะล้มเหลว ในทำนองเดียวกัน การระบุเฉพาะ TURN (UDP) จะล้มเหลวในสภาพแวดล้อมที่อนุญาตเฉพาะ TCP เท่านั้น ดังนั้น หากเป็นไปได้เปลี่ยน:とเทิร์น:การรวมทั้งสองแบบไว้ในเซิร์ฟเวอร์ ICE ช่วยเพิ่มความซ้ำซ้อน ทำให้มั่นใจได้ว่าจะมีตัวเลือกที่ใช้งานได้อย่างน้อยหนึ่งตัวเลือกในทุกสภาพแวดล้อม (แน่นอนว่าเซิร์ฟเวอร์ TURN ต้องรองรับทั้ง UDP และ TCP/TLS ด้วย) ไคลเอ็นต์ (เบราว์เซอร์) จะเลือกเส้นทางที่ใช้งานได้โดยอัตโนมัติ ดังนั้นลำดับในรายการจึงไม่ใช่ปัญหาใหญ่ หากมีอะไรเกิดขึ้น...นโยบายการขนส่งน้ำแข็งをรีเลย์หากไม่ได้ระบุไว้เป็นอย่างอื่น เบราว์เซอร์จะให้ความสำคัญกับการเชื่อมต่อโดยตรง ดังนั้นการเพิ่มรายการ STUN จะช่วยป้องกันการใช้เซิร์ฟเวอร์ TURN โดยไม่จำเป็น นอกจากนี้ การเพิ่มเซิร์ฟเวอร์ที่ไม่เกี่ยวข้อง (เช่น ที่อยู่ที่ไม่ existent) ในรายการเซิร์ฟเวอร์ ICE อาจทำให้เกิดความล่าช้าเนื่องจากหมดเวลา ดังนั้นจึงควรเลือกเฉพาะเซิร์ฟเวอร์ที่ใช้งานได้แน่นอนเท่านั้น

สุดท้ายนี้ ลองเรียกใช้งานแอปพลิเคชัน WebRTC ด้วยการตั้งค่าเหล่านี้ แล้วตรวจสอบสถานะการเชื่อมต่อ โดยใช้เครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ของคุณ...peerConnection.getStats()ใช้ หรือchrome://webrtc-internals(ใน Chrome) คุณสามารถตรวจสอบ ICE Candidate และสถานะการเชื่อมต่อได้ หากทำงานได้ตามที่คาดไว้ ระบบจะเปลี่ยนไปใช้การเชื่อมต่อโดยตรง (P2P) โดยอัตโนมัติในสภาพแวดล้อมที่มี UDP และเปลี่ยนไปใช้การเชื่อมต่อ TURN/TLS ในสภาพแวดล้อมที่ไม่มี UDP

ความแตกต่างระหว่าง SFU และ TURN

การส่งต่อสัญญาณ WebRTC แบ่งออกเป็น "TURN" และ "SFU" อย่างกว้างๆ แต่บทบาท การกำหนดค่า และการใช้งานของทั้งสองแบบนั้นแตกต่างกันอย่างมาก ส่วนนี้จะสรุปความแตกต่างทางเทคนิคของทั้งสองแบบ

TURN: ระบบส่งต่อข้อมูลแบบรีเลย์ ทางเลือกใหม่แทนการสื่อสารแบบ peer-to-peer

TURN (Traversal Using Relays around NAT) คือเซิร์ฟเวอร์รีเลย์เสริมที่ใช้ในสภาพแวดล้อมที่ไม่สามารถสื่อสารแบบ WebRTC P2P ได้ โดยหลักแล้ว เมื่อ STUN ไม่ทำงานเนื่องจาก NAT หรือไฟร์วอลล์ เซิร์ฟเวอร์ TURN จะดักจับแพ็กเก็ตระหว่างพีร์และส่งต่อ เนื่องจากแต่ละพีร์ส่งสตรีมของตนไปยังคู่สนทนาของตนแยกกัน การกำหนดค่าจึงยังคงเป็นแบบเมช และ TURN ทำหน้าที่เป็น "ตัวแทน"

• องค์ประกอบผู้ใช้แต่ละรายส่งข้อมูลผ่านรีเลย์ไปยังผู้ใช้รายอื่น (โดยพื้นฐานแล้วคือเครือข่ายแบบตาข่าย)
• ความสามารถในการปรับขนาด: ต่ำ (ภาระจะเพิ่มขึ้นตามจำนวนคน)
• เนื้อหาของการออกอากาศ: มีเพียงการส่งต่อแพ็กเก็ตแบบง่ายๆ เท่านั้น ไม่มีการวิเคราะห์หรือปรับแต่งสื่อใดๆ

SFU: ระบบถ่ายทอดสัญญาณที่มีประสิทธิภาพสำหรับการโทรแบบหลายคน

หน่วยส่งต่อแบบเลือก (Selective Forwarding Unit หรือ SFU) คือเซิร์ฟเวอร์รีเลย์อัจฉริยะที่ใช้ในการประชุมทางเว็บแบบหลายคนลูกค้าแต่ละรายจะส่งสตรีมหนึ่งรายการไปยัง SFU ซึ่ง SFU จะส่งต่อสตรีมนั้นไปยังผู้เข้าร่วมรายอื่น ๆ ตามตัวเลือกที่กำหนดนอกจากนี้ยังสามารถดำเนินการต่างๆ เช่น การตรวจจับผู้พูด การปรับคุณภาพของภาพ และการเพิ่มประสิทธิภาพความหน่วง ทำให้การออกอากาศมีประสิทธิภาพสูงและสามารถปรับขนาดได้

• องค์ประกอบ: การกำหนดค่าแบบดาวที่แต่ละไคลเอ็นต์เชื่อมต่อกับ SFU ด้วยการเชื่อมต่อเพียงครั้งเดียว
• ความสามารถในการปรับขนาด: สูง (ส่งข้อความเพียงข้อความเดียว แม้ว่าจำนวนคนจะเพิ่มขึ้นก็ตาม)
• เนื้อหาของการออกอากาศวิธีนี้ช่วยให้สามารถควบคุมปลายทางการถ่ายโอนและเพิ่มประสิทธิภาพของสื่อได้

ตารางเปรียบเทียบ TURN และ SFU

TURN เป็นเพียง "ทางเลือกสุดท้ายที่จะใช้เมื่อการสื่อสารแบบ P2P เป็นไปไม่ได้" และในแง่ของการกำหนดค่า มันเป็นรีเลย์ที่เสริมเครือข่าย P2P แบบตาข่าย ในทางกลับกันSFU เป็นสถาปัตยกรรมรีเลย์ที่ได้รับการออกแบบตั้งแต่เริ่มต้นให้มีประสิทธิภาพสำหรับการโทรที่มีผู้เข้าร่วมหลายคนเนื่องจากบทบาทของพวกเขามีความแตกต่างกันโดยพื้นฐาน จึงเป็นสิ่งสำคัญที่จะต้องออกแบบโดยไม่ทำให้เกิดความสับสน

สรุป

บทความนี้ให้คำอธิบายโดยละเอียดเกี่ยวกับความแตกต่างทางเทคนิคและการใช้งานของ STUN, TURN และ TURNS สำหรับผู้ใช้ WebRTC ระดับกลางถึงขั้นสูง รวมถึงวิธีการสร้างเซิร์ฟเวอร์โดยใช้ coturn พร้อมตัวอย่างโค้ด และวิธีการทำงานของ ICE ในสภาพแวดล้อมเครือข่ายที่ท้าทาย

สตันมีน้ำหนักเบาแต่ช่วยให้สามารถสื่อสารโดยตรงในสภาพแวดล้อม NAT ได้เปลี่ยนมันกลายเป็นช่องทางสำคัญในการสร้างการสื่อสารแม้ในสถานการณ์ที่ยากลำบากเลี้ยวด้วยการผสานองค์ประกอบเหล่านี้เข้าด้วยกัน ทำให้สามารถใช้งาน WebRTC ได้แม้ในสภาพแวดล้อมเฉพาะทาง เช่น ภายในบริษัท

แต่ละวิธีมีข้อดีและข้อเสียแตกต่างกัน ดังนั้นในอุดมคติแล้ว คุณควรเชื่อมต่อโดยตรงโดยใช้ STUN เมื่อใดก็ตามที่เป็นไปได้ และใช้รีเลย์ TURN เฉพาะเมื่อจำเป็นอย่างยิ่งเท่านั้น ในการพัฒนาแอปพลิเคชัน WebRTC จริงๆ แล้ว การจัดเตรียมเส้นทางหลายเส้นทางตามที่อธิบายไว้ในการตั้งค่าเซิร์ฟเวอร์ ICE และการกำหนดค่าและการใช้งาน coturn อย่างถูกต้องบนฝั่งเซิร์ฟเวอร์ จะช่วยให้คุณสามารถสื่อสารแบบเรียลไทม์ได้อย่างเสถียรในสภาพแวดล้อมเครือข่ายต่างๆ

WebRTC เป็นเทคโนโลยีที่ซับซ้อนซึ่งผสมผสาน API ของเบราว์เซอร์และเทคโนโลยีเครือข่าย แต่การทำความเข้าใจกลไกของ STUN/TURN และ ICE นั้นจำเป็นอย่างยิ่งสำหรับการสร้างแอปพลิเคชันที่เชื่อถือได้

ผมขอแนะนำให้คุณนำข้อมูลในบทความนี้ไปใช้เพื่อแก้ไขปัญหาการทะลุผ่าน NAT ในผลิตภัณฑ์ของคุณเอง การทำเช่นนั้นจะช่วยให้ผู้ใช้สามารถสื่อสารได้อย่างราบรื่นโดยไม่รู้ตัวเลย ด้วยกระบวนการประมวลผลการเชื่อมต่อที่ออกแบบมาอย่างชาญฉลาดซึ่งเกิดขึ้นเบื้องหลัง