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

Source: https://help.strongfolder.com/ar/guides/how-webrtc-file-transfer-works/
Updated: 2026-11-05

> يعمل نقل الملفات عبر WebRTC على ثلاث مراحل. يعرّف خادم الإشارات متصفحين أحدهما على الآخر؛ ثم يجد STUN وICE مسارًا شبكيًا عبر أجهزة التوجيه المنزلية (NAT)، مع الرجوع إلى خادم ترحيل TURN إذا لم يوجد مسار مباشر؛ ثم يفتح المتصفحان قناة بيانات مشفّرة بـ DTLS وينقلان الملف على أجزاء، مباشرة أو عبر خادم الترحيل، دون تخزينه.

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

**Key facts**

- **WebRTC** معيار في المتصفحات للاتصالات المباشرة والمشفّرة بين جهازين؛ وتستخدم أدوات الملفات **قنوات البيانات** فيه.
- **الإشارات** تعرّف المتصفحين أحدهما على الآخر؛ و**STUN** و**ICE** يجدان مسارًا عبر أجهزة التوجيه (**NAT**)؛ و**خادم ترحيل TURN** يمرّر حركة المرور عندما لا يوجد مسار مباشر.
- **التشفير:** كل قناة بيانات تستخدم **DTLS** — لا يوجد في WebRTC وضع غير مشفّر.
- يستخدم StrongFolder مكتبة PeerJS فوق WebRTC، وخادم إشارات تابعًا لـ StrongFolder، وخوادم STUN عامة (منها خوادم Google)، وخوادم ترحيل TURN خاصة به. لا تُرفع الملفات أبدًا إلى خادم StrongFolder ولا تُخزَّن عليه.
- يتدفق الملف على أجزاء من قرص المرسل إلى قرص المستلم؛ ويبقى المرسل متصلًا.

## ما هو WebRTC؟

[WebRTC](https://help.strongfolder.com/en/glossary/#webrtc) (الاتصال الفوري عبر الويب) مجموعة من واجهات API في المتصفحات
وبروتوكولات الشبكة، وضعت معاييرها W3C وIETF، للاتصالات الفورية بين المتصفحات. تدعمه Chrome وEdge
وFirefox وSafari وOpera جميعها. بُني لمكالمات الفيديو والصوت، لكن فيه أيضًا **قنوات بيانات** تحمل
أي بيانات ثنائية — وهذا بالضبط ما هو الملف.

الخاصية الأساسية: بمجرد إعداد اتصال WebRTC، تنتقل البيانات **بين الطرفين**، لا إلى تخزين خادم.
وهذا ما يجعل [نقل الملفات P2P في المتصفح](https://help.strongfolder.com/en/guides/p2p-file-transfer/) ممكنًا.

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

لأن أي جهاز تقريبًا ليس له عنوان عام خاص به. حاسوبك المحمول خلف جهاز توجيه منزلي، أو جدار حماية
في المكتب، أو شبكة مشغّل اتصالات الهاتف. يجري جهاز التوجيه [NAT](https://help.strongfolder.com/en/glossary/#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 — الإشارات.** يختار المرسل الملفات؛ وتسجّل الخدمة البيانات الوصفية اللازمة للرابط.
عندما يفتح المستلم الرابط، يكون المتصفحان متصلين بخادم [إشارات](https://help.strongfolder.com/en/glossary/#signaling). لا يحدد
WebRTC كيفية عمل الإشارات؛ ويستخدم StrongFolder مكتبة PeerJS مع خادم إشارات خاص به.

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

**الخطوة 4 — STUN.** يسأل كل متصفح خادم [STUN](https://help.strongfolder.com/en/glossary/#stun): «من أي عنوان ومنفذ تراني آتيًا؟»
والجواب هو عنوانه العام كما يعيّنه جهاز التوجيه. تعالج خوادم STUN طلبًا صغيرًا ولا تتعامل مع أي
بيانات من الملفات؛ ويستخدم StrongFolder خوادم STUN عامة، منها خوادم Google، وخوادم خاصة به.

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

**الخطوة 6 — فحوص الاتصال.** يختبر [ICE](https://help.strongfolder.com/en/glossary/#ice) (إنشاء الاتصال التفاعلي) أزواج المرشحين
ويختار أفضل زوج يعمل. إذا كان الجهازان على Wi-Fi نفسها، يفوز المسار المحلي. وإذا سمحت أجهزة
التوجيه، يفوز مسار مباشر عبر الإنترنت («ثقب الجدار» أو hole punching). وإذا لم يعمل أي شيء مباشر،
يُستخدم المسار عبر خادم الترحيل.

**الخطوة 7 — DTLS.** قبل أن تتدفق أي بيانات، يُجري المتصفحان مصافحة [DTLS](https://help.strongfolder.com/en/glossary/#dtls)
(وهو TLS المكيّف لـ UDP) ويتحققان من أن بصمات الشهادات تطابق تلك الواردة في العرض والإجابة. ومن
الآن فصاعدًا يكون كل شيء مشفّرًا.

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

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

| المصطلح | ماذا يفعل | هل يرى بيانات الملفات؟ | المعيار |
|---|---|---|---|
| الإشارات (Signaling) | يمرّر العروض والإجابات والمرشحين بين المتصفحات | لا | غير موحّد (خاص بكل تطبيق) |
| NAT | ميزة في جهاز التوجيه تشارك عنوان IP عامًا واحدًا بين أجهزة كثيرة | — | — |
| STUN | يخبر المتصفح بعنوانه ومنفذه العامين | لا | IETF RFC 8489 |
| ICE | يجمع المرشحين ويختار مسارًا يعمل | لا | IETF RFC 8445 |
| TURN | يمرّر حركة المرور عندما لا يعمل أي مسار مباشر | حزمًا مشفّرة فقط | IETF RFC 8656 |
| DTLS | يشفّر الاتصال (TLS لـ UDP) | يشفّرها | IETF RFC 9147 (1.3)، RFC 6347 (1.2) |
| قناة بيانات SCTP | تسليم موثوق ومرتب للأجزاء | يحملها (مشفّرة) | IETF RFC 8831 |

كل هذه المصطلحات مشروحة باختصار في [مسرد المصطلحات](https://help.strongfolder.com/en/glossary/).

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

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

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

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

[أرسل الملفات الآن](https://strongfolder.com)
## ما مدى أمان تشفير WebRTC؟

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

وهناك تحفّظ صادق واحد ينطبق على كل خدمة WebRTC. يتحقق المتصفحان أحدهما من الآخر عبر **بصمات**
الشهادات التي تُتبادل عبر خادم الإشارات. ولذلك فأنت تثق في أن إشارات الخدمة لن تعبث بها. لهذا
يصف StrongFolder حمايته بأنها **تشفير أثناء النقل** — لا تشفير من طرف إلى طرف بمفاتيح تحتفظ بها
أنت، ولا «معرفة صفرية» (zero-knowledge). لنظرة أوسع على معنى «آمن»، اقرأ
[مشاركة الملفات بأمان](https://help.strongfolder.com/en/guides/secure-file-sharing/) و[الأمان والخصوصية](https://help.strongfolder.com/en/security/).

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

لأن متصفح المرسل *هو* المصدر. لا توجد نسخة على خادم يمكن الرجوع إليها: تقرأ قناة البيانات الأجزاء
من قرص المرسل فقط ما دامت علامة التبويب مفتوحة والجهاز مستيقظًا. يجب أن تبقى علامة تبويب المتصفح لدى المرسل مفتوحة ومتصلة حتى ينتهي المستلم من التنزيل — فالملفات تأتي من جهاز المرسل، لا من خادم. أما كيفية
التخطيط لذلك فمشروحة في [لماذا يبقى المرسل متصلًا](https://help.strongfolder.com/en/guides/why-sender-stays-online/).

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

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

## الخلاصة

نقل الملفات عبر WebRTC تفاوض قصير يتبعه تدفق طويل ومشفّر: تعرّف الإشارات المتصفحين أحدهما على
الآخر، ويجد STUN وICE مسارًا عبر NAT، ويمرّر TURN البيانات كملاذ أخير، وتحمل قنوات البيانات
المشفّرة بـ DTLS الملف من قرص إلى قرص. وللجانب العملي — ما يعنيه هذا لك كمرسل — ابدأ بـ
[نقل الملفات P2P في المتصفح](https://help.strongfolder.com/en/guides/p2p-file-transfer/) و[كيف يعمل StrongFolder](https://help.strongfolder.com/en/how-it-works/).

## FAQ

### ما هي قناة بيانات WebRTC؟

قناة البيانات هي الجزء من WebRTC الذي يحمل بايتات عشوائية بين متصفحين بدلًا من الصوت أو الفيديو. تعمل عبر SCTP فوق DTLS فوق UDP، لذا فهي مشفّرة ويمكن ضبطها لتكون موثوقة ومرتبة — وهذا ما يحتاجه نقل الملفات.

### ما الفرق بين STUN وTURN؟

خادم STUN يخبر المتصفح فقط بالشكل الذي يبدو عليه عنوانه العام، حتى يحاول المتصفحان الاتصال مباشرة؛ ولا تمر عبره أي بيانات من الملفات. أما خادم TURN فهو خادم ترحيل: عندما لا يعمل أي مسار مباشر، يمر التدفق المشفّر عبره. يشغّل StrongFolder خوادم ترحيل TURN خاصة به، تمرّر البيانات ولا تخزّنها.

### هل يرى خادم الإشارات ملفاتي؟

لا. يمرّر خادم الإشارات رسائل الاتصال فقط — أوصاف الجلسات والمرشحين الشبكيين — بين المتصفحين. أما بيانات الملفات فتتدفق عبر قناة البيانات، إما مباشرة أو عبر خادم ترحيل TURN.

### هل نقل الملفات عبر WebRTC مشفّر؟

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

### لماذا يفشل نقل WebRTC أحيانًا أو يبقى بطيئًا؟

عادةً بسبب المسار الشبكي: جدار حماية صارم أو VPN يحجب UDP المباشر، فيرجع الاتصال إلى خادم ترحيل TURN عبر TCP، أو لا يتمكن من الاتصال إطلاقًا. جرّب شبكة أخرى (مثل نقطة اتصال الهاتف)، أو أوقف الـ VPN، أو اطلب من قسم تقنية المعلومات السماح بـ WebRTC.

### هل يستطيع خادم ترحيل TURN قراءة ملفاتي؟

يمرّر خادم الترحيل حزمًا مشفّرة بـ DTLS بين المتصفحين. يرى حركة مرور مشفّرة وأحجامها وتوقيتها، لا محتوى الملف، وخادم الترحيل في StrongFolder لا يخزّن ما يمرّره.