คำอธิบายโดยละเอียดและการฝึกฝนการใช้ STUN/TURN/TURNS/SFU ใน WebRTC

วันที่ 12 เมษายน 2568

สารบัญ

WebRTC คืออะไร?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ประโยชน์ของการเทิร์น

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

ข้อเสียของ TURN

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

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

โดยรวมแล้ว ควรใช้ 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:turnsserver:443"ในโครงการ URIผลัดกัน:คุณสามารถใช้เซิร์ฟเวอร์ TURN ที่เข้ารหัส TLS นี้ได้โดยระบุ

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

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

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

ประโยชน์ของการเลี้ยว

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

ข้อเสียของ TURNS

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

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

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

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

การสื่อสารแบบไหลเมื่อ UDP STUN ไม่พร้อมใช้งาน

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

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

นี่คือขั้นตอนการเจรจาต่อรอง ICE ในสภาพแวดล้อมที่เลวร้ายซึ่งไม่สามารถใช้ UDP ได้ สรุปคือ ผู้สมัครจะถูกทดสอบในลำดับ "โฮสต์ → 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 เป็นเดมอน โดยค่าเริ่มต้นจะใช้ไฟล์กำหนดค่า /etc/turnserver.conf นี่จะโหลดไฟล์ และคุณสามารถแก้ไขได้ (สำรองข้อมูลก่อนแก้ไขเพื่อความปลอดภัย)

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

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

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

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

ฝั่งเซิร์ฟเวอร์สำหรับ STUN/TURNพอร์ต UDP 3478และสำหรับ TURN/TLSพอร์ต TCP 443(หรือ 5349) ต้องเปิดอยู่ นอกจากนี้ รีเลย์ TURN จะใช้ช่วง 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     # 秘密鍵

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

ข้อควรระวังในการใช้ TLS

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

การตรวจสอบการดำเนินงาน

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

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

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

ตัวอย่างการกำหนดค่าเซิร์ฟเวอร์ ICE สำหรับไคลเอนต์ WebRTC (JavaScript)

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

ขั้นแรก ให้สร้างวัตถุการกำหนดค่าสำหรับเซิร์ฟเวอร์ ICEturn.example.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);

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

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

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

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

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

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

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

TURN: Relay เป็นทางเลือกแทน peer-to-peer

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

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

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

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

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

ตารางเปรียบเทียบ TURN กับ SFU

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

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

สรุป

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

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

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

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

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

URL をkoピーしました！