رحلة طلب الويب: من DNS إلى HTTP وTLS

عند زيارة codehub.monster يحتاج الجهاز إلى عنوان IP. يفحص الذاكرة المحلية ثم resolver الذي قد يسأل خوادم DNS المتخصصة حتى يصل إلى السجل المسؤول عن النطاق. النتائج تخزن مؤقتًا وفق TTL لتقليل زمن الاستعلام والحمل.

قد يعيد النطاق أكثر من عنوان لأسباب توزيع الحمل أو شبكات توصيل المحتوى. DNS لا يضمن أن التطبيق يعمل؛ هو يوفر معلومات الوصول. نجاح resolve مع فشل الاتصال يعني أن التشخيص انتقل إلى طبقة أخرى.

بعد اختيار الوجهة ينشأ اتصال نقل، غالبًا TCP أو QUIC بحسب إصدار HTTP. في HTTPS تبدأ مصافحة TLS: يقدم الخادم شهادة تربط المفتاح بالنطاق، ويتحقق العميل من سلسلة الثقة والتاريخ والاسم، ثم يتفق الطرفان على مفاتيح جلسة مشفرة.

التشفير يمنع قراءة المحتوى أثناء النقل ويكشف العبث، لكنه لا يجعل التطبيق آمنًا من أخطاء الصلاحيات أو حقن SQL. كما أن شهادة صحيحة لا تعني أن محتوى الموقع موثوق؛ تعني أن الاتصال بالهوية المحددة مشفر ومثبت وفق سلطة الشهادة.

يرسل العميل method ومسارًا وheaders وربما body. يعالج الخادم الطلب ويعيد status وheaders وbody. GET يفترض أنه قراءة آمنة، وPOST ينشئ أو ينفذ عملية، وPUT/PATCH يعدلان، لكن التطبيق مسؤول عن احترام المعنى وعن التحقق من الصلاحيات.

استخدم 4xx لمشكلة في طلب العميل مثل عدم المصادقة أو عدم وجود المورد، و5xx لعطل منع الخادم من تنفيذ طلب صالح. لا ترجع 200 مع جسم يقول error؛ ذلك يعطل التخزين المؤقت والمراقبة والعملاء الذين يعتمدون على البروتوكول.

إذا لم يحل الاسم، افحص DNS والسجلات. إذا حل الاسم لكن الاتصال مرفوض أو ينتهي بمهلة، افحص الشبكة والمنفذ والخدمة. إذا ظهر خطأ شهادة، افحص النطاق والسلسلة والتاريخ. إذا وصل HTTP، استخدم status وheaders وسجلات الطلب لتحديد مشكلة التطبيق.

DevTools Network يعرض DNS والاتصال ووقت انتظار الاستجابة وحجم التنزيل بدرجات مختلفة حسب المتصفح. curl مفيد لفحص headers وإعادة إنتاج الطلب خارج الواجهة. لا تبدأ بتغيير عشوائي في React إذا كان الخطأ يحدث قبل وصول أي استجابة.