فحص سجل SRV العالمي
في حين أن سجلات A و AAAA القياسية تقتصر على ترجمة اسم نطاق إلى عنوان IP، فإن سجل SRV (الخدمة) أكثر تعقيداً بكثير. تم تحديد سجل SRV في RFC 2782، وهو ينشئ طريقة موحدة لتحديد اسم المضيف الدقيق، والبروتوكول، ورقم المنفذ الدقيق لتطبيقات شبكة محددة. إنها العمود الفقري لاكتشاف خدمات المؤسسات، وتستخدم بكثافة لـ Microsoft Active Directory، وتوجيه SIP/VoIP، والمراسلة الفورية XMPP، وهياكل خوادم الألعاب الجماعية الضخمة (مثل حل _minecraft._tcp.example.com).
التركيب النحوي (Syntax) وربط المنافذ (Port Binding)
يمكن التعرف على سجل SRV على الفور من خلال هيكل التنسيق الصارم الخاص به. يجب أن يبدأ اسم السجل بشرطة سفلية (Underscore) تشير إلى الخدمة، متبوعة بشرطة سفلية تشير إلى بروتوكول النقل، ومرفقة بالنطاق الأساسي (مثل _sip._tls.example.com). يقدم الـ Payload الناتج أربع نقاط بيانات محددة للعميل المتصل: الأولوية (Priority)، الوزن (Weight)، المنفذ الهدف (Port)، واسم المضيف الهدف الأساسي (Hostname). يسمح هذا للمسؤولين بتشغيل خدمات مميزة متعددة على عنوان IP واحد باستخدام منافذ غير قياسية، دون مطالبة المستخدمين النهائيين بحفظ أرقام المنافذ وكتابتها في عملائهم.
تجاوز الفشل الأصلي (Native Failover) وموازنة الحمل المرجحة
أقوى ميزة لسجل SRV هي منطق التوجيه الأصلي متعدد المستويات. يعمل الرقم الصحيح لـ الأولوية (Priority) تماماً مثل سجل MX؛ سيحاول العملاء المتصلون دائماً التفاوض على الـ Handshake مع الخادم ذي الأولوية الأقل أولاً. هذا يؤسس تكراراً لتجاوز الفشل الفوري (Failover Redundancy). إذا كانت السجلات المتعددة تشترك في نفس الأولوية تماماً، يتم تشغيل الرقم الصحيح الوزن (Weight). يعمل هذا كموازن حمل نسبي. إذا كان للخادم (أ) وزن 75 وللخادم (ب) وزن 25، فسيقوم تطبيق العميل بتوجيه 75٪ من الاتصالات الجديدة إلى الخادم (أ). يسمح هذا للمهندسين بتوجيه حركة المرور بذكاء عبر مجموعات ذات قدرات أجهزة متفاوتة.
لماذا يتجاهل HTTP سجلات SRV
أحد الأسئلة الشائعة من المطورين المبتدئين هو لماذا لا تستخدم حركة مرور الويب (HTTP/HTTPS) سجلات SRV لتحقيق موازنة الحمل الأصلية. الجواب تاريخي بحت. بحلول الوقت الذي تم فيه توحيد سجلات SRV، كانت الأعراف المعمارية لـ HTTP الذي يعمل بدقة على المنفذ 80 و HTTPS على المنفذ 443 مشفرة (Hardcoded) بشكل عالمي في كل متصفح ويب. كان من شأن تحويل الويب إلى عمليات بحث SRV أن يضيف عقوبة دقة هائلة (تتطلب Round-Trips إضافية) مقابل فائدة هامشية. بدلاً من ذلك، يعتمد HTTP على Load Balancers في طبقة التطبيق (Application-layer) وتوجيه Anycast IP.