WebRTC
TURN
Networking

آنچه واقعاً وصل می‌شود: TURN و شبکه‌هایی که با آن سر جنگ دارند

هر آموزش WebRTC آنجا تمام می‌شود که «و بعد ICE یک مسیر پیدا می‌کند». روی شبکه‌هایی که کاربران ما واقعاً روی آن‌اند، اغلب پیدا نمی‌کند. سه سال گرداندن یک محصول جلسات در همین‌جا، و عددهای اتصالی که پیش‌فرض‌های ما را عوض کرد.

انتشار۲۱ خرداد ۱۴۰۵

۳ دقیقه مطالعه

روایت صادقانهٔ WebRTC این است که ارتباط نقطه‌به‌نقطه یک بهترین حالت است، نه یک طراحی. روی یک شبکهٔ خانگی خوب در اروپا، حدود ۸۵ تا ۹۰ درصد تماس‌های ما مستقیم برقرار می‌شود. روی شبکه‌هایی که بخش بزرگی از کاربران ما واقعاً روی آن‌اند — NAT در مقیاس اپراتور، NAT متقارن، فیلتر خروجی سازمانی، دیتای موبایل پشت پراکسی — نرخ اتصال مستقیم به چیزی بین یک‌سوم و یک‌دوم می‌افتد و بقیه از رله رد می‌شود.

این خرابی‌ای نیست که بشود با مهندسی حذفش کرد؛ این شرط کار است. آنچه در ادامه می‌آید، چیزهایی است که پس از پذیرفتن همین شرط تغییر دادیم.

برای رله بودجه ببندید، به نقطه‌به‌نقطه امید نبندید

اگر نیمی از تماس‌های شما رله می‌شود، صورت‌حساب پهنای باند و طرح ظرفیت شما اعداد رله است، نه اعداد نقطه‌به‌نقطه. ما TURN را برای همان حالت ۱۰ درصدی که آموزش‌ها تلقین می‌کنند اندازه گرفته بودیم و دو بار غافلگیر شدیم: یک بار با هزینه، و یک بار در یک پنج‌شنبه‌شب که یک رله فایل‌دیسکریپتور کم آورد و یک‌سوم تماس‌های هم‌زمان را با خودش برد.

حالا قاعده ساده است: ظرفیت طوری بسته می‌شود که انگار همهٔ تماس‌ها رله می‌شوند و اتصال‌های نقطه‌به‌نقطه تخفیفی است که گاهی نصیبمان می‌شود. حتی یک بار هم عکسش درست نبوده است.

TCP روی ۴۴۳ راه پشتیبان نیست؛ راهی است که کار می‌کند

UDP در هر چیزی که برای رسانه اهمیت دارد بهتر است، و دقیقاً همان چیزی است که یک شبکهٔ سخت‌گیر اول از همه می‌اندازد. ما TURN روی TLS و درگاه ۴۴۳ را کنار UDP عرضه می‌کنیم و آن را مسیر اضطراری نمی‌دانیم — برای سهم قابل‌توجهی از نشست‌ها این تنها مسیر است، و کلاینتی که آخر از همه امتحانش می‌کند، پیشاپیش هشت ثانیه صرف شکست خوردن کرده است.

تغییر عملی این بود که نامزدها را دیگر بر اساس کیفیت نظری مرتب نکنیم و بر اساس نرخ موفقیت مشاهده‌شده به‌ازای هر شبکه مرتب کنیم؛ چیزی که از گزارش‌های اتصال خودمان درمی‌آید. کلاینتی که روی شبکه‌ای است که چهل بار دیده‌ایم UDPاش شکست خورده، بی‌درنگ نامزد ۴۴۳ را می‌گیرد.

رله را نزدیک کاربر بگذارید، نه نزدیک سرورها

رله‌ای در فرانکفورت که تماس دو نفر در یک شهر ایران را جابه‌جا می‌کند، بی هیچ دلیلی حدود ۱۶۰ میلی‌ثانیه رفت‌وبرگشت اضافه می‌کند. رله‌ها ارزان و بدون وضعیت‌اند و رسانه به‌هرحال باید به یکی از آن‌ها برسد. نزدیک کردنشان به کاربرها — به‌جای نزدیک کردن به بقیهٔ زیرساخت، که غریزه آن‌ها را همان‌جا می‌گذارد — بزرگ‌ترین بهبودی بود که تا امروز در کیفیت ادراک‌شدهٔ تماس اندازه گرفته‌ایم، و یک خط کد هم نداشت.

اتصال را اندازه بگیرید، نه تماس را

اولین داشبورد کیفیت ما صدا و تصویر را در حین تماس اندازه می‌گرفت. همان خرابی‌ای را که همه از آن شکایت داشتند نمی‌دید: تماسی که اصلاً شروع نمی‌شود. حالا برای هر تلاش ثبت می‌کنیم که کدام جفت‌نامزد برنده شده، ICE چقدر طول کشیده و کلاینت به مسیر پشتیبان افتاده است یا نه — و عددی که تماشا می‌کنیم زمان تا نخستین فریم است، نه اتلاف بسته.

اتلاف بسته می‌گوید تماس چطور گذشت. زمان تا نخستین فریم می‌گوید محصول کار می‌کند یا نه.