النقل المشفر من نظير إلى نظير: دليل تقني

نقل الملفات من نظير إلى نظير يُرسل البايتات مباشرةً بين متصفحين أو جهازين دون أن يلمس الملفَ أي خادم. WebRTC، المُقنَّن في RFC 8825 إلى 8837، يوفر النقل: قنوات بيانات مشفَّرة عبر UDP مع DTLS 1.3، واجتياز NAT عبر ICE وSTUN وTURN، والإشارة عبر WebSocket أو HTTP. أدوات مثل Snapdrop وWormhole.app وMagic Wormhole تثبت نجاح هذا النموذج. إليك كيفية بنائه: مصافحة الإشارة، وأفخاخ اجتياز NAT، وطبقات التشفير، وما تكسبه أو تخسره مقارنةً بخدمات نقل الترحيل السحابي.

لماذا P2P لنقل الملفات

الجاذبية بسيطة: لا يُخزِّن الملفَ أي خادم، لا فاتورة نطاق ترددي لخدمة النقل، ورفع المُرسِل هو تنزيل المستلِم بلا نسخة وسيطة. لنقل 10 جيجابايت بين مستخدمين على شبكة LAN جيجابت، P2P ينهي في 80 ثانية بينما الترحيل السحابي يرفع إلى خادم بعيد ويُنزِّل مرة أخرى، مُضاعِفاً استخدام النطاق الترددي والتأخير. الخصوصية أيضاً نقطة بيع — بايتات الملف توجد فقط على أجهزة المُرسِل والمستلِم. المقايضات: يجب أن يكون الطرفان متصلين في آنٍ واحد، اجتياز NAT يفشل أحياناً، والاتصال بسرعة المشارك الأبطأ رفعاً.

قنوات بيانات WebRTC كنقل

WebRTC بدأ كبروتوكول صوت/فيديو لكن RTCDataChannel يمنح نقل رسائل ثنائية عشوائية مع توصيل موثوق مرتَّب (كـ TCP) أو غير موثوق وغير مرتَّب (كـ UDP). تحت الغطاء، قنوات البيانات تعمل عبر SCTP فوق DTLS 1.3 فوق UDP. طبقة DTLS توفر السرية والنزاهة المُصادَق عليها عبر AES-128-GCM أو ChaCha20-Poly1305، مُتفاوَض عليها أثناء المصافحة. لنقل الملفات، أنشئ قناة موثوقة مرتَّبة، جزِّئ الملف إلى رسائل 16 KB أو 64 KB (Chrome تاريخياً حدَّد حجم الرسائل بـ 256 KB)، وأرسلها بالتسلسل مع التحكم في التدفق عبر عتبة bufferedAmount.

دور خادم الإشارة

WebRTC يحتاج خادم إشارة لتبادل معلومات الاتصال (عروض SDP وإجاباتها، ومرشحات ICE) بين الأنداد. خادم الإشارة لا يُرحِّل بايتات الملف، فقط نحو 5 KB من بيانات وصف الاتصال. خدمة إشارة قائمة على WebSocket في Node.js أو Python أو Go تتعامل مع هذا في بضع مئات من أسطر الكود. Firebase Realtime Database وSupabase Realtime وPusher تعمل جميعها كخلفيات للإشارة. خادم الإشارة يرى من يتحدث مع من ومتى، لكن ليس محتوى الملف أبداً. معظم خدمات نقل P2P تُشغِّل إشارتها مجاناً لأن النطاق الترددي ضئيل.

اجتياز NAT: STUN وTURN وICE

معظم الأجهزة تقع خلف NAT، مما يجعل اتصالات IP المباشرة مستحيلة. ICE (Interactive Connectivity Establishment، RFC 8445) يجرِّب مسارات اتصال متعددة. STUN (RFC 8489) يسمح للنظير باكتشاف عنوانه العام ومنفذه عبر خادم STUN عام؛ Google تُشغِّل stun.l.google.com مجاناً. إذا كان لكلا النظيرين NAT معقول (مخروط كامل أو مخروط مُقيَّد)، يعمل اتصال UDP المباشر في نحو 70 بالمئة من المحاولات. للـ NAT المتماثل وجدران الحماية المؤسسية وCGNAT، TURN (RFC 8656) يُرحِّل الحركة عبر خادم. خوادم TURN مكلفة لأنها تحمل بايتات الملف الفعلية. coturn المُستضاف ذاتياً أو twilio.com/stun أو Cloudflare Calls توفر خيارات. توقع أن 10 إلى 30 بالمئة من عمليات النقل P2P ترجع إلى TURN في الواقع.

طبقات التشفير فوق DTLS

DTLS يُشفِّر بيانات WebRTC بالفعل، لذا التشفير على مستوى التطبيق الإضافي يُضيف طبقة أمان إضافية. مصافحة DTLS تُصادِق شهادات الأنداد، لكن WebRTC يستخدم عادةً شهادات موقَّعة ذاتياً لا تتحقق من الهوية — تتحقق فقط من أن الاتصال هو لنفس النظير الذي وقَّع SDP. التشفير على مستوى التطبيق بـ AES-256-GCM وسر مشترك مستمد من لقاء الإشارة يُضيف ضمان الهوية. SPAKE2 PAKE من Magic Wormhole (Password-Authenticated Key Exchange) يستمد مفتاحاً قوياً من عبارة قصيرة مقروءة بشرياً، حتى خادم الإشارة المُخترَق لا يستطيع فك التشفير.

استراتيجية التجزئة لنقل P2P

قنوات بيانات WebRTC لها حد حجم الرسائل (256 KB في معظم المتصفحات، مع تجزئة الرسائل الأكبر ممكنة لكن غير موثوقة). جزِّئ الملفات بـ 16 KB إلى 64 KB لكل رسالة للتوافق. تتبَّع bufferedAmount عبر bufferedAmount وbufferedAmountLowThreshold لتطبيق ضغط العودة — أوقف الإرسال حين يتجاوز المخزن المؤقت 1 MB، استأنف حين ينخفض دون 256 KB. للنزاهة، بصِّم كل جزء بـ SHA-256 وأدرج البصمة في بيان يُرسَل أولاً. المستلِم يُعيد التجميع، يتحقق من البصمات، ويكتب على القرص عبر File System Access API أو تنزيل Blob.

الاعتبارات على الأجهزة المحمولة ومتعددة الأجهزة

P2P بين سطحَي مكتب يعمل جيداً. المحمول إلى سطح المكتب يُدخِل تعقيدات: متصفحات المحمول تُعلِّق التبويبات بقوة، لذا يجب أن يبقي المُرسِل تبويبة المتصفح في المقدمة. تنفيذ iOS Safari لقناة البيانات كان تاريخياً أقل موثوقية من Chromium. الرفع في الخلفية على المحمول يتطلب تطبيقات مدعومة بتطبيق (Snapdrop Relay وShareDrop). تأثير البطارية مهم أيضاً، جلسات WebRTC المستمرة تستنزف البطاريات أسرع من تنزيلات HTTPS. للنقل من محمول إلى محمول على نفس Wi-Fi، AirDrop (iOS/macOS) وNearby Share (Android) يتفوقان على P2P المتصفح باستخدام بروتوكولات الأجهزة المباشرة.

اكتشاف الأنداد بدون حسابات مركزية

كيف يتصل غريبان بدون نظام قائم على الحسابات؟ عدة أنماط تعمل. رمز قصير مثل "4-truck-roger" في Magic Wormhole يخدم عنوان اللقاء وكلمة المرور معاً؛ خادم الإشارة يربط الرموز بالجلسات. رموز QR تُشفِّر URL جلسة تعمل للنقل الشخصي. NFC للاتصال باللمس على Android يتصل بالقرب. للشبكات الأكبر، DHT مثل Mainline DHT لـ BitTorrent يستطيع تمهيد اكتشاف الأنداد بدون خادم مركزي، لكن بحثات DHT تستغرق ثوانٍ ولا تناسب مشاركة الملفات العرضية.

تهديدات الأمان الخاصة بـ P2P

P2P يُدخِل تهديدات لا تمتلكها ترحيلات السحابة. الكشف عن عنوان IP: الاتصالات المباشرة تكشف IP العام لكل نظير للآخر، مما قد يُفضي إلى كشف هوية المستخدمين في سياقات حساسة للخصوصية (كشف الفساد والنشاط الحقوقي). بعض خدمات P2P تُجبر ترحيل TURN لإخفاء الـ IPs بتكلفة الأداء. توزيع البرمجيات الخبيثة أصعب تشديداً لأن مشغِّل الخدمة لا يرى محتويات الملف أبداً. الحرمان من الخدمة عبر استنزاف الاتصال على خادم الإشارة يحتاج تحديد المعدل. للنقل الحساس جداً، خدمة Tor onion تستطيع تغطية الإشارة لإخفاء كلا الـ IPs بتكلفة تأخير كبيرة.

فحص واقعي للأداء

سرعة P2P محدودة بنطاق رفع النظير الأبطأ وتأخير الرحلة ذهاباً وإياباً. على الاتصالات المنزلية، حدود الرفع غالباً 20 إلى 50 ميجابت في الثانية حتى حين يكون التنزيل جيجابت. نقل P2P بـ 10 جيجابايت من رفع منزلي بـ 20 ميجابت إلى مستلِم جيجابت يستغرق 68 دقيقة كحد أدنى. الترحيل السحابي مع رابط رفع سريع وتنزيل مدعوم بـ CDN قد يتفوق بالرفع مرة واحدة إلى خادم حسن الاتصال. P2P يفوز لعمليات النقل على نفس الشبكة المحلية (جيجابت أو أسرع)، للبيانات الحساسة حيث لا نسخة على الخادم مقبولة، ولتحسين التكلفة حين تكون فواتير النطاق الترددي مؤلمة.

متى يفوز الترحيل السحابي

للنقل غير المتزامن حيث لا يكون المُرسِل والمستلِم متصلين في وقت واحد، P2P يفشل تماماً — لا نظير لاستقبال الملف. للنقل الكبير الذي يتجاوز نافذة الجلسة (تبويبات متصفح المحمول تُغلَق، الحواسيب المحمولة تنام)، نموذج "ارفع وشارك رابطاً" الخاص بالترحيل السحابي أكثر عملية. للتوزيع من واحد إلى كثيرين، رفع واحد مع توزيع CDN يتفوق على تشغيل N جلسة P2P متزامنة. HexaTransfer يستخدم نموذج الترحيل السحابي مع تشفير AES-256-GCM من جانب العميل، محققاً معظم فوائد خصوصية P2P مع دعم أفضل بكثير للنقل غير المتزامن والمستلمين المتعددين.

جرّبها على hexatransfer.com — مجاناً، بدون حساب، حتى 10 جيجابايت.