الخلاصة

  • لعقد DHCPv4 الديناميكي ثلاث لحظات حاكمة: يبدأ T1 حالة RENEWING مع الخادم الذي منح العنوان، ويفتح T2 حالة REBINDING بالبث، ثم ينهي انقضاء العقد إذن العميل إن لم ينشئ DHCPACK مدة جديدة.
  • إعادة الارتباط توسّع فرصة التعافي ولا تجعل كل خادم يمكن الوصول إليه صاحب سلطة. لا يمدد خادم بديل العقد إلا إذا كانت له صلاحية إدارية محلية وحالة متسقة عن الارتباط.

شبكة تعمل، وسلطة بدأت تضيق

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

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

وصف العملية بأنها «تجديد تلقائي» يخفي هذه البنية. فالعميل لا يكرر الرسالة نفسها إلى المجموعة نفسها، بل ينتقل بين درجات من الألفة والتعافي ثم الانسحاب.

التخصيص الديناميكي جعل العنوان قابلاً للاسترداد

وصف RFC 1541، الصادر في أكتوبر 1993، التخصيص الديناميكي بأنه منح عنوان لمدة محدودة أو إلى أن يحرره العميل صراحة. وكانت العلاقة التي يديرها خادم DHCP بين العميل والعنوان وبقية المعلمات تسمى ارتباطاً.

أصبحت مجموعة IPv4 المحدودة قابلة لإعادة الاستخدام بالتتابع. يمكن للعنوان نفسه أن يخدم أجهزة مختلفة في أوقات مختلفة، لأن التسليم الأول لم يُعامل كملكية دائمة.

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

حمل العقد ثلاث ساعات لا ساعة واحدة

يفصل RFC 2132 بين الخيار 51 لمدة عقد العنوان، والخيار 58 لزمن التجديد T1، والخيار 59 لزمن إعادة الارتباط T2. القيم الثلاث فترات بالثواني منذ التخصيص وليست تواريخ على ساعة مدنية.

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

ترتيب الحدود هو الرسالة الأهم. يترك T1 وقتاً كافياً للحوار مع صاحب القرار الأصلي. ويترك T2 نافذة أخيرة لمسار تعافٍ أوسع. أما الانقضاء فليس موعد إعادة محاولة آخر، بل نهاية الارتباط القائم.

أعطى T1 الجواب الأول للخادم المؤجِّر

عند T1 ينتقل العميل من BOUND إلى RENEWING. وإذا كان يعرف عنوان الخادم الذي منحه العقد، يرسل إليه DHCPREQUEST ويضع عنوانه الحالي في ciaddr. لا يجمع عروضاً جديدة، بل يسأل عن استمرار قرار معروف.

يحفظ هذا التفضيل ملكية الحالة. فالخادم المؤجِّر يعرف الارتباط الذي أنشأه، وسياسة مجموعة العناوين، وأي تغييرات ينبغي أن تصاحب التمديد. يستطيع إصدار DHCPACK بمدة جديدة أو تغيير معلمات أو عدم تمديد العقد وفق القرار الإداري.

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

وسّع T2 مجال السماع لا مجال الشرعية

إذا لم يصل DHCPACK قبل T2، يدخل العميل REBINDING. يبث DHCPREQUEST، ويضع العنوان المستعمل في ciaddr، ولا يضع معرّف خادم. وبذلك تستطيع خوادم أخرى سماع ما قد لا يصل أبداً إلى الخادم الأصلي.

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

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

ACK وNAK والصمت أحكام مختلفة

ينشئ DHCPACK في RENEWING أو REBINDING استمرارية جديدة. يسجل العميل العقد والمعلمات المعادة ويبدأ مؤقتي T1 وT2 من جديد. وقد تحمل الرسالة إعداداً متغيراً، لذلك ليس التجديد تمديداً شكلياً لرقم واحد.

أما DHCPNAK فهو رفض واضح للإعداد الحالي. يجب على العميل وقف الاستعمال والعودة إلى التهيئة. الاستمرار بعد الرفض يحوّل حالة محفوظة إلى مطالبة تنازع مدير العناوين.

الصمت ليس قبولاً ولا رفضاً ما دامت المدة قائمة. يظل العقد القديم صالحاً وتستمر إعادة الإرسال المحدودة. لكن إذا انقضى قبل ACK، يطلب RFC 2131 من العميل الانتقال إلى INIT، وإيقاف بقية معالجة الشبكة، وطلب الإعداد كأنه غير مهيأ.

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

الذاكرة بعد إعادة التشغيل لم تكن حقاً

قد يتذكر العميل عنوانه السابق ويظن أنه عاد إلى الشبكة نفسها. تسمح INIT-REBOOT بطلب ذلك العنوان، لكنها تعامل الذاكرة باعتبارها اقتراحاً لا ملكية.

يبث العميل الطلب لأنه لا يعرف إن كان الخادم أو الموقع القديم ما زال مناسباً. يستطيع خادم التأكيد بـDHCPACK أو الرفض بـDHCPNAK. وإذا تعذر الاتصال، فلا يسمح RFC 2131 باستعمال الإعداد السابق إلا في الجزء الذي لم ينقض بعد من العقد.

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

أتاح FORCERENEW مراجعة مبكرة مضبوطة

كانت آلة الحالات الأصلية تتحرك أساساً بمؤقتات العميل. ثم أضاف RFC 3203 رسالة FORCERENEW أحادية الإرسال، كي يطلب الخادم من العميل دخول مسار RENEW الطبيعي قبل T1، مثلاً عند الحاجة إلى تغيير الإعداد.

لا تكتب FORCERENEW إعداداً جديداً بذاتها، بل تستدعي DHCPREQUEST عادياً. وإذا أراد الخادم سحب العنوان، يجيب الطلب بـDHCPNAK فيعود العميل إلى الاكتشاف.

يمكن لمحفز مزور أن يقطع الجلسات مراراً، لذلك أوجب RFC 3203 توثيق FORCERENEW وفق RFC 3118. حتى طلب المراجعة المبكرة يحتاج مصدراً مثبتاً وانتقالاً معروفاً، لا أمراً خفياً يغيّر الحالة المحلية.

منح الخادم لا يثبت خلو الوصلة

لا يستطيع DHCPACK حقيقي أن يثبت عدم استخدام مضيف آخر للعنوان على الوصلة المحلية. قرار خدمة الإعداد وملاحظة الوسط نوعان مختلفان من الأدلة.

يطلب RFC 5227 من مضيف IPv4 الاستقصاء قبل بدء استعمال عنوان مُعد حديثاً. وإذا اكتشف عميل DHCP تعارضاً، يرسل DHCPDECLINE. عندها تلتقي خطة الخادم بدليل محلي مضاد ويجب إعادة النظر فيها.

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

المصادر وحدود الدليل

تستند الوقائع التاريخية والبروتوكولية إلى RFC 1541 وRFC 2131 وRFC 2132 وRFC 3118 وRFC 3203 وRFC 5227:

تحدد هذه الوثائق عقد DHCPv4، ولا تثبت القيم الافتراضية الحالية أو تصميم التعافي أو صحة العميل أو حصة الانتشار لأي منتج أو شبكة مسماة. DHCPv6 بروتوكول مختلف، ونسبتا T1 وT2 الافتراضيتان لا تثبتان أن كل خادم يرسلهما أو أن كل عميل يستخدمهما.