Join Telegram Study Group ▷
لنفترض أنه لا يوجد بروتوكول TCP أو حتى طبقة IP. فقط طبقة ارتباط البيانات المقابلة لـ MAC، إلى أي مدى يمكن لبروتوكول HTTP أن يعمل؟
هل من الممكن تغليف HTTP مباشرة في إطار Ethernet؟ بالطبع، في نفس نطاق البث في الطبقة 2، يتم استخدام عنوان MAC لتحديد الطرف الآخر، ثم يتم إرسال بيانات HTTP واستلامها من خلال وظيفة واجهة بطاقة الشبكة.
السؤال المطروح هو كيف نضمن وصول البيانات إلى الطرف الآخر دون فشل؟ هل تسمح بطاقة الشبكة بضمان نقل البيانات بشكل موثوق؟ تقوم بطاقة NIC فقط بتفسير رأس إطار Ethernet. لا يحتوي رأس Ethernet على أي مجال للنقل الموثوق. HTTP هي آلية موثوقة لنقل البيانات، مثل إرسال بيانات بحجم 1000 بايت. يعد TCP موضوعًا مهمًا في تعاون CCNP . انتظر حتى يؤكد الطرف الآخر الاستلام، ثم أرسله مرة أخرى، حتى يمكن نقل البيانات بشكل موثوق.
وبالمثل، فإن بروتوكولات FTP وSTMP وPOP وBGP كلها تدور حول ضمان نقل البيانات بشكل موثوق. هل يجب عليهم تنفيذ هذه الآليات الموثوقة بأنفسهم؟ هذا مؤكد، أي طالما يوجد تطبيق، يجب تنفيذ النقل الموثوق به بواسطة بروتوكول التطبيق! هل هذا غبي جدًا؟ آلية النقل الموثوق بها لجميع بروتوكولات التطبيق هي نفس التنفيذ، ويجب أن يكون الكود متشابهًا. إذا قمنا بتغليف هذا الكود المعاد استخدامه، فإن وظيفة الواجهة API، دعه ينفذ نقل البيانات بشكل موثوق، واستخدم معرفًا للإشارة إلى ذلك. ما هو بروتوكول التطبيق الذي يكون ممكنًا؟ ممكن!!!
هذا هو المنشئ المجرد للغاية لبروتوكول TCP/IP العظيم: TCP! فهو يغلف كود آلية النقل الموثوقة في واجهة برمجة التطبيقات الوظيفية، أي socket، ويستخدم منفذ TCP لتحديد بروتوكول التطبيق لخدمته. يحتاج بروتوكول التطبيق فقط إلى شرح بروتوكوله الخاص وبيانات البروتوكول لإكمال الجلسة من البداية إلى النهاية.
السؤال الثاني: الآن Ethernet + TCP + بروتوكول التطبيق، إلى أي مدى يمكن لهذه الحزمة أن تعمل؟ هل هذا مجال بث كبير كما هو؟ نعم سيدي، كيف لا يمكن للعرض التوضيحي الهروب من دائرة مجال البث. طبقة IP هي لحل هذه المشكلة. مع طبقة IP، يمكن جعل الإنترنت ممكنًا. كلمة إعلانية: المستحيل لا شيء! لمعرفة أن IP هو اختصار لبروتوكول الإنترنت.
ثم قد يكون عليك أن تسأل، أريد طبقة IP، لا أريد طبقة TCP، هل يمكن تغليف البيانات مباشرة في طبقة IP؟ لا بأس! ليس فقط يمكن، ولكن الكثير من البروتوكولات تفعل الشيء نفسه، OSPF، EIGRP، GRE، ESP، AH وغيرها من البروتوكولات تفعل ذلك، إذا أرادوا ضمان نقل موثوق، فإنهم يستخدمون الكود لتحقيق ذلك، بالطبع.
المشكلة هي أن بروتوكول الإنترنت يستخدم بايتًا واحدًا فقط لتمثيل رقم البروتوكول. من الناحية النظرية، يمكنه فقط تحديد 255 بروتوكولًا من الطبقة العليا. الموارد محدودة للغاية، وكلها تهيمن عليها بروتوكولات كبيرة معروفة، مثل TCP وICMP وIGMP، بما في ذلك البروتوكولات المذكورة أعلاه. أين أنت على العجلة! لحل مشكلة نقص الموارد هذه، هناك شيء صغير آخر لا يتم استخدامه لتحديد بروتوكول التطبيق: UDP!
في الواقع، بالإضافة إلى توفير منفذ لتمييز بروتوكول التطبيق، لا يقوم UDP بأي شيء آخر، لكن رقم المنفذ يشغل 2 بايت. من الناحية النظرية، يمكنه حل 65535 بروتوكول تطبيق. يمكن أن يجعل هذا مزاياه كاملة، على وجه التحديد لأنه على عكس TCP، فهو بروتوكول عديم الجنسية تمامًا، لذلك يفضله أيضًا بعض التطبيقات. نظرًا لأن UDP عديم الجنسية، فإن IP عديم الجنسية، ويتم التحكم في جميع حالات الجلسة بواسطة بروتوكول التطبيق. هذا أيضًا خيار.
بالإضافة إلى ذلك، يمكن للتطبيقات المستندة إلى UDP تحقيق نقل موثوق به، مثل TFTP، ثم يمكن لـ TFTP تحقيق نقل موثوق به من تلقاء نفسه؛ يمكنه أيضًا إرسال البيانات إلى UDP، والسماح له بالإرسال، دون الحاجة إلى تأكيد البيانات المرسلة، سيسأل الطلاب: ما نوع التطبيق هذا؟ يتم فقدان حركة المرور الصوتية عندما تفقدها، ولا يمكن للطرف الآخر سماعها.
باختصار، يوفر TCP آلية نقل موثوقة، وخالية من الحالة؛ بينما يوفر UDP مساحة أكبر لتحديد بروتوكول الطبقة العليا، بدون حالة.
1. بدون طبقة الشبكة وطبقة النقل، يجب تنفيذ وظائف التوجيه والنقل الموثوق به بواسطة طبقات أخرى، مما يجعل بروتوكول بعض الطبقات معقدًا للغاية.
2. طبقة النقل الموجودة بالأسفل هي طبقة الاتصال بين المضيفين. أما الطبقة الموجودة أعلى طبقة النقل فهي طبقة الاتصال بين عمليات التطبيق. وبالإضافة إلى النقل الموثوق، تحتاج طبقة النقل أيضًا إلى التعامل مع إرسال الإشارات وفك إرسالها لتطبيقات مختلفة.
