อธิบาย NAT traversal: รีโมทเดสก์ท็อปแบบ P2P ทะลุเราเตอร์ของคุณได้อย่างไร

คุณมี IP สาธารณะเดียวและอุปกรณ์อีกเป็นโหลหลังเราเตอร์ iPad ของคุณอยู่บนเครือข่ายเซลลูลาร์ ห่างออกไปสามเครือข่าย แต่แอปรีโมทเดสก์ท็อปก็เปิดการเชื่อมต่อตรงจากอีกฝั่งหนึ่งไปยังอีกฝั่งได้ภายในไม่ถึงวินาที — มักไม่มีรีเลย์คั่นกลาง นี่คือวิธีที่เวทมนตร์นั้นทำงานจริง: ICE, STUN, TURN, hole punching และความจริงอันน่าอึดอัดเรื่อง symmetric NAT

ทำไมเรื่องนี้สำคัญ

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

แต่คุณเปิด Remio บน iPad แตะที่ Mac แล้วหนึ่งวินาทีต่อมาคุณก็เห็นเดสก์ท็อป วิดีโอและอินพุตไหลตรงระหว่างสองอุปกรณ์ — ไม่มีรีเลย์บนคลาวด์ ไม่มีพร็อกซีคั่นกลางมาเข้ารหัสหน้าจอใหม่

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

ปัญหา NAT ใน 60 วินาที

อินเทอร์เน็ตถูกออกแบบให้ทุกอุปกรณ์มีที่อยู่สาธารณะที่กำหนดเส้นทางได้ของตัวเอง IPv4 ทั้งปริภูมิมีราว 4.3 พันล้านที่อยู่ — เหลือเฟือในปี 1981 แต่ชัดเจนว่าไม่พอในปลายทศวรรษ 1990

วิธีเลี่ยงคือการแปลที่อยู่เครือข่าย (NAT) เราเตอร์ของคุณได้ IPv4 สาธารณะหนึ่งที่อยู่จาก ISP ภายในบ้าน ทุกอุปกรณ์ได้ที่อยู่ส่วนตัวจากช่วงที่สงวนไว้ (โดยทั่วไปคือ 192.168.x.x หรือ 10.x.x.x) เมื่อแล็ปท็อปส่งแพ็กเก็ตออก เราเตอร์เขียนที่อยู่ต้นทางใหม่เป็น IP สาธารณะของตัวเอง จำการแมป แล้วส่งต่อ เมื่อคำตอบกลับมา เราเตอร์ค้นหาการแมปแล้วเขียนปลายทางกลับเป็นแล็ปท็อปของคุณ

นี่คือเหตุผลที่การเชื่อมต่อขาเข้าใช้ไม่ได้โดยปริยาย จากภายนอก แล็ปท็อปของคุณไม่มีที่อยู่ มีแต่เราเตอร์ แพ็กเก็ตของคนแปลกหน้าที่ส่งไป your-router-public-ip:5060 ไปถึงเราเตอร์ที่ไม่มีการแมปรองรับและถูกทิ้ง

สำหรับแอป P2P นี่คือทั้งเกม เพียร์ทั้งสองอยู่หลังเราเตอร์ที่ส่งต่อแพ็กเก็ตเฉพาะเมื่อจำได้ว่าเคยส่งอะไรออกไปก่อน ไม่มีฝั่งไหนแค่ "โทรหา" อีกฝั่งได้ — ต้องร่วมมือกับเราเตอร์เพื่อเปิดเส้นทางชั่วคราว

Hole punching: ทำให้ไฟร์วอลล์ให้คุณกลับเข้ามา

ลูกเล่นคือแบบนี้ ตาราง NAT ของเราเตอร์ใช้ five-tuple เป็นคีย์: IP ต้นทาง พอร์ตต้นทาง IP ปลายทาง พอร์ตปลายทาง และโปรโตคอล เมื่ออุปกรณ์ส่งแพ็กเก็ต UDP ขาออกไปที่ 1.2.3.4:5678 เราเตอร์สร้างรายการชั่วคราวว่า "ถ้ามีแพ็กเก็ต UDP ใดกลับมาจาก 1.2.3.4:5678 ถึง IP สาธารณะของฉันที่พอร์ต X ให้ส่งต่อไปยังอุปกรณ์นี้ที่พอร์ต Y"

รายการนั้นมีอยู่ช่วงเวลาหนึ่ง — โดยทั่วไป 30 ถึง 60 วินาที — แล้วหมดอายุถ้าไม่มีอะไรมารีเฟรช ในช่วงนั้น แพ็กเก็ตใดจากที่อยู่ปลายทางจะถูกยอมรับ

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

นี่เรียกว่า UDP hole punching มันน่าอัศจรรย์เล็กน้อย มีเอกสารอ้างอิงชัดเจน (RFC 5128) และใช้ได้กับ NAT ของผู้บริโภคส่วนใหญ่ในโลกจริง กรณีที่เหลือ — symmetric NAT, CGNAT, ไฟร์วอลล์องค์กร — คือเหตุผลที่ TURN มีอยู่

Hole punching ไม่ใช่การแฮ็ก แต่เป็นสัญญาที่ชัดเจนที่ NAT ถูกออกแบบมา: แพ็กเก็ตขาออกสร้างสิทธิ์ขาเข้า แอป P2P แค่ส่งแพ็กเก็ตขาออกโดยตั้งใจ

STUN: "ที่อยู่สาธารณะของฉันคืออะไร?"

Hole punching ต้องการเงื่อนไขเบื้องต้นหนึ่งข้อ: เพียร์แต่ละฝั่งต้องรู้ที่อยู่ฝั่งสาธารณะของตัวเองเพื่อบอกอีกฝ่ายว่าจะส่งแพ็กเก็ตไปที่ไหน ที่อยู่นั้นมองไม่เห็นจากภายในอุปกรณ์ iPad ของคุณเห็นที่อยู่ Wi-Fi ภายใน (192.168.1.42) สิ่งที่อินเทอร์เน็ตส่วนที่เหลือเห็นหลังเราเตอร์เขียนแพ็กเก็ตใหม่เป็นอีกอย่างหนึ่งโดยสิ้นเชิง

STUN — Session Traversal Utilities for NAT, RFC 5389 — คือโปรโตคอลเล็ก ๆ ที่แก้เรื่องนี้ ขั้นตอนง่ายจนน่าอาย:

1. เพียร์ส่งแพ็กเก็ต UDP ไปยังเซิร์ฟเวอร์ STUN สาธารณะ (Remio ใช้ทั้งเซิร์ฟเวอร์ STUN สาธารณะของ Cloudflare และ Google เพื่อสำรองกัน)
2. เซิร์ฟเวอร์ STUN อ่าน IP และพอร์ตต้นทางจากสาย — ซึ่งตามนิยามคือที่อยู่สาธารณะของเพียร์ที่ผ่านการแปลของ NAT แล้ว
3. เซิร์ฟเวอร์ STUN ตอบกลับด้วยที่อยู่นั้นเป็นเนื้อหา: "เท่าที่ฉันเห็น คุณคือ 203.0.113.42:48291"
4. เพียร์รู้แล้วว่าจะประกาศที่อยู่ใดให้อีกฝ่าย

ที่อยู่ฝั่งสาธารณะนี้เรียกว่า server-reflexive candidate ในศัพท์ของ ICE มันแทบไม่มีต้นทุน — หนึ่งรอบไป-กลับระหว่างตั้งการเชื่อมต่อ และไม่มีภาระแบนด์วิดท์หรือความหน่วงหลังเชื่อมต่อแล้ว งานเดียวของ STUN คือแนะนำเพียร์สองฝ่ายให้รู้จักกัน เมื่อคุยกันแล้ว เซิร์ฟเวอร์ STUN ก็หมดบทบาท

TURN: เมื่อ hole punching ล้มเหลว

Hole punching ใช้ได้กับ NAT ส่วนใหญ่ แต่ไม่ใช่ทั้งหมด กรณีล้มเหลวมีอยู่จริง และแอป P2P ที่ทำเป็นไม่มีกรณีเหล่านี้ก็จะเชื่อมต่อไม่ได้สำหรับผู้ใช้ส่วนไม่น้อย

ตัวร้ายหลัก:

• Symmetric NAT NAT ที่กำหนดพอร์ตสาธารณะต่างกันสำหรับทุกปลายทางที่ต่างกัน STUN บอกเพียร์ของคุณว่าคุณอยู่ที่พอร์ต 48291 (เพราะเป็นพอร์ตที่เซิร์ฟเวอร์ STUN เห็น) แต่เมื่อคุณส่งแพ็กเก็ตไปยังที่อยู่ของเพียร์ เราเตอร์เลือกพอร์ตอื่น — สมมติ 48317 เราเตอร์ของเพียร์ปฏิเสธแพ็กเก็ตเพราะมาจากพอร์ตที่ไม่คาดคิด Hole punching พัง
• Carrier-grade NAT (CGNAT) เครือข่ายเซลลูลาร์และ ISP จำนวนมากซ้อน NAT ชั้นที่สองในระดับผู้ให้บริการ คุณอาจอยู่หลัง NAT สองตัวโดยไม่รู้ตัว และทั้งสองต้องร่วมมือกัน CGNAT มักเป็น symmetric และคุณไม่มีสิทธิ์ผู้ดูแลระบบของมัน
• ไฟร์วอลล์องค์กรที่เข้มงวด เครือข่ายองค์กรบางแห่งบล็อก UDP ขาออกทั้งหมด หรืออนุญาตเฉพาะบางปลายทาง Hole punching ต้องการเส้นทาง UDP ถ้าไม่มีก็ไม่มีโอกาส

สำหรับกรณีเหล่านี้ ทางสำรองคือ TURN — Traversal Using Relays around NAT, RFC 5766 เซิร์ฟเวอร์ TURN คือรีเลย์ที่เพียร์ทั้งสองเข้าถึงได้ เพราะมีที่อยู่สาธารณะที่รับทราฟฟิกขาเข้าเสมอ เพียร์แต่ละฝั่งสร้างการเชื่อมต่อ TLS ขาออกปกติไปยังเซิร์ฟเวอร์ TURN (ซึ่ง NAT ใดก็อนุญาต) แล้วเซิร์ฟเวอร์ส่งต่อไบต์ระหว่างสองฝ่าย

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

นี่คือเหตุผลที่แอปที่ออกแบบดีใช้ TURN เฉพาะเมื่อ hole punching ล้มเหลวอย่างพิสูจน์ได้ ICE จัดการการตัดสินใจนั้นให้อัตโนมัติ

ICE: ลองทุก candidate พร้อมกัน

Interactive Connectivity Establishment, RFC 8445 คือท่าเต้นที่ผูกทั้งหมดนี้เข้าด้วยกัน ICE ไม่เลือกกลยุทธ์ล่วงหน้า มันรวบรวมที่อยู่ candidate ที่เป็นไปได้ของเพียร์แต่ละฝั่งทุกตัว แลกเปลี่ยนรายการเต็มกับอีกฝ่าย แล้วให้ทั้งสองสแต็กตรวจสอบทุกคู่ candidate พร้อมกัน — แข่งกันหาคู่แรกที่ใช้ได้

สำหรับเพียร์แต่ละฝั่ง ICE มักรวบรวม:

• Host candidate — IP ภายในทุกตัวบนทุกอินเทอร์เฟซเครือข่าย (Ethernet, Wi-Fi, อินเทอร์เฟซเสมือน, IPv4 และ IPv6)
• Server-reflexive candidate — ที่อยู่สาธารณะที่ได้จากเซิร์ฟเวอร์ STUN
• Relay candidate — ที่อยู่ที่จัดสรรบนเซิร์ฟเวอร์ TURN

เพียร์ทั้งสองแลกเปลี่ยนรายการเหล่านี้ผ่านช่องสัญญาณ — สำหรับ Remio คือการเชื่อมต่อ WebSocket เล็ก ๆ ไปที่ relay.remio.net ที่ส่ง ICE candidate และคำอธิบายเซสชัน WebRTC (SDP) แล้วก็ไม่มีหน้าที่อะไรอีกเมื่อมีเดียเริ่มไหล

เมื่อได้ทั้งสองรายการ ICE เริ่มการตรวจสอบการเชื่อมต่อ เพียร์แต่ละฝั่งส่งแพ็กเก็ต STUN binding request ตามทุกคู่ candidate เรียงตามลำดับความสำคัญ ลำดับความสำคัญออกแบบให้เลือกเส้นทางที่ความหน่วงต่ำที่สุด:

1. Host ถึง host — เพียร์ทั้งสองอยู่ในเครือข่ายภายในเดียวกัน นี่คือกรณีในฝัน: ความหน่วงไม่กี่ร้อยไมโครวินาที ไม่มีเราเตอร์เกี่ยวข้อง
2. Host ถึง server-reflexive หรือ server-reflexive ถึง server-reflexive — เพียร์อยู่คนละเครือข่าย ทะลุ NAT ของแต่ละฝั่งด้วย hole punching นี่คือสิ่งที่ "P2P ผ่านอินเทอร์เน็ต" มักหมายถึงในทางปฏิบัติ
3. ทุกอย่างที่เกี่ยวกับรีเลย์ — ทางสุดท้าย ใช้เมื่อเส้นทางที่สำคัญกว่าล้มเหลวในการตรวจสอบการเชื่อมต่อทั้งหมดเท่านั้น

คู่ candidate แรกที่สำเร็จทั้งสองทิศทางจะถูกเสนอชื่อเป็นผู้ชนะ และมีเดียเริ่มไหลตามเส้นทางนั้น กระบวนการทั้งหมดมักเสร็จในเวลาน้อยกว่าหนึ่งวินาทีมาก

ICE ยังรวบรวม candidate อย่างต่อเนื่อง ถ้ามีเส้นทางที่ดีกว่าปรากฏกลางเซสชัน — เช่นโทรศัพท์ออกจากเซลลูลาร์ไปใช้ Wi-Fi — ICE เสนอชื่อเส้นทางใหม่ได้โดยไม่ตัดสาย

ทำไม Remio ให้ความสำคัญกับ P2P อย่างหนัก

Remio คือแอปรีโมทเดสก์ท็อป ไม่ใช่วิดีโอคอล งบความหน่วงโหดมาก เพื่อให้เซสชันรู้สึกเหมือนนั่งอยู่หน้าเครื่องโฮสต์ ไปป์ไลน์ทั้งหมด — จับภาพ เข้ารหัส เครือข่าย ถอดรหัส เรนเดอร์ — ต้องเล็กมาก: บน LAN ใช้ราว 8 มิลลิวินาที และที่เหลือคือจังหวะรีเฟรช 60 Hz ของจอคุณเอง (ราว 16.7 มิลลิวินาทีต่อเฟรม) ทุกฮอปที่เพิ่มคือบาป

บนการเชื่อมต่อ LAN P2P โดยตรง ส่วนเครือข่ายของงบนั้นอยู่ที่ราว 1 ถึง 5 มิลลิวินาทีไป-กลับ ไม่มีรีเลย์ ไบต์ไปจากอุปกรณ์หนึ่งถึงอีกอุปกรณ์หนึ่งตรง ๆ ด้วยไปป์ไลน์ของ Remio รวมแล้วเป็นการประมวลผลราว 8 มิลลิวินาทีบน LAN (วัดภายใน ที่เหลือคือจังหวะรีเฟรช 60 Hz ของจอคุณเอง) — อินพุตของคุณไปถึงก่อนเฟรมถัดไปวาด เครื่องระยะไกลรู้สึกไม่ต่างจากเครื่องในมือ

บนการเชื่อมต่อที่ผ่านรีเลย์ TURN — แม้ระดับภูมิภาค — ส่วนเครือข่ายพุ่งเป็น 30 ถึง 80 มิลลิวินาที ความหน่วงรวมที่ผู้ใช้รับรู้เป็น 40 ถึง 100 มิลลิวินาที ยังใช้ได้กับงานส่วนใหญ่ แต่คุณรู้สึกได้ตอนลากเร็วหรือคลิกรัว แทร็กแพดไม่ค่อยรู้สึกเป็นของคุณอีกต่อไป

ส่วนต่างนั้นคือเหตุผลที่เราพยายามอย่างหนักเพื่อรักษาเซสชันบน P2P สแต็ก WebRTC ของ Remio รวบรวมทั้ง candidate IPv4 และ IPv6 คุยกับเซิร์ฟเวอร์ STUN หลายตัวพร้อมกัน และเลือกเส้นทางตรงอย่างแข็งขันระหว่างการเลือกคู่ candidate ของ ICE ภายในเรายังใช้ RTT ของการเชื่อมต่อที่วัดได้เพื่อจัดประเภทเครือข่าย — ต่ำกว่า 15 มิลลิวินาทีเรารู้ว่าเป็น LAN ตัวเข้ารหัสจึงเริ่มสูงและใช้แบนด์วิดท์ได้มากกว่ามาก อะไรที่ช้ากว่านั้นถือเป็น WAN และปรับแบบระมัดระวังกว่า

และ — ส่วนนี้คือสิ่งที่คู่แข่งมักเงียบไว้ — การเชื่อมต่อเข้ารหัสแบบ end-to-end ไม่ว่าเส้นทางใด หน้าจอของคุณไม่เคยแตะเซิร์ฟเวอร์ของเรา และแม้แต่รีเลย์ TURN ก็เห็นแต่ข้อมูลที่เข้ารหัส: กุญแจถูกเจรจาตรงระหว่างสองเพียร์ระหว่างการจับมือ ก่อนที่พิกเซลใดจะขยับ ไม่ว่าไบต์จะไหลแบบ P2P หรือผ่าน TURN เซิร์ฟเวอร์สัญญาณของ Remio และผู้ให้บริการ TURN ก็อ่านไม่ได้ P2P แค่หมายความว่าไม่มีบุคคลที่สามบนเส้นทางข้อมูลเลย

เมื่อรีเลย์หลีกเลี่ยงไม่ได้ (และไม่เป็นไร)

บางครั้งเครือข่ายก็ไม่เป็นใจ Symmetric NAT ทั้งสองฝั่ง CGNAT สองชั้นบนผู้ให้บริการเซลลูลาร์ที่ ISP เข้มงวด ไฟร์วอลล์องค์กรที่อนุญาตเฉพาะ TLS ขาออกไปยังผู้ให้บริการคลาวด์ที่รู้จัก — เหล่านี้คือการตั้งค่าที่เกิดจริงและพบบ่อย ในกรณีเหล่านั้นเซสชันต้องผ่านรีเลย์ ไม่เช่นนั้นก็ไม่เกิดเลย

แบ็กเอนด์ TURN ของ Remio คือ Cloudflare Calls ซึ่งให้เครือข่ายรีเลย์ทั่วโลกใกล้ผู้ใช้ส่วนใหญ่ เมื่อ ICE เลือกเส้นทางรีเลย์ ประสบการณ์ลดจาก "รู้สึกเหมือนในเครื่อง" เป็น "รู้สึกเหมือน Splashtop" — ยังใช้ได้ดี แต่รู้สึกได้ ความหน่วงที่เพิ่มอยู่ที่ 30 ถึง 80 มิลลิวินาทีสำหรับรีเลย์ระดับภูมิภาค ข้ามภูมิภาคอาจถึง 200 มิลลิวินาที

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

นี่คือสถาปัตยกรรมที่เอกสารไวต์เปเปอร์ด้านความปลอดภัยของเราอธิบายละเอียดกว่า สรุปสั้น ๆ: P2P หรือรีเลย์ โมเดลภัยคุกคามเหมือนกัน

ทางหนีทีไล่ของ IPv6

IPv6 มี 340 undecillion ที่อยู่ (3.4 × 10³⁸) — พอให้เม็ดทรายทุกเม็ดบนโลกมี IP สาธารณะของตัวเอง และเหลือเป็นล้านล้าน ในโลกที่เป็น IPv6 ล้วน NAT แทบไม่จำเป็น อุปกรณ์ที่รองรับ IPv6 สองเครื่องส่งแพ็กเก็ตหาที่อยู่ของกันและกันได้เลย และอุปสรรคเดียวคือไฟร์วอลล์ของโฮสต์ที่ปลายทั้งสอง

ถ้าคุณมี IPv6 ที่บ้านและบนผู้ให้บริการเซลลูลาร์ คุณอาจสังเกตว่าบางแอปเชื่อมต่อเร็วกว่าเมื่อทั้งสองฝั่งเป็น IPv6 — เพราะท่าเต้น "รวบรวม candidate ตรวจสอบคู่" ทั้งหมดมีอุปสรรคน้อยกว่า ไม่มีการแปล NAT ให้ค้นหา ไม่ต้องไป STUN แค่ที่อยู่ตรง ๆ

แต่ข้อแม้คือ ในปี 2026 การเปิดใช้ทั่วโลกยังไม่สมบูรณ์ เราเตอร์บ้านจำนวนมากรองรับ IPv6 ไม่ดีหรือไม่รองรับเลย เครือข่ายองค์กรจำนวนมากบล็อก IPv6 ขาเข้าโดยปริยาย ผู้ให้บริการบางรายให้ IPv6 ฝั่งวิทยุแต่บริดจ์ไป IPv4 ที่อื่น เส้นทาง IPv6 ล้วนมีอยู่แต่พึ่งเป็นกลไกเดียวไม่ได้

Remio — เหมือนสแต็ก P2P จริงจังทุกตัว — จึงรวบรวมทั้ง candidate IPv4 และ IPv6 แล้วให้ ICE แข่งกัน ถ้ามีเส้นทาง IPv6 ตรงที่ใช้ได้ มักชนะด้านความหน่วง ถ้าไม่ IPv4 พร้อม hole punching รับช่วง ถ้าทั้งสองล้มเหลว ก็รีเลย์ ผู้ใช้ไม่เห็นอะไรเลย การเชื่อมต่อแค่เกิดขึ้น

จะรู้ได้อย่างไรว่าเซสชันใช้เส้นทางไหน

สงสัยว่าเซสชันของคุณลงเอยที่เส้นทางใด? ตัวบ่งชี้การเชื่อมต่อของ Remio แสดงประเภทด้วยภาษาเข้าใจง่าย — "โดยตรง" สำหรับ P2P "รีเลย์" สำหรับ TURN แผงสถิตินักพัฒนาแสดงสถานะ WebRTC เต็ม รวมถึงประเภท candidate ของคู่ที่ถูกเสนอชื่อ (host, srflx, relay) และ RTT ที่วัดได้

การตีความอย่างเร็ว:

• RTT ต่ำกว่า 5 มิลลิวินาที โดยตรง — คุณอยู่บน LAN เดียวกับโฮสต์ กรณีที่ดีที่สุด ทำได้ที่การประมวลผลราว 8 มิลลิวินาที (ที่เหลือคือจังหวะรีเฟรช 60 Hz ของจอคุณเอง)
• RTT 5 ถึง 15 มิลลิวินาที โดยตรง — เครือข่าย Wi-Fi เดียวกันแต่มีแอคเซสพอยต์หรือเมชเพิ่มอีกหนึ่งฮอป ยังยอดเยี่ยม
• RTT 15 ถึง 80 มิลลิวินาที โดยตรง — คุณอยู่คนละเครือข่ายกับโฮสต์ hole punching สำเร็จ P2P ผ่านอินเทอร์เน็ตทำงาน
• RTT 30 ถึง 80 มิลลิวินาที รีเลย์ (ภูมิภาค) — symmetric NAT หรือ carrier-grade NAT ทำให้ hole punch ล้มเหลว TURN ของ Cloudflare ที่อยู่ใกล้รับช่วง
• RTT 80 ถึง 200 มิลลิวินาที รีเลย์ — TURN ผ่านระยะทางภูมิศาสตร์ที่ไกลกว่า หรือคุณกับโฮสต์อยู่คนละภูมิภาคมาก

ถ้าคุณตกไปรีเลย์เป็นประจำแม้ที่บ้าน ผู้ต้องสงสัยปกติคือโมเด็มของ ISP ที่ทำ symmetric NAT, IPv4 CGNAT บนอินเทอร์เน็ตบ้านของคุณ (พบบ่อยกว่าที่คิดในผู้ขายต่อไฟเบอร์) หรือไฟร์วอลล์ที่เข้มเกินไปบล็อก UDP ขาเข้าคู่มือลดความหน่วงของรีโมทเดสก์ท็อปของเราไล่ผู้ต้องสงสัยทั่วไป และหน้าการเชื่อมต่อ LAN โดยตรงคือทางลัดถ้าอุปกรณ์ทั้งสองอยู่ในเครือข่ายของคุณ

ตัวเลขประสิทธิภาพในโลกจริง

รวมทั้งหมดแล้ว นี่คือตัวเลขความหน่วงที่เราวัดในโปรดักชันตลอดเส้นทางต่าง ๆ ที่เซสชัน Remio เดินได้:

• LAN P2P โดยตรง: RTT เครือข่าย 1–5 มิลลิวินาที end-to-end (จากอินพุตถึงพิกเซลอัปเดต): การประมวลผลราว 8 มิลลิวินาที (ที่เหลือคือจังหวะรีเฟรช 60 Hz ของจอคุณเอง) เมื่อส่วนอื่นของไปป์ไลน์ร่วมมือ
• Wi-Fi เครือข่ายเดียวกันแต่มีฮอปเพิ่ม: RTT เครือข่าย 5–10 มิลลิวินาที
• รีเลย์ TURN ระดับภูมิภาค: RTT เครือข่าย 30–80 มิลลิวินาที
• รีเลย์ TURN ข้ามภูมิภาค: RTT เครือข่าย 80–200 มิลลิวินาที
• เซลลูลาร์ 4G/5G, P2P ที่ผ่าน hole punch: RTT เครือข่าย 40–100 มิลลิวินาที

ตัวเลขเหล่านี้ตรงกับตัวเลขในเบนช์มาร์กของ Remio และอธิบายว่าทำไมเราตั้งเกณฑ์ LAN เทียบ WAN ไว้ที่ RTT 15 มิลลิวินาที — แยกเส้นทางตรงออกจากรีเลย์ใด ๆ (ขั้นต่ำ 30 มิลลิวินาที) หรือเส้นทางเซลลูลาร์ (ขั้นต่ำ 40 มิลลิวินาที) ได้อย่างสะอาด โดยมีผลบวกลวงน้อยมาก

NAT traversal เป็นหัวข้อหนึ่งที่โปรโตคอลแต่ละตัวเรียบง่ายแต่การจัดหมู่ยุ่งยาก ผู้ใช้ส่วนใหญ่ไม่จำเป็นต้องรู้ว่า ICE, STUN และ TURN มีอยู่ — แค่ได้ประสบการณ์แอปที่เชื่อมต่อเร็วจากที่ไหนก็ได้ไปที่ไหนก็ได้ โปรโตคอลทำหน้าที่ได้ดีเมื่อคุณไม่สังเกตเห็น เมื่อคุณสังเกตเห็น — เซสชันใช้เวลานานไปจังหวะหนึ่ง หรือ "โดยตรง" กลายเป็น "รีเลย์" — ตอนนี้คุณก็มีโมเดลในหัวแล้ว

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