في تصميم بروتوكول لماذا كنت تستخدم أي وقت مضى 2 الموانئ
https://stackoverflow.com/questions/626823
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
عند ملقم TCP لا مأخذ تقبل على الميناء ، فإنه يحصل على مقبس جديد للعمل مع هذا العميل.
قبول مأخذ لا تزال صالحة لهذا الميناء يمكن أن تقبل المزيد من العملاء على هذا المنفذ.
لماذا الأصلي FTP مواصفات RFC 959 تقرر إنشاء السيطرة على ميناء بيانات الميناء ؟
لن يكون هناك أي سبب للقيام بذلك في نفس مخصص البروتوكول ؟
يبدو لي أن هذا يمكن أن يكون بسهولة المحدد على منفذ واحد.
نظرا لجميع المشاكل مع جدران الحماية ناتس مع بروتوكول نقل الملفات ، يبدو أن منفذ واحد يمكن أن يكون أفضل بكثير.
العامة لتنفيذ بروتوكول السبب الوحيد الذي أنا يمكن أن أعتقد أن كنت تريد أن تفعل هذا حتى يتسنى لك يمكن أن تكون ملفات من مختلف المضيف من الأوامر تسير.
المحلول
الأولي المنطقي وراء هذا بحيث يمكن:
- الاستمرار في إرسال واستقبال التحكم التعليمات على السيطرة على اتصال أثناء وجودك نقل البيانات.
- لديك أكثر من اتصال بيانات نشط في نفس الوقت.
- الخادم تقرر عندما انها على استعداد لإرسال البيانات.
صحيح أنها يمكن أن تحقق نفس النتيجة عن طريق تحديد معقدة مضاعفة بروتوكول متكامل بروتوكول FTP ، ولكن منذ ذلك الوقت NAT غير مسألة ، اختاروا استخدام ما موجودة بالفعل ، منافذ TCP.
هنا مثال:
أليس يريد ملفين من بوب.أليس يربط بوب المنفذ 21 ويسأل عن الملفات.بوب الاتصالات المفتوحة أليس ميناء 20 عندما تكون جاهزة و إرسال الملفات هناك.وفي الوقت نفسه, تشارلز يحتاج ملف أليس الخادم.تشارلز يصل إلى 21 على أليس ويسأل عن الملف.أليس يربط ميناء 20 على تشارلز عندما تصبح جاهزة ، ويرسل الملفات.
كما يمكنك أن ترى, port 21 العميل الاتصال إلى خوادم ميناء 20 للخوادم الاتصال للعملاء ، ولكن هؤلاء العملاء يمكن أن لا تزال تعمل الملفات على 21.
كل المنافذ تخدم مختلف تماما الغرض ، ومرة أخرى من أجل البساطة ، اختاروا استخدام اثنين من منافذ مختلفة بدلا من تنفيذ بروتوكول التفاوض.
نصائح أخرى
لأن FTP يسمح تحكم منفصلة و البيانات.IIRC, كما صممت في الأصل ، هل يمكن أن يكون 3 يستضيف:تستضيف يمكن أن تسأل المضيفة ب لإرسال البيانات إلى المضيف C.
FTP صمم في وقت الغباء الحديثة جدار الحماية لا يمكن تصوره.منافذ TCP وتهدف هذه الوظائف.مضاعفة اتصالات متعددة على IP واحد.هم لا بديلا عن قوائم التحكم في الوصول.هم لا تهدف إلى توسيع IPv4 إلى 48 بت عناوين أيضا.
أي غير IPv6 بروتوكول سيكون لديك للتعامل مع الفوضى ، لذلك يجب أن عصا صغيرة قريبة من الموانئ.
FTP لديها تاريخ طويل جدا ، كونها واحدة من أول ARPANET بروتوكولات مرة أخرى في أوائل السبعينات (على سبيل المثال ، انظر RFC114 من عام 1971).قرارات التصميم التي قد تبدو غريبة الآن أكثر منطقية بعد ذلك.اتصالات كانت أبطأ بكثير ، وأداء الاتصال السيطرة "من فرقة" ربما بدا خطوة جيدة مع شبكة التكنولوجيا.
الحالي RFC959 يتضمن جيدة قسم التاريخ ، ربط في وقت سابق من المراجع ، إذا كنت يتوهم تفعل القليل من الآثار...
مثل العديد من كبار السن سلك بروتوكولات FTP هو مناسبة للاستخدام من قبل البشر.وهذا هو أنه من السهل جدا استخدام FTP من جلسة عمل المحطة طرفية.المصممين FTP المتوقع أن المستخدمين قد ترغب في مواصلة العمل مع المضيف البعيد أثناء نقل البيانات.هذا يمكن أن يكون صعبا إذا الأوامر و البيانات كانت تسير على نفس القناة.
IETF حظرت ممارسة تخصيص أكثر من منفذ واحد بروتوكولات جديدة لذا فإننا على الأرجح لن نرى هذا في المستقبل.
أحدث بروتوكولات IP مثل SCTP تهدف إلى حل بعض shortcommings TCP الذي يمكن أن يؤدي إلى استخدام منافذ متعددة.برامج 'رئيس من الخط' عرقلة يمنع من وجود عدة طلبات مستقلة/تيارات في الرحلة التي يمكن أن يكون مشكلة بالنسبة لبعض الحقيقي التطبيقات.
IIRC مسألة لم يكن ذلك FTP يستخدم اثنين (أي أكثر من واحد) الموانئ.القضية هي أن السيطرة على اتصال بدأها العميل بيانات القناة بدأت قبل الملقم.أكبر الفرق بين FTP و HTTP أن في HTTP العميل يسحب البيانات في بروتوكول نقل الملفات الخادم يدفع ذلك.NAT القضية تتعلق الخادم دفع البيانات من خلال جدار حماية لا تعرف أن نتوقع الاتصال.
FTP استخدام منافذ منفصلة عن البيانات ومراقبة بدلا أنيقة IMHO.التفكير في كل شيء من الصداع في HTTP المحيطة مضاعفة من البيانات ومراقبة التفكير زائدة رؤوس القواعد المحيطة ضخه طلبات اتصال الحفاظ على التشغيل ، وليس ما.الكثير من ذلك هو تجنب صراحة فصل البيانات ومراقبة ناهيك عن أنه من الممكن أن تفعل أشياء مثيرة للاهتمام مثل تشفير واحد وليس غيرها أو قناة التحكم أعلى جودة الخدمة من البيانات.
يجب أن يكون لديك نظرة على RTSP + RTP protcol.هو تصميم مماثل :كل تيار يمكن إرسالها إلى منفذ مختلف ، إحصاءات عن غضب ، إعادة ترتيب الخ...يتم إرسالها في آخر ميناء.
بالإضافة إلى عدم وجود اتصال لأنه هو UDP.ومع ذلك كان يعدون عند جدار حماية حيث سبق شيئا عاديا (آسف لغتي الإنجليزية) ، لذلك تم وضع تطوير أين كل هذا الصدد يمكن أن تكون جزءا لا يتجزأ في اتصال TCP HTTP الجملة.
تخمين ما ؟ متعددة ميناء البروتوكول هو أبسط من ذلك بكثير (IMO) لتنفيذ http المضاعفة واحد و له الكثير من الميزات.إذا كنت لا تشعر بالقلق مع جدار حماية المشكلة لماذا تختار معقدة مضاعفة المخطط عندما يكون هناك بالفعل واحد القائمة (منفذ TCP)?
FTP قديم البروتوكول.هذا هو السبب الوحيد.المصممين يعتقد أن كمية البيانات المتدفقة عبر منفذ بيانات من شأنها أن تجعل بحيث لا يمكن إرسال أوامر التحكم في الوقت المناسب ، إذا فعلوا ذلك كما اثنين من الموانئ.الجدران النارية ، وخاصة نات جاء وقت لاحق من ذلك بكثير.
أعتقد أنها فعلت ذلك حتى أنه في حين نقل كانت تحدث يمكنك مواصلة العمل مع الخادم و بداية جديدة التحويلات بسهولة (إذا كان العميل الخاص بك يمكن أن تدعم هذا).
علما بأن الوضع السلبي يحل ما يقرب من كل جدار الحماية/NAT المشاكل.
في رأيي انها مجرد سوء اختيار التصميم في المقام الأول.في العصور القديمة حيث كان اختراع جدار حماية NAT لم تكن موجودة ...في الوقت الحاضر, السؤال الحقيقي هو أكثر "لماذا الناس لا تزال ترغب في استخدام FTP" ?كل شيء FTP لا يمكن أن يتم ذلك باستخدام HTTP بطريقة أفضل.
