كيف يعمل بروتوكول HTTP (الجزء الرابع) "ترويسة الرد وكود الحالة".

- يونيو 15, 2019

بروتوكول HTTP

في الأجزاء السابقة (الأول, الثاني, الثالث) تحدثتا عن ماهية بروتوكول http ومراحل طلب صفحة انترنت من سيرفر ما, والآن نكمل مع آخر مرحلة من هذه المراحل وهي...

الخطوة الرابعة: استقبال الرد من السيرفر.

بعد ان يستقبل السيرفر ترويسة الطلب عبر اتصال TCP/TLS ويقوم بمعالجتها, وبعد أن يجلب البيانات المطلوبة سواء من قاعدة البيانات أو من نظام الملفات يبدأ في تكوين ترويسة الرد ويقوم بوضع هذه المعلومات فيها ويرسلها بعد ذلك إلى المتصفح.

وبالنسبة لهذه الترويسة فتكون شبيهة جدا من ترويسة الطلب في البنية, ومثال على ذلك:

إذا ارسلنا هذه الترويسة في الطلب:

GET /How-does-HTTP-work HTTP/1.1\r\n
User-Agent: curl/7.24.0 (amd64-portbld-freebsd8.4) libcurl/7.24.0 OpenSSL/0.9.8y zlib/1.2.3\r\n
Host: http://www.quora.com\r\n
Accept: */*\r\n

r\n\

نحصل على هذا الرد:

HTTP/1.1 200 OK\r\n
Cache-Control: private, no-store, max-age=0, no-cache, must-revalidate, post-check=0, pre-check=0\r\n
Content-Security-Policy: default-src * data: blob:;style-src * 'unsafe-inline';script-src: https://*.quora.com https
Content-Type: text/html; charset=utf-8\r\n
Expires: Fri, 01 Jan 1990 00:00:00 GMT\r\n
Pragma: no-cache\r\n
Server: nginx\r\n
Set-Cookie: m-b="ycQZx8DYXuN_5BkR08oCDQ\075\075"; Domain=.http://quora.com; Max-Age=63072000; Path=/; expires=Sun, 09-Aug-2020 21:27:48 GMT; secure; HttpOnly\r\n
Set-Cookie: m-s="MI_Lrt7GQizk-YF8D1UJXw\075\075"; Domain=.http://quora.com; Max-Age=63072000; Path=/; expires=Sun, 09-Aug-2020 21:27:48 GMT; secure; HttpOnly\r\n
Set-Cookie: m-tgvs="G9up5DnnkGWPV9WS1NXRjyRh18qKVLrHkutQ

G8pDKeJ9yiyVJf5318cPkt6Qn0lJhYLTBe7mmomjlRxnoIUN1w\075\075"; Domain=.http://quora.com; Max-Age=63115200; Path=/; expires=Mon, 10-Aug-2020 09:27:48 GMT\r\n
Set-Cookie: m-early_v=daf763e7c3ddda99; Domain=.http://quora.com; Max-Age=63115200; Path=/; expires=Mon, 10-Aug-2020 09:27:48 GMT\r\n
Strict-Transport-Security: max-age=31536000;\r\n
X-Content-Type-Options: nosniff\r\n
X-Frame-Options: SAMEORIGIN\r\n
X-UA-Compatible: IE=Edge, chrome=1\r\n
X-XSS-Protection: 1; mode=block\r\n
Transfer-Encoding: chunked\r\n
Accept-Ranges: bytes\r\n
Date: Fri, 10 Aug 2018 21:27:48 GMT\r\n
Via: 1.1 varnish\r\n
Connection: keep-alive\r\n
X-Served-By: cache-pao17433-PAO\r\n
X-Cache: MISS\r\n
X-Cache-Hits: 0\r\n
X-Timer: S1533936468.271117,VS0,VE103\r\n

r\n\
!DOCTYPE html><html lang=en><head><link rel='icon' href='https://qsf.fs.quoracdn.net/-3-images.favicon.ico-26-3f34badcb59c8f6c.ico' /><script type="text/javascript">window.Q = {"fontFamilies": ["q-icons", "q_serif"], "errorSamplingRate": 1.0, "settings": {"action": "q", "actionTrail": null, "batchedServerCallUrl": "/webnode2/batched_server_call_POST", "clientLogTrail": null, "componentInspector": false, "controller": "question", "cookiePrefix": "m", "debug": false, "enableFrameBusting": true
. . .

ويشير السطر الأول منها إلى حالة الرد ويكون على الشكل (الإصدار كود-الحالة الرسالة).

الإصدار: ويشير إلى إصدار بروتوكول نقل النص التشعبي المستخدم في ارسال ترويسة الطلب.

كود الحالة والرسالة: وفي هذه الحالة " OK 200" تعني أن السيرفر وجد الملفات أو المعلومات المطلوبة بنجاح وأرفقها في الرد. وهناك أيضا حالات أخرى معرفة ضمن البروتوكول http ومنها "found 302" والتي تستخدم لإعادة توجيه المتصفح إلى عنوان URL آخر, و"not found 404" والتي تعنى أن السيرفر لم يجد المعلومات أو المطلوبة, و الحالة "internal server error 500" والتي تعني أنه حدث خطاء ما بداخل السيرفر.

يحتوي الرد كما ترى على حقول كثيرة والتي تحدثنا عنها في الجزء السابق وسأشرح البعض منها:

حقل "content-type" : يخبر المتصفح أن محتويات الرد (الملف المطلوب) هو نص بلغة HTML بترميز UTF-8 وهذا الترميز يحتوي على حروف ليست في جدول ASCII.

حقل "server" : يخبر المتصفح بنوع السيرفر المستخدم وهو هنا NGINX.

حقول "set-cookie" : يستخدمها السيرفر لتخزين بيانات محلية في المتصفح. ولقد اكتسبت الكوكيز سمعة سيئة بسبب سهولة استخدامها في خرق الخصوصية (مثل تتبع المستخدمين) وسرقة معلومات حساسة عن مستخدمي المواقع.

ولكنها رغم ذلك ذات أهمية كبيرة في عمل معظم المواقع, فمثلا تستخدم لحفظ تسجيل دخولك فلا تحتاج لفعل ذلك في كل مرة تزو الموقع.
وفي هذا الحقل تم تعريف cookie بالشكل m-b="ycQZx8DYXuN_5BkR08oCDQ\075\075″ وهذه ال cookie سوف ترسل إلى السيرفر مع كل طلب من الطلبات اللاحقة.

وهذا النص ذو الشكل الغريب ربما يكون مشفر باستخدام خوارزمية Base64 وهو يستخدم كمعرف لمتصفحي وربما يستخدم للإشارة إلى بياناتي في قاعدة البيانات.

وكذلك تم تعريف "domain" وهو الموقع الذي يمتلك هذه ال cookie وهو مهم حتى لا يتمكن أي موقع آخر من استخدامها.

وقيمتي "max-age" و"expires" تشيران إلى المدة التي سيحتفظ فيها المتصفح بها. وإذ أردت معرفة المزيد عنها يمكنك النظر هنا.

حقل "transfer-encoding" : يحدد الكيفية التي ستنقل بها محتويات الرد إلى المتصفح, وأبسط طريقة لفعل لذلك هي وضع المحتويات بالكامل في الرد وكذلك وضع حقل "content-length" الذي يحتوي على حجم البيانات بالبايت.

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

ويمكن لهذه البيانات (لاحظ هنا أنه هناك فرق بيت ترويسة الرد ومحتويات الرد) أن تكون خليط من أنوع مختلفة من البيانات (HTML, CSS, JavaScript, JSON, ...etc).
وفي النهاية يعالج المتصفح البيانات ويعرضها أمامك كما تراها الآن.

وبينما ركزت على ذكر الطلب والرد لصفحة الانترنت, فمن الجدير بالذكر أنه يحدث في الخلفية طلبات أخرى لكل صورة في الصفحة مع الفعل GET وينتج ردا به الحقل "content-type" وله القيمة "image/jpeg" أو أي نوع آخر من الصور.

في المتصفحات الكبرى يوجد أدوات لتتبع الطلبات الصادرة والردود الواردة وهي موجودة في "أدوات المطور", وفي متصفح كروم توجد في المسار "more-tools >> developer tools" وتبدو بهذا الشكل:

chrome dev tools

وبهذا ينتهى المتصفح من عرض الصفحة أمامك بالكامل, وينتهى الجز الأخير من شرح عمل البروتوكول.

إلى اللقاء.😀

ابحث هذه المدونة الإلكترونية

المهووس

كيف يعمل بروتوكول HTTP (الجزء الرابع) "ترويسة الرد وكود الحالة".

تعليقات

إرسال تعليق

المشاركات الشائعة من هذه المدونة

30 شيء تمنيت لو عرفتها عندما بدأت في البرمجة(الجزء الأول).

ما هي مبادئ SOLID؟ ولما يجب أن يعرفها كل مطور؟

كيف تصبح مطور ويب وتحصل على وظيفة في أسرع وقت؟ (الجزء الثاني)