الجمع الاختباري لمستوى التطبيق لأن المجموع الاختباري لبرنامج التعاون الفني قد يكون ضعيفًا جدًا؟

Question

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

هل هناك أي مطوري تطبيقات يقومون بحماية البيانات من هذا النوع من الأخطاء عن طريق إضافة مجاميع اختبارية على مستوى التطبيق؟

هل هناك أي أنماط متاحة للحماية من مثل هذه الأخطاء أثناء القيام باستدعاء طريقة EJB عن بعد (Java EE 5)؟أو هل تقوم Java بالفعل بفحص المجموع الاختباري للكائنات تلقائيًا (بالإضافة إلى بروتوكول الشبكة الأساسي)؟

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

لم أكن خائفًا أبدًا من أخطاء بت الشبكة بسبب بروتوكول TCP - حتى رأيت هذا المقال.

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

هل يتجاهل كل بائعي برامج المؤسسات مثل SAP وOracle وغيرهم هذا النوع من المشاكل؟ماذا عن البنوك؟ماذا عن برامج البورصة؟

متابعة: شكرا جزيلا لجميع إجاباتك!لذلك يبدو أنه من غير المألوف التحقق من تلف بيانات الشبكة التي لم يتم اكتشافها - ولكن يبدو أنها موجودة.

ألا يمكنني حل هذه المشكلة ببساطة عن طريق تكوين خوادم تطبيقات Java EE (أو واصفات نشر EJB) لاستخدام RMI عبر TLS مع تكوين TLS لاستخدام MD5 أو SHA1 وعن طريق تكوين عملاء Java SE للقيام بنفس الشيء؟هل ستكون هذه طريقة للحصول على مجموع اختباري شفاف وموثوق (على الرغم من المبالغة فيه) حتى لا أضطر إلى تنفيذ ذلك على مستوى التطبيق؟أم أنني مرتبك تمامًا من حيث الحكمة في مكدس الشبكة؟

Answer 1

أنا مقتنع بأن كل تطبيق يهتم بسلامة البيانات يجب أن يستخدم تجزئة آمنة.ومع ذلك، فإن معظمهم لا يفعلون ذلك.الناس ببساطة يتجاهلون المشكلة.

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

كانت الرسائل عبارة عن أشياء مثل أوامر الأسهم والتداولات.إن عواقب إفساد البيانات خطيرة كما تبدو.

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

لقد حددنا المشكلة بالحظ - حيث فشلت جلسة SSH لشخص ما بين اثنين من الخوادم المعنية مع ظهور رسالة خطأ غريبة.من الواضح أن SSH يجب أن يضمن سلامة البيانات.

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

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

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

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

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

Answer 2

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

Answer 3

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

أكثر فائدة من المجاميع الاختبارية إذا كنت حقا يحتاج سيكون الضمان الإضافي على مستوى التطبيق عبارة عن تجزئة SHA-N للبيانات، أو MD5، وما إلى ذلك.