تحليل بانورامي معقد لبروتوكول TCP

تحليل بانورامي معقد لبروتوكول TCP

تقترح منظمة ISO نموذج الشبكة الطبقي OSI. هذا النموذج الطبقي نظري. في النهاية، ينفذ بروتوكول TCP/IP نموذج بروتوكول طبقي. يتوافق كل مستوى مع مجموعة من بروتوكولات الشبكة لإكمال مجموعة محددة من الوظائف. يتم إرسال البروتوكول وفك إرساله بواسطة الطبقات الموجودة أسفله. هذا هو جوهر النموذج الطبقي، وفي النهاية، يتم ترميز كل المنطق في كبلات أو موجات كهرومغناطيسية.

المؤلف: Bomb250 المصدر: مدونة CSDN | 2015-09-15 10:09 المفضلة المشاركة

1. تصميم بروتوكول الشبكة

تقترح منظمة ISO نموذج الشبكة الطبقي OSI. هذا النموذج الطبقي نظري. في النهاية، ينفذ بروتوكول TCP/IP نموذج بروتوكول طبقي. يتوافق كل مستوى مع مجموعة من بروتوكولات الشبكة لإكمال مجموعة محددة من الوظائف. يتم إرسال البروتوكول وفك إرساله بواسطة الطبقات الموجودة أسفله. هذا هو جوهر النموذج الطبقي، وفي النهاية، يتم ترميز كل المنطق في كبلات أو موجات كهرومغناطيسية.

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

تحليل بانورامي معقد لبروتوكول TCP

2. بروتوكولات TCP و IP

بالانتهاء من بروتوكول IP، يمكننا بالفعل إكمال الاتصال من البداية إلى النهاية. لماذا نحتاج إلى بروتوكول TCP؟ هذه مشكلة. إذا فهمنا هذه المشكلة، يمكننا أن نفهم لماذا أصبح بروتوكول TCP على ما هو عليه الآن، لماذا هو "معقد" إلى هذا الحد؟ لماذا هو بسيط إلى هذا الحد؟

كما يوحي اسمه، فإن دور بروتوكول التحكم في الإرسال هو التحكم في الإرسال من البداية إلى النهاية، فلماذا لا يتم تنفيذ هذا التحكم في بروتوكول IP؟ الإجابة بسيطة، أي أن هذا سيزيد من تعقيد بروتوكول IP، ويجب أن يكون بروتوكول IP بسيطًا. ما سبب ذلك؟

أولاً، دعونا نعرف لماذا بروتوكول IP هو الخصر النحيف للساعة الرملية. الطبقة السفلى هي مجموعة كبيرة من بروتوكولات طبقة الارتباط. توفر هذه الروابط دلالات مختلفة جدًا ومتباعدة. من أجل ربط هذه الشبكات غير المتجانسة، نحتاج إلى بروتوكول طبقة الشبكة لتوفير بعض وظائف التكيف على الأقل. يجب ألا يوفر الكثير من "خدمات الضمان"، لأن ضمان الطبقة العليا يعتمد على الضمان الأكثر تقييدًا للطبقة السفلى، لا يمكنك أبدًا ضمان معدل نقل 1000 ميجابايت في الثانية بموجب بروتوكول IP المطبق على رابط معدل نقل 100 ميجابايت في الثانية. الكمية...

تم تصميم بروتوكول IP كبروتوكول لإعادة توجيه الحزم. تمر كل قفزة عبر عقدة وسيطة. يعد تصميم المسار ابتكارًا كبيرًا آخر لشبكة TCP/IP. وبالتالي، لا يحتاج بروتوكول IP إلى اتجاهية، ولم تعد معلومات التوجيه والبروتوكول نفسه مرتبطين بقوة. ترتبط فقط بعنوان IP، وبالتالي فإن بروتوكول IP أبسط كثيرًا. لا يمكن أن يكون جهاز التوجيه كعقدة وسيطة معقدًا للغاية، مما ينطوي على مشكلات تتعلق بالتكلفة، وبالتالي يكون جهاز التوجيه مسؤولاً فقط عن توجيه الحزم وإعادة توجيهها.

لذلك، من الضروري تنفيذ بروتوكول التحكم في الإرسال عند نقطة النهاية. قبل أن نتحدث عن بروتوكول TCP، يجب أن ننظر أولاً إلى ما لا يمكنه فعله. نظرًا لأن بروتوكول IP لا يوفر ضمانًا، فلا يمكن لـ TCP توفير مثل هذه الضمانات التي تعتمد على رابط الطبقة السفلية لـ IP، مثل النطاق الترددي، مثل التأخير، فهذه سلاسل. تقرر طبقة الطريق أنه نظرًا لأنه لا يمكن تصحيح بروتوكول IP، فلا يمكن لـ TCP ذلك، ولكن يمكنها تصحيح بعض "الخصائص غير المضمونة" التي تبدأ من طبقة IP. تتضمن هذه الخصائص عدم موثوقية طبقة IP، وعدم ترتيب طبقة IP، وطبقة IP. لا اتجاه / لا اتصال.

لتلخيص هذا القسم، فإن نموذج TCP/IP من الأسفل إلى الأعلى، تزداد الوظائف، وينخفض ​​عدد الأجهزة التي تحتاج إلى التنفيذ. ومع ذلك، فإن تعقيد الجهاز يتزايد، وبالتالي ضمان تقليل التكاليف. أما بالنسبة للأداء أو العوامل، فإنه يتم تعديله بواسطة البرنامج. بروتوكول TCP هو مثل هذا البرنامج. في الواقع، في البداية، لا يأخذ TCP في الاعتبار الأداء والكفاءة والعدالة. ولهذا السبب فإن بروتوكول TCP معقد.

3. بروتوكول TCP

هذا بروتوكول برمجي خالص، لماذا نصممه بنقطتي نهاية، راجع القسم السابق، هذا القسم يوضح بروتوكول TCP، متخلله بعض المناقشات القصيرة.

3.1. بروتوكول TCP

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

لقد اعتدنا على استخدام TCP كأعلى مجموعة بروتوكولات، دون استخدام بروتوكول طبقة التطبيق كجزء من مجموعة البروتوكولات. ويرجع هذا جزئيًا إلى أن طبقة التطبيق يتم فك تعدد الإرسال فيها بواسطة TCP/UDP، مما يمثل موقفًا معقدًا للغاية. يتم تفسير بروتوكولات طبقة التطبيق بطريقة مختلفة تمامًا. اعتادت بروتوكولات طبقة التطبيق على أن يتم تغليفها بمعيار ASN.1 مماثل، مما يعكس أهمية بروتوكول TCP كأداة إرسال/فك تعدد الإرسال بسبب الاتصال المباشر وواجهة التطبيق، والتي يمكن التحكم فيها بسهولة مباشرة بواسطة التطبيق لتنفيذ استراتيجيات التحكم في الإرسال المختلفة، وهو أحد الأسباب التي تجعل TCP مصممًا ليس بعيدًا جدًا عن التطبيق.

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

3.2. TCP مع الاتصال والنقل الموثوق به ووصول البيانات بالترتيب

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

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

3.2.1. احصل على اتصال

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

الأمراض المستعصية 1: 3 مصافحات و4 تلويحات

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

يستخدم TCP 4 موجات لإزالة اتصال. لماذا تحتاج إلى 4 مرات؟ نظرًا لأن TCP هو بروتوكول ثنائي الاتجاه بالكامل، فيجب إزالة كل قناة على حدة. لاحظ أن معنى 4 موجات و3 مصافحات مختلف. سيسأل العديد من الأشخاص لماذا يكون الاتصال عبارة عن 3 مصافحات، والاتصال عبارة عن 4 موجات. الغرض من المصافحة الثالثة بسيط للغاية. إنه تخصيص الموارد وتهيئة الرقم التسلسلي. في هذا الوقت، لا يتم تضمين نقل البيانات. 3 مرات كافية للقيام بذلك، والغرض من 4 موجات هو إنهاء نقل البيانات وإعادة تدوير الموارد. لا توجد علاقة بين الأرقام التسلسلية لنقطتي النهاية في كلا الاتجاهين. يجب إزالة الرابط الافتراضي عندما لا يكون هناك نقل بيانات في كلا الاتجاهين. الأمر ليس بهذه البساطة مثل التهيئة. يتم تهيئة علم SYN لتهيئة رقم تسلسلي وتأكيد تسلسل رقم SYN. ​​لذلك، يجب إنهاء نقل البيانات في هذا الاتجاه بشكل منفصل في اتجاه واحد.

مرض مستعصي 2: حالة TIME_WAIT

لماذا هذه الحالة، السبب بسيط للغاية، أي أنه في كل مرة يتم فيها إنشاء اتصال، يتم إنشاء الرقم التسلسلي عشوائيًا، والرقم التسلسلي هو 32 بت، وسوف يلتف حوله. الآن دعني أشرح ما علاقة هذا بـ TIME_WAIT.

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

الآن نعتبر أن الطرف السلبي عند إنهاء الاتصال يرسل FIN، ثم يرد الطرف النشط بإقرار. ومع ذلك، قد يتم فقد هذا الإقرار، مما يتسبب في إعادة الطرف السلبي إرسال FIN، والذي قد ينجو من MSL على الإنترنت.

إذا لم يكن هناك TIME_WAIT، فمن المفترض أن الاتصال 1 قد تم قطع الاتصال، ولكن FIN الذي يعيد الطرف السلبي إرساله أخيرًا (أو أي جزء TCP يتم إرساله قبل FIN) لا يزال على الشبكة، ولكن الاتصال 2 يعيد استخدام جميع العناصر الخمسة للاتصال 1. (عنوان IP المصدر، عنوان IP الوجهة، TCP، منفذ المصدر، منفذ الوجهة)، سيتم إنشاء الاتصال فقط، وسوف يصل FIN الذي يصل متأخرًا 1، وسوف ينهي هذا FIN الاتصال باحتمالية منخفضة نسبيًا ولكنها ممكنة بالفعل.

لماذا يكون الاحتمال منخفضًا؟ يتضمن هذا مشكلة مطابقة. يجب أن يقع الرقم التسلسلي لشريحة FIN المتأخرة ضمن رقم التسلسل المتوقع للطرف المتصل 2. على الرغم من أن هذه المصادفة نادرًا ما تحدث، إلا أنها تحدث، بعد كل شيء، يتم إنشاء الرقم التسلسلي الأولي عشوائيًا. لذلك، يجب على الطرف النشط الذي ينهي الاتصال انتظار وقت 2*MSL للدخول في حالة الإغلاق بعد قبول الطرف السلبي والرد على ACK. يتم ضرب السبب في 2 لأن هذه خوارزمية محافظة. في أسوأ الأحوال، يتم فقد ACK للجانب السلبي عند الوصول إلى الجانب السلبي عبر الإنترنت على أطول مسار (تجربة MSL).

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

كما تعلم، لا يحب العديد من الأشخاص حقًا رؤية الكثير من الاتصالات في حالة TIME_WAIT على الخادم، لذا يقومون بتعيين قيمة TIME_WAIT منخفضة للغاية، وهو أمر ممكن في معظم الحالات، ولكنه أيضًا سلوك محفوف بالمخاطر. أفضل طريقة هي عدم إعادة استخدام اتصال.

مرض مستعصي 3: إعادة استخدام اتصال وإعادة استخدام مقبس

هذا مختلف بشكل أساسي، ولا توجد مشكلة بشكل عام في إعادة استخدام المقبس بمفرده لأن TCP يعتمد على الاتصال. على سبيل المثال، إذا ظهر اتصال TIME_WAIT على جانب الخادم، فإن الاتصال يحدد عنصرًا من خمسة عناصر. طالما أن العميل لا يستخدم نفس منفذ المصدر، فلا توجد مشكلة في توصيل الخادم، لأن FIN المتأخر لن يصل إلى الاتصال أبدًا. تذكر أن العنصر المكون من خمسة عناصر يحدد اتصالاً وليس مقبسًا (بالطبع، بالنسبة لمقابس BSD، فإن مقبس القبول الخاص بالخادم يحدد اتصالاً).

3.2.2. موثوقية الإرسال

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

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

مرض مستعصي 4: حساب وقت التوقف عن العمل

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

إذا تم أخذ هذا المتوسط ​​​​فقط مباشرة عن طريق حساب المتوسط ​​​​الحسابي للقياسات المتعددة، فإنه ليس مناسبًا، لأنه بالنسبة لتأخير نقل البيانات، يجب أن نأخذ في الاعتبار الاهتزاز اللحظي لتأخير المسار، وإلا إذا كان القياسان 2 و 98 على التوالي، فإن قيمة مهلة الانتظار ستكون 50، هذه القيمة كبيرة جدًا بالنسبة لـ 2، والنتيجة هي تأخير كبير جدًا للبيانات (ينتظر إعادة الإرسال لفترة طويلة لإعادة الإرسال)، ولكن بالنسبة لـ 98، فهي صغيرة جدًا والنتيجة هي إعادة إرسال مفرطة (الطريق بعيد، وكان يجب أن يكون بطيئًا، ونتيجة لذلك تم تأكيد عدد كبير من عمليات إعادة الإرسال بشكل صحيح ولكن مقاطع TCP متأخرة).

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

مرض مستعصي 5: مهلة زمنية