أغلب إن لم يكن كل المستخدمين قد سمع بال HTTP من قبل، على الأقل قاموا بكتابته في المتصفحات http:// لفتح المواقع المطلوبة. وبالرغم من الاستخدام المتكرر الا أن كثير من المختصين (مطورين تطبيقات الويب، مختصي الحماية، مدراء الأنظمة) ليست لديهم معلومات كافية حول هذا البروتوكول، والذي أصبحت تعتمد عليه الكثير من التقنيات. بدءاً من مواقع الويب سواء كانت Static أو Dynamic، مروراً بخدمات الويب Web services مثل ال RESTful، ومروراً باليات حفظ الجلسات State Management والكوكيز Cookies وكيفية حمايتها، وانتهاءً بالخدمات المساعدة حتى يمكن تحمل المزيد من الطلبات مثل Load Balancer أو استخدام البروكسيات Proxies بأنواعها المختلفة.

في هذا الموضوع سوف يتم الحديث بشكل سريع (نظرة من 30000 قدم) حول البروتوكول وكيف يعمل، وبعض المصطلحات الأساسية مثل ال Resources وال Transactions وشكل الرسائل المرسلة من الكلاينت الى السيرفر، بالإضافة الى أمثلة على ارسال طلبات HTTP باستخدام بعض الأدوات واللغات.

بقية المواضيع القادمة، سوف تتناول هذه الفقرات مجدداً ولكن تقوم بالتفصيل فيها، بالإضافة لبعض المواضيع الأخرى، ومن هذه المواضيع:

بعد انتهائك من جميع المواضيع، سوف تكون قادراً على:

• كيف يعمل ال Cookies وكيف تحمي ال Cookies بشكل صحيح من ال Hijacking
• ال Authentications وأنواعها المختلفة
• كيف يعمل ال HTTPS وتفاصيله
• ال Headers المستخدمة في الحماية مثل ال HSTS وال HPKP وال CSP في المتصفح.
• استخدام ال HTTP Caching بكفاءة
• معرفة ال Load Balancer وال Proxies بأنواعها
• كيف تعمل ال Web Crawling وال Data Scrapping
• كيف يعمل ال Web Servers وتقوم بكتابة ويب سيرفر صغير
• كتابة HTTP Proxy لعمل Logging وفلترة للبيانات
• كتابة HTTP Tunnel وارسال بيانات عبر بروتوكولات غير مدعومة في الشبكة.

باختصار سوف تكون مبرمج مواقع وخدمات ويب أفضل، مدير مواقع ويب أفضل، فهم أفضل في حماية مواقع وخدمات الويب، ولذلك ال HTTP هو الأساس في الويب.

مقدمة

ال HTTP هو البرتوكول الذي يعمل عليه الويب، وهو الذي من خلاله تتواصل مع السيرفر وترسل البيانات فكل الطلبات التي تقوم بها من المتصفح (الكلاينت Client) أو التطبيقات في الجوالات، سواءً كانت تعبئة النماذج والتسجيل، أو شراء المنتجات وتصفح مواقع التواصل الاجتماعي أو مشاهدة المقاطع على اليوتيوب. فكلها تستخدم برتوكول ال HTTP.

وهذه الطلبات سوف تذهب الى السيرفر (ال Web Server) ويتم بها تحديد المحتوى الذي يريد المستخدم الوصول اليه (ال Resource) وذلك من خلال الرابط للمحتوى (ال URI) ويكون لها صيغة معينة في الطلب HTTP Request Message يتم تحديد بعض المعلومات حول الكلاينت الذي أصدر الطلب Request Headers.

ومن ثم يقرأ السيرفر الطلب، ويجلب المحتوى ويرسله الى الكلاينت (ال HTTP Response Message)، وفي الرد سوف يحدد السيرفر نوعية المحتوى MIME Type حتى يستطيع المتصفح عرضه بالطريقة المناسبة بالإضافة الى نتيجة الرد سواء كان المحتوى موجود أو غير موجود Status Code وبعض المعلومات الأخرى.

داخلياً فال HTTP يقوم بفتح اتصال TCP Socket مع السيرفر من خلال عنوانه IP Address ورقم البورت (الافتراضي 80 إذا لم يتم تحديده)، ومن ثم بعد فتح الاتصال يتم ارسال الطلب HTTP Request، وعادة ما يتم الرد ال HTTP Response في نفس الاتصال أو يمكن ان تكون كلاً في اتصال TCP مختلف عن الآخر.

انتهت المقدمة وسوف نبدأ الآن الجولة مع المصطلحات السابقة ونأخذ لمحة بسيطة عن كل منهم.

الفرق بين الويب Web والإنترنت Internet

قبل الولوج في ال HTTP، نذكر بالفرق بين الانترنت Internet وال World Wide Web (اختصاراً WWW أو Web)، حيث يخلط الكثيرين بينهم، حيث ان الويب Web ما هو إلا جزء من الانترنت Internet. فالإنترنت هي الشبكة العالمية والتي تقدم العديد من الخدمات مثل الويب، البريد الالكتروني، تبادل الملفات FTP وغيرها من الخدمات. بينما الويب هو أحد الخدمات التي تعتبر الأكثر استخداماً لذلك قد يطلق البعض على الويب بالإنترنت.

السيرفر Web Server والكلاينت Web Client

كل محتوى المواقع التي تزورها توجد على سيرفرات في مكان ما، وهذه ال Web Servers يتواجد بداخلها ذلك المحتوى وهي التي تقوم بخدمتك بهذا المحتوى، وهذه ال Web Servers تستخدم بروتكول ال HTTP لذلك احياناً تسمى HTTP Servers.

عندما تطلب موقعاً ما فأنت تستخدم ما يعرف بال Web Client وهو الذي يرسل طلب ال HTTP (ال HTTP Request) الى السيرفر، والذي يقوم بفهم الطلب وارجاع الرد المناسب لك (HTTP Response).

المتصفحات Web Browsers التي تستخدمها للدخول على المواقع (مثل Chrome, Firefox وغيرها) هي تعتبر Web Client وتقوم بإرسال طلب ال HTTP وعرض النتيجة من السيرفر بالشكل المناسب. مثلاً قمت بكتابة الرابط http://ksu.edu.sa/ في المتصفح وقمت بالدخول عليه، فسوف يقوم المتصفح بإرسال طلب ال HTTP الى سيرفر الموقع، ويقوم السيرفر بإيجاد الصفحة التي تريدها (الصفحة الرئيسية في الموقع) وإذا تم الايجاد فسوف يرسل لك محتوى الصفحة داخل الرد HTTP Response بالإضافة الى نوع المحتوى وحجمه وبعض المعلومات، حتى يقوم المتصفح بعرض المحتوى بالطريقة المناسبة لذلك المحتوى.

محتوى المواقع Resources

السيرفرات Web Servers تحتوي على محتوى الموقع من صفحات وصور وملفات والخ، وهذا المحتوى نسميه بال Resources، سواء كانت صفحات Pages أو الصور Images أو حتى ملفات الصوت والفيديو كلها تعتبر Resources، ولو نظرت للويب فسوف تجد أن هناك بلايين ال Resources الموجودة.

هذه ال resources يمكن ان تكون موجودة فعلياً في نظام ملفات السيرفر Physical Files (أو Static Files) أو أنها تكون غير موجودة على القرص وانما يقوم الموقع بتوليدها وقت الحاجة Dynamic Resources، سواء من خلال هويتك في الموقع، او على حسب الطلب الذي تريده او حتى الوقت الان.

الصورة التالية تبين عدة انواع من ال Resources المختلقة، فمثلاً الصورة والملف نصي هما Static Resources بينما الاخرى هي Dynamic Resources تكون من داخل الموقع من قاعدة البيانات ويتم جلبها، أو من خدمات اخرى خارجية مثل خدمة الطقس او التاريخ والوقت وغيرها سواء كانت تتبع لنفس الجهة، أو من مواقع اخرى لجهات خارجية.

أنواع المحتوى Media Types

كل سيرفر في الويب يخزن العديد من انواع البيانات المختلفة، لذلك في ال HTTP يجب تحديد نوع كل محتوى object يتم ارساله عبر الويب، وهذه العلامة تعرف بال MIME Type. وال MIME هي اختصار ل Multipurpose Internet Mail Extensions وهي صممت في الأساس لحل مشكلة ارسال رسائل البريد بين الانظمة المختلفة، وتم استخدامها في ال HTTP لتحديد نوع المحتوى لكل ما يتم ارساله.

الصورة التالية تبين ان السيرفر ارجع صورة للكلاينت وفي الرد لاحظ انه تم تحديد MIME Type (بالاسم Content-Type) وتم تحديد النوع كصورة image/png. وبعد وصول الرد للمتصفح فسوف يقوم بالتعامل مع المحتوى على حسب نوعه، وغالب المتصفحات تستطيع التعامل مع مئات الأنواع من الملفات المختلفة. حيث سيتم عرض الصورة إذا كان المحتوى صورة، او يتم عرض الصفحة إذا كان المحتوى هو HTML، أو يتم تشغيل ملف الصوت، أو استدعاء plugin لتشغيل ملف من نوع محدد.

وال MIME Type هو نص يوضع على ال Content-Type، ومن الأمثلة عليه:

وغيرها المئات من ال MIME Types يمكنك مشاهدتهم في هذه القائمة (قائمة أنواع ال MIME).

الروابط URIs

كل ال resources في السيرفرات لديها طريقة يمكن من خلالها الوصول لها (حتى تستطيع الوصول لها)، وهذا ما يعرف بال Uniform Resource Identifier واختصاراً URI. وال URI هو نص يعرف Identify اسم او مسار أو كلاهما (اسم ومسار) لأي resource. وهناك نوعين من ال URI، وكلاهما يعرفان ال resources:

• ال URL وهو اختصاراً Uniform Resource Locator وهو أشهر اشكال تحديد ال resources. وهو يحدد مسار ال resource بالضبط في السيرفر، واي URL يعتبر URI.
• ال URN وهو اختصار ل Uniform Resource Name. وهو يسمي ال resource، بغض النظر عن مكان تواجده. وهذه الخاصية (عدم تحديد المكان) تسمح لل resources بالانتقال من مكان لأخر وبالتالي يتم الوصول له من خلال نفس الاسم. وأي URN يعتبر URI.

ال URL بشكل عام يتكون من 3 أجزاء:

• ال Scheme ويتم تحديد البروتكول المستخدم مثلاً http (يبدأ الرابط http://) أو ftp://
• عنوان الموقع example.com
• مسار واسم ال resource مثلاً /products/mobile.png

مثال على ال URI لصورة في أحد السيرفرات (رابط الشعار)، كما في الصورة التالية، ومن خلال ال URL (أو URI) سوف تجد أنك تستطيع الوصول للمحتوى Resource في السيرفر:

بينما ال URN فهي تبدأ دائماً ب urn: وهي يمكن ان تستخدم للملفات وغير الملفات مثل مفاهيم او أفكار معينة تحتاج لأسماء فريدة. وإذا كان ال URN يمثل اسم لملف فيمكن ان يتم تحويل ال URN الى URL من خلال محول يقوم بتحويل النوع الى الآخر.

من الأمثلة على ال URN:

• urn:ietf:rfc:2141 وهو يشير الى RFC 2141
• urn:ISBN0-486-27557-4 وهو يشير الى الرواية التي تحمل رقم ال ISBN

ال URN ليست منتشرة وتحتاج لبنية معينة تستطيع فهم ايجاد ال resource ومكانه من الاسم الفريد. ولن نتحدث عن ال URN ومن هذه النقطة عندما نتحدث عن الروابط أو ال URI فغالباً نتحدث عن ال URL.

التواصل بين الكلاينت والسيرفر Transactions

ال HTTP يعمل بمفهوم ال Request-Response وهذا ما نطلق عليه بال Transaction، حيث تبدأ ال Transaction من طلب الكلاينت HTTP Request الذي يرسل الى السيرفر، وينتهي بالنتيجة التي يرسلها السيرفر الى الكلاينت HTTP Response. وفي الطلب المرسل من الكلاينت، والنتيجة الراجعة من السيرفر يكون هناك محتوى أو بيانات نطلق عليها الرسالة HTTP Message بين الكلاينت والسيرفر.

طرق الطلبات Methods

ال HTTP يدعم أكثر من نوع للطلبات وتسمى بال HTTP Methods، وكل طلب يتم ارساله يجب ان يحدد الطريقة له. هذه الطريقة Method تخبر السيرفر بنوع العمل المراد تنفيذه مثلاً جلب صفحة الويب، تشغيل برنامج ما، حذف ملف، وهكذا. الجدول التالي يعرض أكثر 5 طرق استخداماً.

نتيجة الرد Status Code

كل الردود HTTP Response من السيرفر تأتي بنتيجة ما Status Code، وهو رقم من 3 خانات يخبر الكلاينت هل الطلب تم بنجاح أم ان هناك شيء على المتصفح القيام به مثلاً. من بعض هذه ال Status Code هي:

وبعد ال Status Code يأتي وصف نصي يوضح النتيجة وهذا النص لا يتم قراءته بواسطة الكلاينت وانما يتم التعامل مع ال Status code. ولذلك النتائج التالية هي نفسها من وجه نظر الكلاينت

200 OK
200 Document attached
200 Success
200 All’s cool, dude

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

الصفحات تتكون من العديد من ال Resources

عادة ما تتكون صفحات الويب من العديد من ال resources التي يجب جلبها، لذلك سوف يقوم المتصفح بإرسال العديد من الطلبات حتى يعرض صفحة واحدة (لكل Resource يتم ارسال طلب له)، حيث يقوم المتصفح اولاً بطلب الصفحة المطلوبة HTML واثناء عرضها في الصفحة سوف يقابل العديد من ال resources الاخرى مثل ملفات الجافا سكربت، الصور، ملفات ال css سواء كانت في نفس السيرفر او في سيرفر اخر، فسوف يقوم المتصفح بطلب هذه ال resources كلأ في طلب منفصل.

محتوى الطلب والرد Messages

بنية الطلب والرد تكون مطابقة لبروتكول ال HTTP حتى يستطيع الطرفان التحدث فيما بينهم، ومحتوى الطلب HTTP Request والرد HTTP Response نطلق عليه الرسائل Messages، وتركيبة هذه الرسائل Messages بسيطة، حيث هي مجموعة من الأسطر النصية plain text كل منها ينتهي بسطر فارغ new line (CRLF) ولهذا هي سهلة القراءة والكتابة حتى للمستخدمين أنفسهم.

الصورة التالية تعرض الرسائل بعد اجراء Transaction (طلب ورد)

الرسائل المرسلة من الكلاينت الى السيرفر نسميها Request Messages بينما الرسائل المرسلة من السيرفر الى الكلاينت تسمى Response Messages. وهيكل هذه الرسائل مشابه لبعض بشكل كبير.

وبشكل عام تتكون الرسالة HTTP Message من 3 اجزاء:

• السطر الأول Start Line: وهو الذي يخبر ما الذي يجب فعله في حال كانت الرسالة هي طلب، او ماذا حدث إذا كانت الرسالة هي رد Response.
• حقول الترويسة Header Fields: وهي مجموعة من الحقول تتكون من اسم وقيمة (بينهم نقطتان) حتى يسهل عمل قراءتها. والترويسة تنتهي بسطر فارغ Blank Line، وقد تكون هناك أكثر من ترويسة وقد لا يكون هناك اي شيء بها.
• المحتوى Body: بعد السطر الفارغ يأتي الجزء الاختياري وهو المحتوى وقد يحتوي على اي بيانات. فاذا كانت الرسالة هي طلب فالمحتوى هي البيانات المراد ارسالها للسيرفر، وإذا كانت الرسالة رد فالمحتوى يكون البيانات المرسلة من السيرفر الى الكلاينت. وهذا الجزء Body يمكن ان يحتوي على بيانات سواء كانت نصية او حتى ثنائية binary مثل الصور، الفيديو، الملفات.

الصورة التالية تعرض الرسائل بعد اجراء Transaction:

في الصورة اعلاه قام المتصفح بطلب الصفحة https://informatic-ar.com/ وتم ارسال الطلب وبدء الطلب بال GET Method في السطر الأول، وبعدها مسار ال resource المطلوب وهو / (وهو الصفحة الرئيسية في الموقع) وحدد الطلب بأنه يستخدم النسخة 1.1 من البرتوكول HTTP. ولا يوجد اي body في الطلب لأنه لا يحتاج لإرسال بيانات لجلب GET صفحة من السيرفر.

وقام السيرفر بإرسال الرد HTTP Response Message واحتوى على نوع البروتكول 1.1 وال Status Code، وصف له OK، ومن ثم مجموعة من الترويسات Header Fields وبعدها أتى محتوى الصفحة المطلوبة. من الترويسات المستخدمة هي طول المحتوى Content-Length ونوع المحتوى Content-Type.

نسخ البروتوكول Versions

هناك العديد من النسخ المستخدمة في ال HTTP ومنها:

• HTTP/0.9 وهي اول نسخة مبدئية لل HTTP، واحتوت على مشاكل كثيرة في التصميم. وهي تدعم GET فقط، ولا تدعم ال MIME ولا ال HTTP Headers. وهي صممت فقط لجلب ال HTML فقط.
• HTTP/1.0 وهي النسخة التي انتشرت بعد ذلك، وتم اضافة رقم النسخة في ال Headers، وتم دعم ال methods الاخرى، وال MIME. وأصبح هنا بالإمكان عرض الصفحات التفاعلية واخذ المدخلات من المستخدم وهذا ما ساعد الويب World Wide Web في الانتشار.
• HTTP/1.0+ قامت العديد من الكلاينت مثل المتصفحات وال Web Servers بإضافة بعض الخصائص لل HTTP في منتصف التسعينيات بحسب احتياجاتهم. مثل ال keep-alive ودعم البروكسي، ولكنها لم تصبح رسمية. ولذلك هذه النسخة لم تعد كنسخة رسمية في البروتوكول
• HTTP/1.1 وهي الأكثر انتشاراً حالياً في كل المواقع والمتصفحات، وتم اصلاح العديد من المشاكل في تصميم البروتوكول، واضافة خصائص تحسين الاداء، وطور في أواخر التسعينيات
• SPDY سبيدي حتى 2005 طُرِحت العديد من المقترحات حول تغيير ال HTTP الحالي، وكان أهم هذه الاطروحات هو SPDY بواسطة موظفين من قوقل، وقد حاز على العديد من الاهتمامات بواسطة الشركات، المبرمجين ودعم المتصفحات، مما جعل ال IETF تبدء في تطوير النسخة الثانية من ال HTTP ووضع المعايير لها وهذا ما يعرف بال HTTP/2 أو h2 اختصاراً.
• HTTP/2.0 النسخة الثانية من ال SPDY/2 اعتبرت هي نواة ال HTTP/2 وحتى المطورين الاساسين اشتركوا في وضع المعايير في ال HTTP/2، وبالتالي اصبح ال HTTP/2 هو المعيار الحالي لل HTTP ونشر المعيار في 2015، وهذه النسخة أصبحت binary بدلاً من نصية وأصبحت أكثر كفاءة في إدارة الاتصالات والضغط (ضغط ال Headers) وبالتالي أصبحت أسرع بكثير جداً. والجميل أن النسخة هذه لا تتطلب أي تغيير في تركيبة وبنية المواقع حتى تستطيع دعم هذه النسخة، وكل المتصفحات أصبحت تدعم هذه النسخة الان وكما أنها تجبر كل المواقع التي تدعم هذه النسخة باستخدام TLS، وبالتالي كل المواقع تصبح HTTPS مباشرة، وحسب الاحصائيات May-2017 (بواسطة W3Techs) فإن حوالي 13% من أشهر 10 مليون موقع أصبح يدعم هذه النسخة، ويمكن تجربة سرعة ال HTTP/2 من خلال الموقع httpvshttps.com) والصورة التالية تبين الفرق في السرعة بين هذه النسخة والنسخة السابقة، سوف نتحدث عن النسخة هذه في مقالة منفصلة.

كيف يتم اجراء الاتصال Connections

أخذنا فكرة عن ال HTTP والرسائل وال Transaction، لنتحدث عن كيف تنتقل هذه الرسائل من مكان آخر، وأول معلومة هي ان بروتكول ال HTTP يعتبر من بروتوكولات طبقة التطبيقات Application Layer Protocol وهذا يعني ان ال HTTP لا يحتاج لأن يعرف التفاصيل الشبكية وكيف ستنتقل الرسائل حتى تصل للطرف الاخر. وسوف تكون من مسؤولية طبقات اخرى القيام بذلك. وهنا يأتي دور البرتوكول الشائع الموثوق في النقل وهو TCP.

فبعد أن يتم فتح اتصال ال TCP يتم ارسال الرسائل بين الكلاينت والسيرفر، وال TCP سوف يضمن عدم فقدان الرسائل، وأنها تصل كاملة وبالترتيب الذي ارسلت فيه.

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

بهذا الشكل، عندما يريد الكلاينت ارسال رسالة الى السيرفر، فيقوم اولاً بفتح اتصال TCP بين الكلاينت والسيرفر ويتصل بالسيرفر من خلال عنوانه IP Address ورقم البورت الذي يعمل على الويب سيرفر.

لذلك يمكن للمبرمج التواصل مع ال HTTP Server باستخدام مكتبات ال HTTP أو انه يقوم مباشرة بفتح ال TCP Socket وكتابة البيانات HTTP Request مباشرة بدون الحاجة الى مكتبات HTTP.

وفتح الاتصال TCP مشابه لعملية اتصال على أحد ما داخل شركة، فسوف يتم الاتصال أولاً برقم الشركة، ومن ثم بعدها ادخال رقم التحويلة للشخص المراد الوصول له. وفي ال TCP تحتاج الى عنوان السيرفر IP Address حتى تقوم بالاتصال عليه، ورقم البورت الذي يسمته اليه البرنامج الموجود على السيرفر.

ويتم جلب عنوان السيرفر ورقم البورت من خلال اURL، وهذه أمثلة على عدة URL وكيف يمكن جلب البيانات منها، ويتم معرفة العنوان والبورت، حيث بعدها يستطيع المتصفح فتح اتصال TCP بسهولة

والخطوات التي يقوم بها المتصفح هي:

• يقوم المتصفح باستخراج ال Hostname من ال URL
• يقوم المتصفح بالحصول على ال IP Address من خلال ال DNS
• يقوم المتصفح بالحصول على ال port (إذا وجد، والا استخدم الافتراضي)
• يقوم المتصفح بفتح اتصال TCP مع الويب سيرفر
• يرسل المتصفح HTTP Request Message الى السيرفر
• السيرفر يرسل ال HTTP Response Message الى الكلاينت
• يغلق اتصال ال TCP ويقوم المتصفح بعرض النتيجة

ملاحظة: حالياً في البروتوكول HTTP/1.1 فالاتصال لن ينقطع مباشرة في الوضع الافتراضي، وانما سينقطع بعد فترة من عدم الاستخدام idle time، وذلك حتى يسمح للطلبات التالية بأن ترسل وبالتالي يتحسن الأداء، وليس كما كان عليه في السابق، في موضوع ال Connections سوف نتحدث عن هذه الخاصية Connection Persistence بالتفصيل.

معمارية الويب Web Architecture

في هذا الموضوع، تحدثنا عن كيفية التواصل بين برنامجين (المتصفح Web Browsers والسيرفر Web Servers) والرسائل بينهم في ال Transaction. ولكن هناك العديد من البرامج الاخرى التي قد تتعامل معها، ومنها:

• ال Proxy وهي برامج تكون موجود بين الكلاينت والسيرفر
• ال Caches وهي برامج تحفظ البيانات الأكثر شيوعاً قرب الكلاينت
• ال Gateways وهي برامج ويب سيرفر ولكنها تتعامل مع تطبيقات اخرى
• ال Tunnels وهو بروكسي يقوم بإرسال رسائل ال HTTP
• ال Agents وهي برامج تقوم بعمل طلبات ال HTTP تلقائياً.

وفيما يلي وصف موجز حول هذه البرامج ودورها في تشكيل معمارية الويب.

البروكسيات Proxies

وال HTTP proxy server من أحد البرامج المهمة، في الأمان، تحسين الأداء وغيرها من المهام. الصورة التالية تعرض بروكسي سيرفر بين الكلاينت والسيرفر، وهذا البروكسي يستقبل كل طلبات الكلاينت، ومن ثم يرسلها الى السيرفر (ويستطيع تعديلها إذا اراد).

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

الحفظ المؤقت Caches

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

ال Gateways

وهي برامج تكون وسيطة لسيرفرات اخرى، وتستخدم لتحويل ال HTTP Traffic الى برتوكول اخر، مثلاً Gateway يستقبل طلبات ال HTTP عبر ال URL ومن ثم يقوم بطلب الملف من خلال بروتكول FTP. ومن ثم يرجع الرد الى الكلاينت في HTTP Response. والكلاينت قد لا يعلم انه يتواصل مع Gateway.

ال Tunnels

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

مثال آخر، حيث سابقاً لم تكن كل الكلاينت تدعم ال HTTPS لذلك كانت تتصل على HTTPS Tunnel تأخذ ال HTTP Request وبداخلها يكون الطلب ومن ثم يتم اجراء ال SSL مع السيرفر الحقيقي ويرجع البيانات المشفرة الى الكلاينت.

ال Agents

وهي برامج client programs تقوم بعمل HTTP Requests، واي تطبيق يقوم بإرسال الطلبات يعتبر HTTP Agent، وذكرنا أحد ال http agent وهو المتصفح web browser ولكن هناك العديد من البرامج الاخرى، مثلاً العناكب Spiders او ال Web Robots وتقوم بزيارة المواقع وتصفح محتواها، لغرض بناء ارشفة للويب أو الموقع، أو لأحد محركات البحث، او حتى للبحث في اسعار المنتجات كمقارنة بين شركة واخرى.

أمثلة عملية

خلال المواضيع القادمة سوف تتناول العديد من البرامج والأدوات مثل:

1. Telnet وهو برتوكول يستخدم للوصول للأجهزة باستخدام TCP/IP.
2. Fiddler وهو proxy يتم تنزيله على الجهاز بحيث يكون وسيط بينك وبين السيرفر.
3. Wireshark وهو برنامج لتحليل كل ال Traffic الصادرة والواردة من كرت الشبكة في الجهاز
4. Postman وهي أداة تستخدم لإرسال طلبات ال HTTP
5. Browser Tools وغالب المتصفحات تحتوى على أدوات للمطورين، تستطيع من خلالها مشاهدة الطلب HTTP Request والرد HTTP Response والكوكيز وغيرها
6. برمجياً Programmatically ويمكن برمجياً باستخدام أي لغة ارسال طلبات HTTP أو حتى التعامل مع ال TCP Socket كما سنشاهد لاحقاً.

مشاهدة النتيجة من أحد المواقع

قم بفتح المتصفح والدخول على الموقع التالي www.ksu.edu.sa، وبعد ظهور النتيجة سوف تلاحظ ان الرابط اصبح ksu.edu.sa (بدون ال www).

فما الذي حدث؟  يمكنك فتح ال developer tools في متصفحك (في كروم قم بالضغط على F12)، وقم بفتح ال Network Tab وقم بفتح الموقع www.ksu.edu.sa مجدداً.

سوف تشاهد في صفحة ال Network كل الطلبات التي يقوم بها المتصفح لعرض الصفحة، وهذا يشمل كل الصور والملفات وغيرها، ويمكن ان تضغط على أي طلب حتى تفتح صفحة تشاهد تفاصيل ال HTTP Request وال HTTP Response لكل من الطلبات التي تمت في هذه الصفحة.

الذي يهم هو أول طلبين، ولاحظ الأول كان www.ksu.edu.sa والنتيجة هي 301  والتي تعني أنه هذه الصفحة انتقلت لمكان اخر بشكل نهائي، قم بالضغط عليها لمشاهدة تفاصيل النتيجة بشكل أوسع، كما يلي:

يمكنك الضغط على view source لمشاهدة كامل ال Headers للطلب والرد، والمتصفح الان يقوم بمحاولة عرض اهم الأشياء في الترويسات، وكما هو واضح النتيجة هي 301 Moved Permanently وسوف تجد في الرد ال Location الجديد كما هو واضح ksu.edu.sa. وفي الطلب كما يتضح ان ال host هو الموقع الأول.

لنرجع الى ال Network Tab (بالضغط على Esc لإغلاق التفاصيل) وادخل لتفاصيل الطلب الثاني ksu.edu.sa وسوف تجد التالي:

وستجد ان الطلب كان للموقع ksu.edu.sa في ال Request Header وهذا صحيح لأنه طلب اخر، وسوف تجد الرد 200 OK وان الملف هو HTML وقام المتصفح بعرضه بشكل صحيح. لا تقلق بخصوص بقية ال Headers والتي سيتم مناقشتها ودور كل منها في المواضيع القادمة.

سوف نقوم بالتجربة الآن من خلال أي طريقة نستطيع عمل HTTP Request، وسوف نقوم بطريقتين الأولى باستخدام أداة جاهزة وسوف نستخدم ال Telnet (وان كنا لن نستخدمها كثيراً لاحقاً، وسنركز على الأدوات الأخرى)، وبرمجياً كما يلي.

ارسال ال HTTP Request من خلال ال Telnet

لأن ال HTTP يستخدم ال TCP فيمكن استخدام الأداة Telnet وستقوم بالاتصال TCP بالعنوان ورقم البورت المحدد وستقوم بطباعة النتيجة مباشرة، وال Telnet يتصل عادة بالبورت 23 ولذلك يجب اخباره بالاتصال بالبورت المناسب وهو 80 في الوضع الافتراضي.

وال Telnet في الوضع الافتراضي في انظمة ويندوز 7 أو 8 أو 10 غير موجود، ويجب تفعيله من خلال ال Windows Features.

بعد ذلك يمكن الاتصال به من خلال سطر الأوامر. والطريقة كالتالي:

• قم بفتح سطر الأوامر Command Line من خلال قائمة run ثم cmd
• ادخل امر الاتصال بالموقع من خلال ال Telnet وذلك بكتابة الامر telnet www.ksu.edu.sa 80 وبعد الضغط على Enter سوف تجد أنك انتقلت لصفحة ال Telnet بعد الاتصال لكي تقوم بكتابة الطلب HTTP Response بنفسك. وقم بإدخال الاوامر التالية والتي تمثل الطلب (ولن تراها):
• قم بإدخال GET / HTTP/1.1 ومن ثم اضغط ENTER
  1. وهي بمعنى جلب ال resource الموجود في الرابط / (ال root او الصفحة الرئيسية). وتم تحديد طريقة الجلب وهي GET ونسخة البرتوكول HTTP 1.1
• قم بإدخال host: www.ksu.edu.sa ومن ثم اضغط ENTER
  1. وقيمة ال host مطلوبة في ال HTTP 1.1، حيث هي تبين للويب سيرفر الموقع الذي تريده، فهناك سيرفرات تستضيف أكثر من موقع، ولذلك قيمة ال Host هي التي تحدد اي موقع من المواقع الموجودة على الويب سيرفر تريده (إذا كان هناك أكثر من موقع)، ولكن هذه القيمة مطلوبة حتى لو كان هناك موقع واحد في السيرفر
• قم بالضغط على ENTER مجدداً لإرسال الطلب الى السيرفر

سوف يظهر الرد بعد ذلك:

وهي تقول بأن الصفحة الرئيسية في الموقع www.ksu.edu.sa تم نقلها ، وفي السطر الثالث تم توضيح الرابط لل resource الجديد.

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

لماذا قام الموقع بإرجاع 301 بدلاً من ارجاع النتيجة مباشرة؟ وهذا النوع من الردود يعرف بالتحويل او ال Redirect وهو شائع كثيراً خصوصاً تحويل طلب www.example.com الى example.com حتى يتم عمل URL canonicalization.

ما الفائدة من ال URL canonicalization؟ وهي تستخدم في تحسين أداء محركات البحث SEO، حيث محركات البحث لديها حساسية من المحتوى المكرر، حيث يرى المحرك بأن www.exmaple.com و example.com هما موقعان مختلفان ووجود نفس المحتوى فيهم سوف يؤثر على ظهور موقعك في محركات البحث، ولذلك سوف يقوم المطور بتحويل طلبات ال www. الى الموقع بدونها من خلال ارسال نتيجة 301 في الرد على الطلب الأول، وهذه يمكن عمل من اعدادات الويب سيرفر أو الموقع نفسه، وهي تختلف من framework لأخر ومن web server لأخر.

يمكنك تكرار التجربة في ال Telnet وجعل ال Host هو host: ksu.edu.sa وسوف تجد أن الرد اظهر محتوى الصفحة الرئيسية كاملاً.

ارسال طلب ال HTTP برمجياً

كل لغات البرمجة بها مكتبات سواء مع اللغة للإرسال طلبات ال HTTP أو مكتبات مساعدة، وسوف نأخذ مثالاً على لغة الجافا باستخدام الكلاس URLConnection ونرسل طلب HTTP:

import java.io.*;
import java.net.*;

public class SendRequest {
    public static void main(String[] args) {                
        String host = "http://www.ksu.edu.sa";
        try {           
            URL url = new URL(host);
            URLConnection urlConnection = url.openConnection();
            
            //HttpURLConnection connection = (HttpURLConnection) urlConnection; 
            //connection.setInstanceFollowRedirects(false);

            // show headers
            for (int j = 1; ; j++) {
              String header = urlConnection.getHeaderField(j);
              if (header == null) 
                  break;
              System.out.println(urlConnection.getHeaderFieldKey(j) + ": " + header);
            }
        
            System.out.println();
            
            // show html response
            try(InputStream raw = urlConnection.getInputStream()) {
                InputStream buffer = new BufferedInputStream(raw);
                Reader reader = new InputStreamReader(buffer);
                int c;
                while ((c = reader.read()) != -1) {
                    System.out.print((char)c);
                }
            }
        }
        catch(MalformedURLException ex) {
            System.err.println(host + " is not a parseable URL");
        }
        catch(IOException ex) {
            System.err.println(ex);
        }
    }
}

عند تشغيلك للمثال، سوف تتفاجأ بأن الطلب بالرغم من انه كان للموقع www.ksu.edu.sa الا انه تم جلب بيانات ال ksu.edu.sa، وهذا يرجع لطبيعة عمل ال URLConnection حيث هي كما نص التوثيق بأنها تتبع ال Redirection مثل المتصفح. ولذلك سوف تقوم مباشرة بعد مشاهدة نتيجة 301 بعمل طلب اخر للرابط في ال Location بدون أي تدخل منك.

قم بإلغاء التعليقات في السطرين 11 و12 حتى تلغى خاصية تتبع الروابط وبعدها سوف تجد المخرج كما هو متوقع بالضبط.

نهاية البداية

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

المصادر

• كتاب HTTP: The Definitive Guide (الرابط)
• مقالات Scott Allen عن ال HTTP (الرابط)
• كتاب Learning HTTP/2 (الرابط)