يحتوي نظام التشغيل macOS على قنبلة موقوتة مدتها 49.7 يومًا للشبكات، حيث يتم إصلاحها فقط من خلال إعادة التشغيل – تؤدي عملية المقارنة على قيمة زمنية غير موثوقة إلى إيقاف تشغيل الأجهزة في مساراتها
من خلال تجربة شخصية، فإن استخدام جهاز Mac كخادم أو أداة تشبه الخادم يعد أمرًا رائعًا مثير للاهتمام الاقتراح، على الرغم من جذوره التي تعمل بنظام Unix، فإن نظام التشغيل ليس مصممًا تمامًا للاستخدام غير المراقب على مدار الساعة طوال أيام الأسبوع ومن الصعب إعداده واستخدامه على هذا النحو – وهي كلمات متعارضة، لكنني أقف إلى جانبها. في حين أن معظم المستخدمين سيعيدون تشغيل جهاز Mac الخاص بهم مرة واحدة على الأقل في غضون بضعة أسابيع، إذا تركت جهازًا قيد التشغيل لمدة 49 يومًا و17 ساعة ودقيقتين و47 ثانية على وجه التحديد، فستتوقف العديد من الأجزاء عن العمل فجأة مع انتهاء مكدس شبكة TCP/IP الخاص به.
هذه هي النتائج التي توصل إليها الأشخاص في Photon، الذين قاموا ببعض التحقيقات الجادة بعد مواجهة مشكلة غامضة في أسطول من أجهزة Mac التي يستخدمونها لمراقبة خدمات iMessage. كشفت المشكلة عن نفسها عندما توقفت بعض الأجهزة عن الاستجابة لاتصالات الشبكة فجأة، على الرغم من أنها استجابت لطلبات اختبار الاتصال بعبارة “كل شيء على ما يرام يا رئيس!”
حافظت الأجهزة المذكورة على استمرار اتصالات الشبكة الحالية، مما جعل تشخيص الموقف أكثر صعوبة، حيث كان الفشل غير قابل للتفسير وغير مرئي. لم يكن أمام فريق Photon الكثير من الخيارات، وكان عليهم إعادة تشغيل الأجهزة لحل المشكلة، وهو أمر يكرهه أي مسؤول نظام باعتباره “حلًا” لمشكلة غامضة. ففي النهاية، إذا حدث ذلك مرة واحدة، فسوف يحدث مرة أخرى، وبالتأكيد في أسوأ وقت ممكن.
يستمر المقال أدناه
وبعد أن اكتشف الفريق مجموعة أخرى من الأجهزة التي كانت تصل إلى وقت تشغيل يبلغ 49.7 يومًا، قاموا بإعداد بعض البرامج النصية لاختبار نظريتهم. للأسف، وجدوا أنه عندما جاءت اللحظة المصيرية، توقف جهاز Mac الذي كانوا يقومون بإنشاء اتصالات جديدة باستمرار عن القيام بذلك دون أي خطأ.
ثم حول الفريق انتباهه إلى السبب الجذري، حيث كان من الواضح أنه مرتبط بمؤقت متعلق بالشبكة. لقد وجدوا أن الجاني هو “tcp_now”العداد الداخلي، وهو الرقم الذي كان “مقدرًا له أن يفيض”. المهمة التي يقوم بها tcp_now هي تتبع الوقت الحالي منذ بدء التشغيل بقدر ما يتعلق الأمر بمكدس TCP، وصولاً إلى المللي ثانية. يتم تمثيل tcp_now كعدد صحيح غير موقّع بطول 32 بت، ويبلغ الحد الأقصى لقيمته 4,294,967,295 (2^32 – 1) قبل أن يلتف حول الصفر. نظرًا لأنه يتتبع المللي ثانية، فإن الحد الأقصى لـ tcp_now هو 4,294,967 ثانية، أو 49.7 يومًا.
وفقًا للمعايير، تقوم أنظمة التشغيل بجمع وإزالة اتصالات TCP المغلقة بعد فترة قصيرة؛ 30 ثانية في حالة نظام التشغيل macOS. نتيجة محاولة تنظيف هذه الاتصالات غير النشطة عندما يكون tcp_now قريبًا من الحد الأقصى أو عنده (ويعلق هناك بفضل خطأ في XNU kernel من Apple) هو أن حالة انتهاء صلاحية أي اتصال يتم حسابها مقابل هذا الرقم المجمد، مما يؤدي إلى قيمة تتجاوز دائمًا عددًا صحيحًا غير موقّع 32 بت. عندما يأتي الفحص الدوري لمعرفة ما إذا كان من المفترض حذف اتصال مغلق، تكون النتيجة دائمًا “لا”، لأن حسابات المقارنة لا تعمل.
تمتلئ حزمة TCP بعد ذلك بالمنافذ المؤقتة التي تم الاحتفاظ بها بشكل خاطئ وتتوقف بشكل فعال عند عدم توفر المزيد. وتعتمد سرعة حدوث ذلك على مقدار نشاط الشبكة، ولكن في أي خادم أو بيئة احترافية، لا بد أن يكون هذا حدثًا سريعًا. هذه الفئة من المشاكل غير معروفة تقريبًا، فقد كانت تجاوزات الأعداد الصحيحة هي السبب في تعطل نظام التشغيل Windows 98 الشهير لمدة 49.7 يومًا ومشكلة عام 2038 القادمة.
احصل على أفضل أخبار Tom's Hardware والمراجعات المتعمقة، مباشرة إلى صندوق الوارد الخاص بك.
وفقًا لفوتون، فإن التخفيف الحالي هو إعادة تشغيل، على الرغم من أن الفريق يقول إنه يعمل على حل بديل. ووجدوا أيضًا أن هذه المشكلة هي مصدر بعض الأخطاء التي تمت مناقشتها عبر الإنترنت في منتديات مجتمع Apple أيضًا. يحدد RFC 7323 الموجود منذ فترة طويلة ما يجب أن يحدث لساعة الطابع الزمني (tcp_now) عندما تصل إلى الحد الأقصى، لكن نواة Apple تنفذ تنفيذًا غير صحيح. من الآمن أن نقول إنه من المرجح أن يتم حل هذه المشكلة بسرعة، ونأمل أن يتم ذلك قبل 49.7 يومًا من صدور التقرير.
يتبع أجهزة توم على أخبار جوجل، أو أضفنا كمصدر مفضل، للحصول على آخر الأخبار والتحليلات والمراجعات في خلاصاتك.
التعليقات