מה עושים שרתי STUN ו-TURN
WebRTC מפעיל שיחות וידאו, שיתוף מסך והעברת קבצים בין דפדפנים. לפני ששני מכשירים יכולים לתקשר ישירות, כל אחד מהם צריך לדעת באיזו כתובת אפשר להגיע לשני. אבל רוב המכשירים נמצאים מאחורי נתב ביתי או חומת אש ארגונית ומשתמשים בכתובות פרטיות שמתורגמות על ידי NAT. שרתי STUN ו-TURN פותרים את זה:
- STUN אומר למכשיר איך הוא נראה מהאינטרנט: כתובת ה-IP הציבורית והפורט שלו. עם המידע הזה, שני צדדים יכולים לרוב להתחבר ישירות.
- TURN משמש כממסר כשחיבור ישיר אינו אפשרי, למשל מאחורי NAT סימטרי, חומות אש מחמירות או רשתות שמאפשרות רק TCP.
הרצת הבדיקה
- הזינו את כתובת השרת עם הקידומת stun:, turn: או turns: (למשל stun:server.example.com:3478 או turn:server.example.com:3478?transport=tcp).
- עבור שרתי TURN, מלאו שם משתמש ואישור גישה. אם אתם משתמשים באישורים מוגבלים בזמן, ודאו שהם לא פגו.
- הוסיפו שרתים נוספים לפי הצורך והריצו את הבדיקה. הדפדפן אוסף מועמדי ICE ומציג כל אחד מהם עם הסוג, הכתובת, הפרוטוקול והזמן שלקח לו להגיע.
אם אין לכם שרת משלכם, השתמשו באפשרות לבדוק את השרתים שלנו כדי לראות איך נראית תוצאה תקינה.
קריאת סוגי המועמדים
כל שורה בתוצאה היא מועמד ICE. המשמעות שלה תלויה בסוג:
- host: הכתובת המקומית של המכשיר עצמו. דפדפנים מודרניים מסתירים אותה מאחורי שם .local אקראי לשמירה על פרטיות.
- srflx: הכתובת הציבורית שדיווח עליה שרת ה-STUN. אם הוא מופיע, STUN עובד.
- relay: כתובת הממסר שהקצה שרת ה-TURN. אם הוא מופיע, TURN והאימות עובדים.
- prflx: כתובת שהתגלתה במהלך בדיקות קישוריות; נדיר לראות אותה בבדיקה חד-צדדית.
עמודת הזמן מראה כמה מילישניות אחרי ההתחלה הגיע כל מועמד. היא נותנת מושג על המרחק לשרת ועל העומס עליו; זמנים של כמה מאות מילישניות עלולים לעכב באופן מורגש את הקמת השיחה.
בעיות נפוצות
- אין מועמד relay: שם משתמש או סיסמה שגויים, static-auth-secret לא תואם בשרת, או פורט TURN שחסום על ידי חומת אש.
- עובד רק ב-UDP: עבור משתמשים ברשתות מוגבלות, הוסיפו ?transport=tcp או turns: (TLS) בפורט 443.
- turns: נכשל אבל turn: עובד: ייתכן שתעודת ה-TLS לא תקינה, פגה או לא תואמת את שם המארח.
- כתובת srflx לא צפויה: עם CGNAT או VPN, הכתובת הציבורית שייכת לספק האינטרנט או לספק ה-VPN.
הבדיקה רצה כולה בדפדפן; אישורי הגישה שאתם מזינים משמשים רק את הדפדפן שלכם להתחברות לשרת שציינתם. כדי לראות את כתובת ה-IP הציבורית ואת מצב דליפת ה-WebRTC, בקרו בדף מה כתובת ה-IP שלי. כדי למדוד איבוד חבילות אמיתי בערוץ נתונים של WebRTC, נסו את בדיקת איבוד החבילות, ובדקו את השהיית הבסיס עם בדיקת הפינג לפני שאתם מכווננים את איכות השיחות באפליקציה שלכם.