كيف يعمل نقل الملفات عبر WebRTC

يتيح نقل الملفات عبر WebRTC لمتصفحين إرسال ملف أحدهما إلى الآخر دون رفعه إلى تخزين سحابي. يبدو الأمر بسيطًا، لكن الإنترنت لم يُبنَ ليتصل جهازا كمبيوتر منزليان أحدهما بالآخر مباشرة. يشرح هذا الدليل ما يحدث فعلًا — الإشارات وNAT وSTUN وICE وTURN وDTLS وقنوات البيانات — بلغة مبسطة، وهو في جوهره بروتوكول نقل الملفات بين الأجهزة في المتصفح، مع StrongFolder مثالًا.

ما هو WebRTC؟

WebRTC (الاتصال الفوري عبر الويب) مجموعة من واجهات API في المتصفحات وبروتوكولات الشبكة، وضعت معاييرها W3C وIETF، للاتصالات الفورية بين المتصفحات. تدعمه Chrome وEdge وFirefox وSafari وOpera جميعها. بُني لمكالمات الفيديو والصوت، لكن فيه أيضًا قنوات بيانات تحمل أي بيانات ثنائية — وهذا بالضبط ما هو الملف.

الخاصية الأساسية: بمجرد إعداد اتصال WebRTC، تنتقل البيانات بين الطرفين، لا إلى تخزين خادم. وهذا ما يجعل نقل الملفات P2P في المتصفح ممكنًا.

لماذا لا يستطيع متصفحان الاتصال أحدهما بالآخر ببساطة؟

لأن أي جهاز تقريبًا ليس له عنوان عام خاص به. حاسوبك المحمول خلف جهاز توجيه منزلي، أو جدار حماية في المكتب، أو شبكة مشغّل اتصالات الهاتف. يجري جهاز التوجيه NAT (ترجمة عناوين الشبكة): تتشارك أجهزة خاصة كثيرة عنوان IP عامًا واحدًا، ولا يسمح جهاز التوجيه إلا بحركة المرور التي تردّ على شيء أُرسل من الداخل.

لذا يواجه المتصفحان ثلاث مشكلات قبل أن تتدفق أي بيانات من الملفات:

1. لا يعرفان كيف يصل أحدهما إلى الآخر — فلا أحد منهما يعرف أن الآخر موجود.
2. لا يعرفان عنوانهما العام — بل الخاص فقط، مثل 192.168.1.20.
3. قد تحجب أجهزة التوجيه لديهما حركة المرور الواردة غير المطلوبة.

يحل WebRTC كل مشكلة بآلية منفصلة.

كيف يعمل نقل الملفات عبر WebRTC خطوة بخطوة؟

إليك المسار الكامل، من النقر على «مشاركة» حتى آخر بايت:

 Sender browser                   Servers                      Recipient browser
 ──────────────                   ───────                      ─────────────────
 1. Choose files ──── metadata ──▶ Signaling server
                                        ◀──────── 2. Open link ────────
 3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP)
 4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?"
 5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates
 6. ICE checks: try LAN → direct internet → TURN relay
 7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake
 8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk

الخطوتان 1–2 — الإشارات. يختار المرسل الملفات؛ وتسجّل الخدمة البيانات الوصفية اللازمة للرابط. عندما يفتح المستلم الرابط، يكون المتصفحان متصلين بخادم إشارات. لا يحدد WebRTC كيفية عمل الإشارات؛ ويستخدم StrongFolder مكتبة PeerJS مع خادم إشارات خاص به.

الخطوة 3 — العرض والإجابة. ينشئ أحد المتصفحين عرضًا (offer) بصيغة SDP (بروتوكول وصف الجلسة): «أريد قناة بيانات، وهذه بصمة التشفير وقدراتي». ويرد الآخر بإجابة (answer). وكلاهما يمر عبر خادم الإشارات.

الخطوة 4 — STUN. يسأل كل متصفح خادم STUN: «من أي عنوان ومنفذ تراني آتيًا؟» والجواب هو عنوانه العام كما يعيّنه جهاز التوجيه. تعالج خوادم STUN طلبًا صغيرًا ولا تتعامل مع أي بيانات من الملفات؛ ويستخدم StrongFolder خوادم STUN عامة، منها خوادم Google، وخوادم خاصة به.

الخطوة 5 — مرشحو ICE. يجمع كل متصفح مرشحين (candidates) — طرقًا ممكنة للوصول إليه: عنوانه على الشبكة المحلية (host)، وعنوانه العام من STUN (server-reflexive)، وعنوانًا على خادم ترحيل TURN (relayed). ويتبادلان المرشحين عبر الإشارات.

الخطوة 6 — فحوص الاتصال. يختبر ICE (إنشاء الاتصال التفاعلي) أزواج المرشحين ويختار أفضل زوج يعمل. إذا كان الجهازان على Wi-Fi نفسها، يفوز المسار المحلي. وإذا سمحت أجهزة التوجيه، يفوز مسار مباشر عبر الإنترنت («ثقب الجدار» أو hole punching). وإذا لم يعمل أي شيء مباشر، يُستخدم المسار عبر خادم الترحيل.

الخطوة 7 — DTLS. قبل أن تتدفق أي بيانات، يُجري المتصفحان مصافحة DTLS (وهو TLS المكيّف لـ UDP) ويتحققان من أن بصمات الشهادات تطابق تلك الواردة في العرض والإجابة. ومن الآن فصاعدًا يكون كل شيء مشفّرًا.

الخطوة 8 — قناة البيانات. فوق DTLS يعمل SCTP، الذي يمنح قناة البيانات تسليمًا موثوقًا ومرتبًا. في StrongFolder يطلب متصفح المستلم ملفًا، فيقرأه متصفح المرسل من القرص على أجزاء ويرسلها، ويكتب المستلم كل جزء على القرص فور وصوله — لذا حتى الملفات الكبيرة جدًا لا تحتاج أبدًا إلى أن تتسع لها الذاكرة.

ماذا تعني STUN وTURN وICE والمصطلحات الأخرى؟

كل هذه المصطلحات مشروحة باختصار في مسرد المصطلحات.

متى يُستخدم خادم ترحيل TURN، وماذا يرى؟

خادم الترحيل هو البديل الاحتياطي لا الخيار الافتراضي. لا يستخدمه ICE إلا عندما لا يتصل أي زوج مرشحين مباشر — عادةً على الشبكات ذات NAT المتماثل (بعض مشغّلي الهاتف المحمول)، أو جدران الحماية المؤسسية التي تحجب UDP الصادر، أو بعض شبكات VPN.

إذا تعذّر الاتصال المباشر (جدار حماية مؤسسي صارم، أو بعض شبكات الهاتف المحمول)، يمر التدفق المشفّر عبر خادم ترحيل (TURN) تابع لـ StrongFolder. يمرّر خادم الترحيل البيانات ولا يخزّنها.

يتلقى خادم الترحيل حزمًا مشفّرة بـ DTLS ويمرّرها. يمكنه أن يرى أن حركة مرور تتدفق، وكميتها وتوقيتها — لا ما بداخلها. وقد يكون النقل عبر خادم الترحيل أبطأ من النقل المباشر، لأن كل بايت يقطع رحلة إضافية عبره. إذا كان النقل بطيئًا على غير العادة، فجرّب شبكة مختلفة: نقطة اتصال الهاتف أو Wi-Fi المنزل كثيرًا ما تتصل مباشرة حيث لا تتصل شبكة المكتب.

ما مدى أمان تشفير WebRTC؟

يجعل WebRTC التشفير إلزاميًا: لا توجد طريقة لفتح قناة بيانات غير مشفّرة. يستخدم DTLS خوارزميات تشفير حديثة يتفاوض عليها المتصفحان، وتُنشأ مفاتيح جديدة لكل اتصال.

وهناك تحفّظ صادق واحد ينطبق على كل خدمة WebRTC. يتحقق المتصفحان أحدهما من الآخر عبر بصمات الشهادات التي تُتبادل عبر خادم الإشارات. ولذلك فأنت تثق في أن إشارات الخدمة لن تعبث بها. لهذا يصف StrongFolder حمايته بأنها تشفير أثناء النقل — لا تشفير من طرف إلى طرف بمفاتيح تحتفظ بها أنت، ولا «معرفة صفرية» (zero-knowledge). لنظرة أوسع على معنى «آمن»، اقرأ مشاركة الملفات بأمان والأمان والخصوصية.

لماذا يجب أن يبقى متصفح المرسل مفتوحًا؟

لأن متصفح المرسل هو المصدر. لا توجد نسخة على خادم يمكن الرجوع إليها: تقرأ قناة البيانات الأجزاء من قرص المرسل فقط ما دامت علامة التبويب مفتوحة والجهاز مستيقظًا. يجب أن تبقى علامة تبويب المتصفح لدى المرسل مفتوحة ومتصلة حتى ينتهي المستلم من التنزيل — فالملفات تأتي من جهاز المرسل، لا من خادم. أما كيفية التخطيط لذلك فمشروحة في لماذا يبقى المرسل متصلًا.

ما سرعة نقل الملفات عبر WebRTC؟

لا توجد سرعة ثابتة. السقف هو أبطأ رابط في المسار: وهو عادةً سرعة الرفع لدى المرسل. وكقاعدة تقريبية، يستغرق 1 GB نحو 2.7 دقيقة بسرعة 50 Mbit/s، ونحو 80 ثانية بسرعة 100 Mbit/s، وأقل من دقيقة بكثير على شبكة محلية سريعة. وتجري عمليات النقل الفعلية أبطأ قليلًا من هذه الأرقام بسبب عبء البروتوكول وسرعة القرص، ومع خادم الترحيل، القفزة الإضافية. يمكن لعدة مستلمين فتح الرابط نفسه؛ وكل منهم ينزّل مباشرة من المرسل. وعدة عمليات تنزيل في وقت واحد تتقاسم سرعة الرفع لدى المرسل.

الخلاصة

نقل الملفات عبر WebRTC تفاوض قصير يتبعه تدفق طويل ومشفّر: تعرّف الإشارات المتصفحين أحدهما على الآخر، ويجد STUN وICE مسارًا عبر NAT، ويمرّر TURN البيانات كملاذ أخير، وتحمل قنوات البيانات المشفّرة بـ DTLS الملف من قرص إلى قرص. وللجانب العملي — ما يعنيه هذا لك كمرسل — ابدأ بـ نقل الملفات P2P في المتصفح وكيف يعمل StrongFolder.