استخدامات التورنت القانونية وتوزيع الملفات الكبيرة

في مقال كيف يعمل BitTorrent؟ شرحنا القطع والهاش وال Tracker وال DHT، ورأينا أن أكثر من ألف جهاز كانت تشارك ملف تثبيت Debian في لحظة واحدة، والسؤال الآن: أين يستخدم التورنت بشكل قانوني غير توزيعات Linux، ومتى يكون الأداة المناسبة لملف كبير داخل شركتك؟ وكثير من الناس يربطون الكلمة بالأفلام المقرصنة فقط، ولكن البروتوكول نفسه أداة لتوزيع الملفات الكبيرة على أجهزة كثيرة، وتستخدمه مشاريع ومؤسسات معروفة بشكل رسمي.

وهذا هو المقال الثاني في مرحلة التورنت ومشاركة الملفات P2P، وسوف نناقش في هذا المقال ما يلي:

• توزيعات Linux وأرشيف الإنترنت Internet Archive، وكيف يستخدمون التورنت بجانب HTTP.
• توزيع البرامج على آلاف السيرفرات داخل الشركة، كما فعلت Twitter بأداة Murder وFacebook في نشر الكود.
• متى لا يكون التورنت هو الحل المناسب.
• مختبر على Docker: Tracker خاص بأداة opentracker، وبذرة وأربعة أجهزة بعميل Transmission، نوزع فيه ملفاً حجمه 134 ميغابايت ونقيس الوقت وما رفعته البذرة، ثم نفسد قطعة ونرى كيف تصلح نفسها.
• ما الذي يجب أن تنتبه له إذا استخدمته في مؤسستك.

توزيعات Linux: التورنت بجانب سيرفرات التحميل

أشهر استخدام قانوني للتورنت هو توزيع ملفات تثبيت أنظمة التشغيل، فملف ISO حجمه مئات الميغابايتات أو عدة جيجابايتات، ويحمله آلاف الناس في يوم صدور الإصدار الجديد، وهذا بالضبط الحمل الذي يتعب سيرفرات التحميل:

• Debian: تنشر ملفات تورنت رسمية لكل ملفات التثبيت في صفحة التحميل بالتورنت، وتقول الصفحة إن التورنت يضع حملاً قليلاً على سيرفراتهم لأن الأجهزة ترفع لبعضها أثناء التحميل، وتطلب منك ترك العميل يعمل بعد انتهاء التحميل لتساعد غيرك، وقد فحصنا أحد هذه الملفات في المقال السابق.
• Ubuntu: صفحة طرق التحميل الأخرى فيها قسم BitTorrent بروابط تورنت لنسخ سطح المكتب والسيرفر، وتصف التورنت بأنه شبكة تحميل قد تعطيك سرعة أعلى وتحميلاً أكثر ثباتاً للملفات الكبيرة، ولدى Ubuntu أيضاً Tracker رسمي على torrent.ubuntu.com.

ولاحظ أن التوزيعتين لم تستبدلا HTTP بالتورنت، وإنما أضافتاه بجانبه، فمن يريد رابطاً مباشراً يأخذه، ومن يريد أن يخفف الحمل ويشارك يأخذ التورنت، وملف تورنت Debian نفسه فيه رابط HTTP للملف Webseed حتى لا يتوقف التحميل إذا لم يجد العميل أي جهاز.

أرشيف الإنترنت Internet Archive

أرشيف الإنترنت مكتبة رقمية غير ربحية تحفظ كتباً وتسجيلات وأفلاماً كثير منها في الملكية العامة Public Domain، وحسب صفحة المساعدة الخاصة بالتورنت فقد بدأ منذ صيف 2012 بتوزيع مجموعاته العامة عبر التورنت كإضافة إلى التحميل عبر HTTP، وتذكر الصفحة أن أكثر من 1.4 مليون عنصر متاح بهذه الطريقة، بمجموع يقارب البيتابايت من مواد الملكية العامة. والفكرة المهمة في طريقتهم أن ملفات التورنت عندهم تعتمد كثيراً على ال Webseeding، أي أن سيرفرات الأرشيف نفسها تعمل كبذرة عبر HTTP، فإذا لم يجد عميلك أي جهاز آخر حمل من سيرفراتهم مباشرة، وإذا وجد أجهزة أخذ منها وخفف الحمل عنهم.

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

داخل الشركات: نشر الكود على آلاف السيرفرات

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

• Twitter وأداة Murder (2010): نشرت Twitter أداة مفتوحة المصدر اسمها Murder، ويصفها ملف المشروع بأنها طريقة لاستخدام BitTorrent في توزيع الملفات على عدد كبير من السيرفرات في بيئة الإنتاج، من مئات إلى عشرات الآلاف، حيث لا تنجح أنظمة التوزيع المركزية. وفيها Tracker على سيرفر واحد، وبذرة عندها الملف المضغوط، وبقية السيرفرات تتبادل القطع، وكل سيرفر ينتهي يستمر في الرفع مدة قصيرة، 30 ثانية في الإعداد الافتراضي، حتى لا تصبح البذرة نقطة ضغط، والملف نفسه يذكر أن المشروع ما زال يعمل ولكنه لم يعد يصان.
• Facebook (2013): في ورقة Development and Deployment at Facebook المنشورة في مجلة IEEE Internet Computing، ذكر الباحثون أن الملف التنفيذي الذي ينشر حجمه قرابة 1.5 جيجابايت بما فيه سيرفر الويب والتطبيق، وأنه يصل إلى كل السيرفرات عبر BitTorrent المضبوط ليقلل الحركة بين المواقع بتفضيل الأجهزة في الرف Rack نفسه والمجموعة Cluster نفسها، وأن وصوله إلى كل السيرفرات يأخذ قرابة 20 دقيقة.

والصورة التالية تبين هذا الشكل من النشر:

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

متى لا يكون التورنت هو الحل؟

• عدد قليل من المستقبلين: إذا كان الملف يذهب إلى سيرفرين أو ثلاثة، فالأداة البسيطة مثل rsync أو التحميل من Object Storage أوضح وأسهل في التشغيل، والسبب أن فائدة التورنت تكبر مع عدد الأجهزة التي تحمل في الوقت نفسه، وسوف نرى ذلك بالأرقام في المختبر.
• ملفات صغيرة كثيرة تتغير باستمرار: كل تغيير يعني تورنتاً جديداً بهاش جديد، كما رأينا في أرشيف الإنترنت.
• مستخدمون على الإنترنت العام: هنا شبكة توصيل المحتوى CDN التي شرحناها في CDN للمبتدئين أنسب غالباً، لأن كثيراً من الشبكات وجدران الحماية تمنع منافذ التورنت، ولأن المستخدم العادي لا يريد تثبيت عميل تورنت.
• سياسة الأمن في شبكتك: كثير من فرق الأمن تمنع حركة P2P في شبكة الشركة، فإذا أردت استخدامه داخلياً فاتفق معهم على شبكة وTracker ومنافذ محددة، كما سنرى في نهاية المقال.

المختبر: Tracker خاص وأربعة أجهزة على Docker

الآن نجرب الفكرة بأنفسنا داخل جهاز واحد: Tracker خاص، وبذرة عندها ملف تجريبي، وثلاثة أجهزة تحمله في الوقت نفسه، وجهاز رابع ينضم بعدهم. ونستخدم opentracker، وهو Tracker مفتوح المصدر صغير جداً يقول موقعه إنه يهدف لأقل استهلاك للموارد حتى يعمل على راوتر Wi-Fi، وترخيصه في حزمة Alpine هو Beerware، ومع كل جهاز عميل Transmission بنسخة ال Daemon التي تعمل دون واجهة. وكل ما نوزعه في المختبر ملف من بيانات عشوائية صنعناه بأنفسنا، والصورة التالية تبين شكل المختبر:

ملفات المختبر

نبني Image واحدة فيها opentracker وTransmission، وكل الحزم مثبتة على إصدار محدد حتى تحصل على النتيجة نفسها، وهذا ملف Dockerfile:

# one small image for the tracker and the peers, every package pinned
FROM alpine:3.24
RUN apk add --no-cache \
      opentracker=0_git20210823-r2 \
      transmission-daemon=4.1.2-r0 \
      transmission-remote=4.1.2-r0 \
      transmission-extra=4.1.2-r0 \
      python3

في الإعداد أعلاه لاحظ التالي:

• حزمة opentracker في Alpine مبنية من نسخة الكود بتاريخ 23 أغسطس 2021، أما المشروع نفسه فقد أصدر النسخة 1.0 في الأول من يناير 2025 كما في صفحته، وفيها دعم IPv4 وIPv6 معاً في Tracker واحد، لذلك إذا بنيته لبيئة إنتاج فابنه من الكود المصدري بالإصدار الأحدث.
• الحزمة transmission-extra فيها الأدوات transmission-create وtransmission-show، وtransmission-remote هي الأداة التي تتحكم بها في ال Daemon من سطر الأوامر.

ثم ملف compose.yaml:

name: lab-torrent
x-peer: &peer
  image: lab-torrent-tools:1
  command: ["transmission-daemon", "--foreground", "--config-dir", "/config",
            "--no-dht", "--no-lpd", "--no-portmap", "--allowed", "127.0.0.1",
            "--download-dir", "/data", "--peerport", "51413"]

services:
  tracker:
    image: lab-torrent-tools:1
    container_name: lab-torrent-tracker
    command: ["opentracker", "-p", "6969", "-P", "6969"]
    ports:
      - "127.0.0.1:16969:6969"

  seed:
    <<: *peer
    container_name: lab-torrent-seed
    volumes: ["seed-data:/data", "./share:/share"]

  peer1:
    <<: *peer
    container_name: lab-torrent-peer1
    volumes: ["peer1-data:/data", "./share:/share"]

  peer2:
    <<: *peer
    container_name: lab-torrent-peer2
    volumes: ["peer2-data:/data", "./share:/share"]

  peer3:
    <<: *peer
    container_name: lab-torrent-peer3
    volumes: ["peer3-data:/data", "./share:/share"]

  solo:
    <<: *peer
    container_name: lab-torrent-solo
    volumes: ["solo-data:/data", "./share:/share"]

volumes:
  seed-data:  { name: lab-torrent-seed-data }
  peer1-data: { name: lab-torrent-peer1-data }
  peer2-data: { name: lab-torrent-peer2-data }
  peer3-data: { name: lab-torrent-peer3-data }
  solo-data:  { name: lab-torrent-solo-data }

في الإعداد أعلاه لاحظ التالي:

• كل الأجهزة تشترك في إعداد واحد عبر x-peer، ولكل جهاز Volume خاص به للبيانات، ومجلد share مشترك نضع فيه ملف التورنت والسكربت فقط، فالملف نفسه لا ينتقل إلا عبر التورنت.
• --no-dht و--no-lpd تغلق ال DHT واكتشاف الأجهزة في الشبكة المحلية Local Peer Discovery، و--no-portmap تمنع فتح المنافذ في الراوتر تلقائياً، فلا يجد الأجهزة بعضهم إلا عبر ال Tracker الخاص بنا.
• --allowed 127.0.0.1 تجعل واجهة التحكم RPC على المنفذ 9091 تقبل الطلبات من داخل ال Container فقط، ولم ننشر هذا المنفذ على الجهاز أصلاً.
• المنفذ الوحيد المنشور هو منفذ ال Tracker على 127.0.0.1:16969 حتى نقرأ إحصاءاته من الجهاز، وال opentracker يعمل على المنفذ 6969 عبر TCP وUDP كما في -p و-P.

وأخيراً السكربت share/fetch.sh الذي يضيف التورنت إلى جهاز وينتظر حتى يكتمل ويطبع الوقت:

#!/bin/sh
# fetch.sh <name>: add the torrent, wait until it is complete, print how long it took
hash=$(transmission-show /share/build-2026.10.torrent | awk '/Hash v1/ {print $3}')
start=$(date +%s)
transmission-remote -a /share/build-2026.10.torrent > /dev/null
until transmission-remote -t $hash -i | grep -q 'Percent Done: 100%'; do sleep 1; done
echo "$1: done in $(( $(date +%s) - start )) s"

التشغيل وإنشاء التورنت الخاص

chmod +x share/fetch.sh
docker build -t lab-torrent-tools:1 .
docker compose up -d
docker compose ps --format 'table {{.Name}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

والمخرج سوف يكون كما يلي:

NAME                  IMAGE                 STATUS         PORTS
lab-torrent-peer1     lab-torrent-tools:1   Up 6 seconds
lab-torrent-peer2     lab-torrent-tools:1   Up 5 seconds
lab-torrent-peer3     lab-torrent-tools:1   Up 4 seconds
lab-torrent-seed      lab-torrent-tools:1   Up 5 seconds
lab-torrent-solo      lab-torrent-tools:1   Up 7 seconds
lab-torrent-tracker   lab-torrent-tools:1   Up 4 seconds   127.0.0.1:16969->6969/tcp

الآن نصنع على البذرة ملفاً تجريبياً حجمه 128 ميغابايت يمثل إصداراً من تطبيقك، ثم ننشئ له تورنتاً خاصاً بالخيار -p وقطع حجمها 1 ميغابايت:

docker exec lab-torrent-seed sh -c 'head -c 134217728 /dev/urandom > /data/build-2026.10.tar && transmission-create -p -t http://lab-torrent-tracker:6969/announce -s 1024 -o /share/build-2026.10.torrent /data/build-2026.10.tar'
docker exec lab-torrent-seed transmission-show /share/build-2026.10.torrent

والمخرج سوف يكون كما يلي:

Creating torrent "/share/build-2026.10.torrent"
1 file, 134.2 MB
128 pieces, 1 MiB each
 done!
Name: build-2026.10.tar
File: /share/build-2026.10.torrent

GENERAL

  Name: build-2026.10.tar
  Hash v1: fc6c45ae7ea547c52d80654c7097deb8acf65257
  Created by: Transmission/4.1.2 (f234716f3e)
  Created on: Thu Oct 08 20:16:46 2026

  Piece Count: 128
  Piece Size: 1 MiB
  Total Size: 134.2 MB
  Privacy: Private torrent

TRACKERS

  Tier #1
  http://lab-torrent-tracker:6969/announce

FILES

  build-2026.10.tar (134.2 MB)

لاحظ السطر Privacy: Private torrent، أي أن القيمة private=1 داخل قسم info، فلن يعلن أي عميل هذا التورنت إلا لل Tracker الخاص بنا كما شرحنا في التورنت الخاص. ثم نضيف التورنت إلى البذرة، ونحدد سرعة الرفع عندها ب 2000 كيلوبايت في الثانية، أي 2 ميغابايت في الثانية:

docker exec lab-torrent-seed sh -c 'transmission-remote -a /share/build-2026.10.torrent && transmission-remote -t all -u 2000 && transmission-remote -l'

والمخرج سوف يكون كما يلي:

localhost:9091/transmission/rpc/ returned a successful response
localhost:9091/transmission/rpc/ returned a successful response
    ID    Done       Have  ETA              Up      Down  Ratio  Status       Name
     1    100%   134.2 MB  Done            0.0       0.0   0.00  Idle         build-2026.10.tar
Sum:             134.2 MB                  0.0       0.0

وقد يتساءل البعض: لماذا نحدد سرعة البذرة؟ والإجابة أن كل ال Containers على جهاز واحد، والشبكة بينها أسرع بكثير من أي شبكة حقيقية، فبدون حد للسرعة سوف ينتهي كل شيء في ثوان ولن نرى أي فرق، أما 2 ميغابايت في الثانية فتمثل سيرفر ملفات بخط محدود، وكل الأرقام التالية من الجهاز نفسه وبالإعداد نفسه، فهي للمقارنة بين الحالات وليست قياساً لسرعة التورنت عموماً.

ثلاثة أجهزة في الوقت نفسه

docker exec lab-torrent-peer1 /share/fetch.sh peer1 &
docker exec lab-torrent-peer2 /share/fetch.sh peer2 &
docker exec lab-torrent-peer3 /share/fetch.sh peer3 &
wait
for c in seed peer1 peer2 peer3; do echo "== $c"; docker exec lab-torrent-$c transmission-remote -t all -i | grep -E '^  (Downloaded|Uploaded|Ratio):'; done

والمخرج سوف يكون كما يلي:

peer3: done in 111 s
peer2: done in 112 s
peer1: done in 112 s
== seed
  Downloaded: None
  Uploaded: 203.0 MB
  Ratio: 1.51
== peer1
  Downloaded: 134.2 MB
  Uploaded: 66.72 MB
  Ratio: 0.49
== peer2
  Downloaded: 134.2 MB
  Uploaded: 65.42 MB
  Ratio: 0.48
== peer3
  Downloaded: 134.2 MB
  Uploaded: 67.85 MB
  Ratio: 0.50

في المخرج أعلاه لاحظ التالي:

• الأجهزة الثلاثة حملت 402.6 ميغابايت في المجموع (3 في 134.2)، ولكن البذرة رفعت منها 203.0 ميغابايت فقط، والباقي وهو قرابة 200 ميغابايت رفعته الأجهزة لبعضها، فكل جهاز رفع للآخرين قرابة نصف ما حمله.
• لو حملت الأجهزة الثلاثة الملف من سيرفر HTTP بالسرعة نفسها، لاحتاج السيرفر أن يرفع 402.6 ميغابايت بسرعة 2 ميغابايت في الثانية، أي قرابة 201 ثانية على الأقل حتى يكتمل آخر جهاز، وهذا رقم محسوب وليس قياساً، أما بالتورنت فاكتمل الثلاثة في 112 ثانية.

ونسأل ال opentracker عن إحصاءاته من الجهاز عبر المنفذ المنشور:

curl -s 'http://127.0.0.1:16969/stats?mode=everything' | head -n 40

والمخرج سوف يكون كما يلي (أول 40 سطراً):

<?xml version="1.0" encoding="UTF-8"?>
<stats>
  <tracker_id>1947370276</tracker_id>
  <version>
0_git20210823
  </version>
  <uptime>131</uptime>
  <torrents>
    <count_mutex>1</count_mutex>
    <count_iterator>1</count_iterator>
  </torrents>
  <peers>
    <count>4</count>
  </peers>
  <seeds>
    <count>4</count>
  </seeds>
  <completed>
    <count>3</count>
  </completed>
  <connections>
    <tcp>
      <accept>8</accept>
      <announce>7</announce>
      <scrape>0</scrape>
    </tcp>
    <udp>
      <overall>0</overall>
      <connect>0</connect>
      <announce>0</announce>
      <scrape>0</scrape>
      <missmatch>0</missmatch>
    </udp>
    <livesync>
      <count>0</count>
    </livesync>
  </connections>
  <debug>
    <renew>
      <count interval="00">0</count>

ال Tracker يعرف تورنتاً واحداً وأربعة أجهزة كلها أصبحت تملك الملف كاملاً، وثلاثة تحميلات اكتملت، وسبعة طلبات Announce عبر TCP، ولم يمر عليه أي بايت من الملف نفسه، فهو كما قلنا في المقال السابق يعرف من يملك ماذا فقط.

جهاز رابع ينضم إلى سرب جاهز

الآن الأجهزة الثلاثة أكملت وأصبحت بذوراً، فماذا يحدث إذا انضم جهاز جديد؟

docker exec lab-torrent-solo /share/fetch.sh solo
for c in seed solo; do echo "== $c"; docker exec lab-torrent-$c transmission-remote -t all -i | grep -E '^  (Downloaded|Uploaded|Ratio):'; done

والمخرج سوف يكون كما يلي:

solo: done in 26 s
== seed
  Downloaded: None
  Uploaded: 230.7 MB
  Ratio: 1.71
== solo
  Downloaded: 134.2 MB
  Uploaded: None
  Ratio: 0.00

الجهاز الجديد حمل الملف كاملاً في 26 ثانية، مع أن البذرة محددة بسرعة 2 ميغابايت في الثانية، والسبب أن البذرة رفعت له 27.7 ميغابايت فقط (230.7 ناقص 203.0)، والباقي جاءه من الأجهزة الثلاثة. وهذا ما يحدث في نشر الكود داخل الشركات: كل سيرفر ينتهي يصبح مصدراً، فالسيرفرات التي تبدأ متأخرة تنتهي أسرع.

جهاز واحد مع البذرة فقط

للمقارنة نوقف التورنت في الأجهزة الثلاثة، ونحذف التورنت وبياناته من الجهاز الرابع، ثم نعيد التحميل عليه، فلا يبقى له مصدر إلا البذرة:

for c in peer1 peer2 peer3; do docker exec lab-torrent-$c transmission-remote -t all --stop > /dev/null; done
docker exec lab-torrent-solo transmission-remote -t all --remove-and-delete > /dev/null
until [ "$(docker exec lab-torrent-solo transmission-remote -l | wc -l)" = 2 ]; do sleep 1; done
sleep 4
docker exec lab-torrent-solo /share/fetch.sh solo
docker exec lab-torrent-seed transmission-remote -t all -i | grep -E '^  Uploaded'

والمخرج سوف يكون كما يلي:

solo: done in 78 s
  Uploaded: 365.0 MB

جهاز واحد مع البذرة وحدها احتاج 78 ثانية، والبذرة رفعت له 134.3 ميغابايت (365.0 ناقص 230.7)، أي الملف كاملاً. والحد النظري هو 134.2 ميغابايت مقسومة على 2 ميغابايت في الثانية، أي قرابة 67 ثانية، والفرق وقت الاتصال بال Tracker وبداية التحميل. والصورة التالية تجمع الحالات كلها:

ولاحظ أن ثلاثة أجهزة معاً احتاجت 112 ثانية وجهازاً واحداً احتاج 78 ثانية، فالتورنت لم يجعل الثلاثة بسرعة الواحد، لأن الأجهزة في البداية لا تملك قطعاً تتبادلها، والبذرة وحدها هي المصدر، ولكنه جعل الحمل على البذرة أقل من نصف ما كان سيحمله سيرفر HTTP، والفرق يكبر كلما زاد عدد الأجهزة، وهذا هو الرقم الذي يهم من يوزع على آلاف السيرفرات.

نفسد قطعة ونرى كيف تصلح

الآن نغير بايتاً واحداً في نسخة peer1 عند الموقع 70000000، ثم نطلب من Transmission أن يتحقق من الملف:

docker exec lab-torrent-peer1 sh -c 'printf "X" | dd of=/data/build-2026.10.tar bs=1 seek=70000000 conv=notrunc 2>/dev/null; transmission-remote -t all --verify >/dev/null; sleep 4; transmission-remote -l; transmission-remote -t all -i | grep -E "^  (Have|Percent Done)"'

والمخرج سوف يكون كما يلي:

    ID    Done       Have  ETA              Up      Down  Ratio  Status       Name
     1   99.2%   133.2 MB  Unknown         0.0       0.0   0.67  Stopped      build-2026.10.tar
Sum:             133.2 MB                  0.0       0.0
  Percent Done: 99.2%
  Have: 133.2 MB (133.2 MB verified)

النسبة نزلت من 100% إلى 99.2%، وهي قطعة واحدة من 128 (127 مقسومة على 128 تساوي 99.2%)، وهي القطعة رقم 66 لأن 70000000 مقسومة على 1048576 تقع فيها. ثم نشغل التورنت مرة أخرى وننتظر حتى يكتمل:

docker exec lab-torrent-peer1 sh -c 'transmission-remote -t all --start >/dev/null; until transmission-remote -t all -i | grep -q "Percent Done: 100%"; do sleep 1; done; transmission-remote -l; transmission-remote -t all -i | grep -E "^  (Have|Downloaded)"'

والمخرج سوف يكون كما يلي:

    ID    Done       Have  ETA              Up      Down  Ratio  Status       Name
     1    100%   134.2 MB  Done            0.0     524.3   0.67  Idle         build-2026.10.tar
Sum:             134.2 MB                  0.0     524.3
  Have: 134.2 MB (134.2 MB verified)
  Downloaded: 135.3 MB

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

تنظيف المختبر

من داخل مجلد المختبر نحذف ال Containers والشبكة وال Volumes بالاسم، ثم ال Image التي بنيناها:

docker compose down -v
docker image rm lab-torrent-tools:1
docker ps -a --filter name=lab-torrent --format '{{.Names}}'

والأمر الأخير لا يطبع شيئاً، أي أنه لم يبق أي Container من المختبر.

إذا استخدمته في مؤسستك

• اجعل ال Tracker داخلياً: لا تنشر منفذه على الإنترنت، وضعه في شبكة لا يصل إليها إلا السيرفرات التي توزع عليها كما في تقسيم الشبكة. والسبب أن opentracker بالإعداد الافتراضي يتتبع أي تورنت يعلن له، وصفحته تذكر أن قصره على قائمة محددة من ال Info Hashes يحتاج بناءه بخيار WANT_ACCESSLIST_WHITE مع ملف القائمة.
• استخدم التورنت الخاص: بالخيار -p كما في المختبر، وأغلق ال DHT واكتشاف الشبكة المحلية في العملاء، حتى لا يعلن أي سيرفر ملفات الشركة خارج ال Tracker الخاص بكم.
• لا تنشر واجهة التحكم: منفذ RPC في Transmission يتحكم في التحميل والحذف، فاجعله على 127.0.0.1 أو خلف مصادقة.
• ضع حداً للسرعة: في ساعات العمل حتى لا يأخذ النشر خط الفرع البعيد كله، وTransmission يدعم حدوداً للرفع والتحميل كما فعلنا.
• التورنت يضمن سلامة النقل وليس الثقة في المصدر: الهاش يثبت أن الملف لم يتغير بعد إنشاء التورنت، ولكنه لا يثبت من أنشأه، لذلك وقع ملف الإصدار أو وزع ملف التورنت نفسه من مكان موثوق.

وسوف نتناول في مقالات مخططة في مرحلة التورنت تشغيل qBittorrent بواجهة ويب على السيرفر، وبناء Tracker خاص لمؤسستك مع opentracker بالتفصيل، ومشاركة الملفات من المتصفح مع WebTorrent، والأمان والخصوصية مع التورنت.

تدريب عملي

• أعد المختبر مع جهازين بدل ثلاثة ثم مع خمسة، وسجل في كل مرة ما رفعته البذرة ووقت آخر جهاز، وارسم العلاقة بين عدد الأجهزة وحمل البذرة.
• غير حجم القطعة إلى 4 ميغابايت بالخيار -s 4096، ثم أفسد بايتاً كما فعلنا، ولاحظ كم زاد ما أعاد العميل تحميله.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• التورنت تقنية قانونية تستخدمها Debian وUbuntu لتوزيع ملفات التثبيت، وأرشيف الإنترنت لتوزيع مواد الملكية العامة، دائماً بجانب HTTP وليس بدلاً منه.
• داخل الشركات استخدمته Twitter بأداة Murder لنشر الكود على مئات إلى عشرات الآلاف من السيرفرات، وFacebook لنشر ملف بحجم 1.5 جيجابايت في قرابة 20 دقيقة.
• في المختبر حملت ثلاثة أجهزة 402.6 ميغابايت ورفعت البذرة منها 203.0 ميغابايت فقط، وجهاز انضم بعدهم اكتمل في 26 ثانية بدل 78.
• القطعة الفاسدة تكتشف بالتحقق ويعاد تحميلها وحدها، وفي المختبر كلف ذلك قرابة 1 ميغابايت فقط.
• لا يناسب التورنت عدداً قليلاً من المستقبلين، ولا الملفات التي تتغير باستمرار، ولا المستخدمين على الإنترنت العام غالباً.
• في المؤسسة اجعل ال Tracker داخلياً، والتورنت خاصاً، وواجهة التحكم مغلقة، والسرعة محدودة، ووقع ملفاتك.

دليلكيف يعمل BitTorrent؟ شرح التورنت للمبتدئينكيف يقسم التورنت الملف إلى قطع ويتحقق منها بالهاش، وكيف يجد جهازك الأجهزة الأخرى التي تشارك الملف دون سيرفر مركزي.دليلكيف تعمل شبكة توصيل المحتوى CDN وما الذي تحفظهلماذا يبطؤ موقعك على الزائر البعيد، وكيف تقرب شبكة CDN ملفاتك منه، وكيف تمنعها من حفظ الصفحات الخاصة.دليلتقسيم الشبكة Network Segmentation بال VLAN وال VPCلماذا تصل كاميرا مخترقة إلى قاعدة بياناتك، وكيف تمنع ذلك بتقسيم الشبكة إلى مناطق لا يمر بينها إلا ما تسمح به.دليلتثبيت Docker Engine وCompose على Ubuntuكيف تثبت Docker على Ubuntu من المستودع الرسمي، وتضبطه من البداية حتى لا يمتلئ القرص أو تنكشف منافذك للإنترنت.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتنفيذ المختبر على opentracker (حزمة Alpine 0_git20210823-r2) وTransmission 4.1.2 في Image مبنية على alpine:3.24، وDocker Engine 29.8.0 وDocker Compose v5.5.1 على Windows 11 مع Docker Desktop.