ما هو نقل الملفات من الند للند؟

آخر تحديث: 2026-08-07

يُستخدم مصطلح «من الند للند» بشكل فضفاض، وإليك ما يعنيه فعليًا في نقل الملفات: ينتقل ملفك مباشرةً من جهاز إلى آخر، لا صعودًا إلى خادم شركة ونزولًا منه. لا محطة في المنتصف يمكن أن تستقر فيها نسخة.

يبدو ذلك بسيطًا، لكن المسارات الفعلية تختلف. تشرح الصفحة أولًا WebRTC/ICE العام حيث يمكن أن يكون TURN احتياطيًا، ثم تميّز تنفيذ Relayium: WebRTC في المتصفح مباشر داخل شبكة LAN نفسها، وTURN مستخدم حسب التصميم عبر الشبكات، وCLI مباشرة فقط.

P2P مقابل الطريقة المعتادة: إلغاء المحطة الوسطى

تعمل معظم أدوات «إرسال ملف» بالرفع: يصعد ملفك من جهازك إلى خادم الشركة، ويُخزَّن هناك، ثم ينزّله الشخص الآخر منه. هذه قفزتان، ولبعض الوقت تستقر نسخة كاملة من ملفك على مساحة تخزين شخص آخر — حتى وإن حُذفت لاحقًا.

يتخطى النقل من الند للند تلك المحطة. فما إن يُفتح اتصال بين جهازك وجهاز الشخص الآخر حتى تتدفق بايتات الملف مباشرةً عبر تلك القفزة الواحدة ولا شيء غيرها. لا توجد نسخة على جانب الخادم لتُخزَّن أو تُؤمَّن أو تُحذَف في نهاية المطاف، لأنها لم تُرفع أصلًا.

النقل القائم على الرفع: من جهازك إلى خادم إلى جهازهم — قفزتان، ونسخة مُخزَّنة بينهما.
النقل من الند للند: من جهازك مباشرةً إلى جهازهم — قفزة واحدة، ولا شيء يُخزَّن.
لوضع Relayium الفوري في المتصفح مساران: يتصل WebRTC مباشرةً داخل شبكة LAN نفسها؛ وعبر الشبكات يحمل TURN حسب التصميم نصًا مشفّرًا من الطرف إلى الطرف بلا نسخة محتوى أو سجل فوري على الخادم.

كيف يعثر جهازان على بعضهما فعليًا: STUN

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

هذا هو الغرض من STUN (أدوات اجتياز الجلسة عبر NAT). يسأل كل جهاز خادم STUN صغيرًا خفيفًا سؤالًا واحدًا لوهلة: «من أي عنوان ومنفذ تراني قادمًا؟» فتخبره الإجابة بعنوانه المرئي للخارج — لا الملف، ولا أي محتوى، بل ما يكفي من معلومات الشبكة لوصف مسار العودة إليه. ويتبادل الجهازان هذه المعلومات (عبر خطوة إشارة لا تحمل سوى تفاصيل إعداد الاتصال، ولا تحمل بايتات الملف قط) ثم يحاولان فتح مسار مباشر إلى عنوان كل منهما. وفي حصة كبيرة من الحالات الواقعية — لا سيما جهازان على نفس شبكة Wi-Fi، أو أنواع NAT التي تتصرف على نحو متوقّع — ينجح ذلك، ويُفتح اتصال مباشر بالكامل.

لا يعرف STUN ويشارك سوى عناوين الشبكة — ولا يعرف قط محتويات الملفات أو أسماءها أو مفاتيح التشفير.
يستخدم Relayium تقنية WebRTC مباشرةً لجلسات المتصفح داخل شبكة LAN نفسها. أما مسار المتصفح عبر الشبكات فيُرحّل عمدًا.
تعمل أوامر send/receive وtext في Relayium CLI باتصال P2P مباشر فقط: فلا تُمرَّر بايتات الملفات أو الرسائل عبر TURN أو أي خادم Relayium آخر. وإذا تعذّر على الطرفين إنشاء اتصال مباشر، تفشل الجلسة بدل الرجوع إلى مُرحِّل.
جهازان على الشبكة نفسها (دون حاجة إلى رمز) يتصلان عادةً على النحو الأكثر مباشرةً بينها جميعًا، إذ لا يوجد غالبًا أي NAT يعترض الطريق.

حين يتعذّر العثور على مسار مباشر: مُرحِّل TURN

أحيانًا لا يكفي STUN. فبعض أنواع NAT — لا سيما على شبكات الشركات الأكثر صرامةً أو لدى بعض مشغّلي الهاتف المحمول — يصعب التنبؤ بها إلى حدٍّ يجعل من المستحيل اكتشاف مسار مباشر من المعلومات الخارجية وحدها. وإذا كان كلا الجهازين خلف هذا النوع من NAT، فإن الاتصال المباشر حقًا يكون ببساطة غير ممكن؛ ولا بد لشيء أن يُرحِّل حركة البيانات بينهما.

في تصميم WebRTC/ICE عام، يمكن أن يكون TURN مُرحِّلًا احتياطيًا عند فشل المسار المباشر. أما تطبيق Relayium في المتصفح فيختار بوضوح WebRTC المباشر داخل شبكة LAN نفسها وTURN منذ البداية لكل الجلسات عبر الشبكات. يُشفّر الملف من الطرف إلى الطرف قبل وصوله، فلا يحمل المُرحِّل إلا نصًا مشفّرًا ولا يستطيع قراءة المحتوى أو فك تشفيره.

على الشبكة نفسها يصل Relayium بين الأجهزة مباشرةً؛ أمّا عبر الشبكات فيستخدم مُرحِّل TURN افتراضيًّا، لأن المسار المباشر كثيرًا ما يتعذّر إيجاده هناك.
يمرّر المُرحِّل نصًا مُشفَّرًا فقط؛ ولا يملك قط مفتاح فك التشفير ولا يستطيع قراءة محتويات الملفات أو أسمائها أو أي شيء آخر عمّا بداخلها.
تعمل أوامر send/receive وtext في Relayium CLI باتصال P2P مباشر فقط: فلا تُمرَّر بايتات الملفات أو الرسائل عبر TURN أو أي خادم Relayium آخر. وإذا تعذّر على الطرفين إنشاء اتصال مباشر، تفشل الجلسة بدل الرجوع إلى مُرحِّل.

لماذا يهم هذا: الخصوصية والسرعة

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

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

كيف يجمع Relayium هذا كله

ما تحتاجه للتحقّق بنفسك

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

افتح relayium.com على جهازين على الشبكة نفسها فيعثر كل منهما على الآخر تلقائيًا في العادة — دون حساب ودون رمز ودون أي شيء يُثبَّت؛ تلك هي حالة الشبكة المحلية التي لا يكون STUN فيها ضروريًا غالبًا. أما الإرسال عبر الإنترنت إلى شخص على شبكة مختلفة فيستخدم رمز اقتران: يسجّل المُرسِل الدخول، ويولّد رمزًا (أو يشارك رابطًا، مع رمز QR اختياري للمسح)، وما إن ينضم الشخص الآخر حتى يجري النقل عبر مُرحِّل TURN مشفَّر — وهو المسار الموثوق عبر شبكات NAT التي يصعب التنبؤ بها، ولا يحمل إلا نصًا مُشفَّرًا — ويبقى المُستقبِل بلا حاجة إلى حساب.

عند فتح المسار الفوري، يتدفق ما يصل إلى 1000 ملف باستمرار عبر الطريق المختار ويُفحص كل ملف بـ SHA-256. لا يحتفظ Relayium بنسخة محتوى فورية أو سجل نقل على الخادم. وإذا كان الطرف الآخر غير متصل، فالرابط المُخزّن بمعرفة صفرية وضع منفصل.

والجهازان على شبكة Wi-Fi نفسها، افتح Relayium على كلٍّ منهما وأرسل الملف.
```
https://relayium.com/
```
اقرأ الوسم الذي يضعه التطبيق على الاتصال. على الشبكة نفسها يكتب «مباشر عبر LAN».
والآن ضع الجهازين على شبكتين مختلفتين وأرسل مرة أخرى، هذه المرة برمز اقتران.
```
https://relayium.com/cross-network
```
اقرأ الوسم مجددًا. «مباشر P2P» يعني أنه وُجد مسار مباشر عبر الإنترنت، و«مُرحَّل» يعني أنه لم يوجد، وأن المُرحِّل المشفَّر هو من حمل البايتات.
دوّن أيَّهما ظهر لك، وعلى أي زوج من الشبكات. فهذه إجابتك أنت عن السؤال الذي فتح به هذا المقال، لا إجابتنا نحن.

ماذا تخبرك هذه الأوسمة

على الشبكة نفسها تحصل على «مباشر عبر LAN». وعبر الشبكات تحصل إما على «مباشر P2P» وإما على «مُرحَّل»، وأيُّهما يتحدّد بالشبكتين ذاتيهما لا بشيء ضبطته أنت.

و«مُرحَّل» ليس فشلًا. بل يعني أن مسار الاحتياط موجود ويؤدّي عمله، وأن المُرحِّل لا يحمل طوال الوقت إلا نصًا مشفَّرًا — وهي بعينها الحالة التي يصفها قسم TURN في هذا المقال، لكن مرئية من الداخل.

حين لا يكون الوسم كما توقّعت

ثلاثة أمور تفاجئ الناس أول مرة ينظرون فيها. ولا أحد منها عيب يحتاج إصلاحًا، لكن كلًّا منها يستحق أن تعرف اسمه.

ما تراه، وما تفحصه، وماذا يعني

عبر الشبكات يظهر دائمًا «مُرحَّل» ولا يظهر «مباشر P2P» أبدًا.

https://relayium.com/cross-network   # the path label reads the same on both ends

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

على شبكة Wi-Fi واحدة لا يظهر «مباشر عبر LAN» إطلاقًا.

https://relayium.com/   # both devices on one Wi-Fi, and the path label never says LAN direct

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

لا يوجد أي وسم مسار على الإطلاق.

https://relayium.com/   # there is no path label until the two ends have connected

الوسم يسمّي اتصالًا، فهو يظهر متى وُجد اتصال. وقبل أن يعثر الطرفان على بعضهما لا يوجد ما يُسمّى، و«نقل لا يبدأ أصلًا» مشكلة مختلفة عن «نقل سلك مسارًا غير متوقَّع».

الأسئلة الشائعة

هل النقل من الند للند هو نفسه التشفير من الطرف إلى الطرف؟

هما مترابطان لكنهما ليسا متطابقين. يصف P2P الاتصال بين النهايات ولا يضمن أن تكون كل قفزة مباشرة؛ فقد يحمل TURN الحركة. ويحدد التشفير إن كان الوسيط يستطيع قراءتها. يستخدم Relayium WebRTC مباشرةً داخل شبكة LAN نفسها وTURN مشفّرًا من الطرف إلى الطرف عبر الشبكات، ولا يستطيع المُرحِّل قراءته أو فك تشفيره.

هل يمرّ النقل من الند للند بأي خادم على الإطلاق؟

يساعد خادم إشارة صغير الجهازين على العثور على عنوان كل منهما — لكنه لا يرى سوى معلومات إعداد الاتصال، ولا يرى بايتات الملف قط. وعبر الشبكات في المتصفح، يمرّر مُرحِّل TURN بيانات الملف المُشفَّرة بحكم التصميم، لكنه حتى حينئذٍ لا يتعامل إلا مع نص مُشفَّر لا يستطيع فك تشفيره.

لماذا قد يفشل الاتصال المباشر من الأساس؟

بعض الشبكات — غالبًا جدران الحماية الصارمة للشركات أو بعض أنواع NAT لدى مشغّلي الهاتف المحمول — مبنية على نحو يجعل من المستحيل اكتشاف عنوان يمكن الوصول إليه من المعلومات الخارجية وحدها. وبدل إنفاق نحو عشرين ثانية لاكتشاف ذلك في كل عملية نقل، يُمرِّر تطبيق Relayium في المتصفح كل عمليات النقل عبر الشبكات على المُرحِّل من البداية — فالذي يحملها هو المُرحِّل، لا محاولة اتصال مباشر فاشلة.

هل يكون النقل من الند للند أبطأ حين يمرّ عبر مُرحِّل؟

قد يضيف بعض زمن الاستجابة، إذ إن المُرحِّل قفزة إضافية تمر بها البيانات وهو خادم مشترك لا خادم مخصَّص. لكنه يظل أسرع عمومًا من أسلوب الرفع ثم التنزيل، إذ لا انتظار لاستقرار الملف كاملًا على خادم قبل أن يبدأ جانب التنزيل.

هل يحتاج الطرفان إلى حساب للنقل من الند للند؟

جهازان على الشبكة نفسها لا يحتاجان إلى حساب على الإطلاق. والإرسال عبر الشبكات برمز اقتران يتطلب أن يسجّل المُرسِل الدخول، أما الشخص المُستقبِل فلا يحتاج إلى حساب مطلقًا في كلتا الحالتين.

هل تريد التجربة؟ افتح Relayium على جهازين وابدأ جلسة فورية مشفّرة.

جرّب Relayium الآن