بروتوكولات نقل الملفات من Kermit إلى rsync

سبب استمرار تغيّر بروتوكولات نقل الملفات

صُمّم كل بروتوكول لنقل الملفات استجابةً لنمط الفشل الذي كان سائداً في عقده الخاص. افترض Kermit أن الخط سيتسبب في إفساد وحدات البايت. وافترض XMODEM وZMODEM أن الاتصال بطيء وأنك تدفع مقابل كل دقيقة. وافترض FTP (بروتوكول نقل الملفات) أن الشبكة الوسيطة ستتعاون. أما SSH فافترض أنها معادية. هذا هو الافتراض الذي انتصر، ولذلك يوفّر لك VPS اليوم SFTP وrsync عبر SSH، ولا يوفّر الكثير غير ذلك.

يوجد سبب للنظر في هذا الموضوع الآن. أُصدر C-Kermit 11.0.506 في 3 August 2026. وهو أول إصدار غير تجريبي منذ C-Kermit 9.0.302 في 20 August 2011، مع أن البروتوكول الذي ينفّذه صُمّم في May 1981. تكفي مدة خمسة وأربعين عاماً لمتابعة ظهور فئة كاملة، وتوحيدها معيارياً، ثم تضررها بسبب الشبكة التي كانت تعمل عليها، وأخيراً استيعابها ضمن SSH.

Kermit، 1981: صُمِّم لخط يبتلع وحدات البايت

أُنشئ Kermit في مايو 1981 في مركز الحاسوب بجامعة Columbia على يد Frank da Cruz وBill Catchings. جاء الاسم من Kermit the Frog. يذكر da Cruz أن تقويم Muppets كان معلّقاً على الحائط بينما كانت المجموعة تحاول ابتكار اسم، ولم يتوقع أحد أن ينتشر هذا البرنامج.

لم تكن المشكلة التي حلّها Kermit هي السرعة. لم يكن المسار بين الطرفية والحاسوب المركزي قناةً لتمرير وحدات بايت عشوائية. كان جهاز محارف يفرض قيوده الخاصة. قد يكون 7-bit. وقد يعمل بنمط half-duplex. وقد يبتلع محارف التحكم، أو ينفّذ أحدها كأمر. لذلك لم يكن إرسال ملف ثنائي عبره دون تعديل ممكناً.

لذلك التزم التصميم بهذه القيود حرفياً. ويسرد تاريخ Kermit Project نفسه هذه القيود:

• حزم قصيرة، لأن معظم الحواسيب المركزية لم تكن تستطيع استقبال دفعات طويلة من البيانات الواردة من طرفية
• نمط half-duplex يعتمد على التوقف والانتظار، لأن حواسيب IBM المركزية لم تكن تدعم الاتصال بنمط full-duplex
• ترميزات قابلة للطباعة لمحارف التحكم والمحارف ذات 8 بت، لأن أياً منهما لم يكن يستطيع المرور عبر مشغّل الطرفية في الحاسوب المركزي
• مجموع تحقق لكل حزمة، يرد عليه المستقبل، بحيث تؤدي الحزمة التالفة إلى إعادة إرسال واحدة بدلاً من إعادة إرسال الملف

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

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

أنهت Columbia رعايتها في 2011، وأصدرت C-Kermit بموجب رخصة BSD المعدّلة ذات البنود الثلاثة. واصل Frank da Cruz العمل في المشروع لمدة 44 عاماً، من تصميم 1981 حتى 2025. ويتولى مشروع OpenKermit صيانة إصدار 2026، بينما يعمل John Goerzen على تحديث قاعدة شيفرة C أقدم من معظم الأشخاص الذين يقرؤونها الآن.

XMODEM وZMODEM: عندما شكّلت تكلفة الهاتف التصميم

كتب Ward Christensen الملف MODEM.ASM في عام 1977، والبروتوكول الذي قدّمه هو XMODEM. وفي عام 1978، أتاح هو وRandy Suess نظام CBBS عبر الإنترنت، وكان أول نظام عام للوحات النشرات. توفي Christensen في 11 October 2024.

يُعد XMODEM من أصغر البروتوكولات الممكنة تقريباً. تنتقل البيانات في كتل حجم كل منها 128 بايت. تحمل كل كتلة مجموع تحقق من بايت واحد، وهو مجموع بايتات البيانات الـ128 محسوباً modulo 256. يقرّ المستقبل باستلام كل كتلة أو يطلب إرسالها مجدداً. يعود هذا التصميم إلى أسباب اقتصادية. في خط الاتصال الهاتفي، تدفع مقابل الوقت، لذلك يجب أن يكلّف خطأ في الاتصال كتلة واحدة بدلاً من كامل عملية النقل.

وتظهر نقطة الضعف في الجملة نفسها. ينتظر XMODEM إقراراً بعد كل 128 بايت. عبّر Chuck Forsberg عن ذلك بوضوح في مواصفة ZMODEM: "يتسبب قِصر طول الكتلة في انخفاض معدل النقل عند استخدامها مع أنظمة تقاسم الوقت، وشبكات تبديل الحزم، ودوائر الأقمار الصناعية." زمن الاستجابة هو ما يعيق أسلوب التوقف والانتظار، وليس عرض النطاق الترددي. كل رحلة ذهاب وإياب تعني وقتاً خاملاً على خط تُحاسب على استخدامه.

جاء YMODEM بعد ذلك، وصاغ Ward Christensen الاسم في عام 1985. وتمثّل إسهامه في النقل الدفعي. يرسل المرسل اسم الملف وحجمه قبل البيانات، لذلك يمكن نقل عدة ملفات في جلسة واحدة، ويعرف المستقبل موضع نهاية كل ملف.

ZMODEM هو إجابة Chuck Forsberg، وقد كتبه في Omen Technology. تحمل المواصفة رقم المراجعة 14 October 1988، وتنص على أن "ZMODEM طُوّر للملك العام بموجب عقد مع Telenet". كانت Telenet تدير شبكة عامة لبيانات تبديل الحزم، ويظهر أثر ذلك العقد في التصميم. يتجاوز ZMODEM محارف التحكم الخاصة بالشبكة، حتى لا تستهلكها شبكة حزم تقع في الوسط. ويحدّد بداية كل إطار بتسلسل محارف فريد بدلاً من استنتاج حدود الإطار من الصمت، ولذلك يتعافى من التشويش دون انتظار انتهاء مهلة. كما يوفّر استئنافاً صريحاً، بحيث تبدأ عملية النقل المتوقفة من الموضع الذي توقفت عنده.

والأهم أنه يتوقف عن الانتظار. تصف المواصفة ذلك بقولها إن "ZMODEM يستخدم الملف بأكمله فعلياً كنافذة". يرسل المرسل البيانات باستمرار، ولا يتوقف إلا عندما يبلغه المستقبل بوجود مشكلة. وهذه هي الفكرة نفسها التي يعبّر عنها TCP في نافذته، لكن من الاتجاه المعاكس، بعدما راقب شخص مودماً خاملاً.

لماذا تقادمت اتصالات FTP الثنائية بهذا السوء

FTP أقدم من كل ذلك. يعود تاريخ RFC 114، بعنوان "بروتوكول نقل الملفات"، إلى 16 April 1971، وكتبه A. Bhushan.

التفصيل المهم هو أن RFC 114 درس تصميم الاتصالين ورفضه. قيّم Bhushan خيار "استخدام رابطين مزدوجي الاتجاه بالكامل، أحدهما لمعلومات التحكم والآخر للبيانات"، ثم خلص إلى ما يلي: "نوصي باستخدام اتصال واحد مزدوج الاتجاه بالكامل لتبادل البيانات ومعلومات التحكم معاً." ظهر الفصل لاحقاً. ينص RFC 354، المؤرخ في 8 July 1972، على أن "البيانات والملفات تُنقل عبر اتصال البيانات فقط"، بينما تنتقل الأوامر عبر اتصال Telnet منفصل. أما RFC 959، الصادر في October 1985 بقلم Postel وReynolds، فهو الإصدار الذي لا يزال الجميع يطبّقه.

ثبّت RFC 959 المنافذ أيضاً. منفذ البيانات الافتراضي للخادم هو "المنفذ المجاور لمنفذ اتصال التحكم، أي L-1"، وهو المنفذ 20 عندما يكون اتصال التحكم على المنفذ 21.

الجزء الذي لم يصمد هو الآتي. في وضع FTP الأصلي، يفتح الخادم اتصال البيانات عائداً إلى العميل. لا يملك العميل الموجود خلف NAT (ترجمة عناوين الشبكة) عنواناً يمكن للخادم الوصول إليه، كما أن العميل الموجود خلف جدار ناري لا يقبل الاتصالات الواردة. لذلك لا يصل اتصال البيانات، وتتعطل عملية النقل فور طلب قائمة أو ملف. كان الحل هو PASV، الذي يعرّفه RFC 959 بأنه طلب من الخادم "أن يستمع على منفذ بيانات، ليس منفذ البيانات الافتراضي، وأن ينتظر اتصالاً بدلاً من البدء به عند تلقي أمر نقل". يرد الخادم بالعنوان والمنفذ اللذين يجب الاتصال بهما:

PASV
227 Entering Passive Mode (203,0,113,10,195,80)

تعني هذه الاستجابة أن المضيف هو 203.0.113.10، وأن المنفذ هو 195 مضروباً في 256 زائد 80، أي 50000. أعد قراءة ذلك، وستظهر المشكلة البنيوية. تُعلَن نقطة نهاية الاتصال الثاني داخل حمولة الاتصال الأول. لا يستطيع جهاز NAT أو الجدار الناري تمرير ذلك الاتصال إلا إذا حلّل قناة التحكم وفتح المنفذ الذي يراه فيها. يتضمن Linux مساعداً لتتبّع الاتصالات ينفّذ ذلك تحديداً. لا يعمل هذا المساعد إلا عندما يكون اتصال التحكم بنص واضح، لذلك يؤدي تغليف FTP باستخدام TLS (أمان طبقة النقل) إلى حجب المعلومات عن الوسيط الشبكي الذي كان يجعل FTP قابلاً للاستخدام.

هذا هو الدرس المستخلص من FTP في جملة واحدة. فقد جعل الشبكة طرفاً مشاركاً في البروتوكول. ولا يستطيع بروتوكول يحتاج إلى فهم الشبكة له أن يصمد أمام شبكة تتوقف عن الوثوق به.

النهاية موثقة. أزال Firefox دعم FTP في الإصدار 90 في July 2021. وأزال Chrome شيفرة FTP في Chrome 95 في October 2021.

rcp وأوامر r: الثقة حسب اسم المضيف

جلبت 4.2BSD، التي أصدرتها Berkeley عام 1983 بتمويل من DARPA، الأوامر rcp وrsh وrlogin. صُممت هذه الأوامر لحرم جامعي يضم أجهزة Unix على شبكة واحدة، ويُظهر نموذج المصادقة ذلك بوضوح. كان أحد المضيفين يصرّح بالمستخدم الذي يجري الاتصال. إذا أفاد /etc/hosts.equiv أو ملف ~/.rhosts الخاص بالمستخدم بأن ذلك المضيف موثوق، قُبل التصريح ولم يُطلب أي كلمة مرور.

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

أصاب rcp في تصميم الواجهة. مصدر ووجهة، ثم انتهاء العملية. لا توجد جلسة لفتحها، ولا وضع نقل للتفاوض عليه، ولا اتصال ثانٍ لإنشائه. إنه يتصرف مثل cp مع نقطتين في المسار. وقد استمرت هذه الواجهة أربعة عقود بعد انتهاء صلاحية البروتوكول.

SSH يستوعب الفئة بأكملها

في عام 1995، كتب Tatu Ylonen، الذي كان آنذاك باحثاً في Helsinki University of Technology، بروتوكول SSH رداً على هجوم لالتقاط كلمات المرور على شبكة الجامعة. وأصدره كبرمجية حرة مع الشيفرة المصدرية في يوليو 1995. وبحلول نهاية ذلك العام، قُدّر عدد المستخدمين بنحو 20,000 مستخدم في 50 دولة، وفي ديسمبر 1995 أسس SSH Communications Security لمواصلة تطويره.

أصبحت الرخصة أكثر تقييداً في الإصدارات اللاحقة، لذلك اشتق مطورو OpenBSD آخر إصدار مرخّص بحرية، وهو ssh 1.2.12. أُدخل الإصدار الأول في 26 سبتمبر 1999، وصدر OpenSSH 1.2.2 مع OpenBSD 2.6 في 1 ديسمبر 1999. يمثّل هذا الاشتقاق حالة مختصرة توضّح لماذا تهم شروط تراخيص البرمجيات مفتوحة المصدر عملياً، لأن تطبيق SSH الذي يشغّله معظم الناس اليوم ينحدر من الإصدار الوحيد الذي كانت رخصته لا تزال تسمح بذلك.

بعد ظهور SSH، لم يعد نقل الملفات مشكلة منفصلة. يوفّر تدفق موثّق ومشفّر يحمل قنوات متعددة ما كانت البروتوكولات الأقدم تحتاج إلى بنائه بنفسها: سلامة البيانات، وترتيبها، ومسار بيانات ثانياً لا يحتاج إلى اتصال TCP ثانٍ. إذا كانت هذه الآليات جديدة عليك، فابدأ بفهم ماهية SSH فعلياً قبل المتابعة.

نتجت عنه أداتان. كان scp بروتوكول rcp السلكي الذي يعمل داخل جلسة SSH، ولذلك ورث واجهة سطر أوامر rcp كما هي تماماً. أما SFTP فهو تصميم مختلف: بروتوكول ملفات فعلي يوفّر عرض محتويات الأدلة، وسمات الملفات، والوصول العشوائي، وينقل ذلك عبر قناة SSH. لم يصبح SFTP معيار RFC قط. بلغ مسودّة IETF، draft-ietf-secsh-filexfer، الإصدار 13 في 18 يوليو 2006، ثم انتهت صلاحيتها. يطبّق OpenSSH الإصدار 3 من تلك المسودّة. إن أكثر بروتوكولات نقل الملفات الآمنة استخداماً في العالم هو مراجعة مرقّمة لمسودّة متروكة، ومع ذلك فهو يعمل.

أُحيل بروتوكول scp القديم إلى التقاعد أيضاً. حذّر OpenSSH 8.8، الذي صدر في 26 سبتمبر 2021، من أن «إصداراً قريباً من OpenSSH سيحوّل scp(1) من استخدام بروتوكول scp/rcp القديم إلى استخدام SFTP افتراضياً». ونفّذ OpenSSH 9.0، الذي صدر في 8 أبريل 2022، ذلك فعلاً: «يحوّل هذا الإصدار scp(1) من استخدام بروتوكول scp/rcp القديم إلى استخدام بروتوكول SFTP افتراضياً».

تفسّر هذه النقطة سبباً من أسباب الاعتقاد الشائع. كان بروتوكول scp القديم يوسّع أحرف البدل في أسماء الملفات البعيدة عبر تمريرها إلى الصدفة البعيدة، ولذلك تعلّم المستخدمون وضع علامات اقتباس مزدوجة حول كل محرف خاص في المسار البعيد. وتقول ملاحظات الإصدار 8.8 إن scp عبر SFTP «لم يعد يتطلب وضع علامات الاقتباس الدقيقة والهشة هذه». لذلك، على خادم حالي، يُعد scp عميلاً لـSFTP يستخدم واجهة سطر أوامر rcp. لقد صمدت الواجهة منذ عام 1983، أما بروتوكول النقل منذ عام 1983 فلم يصمد.

rsync، 1996: أرسل الفرق لا الملف

أعلن Andrew Tridgell وPaul Mackerras عن rsync في 19 يونيو 1996 في الجامعة الوطنية الأسترالية، بالتزامن مع التقرير التقني TR-CS-96-05 بعنوان "خوارزمية rsync".

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

تستحق الآلية الفهم لأنها تفسّر سلوك rsync. يقسّم المستقبل نسخته الموجودة إلى كتل ذات حجم ثابت، ويحسب قيمة checksum لكل كتلة باستخدام خوارزميتين: واحدة ضعيفة ورخيصة، وأخرى قوية ومكلفة. ثم يرسل هذه القائمة إلى المرسل. يحرّك المرسل نافذة فوق ملفه بايتاً واحداً في كل مرة، ويحدّث قيمة checksum الضعيفة بشكل تزايدي. وهذا ما يجعل الفحص بايتاً ببايت قابلاً للتنفيذ عملياً. بعد ذلك يُتحقق من التطابق الضعيف باستخدام checksum القوية. وتتحول التطابقات المؤكدة إلى مراجع للكتل. أما كل ما عدا ذلك فيُرسل كـliteral bytes. يعيد المستقبل بناء الملف من مراجع إلى الكتل الموجودة لديه ومن الـliteral bytes التي استلمها للتو.

إذا أُدرج بايت واحد في بداية ملف كبير، فعلى أداة فرق ساذجة إرسال الملف بأكمله لأن كل offset تغيّر. تعثر نافذة التمرير على الكتل نفسها عند offsets الجديدة، لذلك يرسل rsync بايتاً واحداً إضافة إلى بيانات الإدارة. ولهذا السبب لا يزال rsync الأداة المناسبة لدليل ستنسخه أكثر من مرة.

هناك سلوكان يفاجئان المستخدمين بانتظام، وكلاهما موثق في الدليل. أولاً، لا يحسب rsync checksum للملفات ليقرر ما إذا كان سيفحصها. بل "يعثر على الملفات التي تحتاج إلى نقل باستخدام خوارزمية 'فحص سريع' (افتراضياً)، تبحث عن الملفات التي تغيّر حجمها أو وقت آخر تعديل لها". إذا تغيّرت محتويات ملف مع بقاء حجمه وطابعه الزمني متطابقين، فسيُتخطى الملف. يغيّر --checksum ذلك، ويجعل الطرفين يقرآن كل ملف مرشح بالكامل. ثانياً، تكون خوارزمية delta معطّلة افتراضياً عندما يكون المساران محليين، لأن قراءة نسختين وحساب checksum لهما على جهاز واحد تكلف أكثر من نسخ البايتات. لا يتحقق التوفير إلا عندما يكون الرابط هو الجزء البطيء.

ما الذي ستستخدمه فعلياً على VPS، ولماذا

باختصار: استخدم SFTP لبضعة ملفات، وrsync عبر SSH لدليل ستنسخه مرة أخرى.

يعمل كلاهما عبر SSH، ولذلك يرثان التحقق من مفاتيح المضيف والتشفير من دون إعداد إضافي. هذا يلخّص خمسين عاماً من العمل في إعداد افتراضي. كان على مصممي Kermit افتراض أن الخط قد يفسد البيانات، لذلك أضافوا checksums وإعادة الإرسال إلى البروتوكول. يتولى TCP ذلك الآن. وكان على Christensen وForsberg افتراض أن كل بايت له تكلفة، لذلك أضافوا الاستئناف والبث المتسلسل. تتولى خوارزمية delta في rsync ذلك الآن، وتنفذه على نحو أفضل. افترض مؤلفو FTP وجود شبكة من المضيفين المتعاونين، وهذا هو الافتراض الوحيد بينها الذي تبيّن خطؤه بطريقة لم يكن بالإمكان إصلاحها بأي قدر من العمل على البروتوكول.

ما الذي لا تزال تتيحه قيم checksum

أدّت كلمة «checksum» ثلاث وظائف مختلفة خلال هذه المسيرة، ولا يمكن استخدام هذه الوظائف بالتبادل.

كانت قيم checksum لكل حزمة في Kermit وXMODEM تكتشف تلف البيانات أثناء النقل عبر الشبكة. يتولى TCP checksum وتصحيح الأخطاء في طبقة الوصلة هذه المهمة اليوم، ولذلك لا تطلب منك أي أداة نقل حديثة التفكير فيها.

لا تجيب قيم checksum للكتل في rsync عن سؤال «هل هذه البيانات صحيحة؟». بل تجيب عن سؤال «هل لديك هذه الكتلة مسبقاً؟». لذلك تكون قيمة checksum القوية هناك مفتاح بحث، وليست دليلاً على مصدر الملف.

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

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

FAQ

هل لا يزال استخدام FTP آمناً على VPS؟

لا. يرسل FTP العادي بيانات الاعتماد ومحتويات الملفات بنص واضح، لذلك يستطيع أي طرف على المسار قراءتهما. كما يعتمد على جدار ناري يحلل قناة التحكم، وهذا لا يعود ممكناً بمجرد تشفير قناة التحكم باستخدام TLS. وقد أوقفت المتصفحات دعمه بالفعل: أزال Firefox دعم FTP في الإصدار 90 في يوليو 2021، وأزال Chrome الشيفرة في الإصدار 95 في أكتوبر 2021. استخدم SFTP عبر SSH، فهو يحتاج إلى منفذ واحد ولا يحتاج إلى وسيط شبكي يميّز البروتوكول.

لماذا يحتاج FTP إلى الوضع السلبي أصلاً؟

لأن الخادم، في الوضع الأصلي لـFTP، يفتح اتصال البيانات باتجاه العميل. يحدد RFC 959 منفذ البيانات الافتراضي للخادم بأنه "المنفذ المجاور لمنفذ اتصال التحكم، أي L-1"، ولذلك يكون المنفذ 20 عندما يكون منفذ التحكم 21. لا يملك العميل الموجود خلف NAT (ترجمة عناوين الشبكة) عنواناً يمكن للخادم الوصول إليه، لذلك لا يصل هذا الاتصال وتتوقف عملية النقل. يعكس PASV الاتجاه: يستمع الخادم بدلاً من ذلك، ويرد بعنوان ومنفذ داخل رد 227 Entering Passive Mode ليتصل به العميل.

هل لا يزال scp يستخدم بروتوكوله الخاص؟

ليس منذ OpenSSH 9.0، الذي صدر في 8 أبريل 2022، و"يحوّل scp(1) من استخدام بروتوكول scp/rcp القديم إلى استخدام بروتوكول SFTP افتراضياً". وقد أعلن OpenSSH 8.8 هذا التغيير في سبتمبر 2021. يكمن الاختلاف الظاهر في الاقتباس. كان البروتوكول القديم يوسّع أحرف البدل البعيدة بتمريرها إلى الصدفة البعيدة، أما البروتوكول المعتمد على SFTP فلا يفعل ذلك، ولذلك تتصرف المسارات التي كانت تعتمد على توسعة الصدفة بشكل مختلف الآن.

متى يكون rsync أفضل من scp بالنسبة إلى VPS؟

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

لماذا شفّر Kermit الملفات على هيئة نص قابل للطباعة بدلاً من إرسال البايتات الخام؟

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