التفكير المنطقي في مشاكل الشبكات

الحالة الكلاسيكية 1

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

نظرًا لأن إعادة الإرسال مشكوك فيها، فإن من الضروري فهم طبيعتها. تتضمن إعادة الإرسال في الأساس إعادة الإرسال بسبب انتهاء المهلة. لتأكيد ما إذا كانت إعادة الإرسال هي السبب بالفعل، فإن المعلومات المتعلقة بالوقت ضرورية، وهي غير متوفرة في لقطة الشاشة أعلاه. بعد طلب لقطة شاشة جديدة من مسؤول قواعد البيانات، تم تضمين معلومات الطابع الزمني.

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

الحالة الكلاسيكية 2

توضح حالة كلاسيكية أخرى أهمية التفكير المنطقي في تحليل مشكلات الشبكة.

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

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

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

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

من أحداث اليوم الأول، تأكد حدوث المشكلة بالفعل. حاول الجميع المشارك التركيز على السبب، وقاموا بتقديم تخمينات مختلفة، لكن السبب الحقيقي ظل غامضًا.

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

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

في اليوم الثالث، أبلغ المطورون أنَّ مشكلة الصباح الباكر لم تتكرر، وتحليل التقاط الحزم أكد أنَّ المشكلة لم تحدث. بعد التفكير الدقيق، بدا الأمر غير محتمل أن يكون الخلل بشكل خاص في وسيط قاعدة البيانات MySQL: حدوث التكرارات المتكررة في الصباح الباكر والتكرارات النادرة خلال النهار كانت أمورًا محيرة. كان الخيار الوحيد هو انتظار حدوث المشكلة مرة أخرى وتحليلها استنادًا إلى تقاط الحزم.

في اليوم الرابع، لم تظهر المشكلة مرة أخرى.

ومع ذلك، في اليوم الخامس، ظهرت المشكلة مرة أخرى أخيرًا، مما أعاد الأمل بحلها.

ملفات التقاط الحزم كثيرة. أولًا، اطلب من المطورين تقديم الطابع الزمني عند حدوث المشكلة، ثم ابحث في البيانات الواسعة لتقاط الحزم لتحديد الاستعلام SQL الذي تسبب في المشكلة. النتيجة النهائية كما يلي:

من محتوى التقاط الحزم أعلاه (الملتقط من الخادم)، يبدو أن الاستعلام SQL تم إرساله في الساعة 3 صباحًا. استغرق وسيط قاعدة البيانات MySQL 630 ثانية (03:10:30.899249-03:00:00.353157) لإرجاع الاستجابة SQL إلى العميل، مما يشير إلى أن وسيط قاعدة البيانات MySQL استجاب حقًا للاستعلام SQL. ومع ذلك، بعد 238 مايكروثانية فقط (03:10:30.899487-03:10:30.899249)، تلقت طبقة TCP للخادم حزمة إعادة ضبط، والتي كانت سريعة بشكل مشبوه. من المهم أن نلاحظ أن هذه الحزمة لا يمكن افتراضها على الفور أنها من العميل.

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

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

إذن، من قام بإرسال إعادة التعيين؟ المشتبه به الرئيسي هو بيئة سحابة أمازون. استنادًا إلى تحليل التقاط الحزم هذا، قامت عمليات DBA بالاستعلام من خدمة عملاء أمازون وتلقت المعلومات التالية:

تتوافق استجابة خدمة العملاء مع نتائج التحليل، مما يشير إلى أن جهاز ELB (موازن الحمل المرن، مشابه لـ LVS) التابع لأمازون قد أنهى جلسة TCP بالقوة. وفقًا لملاحظاتهم، إذا كانت الاستجابة تتجاوز عتبة 350 ثانية (كما لوحظ في التقاط الحزم على أنها 630 ثانية)، فإن جهاز ELB الخاص بأمازون يرسل إعادة تعيين إلى الطرف المستجيب (في هذه الحالة، الخادم). لم تتلقَ نصوص العميل التي نشرها المطورون إعادة التعيين واعتقدوا عن طريق الخطأ أن اتصال الخادم لا يزال نشطًا. تشمل التوصيات الرسمية لمثل هذه المشاكل استخدام آليات إبقاء TCP لتخفيف هذه المشاكل.

مع الحصول على الاستجابة الرسمية، اعتُبرت المشكلة محلولة بالكامل.

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