سؤال

أنا متأكد من أن هناك سببًا قديمًا لذلك، لكن ما هو؟يبدو أنها خدمة موجهة نحو توصيل بيانات موثوقة.

هل كانت مفيدة؟

المحلول

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

لاحظ أن NFS V3 + يمكن استخدام TCP.

نصائح أخرى

UDP هو الافتراضي ل NFSV2 (الذي يجب أن يستخدمه أحد حقا هذه الأيام) ولكن استخدام NFSV3 TCP افتراضيا. يتصاعد TCP أكثر موثوقية وأنت تعرف أن لديك مشكلة شبكة أسرع بكثير من UDP.

UDP عديم الحالة، وTCP ليس كذلك، لكن TCP لديه العديد من الخصائص المحددة مسبقًا التي لا تناسب NFS، أو بالأحرى أن NFS أراد التحكم في التفاصيل.على وجه الخصوص، عندما يقوم TCP بنقل الحزم، فإنه يتحكم في المهلات، وما إلى ذلك.

باستخدام UDP، ستفقد النفقات العامة التي لا تريدها بأي شكل من الأشكال.عندما كان نظام ملفات NFS، كانت الفكرة في الأصل هي أن النظام يقوم بالكتابة، وإذا انتهى نصفها فقط، فسيكون ذلك سيئًا ...لذلك سيستمر NFS (في الوضع الصعب) في إعادة محاولة إكمال المعاملة إلى الأبد، دقيقة واحدة، 5، 10، وساعة، في اليوم ...عندما يعود الاتصال، يمكن أن تستمر المعاملة في الاكتمال...

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

يشبه القياس إلى حد ما كيفية عمل عناصر RS232 ...ستقوم الإلكترونيات بعملها وتحميل مخازنها المؤقتة وسوف تمتلئ وتضطر إلى التوقف (أو فقدان المعلومات)، ويمكنها تمرير هذا التدفق من المعلومات (وإفراغ مخازنها المؤقتة والمتابعة) عندما يكون CTS (مسح لإرسال الدبوس - كما هو الحال في المعدن دبوس على القابس) كان مرتفعًا أو منخفضًا (أيًا كان من المفترض أن يكون).

تخميني هو أنه ربما بالنسبة للأسباب القديمة (التاريخية). في الأصل NFS كان يستخدم في شبكات الكمون المنخفضة حيث كان هناك القليل جدا من الاحتمال للخطأ، لذلك تفوق النفقات العامة لبدء المصافحة ذات الاتجاهين لإعداد اتصال TCP (إلى جانب الاعتراف ثنائي الاتجاه بجميع الرسائل) بساطة باستخدام بروتوكول بدون اتصال مثل UDP.

عند استخدام UDP كبروتوكول للنقل، من المفترض أنه سيكون الأمر متروكا لعميل NFS لإدارة إعادة الإرسال إذا لزم الأمر.

يتم استخدام UDP عند إدارة البروتوكول من قبل التطبيق نفسه. قد يكون التطبيق فكرة أفضل لكيفية القيام بذلك، أو قد يكون أسرع (بموجب الشروط الخاصة للتطبيق). TCP جميل جدا ولكن لديه الكثير من النفقات العامة المرتبطة به.

أداء. UDP لديه النفقات العامة أقل بكثير من TCP. من ناحية أخرى، يتعين على NFS التعامل مع وسائل النقل الموثوق بها من تلقاء نفسها، ثم (مقارنة مع TCP)، ولكن لأن هذا هو بروتوكول لمحبي المشابك حيث توجد مشاكل الاتصال وقطرات الحزمة (أو أفضل: يجب أن تكون) مشكلة، فهي محسنة للأداء.

تم استخدام UDP أيضا لأنه قد يقلل بشكل كبير من استخدام الذاكرة. في الثمانينيات من القرن الماضي عندما تم تطوير NFS في الأصل، سيكون لديك نظام يونيكس مع مثل 4-8 ميجابايت من ذاكرة الوصول العشوائي، و (على الأقل في البيئة الأكاديمية) قد يكون "الخادم" مجرد واحدة من هذه الأنظمة 4-8MB مع عدد قليل أقراص إضافية مدمن مخدرات لها. كان استخدام ذاكرة الوصول العشوائي على الخادم مصدر قلق كبير، ويمكن أن تضيع عدة ميغابايت إلى TCP المخازن المؤقتة التي تم استخدامها بشكل أفضل كذاكرة التخزين المؤقت للقرص. كما أنه من السهل التعامل مع ضغط الذاكرة، يمكن لخادم NFS الوافد ببساطة إسقاط الطلبات.

يقلل اتصال UDP عديمي الجنسية يقلل من حركة مرور الشبكة، حيث يرسل خادم NFS العميل ملف تعريف الارتباط بعد مخول العميل للوصول إلى وحدة التخزين المشتركة. هذه ملف تعريف الارتباط هذه هي قيمة عشوائية مخزنة على جانب الخادم ويتم تمريرها مع طلبات RPC من العميل.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top