بروتوكول نقل النص التشعبي HTTP ماهو وكيف يعمل

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

بدأ تطوير HTTP بواسطة Tim Bern­ers-Lee في CERN في عام 1989 وتم تلخيصه في مستند بسيط يصف سلوك العميل والخادم باستخدام أول إصدار من بروتوكول HTTP والذي تم تسميته 0.9. 

سرعان ما تطور هذا الإصدار الأول من بروتوكول HTTP إلى إصدار أكثر تفصيلاً كان أول مسودة نحو إصدار مستقبلي بعيد 1.0. 

بدأ تطوير طلبات HTTP المبكرة للتعليقات (RFCs) بعد بضع سنوات وكان جهدًا منسقًا من قبل فريق عمل هندسة الإنترنت (IETF) واتحاد شبكة الويب العالمية (W3C) ، مع انتقال العمل لاحقًا إلى IETF.

تم الانتهاء من HTTP / 1 وتوثيقه بالكامل (كإصدار 1.0) في عام 1996. وقد تطور (كإصدار 1.1) في عام 1997 ثم تم تحديث مواصفاته في عام 1999 وفي عام 2014. 

يستخدم أكثر من 76٪ من مواقع الويب المتغير الآمن المسمى HTTPS . 

HTTP / 2 هو تعبير أكثر كفاءة عن دلالات HTTP “على السلك” ، وقد تم نشره في عام 2015 ؛ يتم استخدامه من قبل أكثر من 45٪ من مواقع الويب ؛ يتم دعمه الآن من قبل جميع متصفحات الويب تقريبًا (96٪ من المستخدمين) وخوادم الويب الرئيسية عبر بروتوكول أمان طبقة النقل (TLS) باستخدام امتداد تفاوض بروتوكول طبقة التطبيق (ALPN) حيث TLS 1.2 أو الأحدث مطلوب.  

HTTP / 3 هو الوريث المقترح لـ HTTP / 2 ؛ 2 3 يتم استخدامه من قبل أكثر من 20٪ من مواقع الويب ؛ 4 وهي مدعومة الآن من قبل العديد من متصفحات الويب (73٪ من المستخدمين). يستخدم HTTP / 3 QUIC بدلاً من TCP لبروتوكول النقل الأساسي. مثل HTTP / 2 ، فإنه لا يلغي الإصدارات الرئيسية السابقة من البروتوكول. تمت إضافة دعم HTTP / 3 إلى Cloud­flare و Google Chrome أولاً ،   وتم تمكينه أيضًا في Fire­fox . 8

نظرة فنية عامة 

بروتوكول نقل النص التشعبي HTTP ماهو وكيف يعمل, الملك التقني

عنوان URL يبدأ بنظام HTTP وتسمية اسم مجال WWW

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

متصفح الويب هو مثال على وكيل المستخدم (UA). أنواع أخرى من وكيل المستخدم وتشمل البرامج الفهرسة المستخدمة من قبل مقدمي البحث ( برامج زحف الويب )، متصفحات صوت ، تطبيقات الجوال ، وغيرها من البرامج التي يصل، يستهلك أو محتوى يعرض على شبكة الإنترنت.

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

السماح العقد HTTP المتوسط (خوادم بروكسي، ومخابئ على شبكة الإنترنت، وما إلى ذلك) لإنجاز مهامهم، وبعض من رؤوس HTTP (وجدت في HTTP طلبات / ردود) تدار هوب التي كتبها الهيب تدار في حين رؤوس HTTP أخرى نهاية ل- end (تتم إدارتها فقط بواسطة العميل المصدر وخادم الويب الهدف).

HTTP هو بروتوكول طبقة تطبيق مصمم في إطار مجموعة بروتوكولات الإنترنت . يفترض تعريفه وجود بروتوكول أساسي وموثوق به لطبقة النقل ، وبالتالي فإن بروتوكول التحكم في الإرسال (TCP) شائع الاستخدام. ومع ذلك، HTTP يمكن تكييفها لاستخدام بروتوكولات يمكن الاعتماد عليها مثل بروتوكول مخطط بيانات المستخدم (UDP)، على سبيل المثال في HTTPU و بروتوكول اكتشاف بسيطة خدمة (SSDP).

يتم تحديد موارد HTTP وتحديد موقعها على الشبكة بواسطة Uni­form Resource Loca­tors (URLs) ، باستخدام مخططات معرفات الموارد الموحدة (URI) http و https . كما هو محدد في RFC 3986 ، يتم ترميز URIs كارتباطات تشعبية في مستندات HTML ، وذلك لتكوين مستندات نص تشعبي مترابطة . 

في HTTP / 1.0 ، يتم إجراء اتصال منفصل بنفس الخادم لكل طلب مورد. 

في HTTP / 1.1 بدلاً من ذلك ، يمكن إعادة استخدام اتصال TCP لتقديم طلبات موارد متعددة (على سبيل المثال صفحات HTML ، الإطارات ، الصور ، البرامج النصية ، صفحات الأنماط ، إلخ).

لذلك ، تعاني اتصالات HTTP / 1.1 من زمن انتقال أقل نظرًا لأن إنشاء توصيلات TCP يمثل عبئًا كبيرًا ، خاصة في ظل ظروف حركة المرور العالية.

HTTP / 2 هو مراجعة لـ HTTP / 1.1 السابق من أجل الحفاظ على نفس نموذج خادم العميل ونفس طرق البروتوكول ولكن مع هذه الاختلافات بالترتيب :

  • لاستخدام تمثيل ثنائي مضغوط للبيانات الوصفية (رؤوس HTTP) بدلاً من التمثيل النصي ، بحيث تتطلب الرؤوس مساحة أقل بكثير ؛
  • لاستخدام اتصال TCP / IP واحد ( مشفر عادة ) لكل مجال خادم يتم الوصول إليه بدلاً من 2..8 اتصالات TCP / IP ؛
  • لاستخدام واحد أو أكثر من التدفقات ثنائية الاتجاه لكل اتصال TCP / IP يتم فيه تقسيم طلبات واستجابات HTTP وإرسالها في حزم صغيرة تقريبًا لحل مشكلة HOLB ( رأس حظر الخط ؛ ملاحظة : في الممارسة العملية ، يتم استخدام هذه التدفقات على أنها متعددة الاتصالات الفرعية TCP / IP للطلبات / الاستجابات المتزامنة متعددة الإرسال ، مما يقلل بشكل كبير من عدد اتصالات TCP / IP الحقيقية على جانب الخادم ، من 2..8 لكل عميل إلى 1 ، والسماح للعديد من العملاء بالخدمة في وقت واحد) ؛
  • لإضافة قدرة دفع للسماح لتطبيق الخادم بإرسال البيانات إلى العملاء متى توفرت بيانات جديدة (دون إجبار العملاء على طلب بيانات جديدة بشكل دوري إلى الخادم باستخدام طرق الاقتراع ). 4

وبالتالي ، فإن اتصالات HTTP / 2 تواجه زمن انتقال أقل بكثير ، وفي معظم الحالات ، سرعة أكبر من اتصالات HTTP / 1.1.

HTTP / 3 هو مراجعة لـ HTTP / 2 السابق من أجل استخدامبروتوكولات النقل QUIC + UDP بدلاً من اتصالات TCP / IP أيضًا لتحسين متوسط سرعة الاتصالاتبشكل طفيف ولتجنب المشكلات العرضية (النادرة جدًا) لاتصال TCP / IP الازدحام الذي يمكن أن يمنع مؤقتًا أو يبطئ تدفق البيانات لجميع تدفقاتها (شكل آخر من أشكال ” منع رأس الخط ”).

التاريخ 

بروتوكول نقل النص التشعبي HTTP ماهو وكيف يعمل, الملك التقنيتيم برنرز — لي

صاغ تيد نيلسون مصطلح النص التشعبي في عام 1965 في مشروع Xanadu ، والذي كان مستوحى بدوره من رؤية فانيفار بوش في الثلاثينيات من القرن الماضي لنظام ” memex ” لاسترجاع المعلومات وإدارتها المستند إلى الميكروفيلم الموصوف في مقالته عام 1945 ” كما قد نفكر” “. يعود الفضل إلى Tim Bern­ers-Lee وفريقه في CERN في اختراع HTTP الأصلي ، إلى جانب HTML والتقنية المرتبطة بخادم ويب وواجهة مستخدم عميل تسمى متصفح الويب . اقترح بيرنرز لي لأول مرة مشروع “World­WideWeb” في عام 1989، المعروفة الآن باسم شبكة الويب العالمية .

بدأ تشغيل أول خادم ويب في عام 1990 .   كان للبروتوكول المستخدم طريقة واحدة فقط ، وهي GET ، والتي تطلب صفحة من الخادم. كانت الاستجابة من الخادم دائمًا صفحة HTML. 

HTTP / 0.9
في عام 1991 تمت كتابة أول نسخة رسمية موثقة من HTTP كمستند بسيط وسميت هذه النسخة HTTP / 0.9. 

HTTP / 1.0‑Draft
منذ عام 1992 تمت كتابة وثيقة جديدة لتحديد تطور البروتوكول الأساسي نحو نسخته الكاملة التالية. لقد دعمت كلاً من طريقة الطلب البسيطة للإصدار 0.9 وطلب GET الكامل الذي تضمن إصدار HTTP للعميل. كانت هذه أول مسودات HTTP / 1.0 غير رسمية عديدة سبقت العمل النهائي على HTTP / 1.0. 

مجموعة عمل W3C HTTP
بعد أن قررت أن الميزات الجديدة لبروتوكول HTTP مطلوبة وأنه يجب توثيقها بالكامل باعتبارها RFCs رسمية ، في أوائل عام 1995 ، تم تشكيل مجموعة عمل HTTP (HTTP WG ، بقيادة Dave Raggett ) بهدف التوحيد القياسي وتوسيع البروتوكول بعمليات موسعة ، ومفاوضات موسعة ، ومعلومات وصفية أكثر ثراءً ، مرتبطة ببروتوكول أمان أصبح أكثر كفاءة عن طريق إضافة طرق إضافية وحقول رأس . 

خططت مجموعة عمل HTTP لمراجعة ونشر إصدارات جديدة من البروتوكول مثل HTTP / 1.0 و HTTP / 1.1 خلال عام 1995 ، ولكن بسبب المراجعات العديدة ، استمر هذا الجدول الزمني أكثر من عام واحد. 

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

HTTP / 1.0
في مايو 1996 تم نشر RFC 1945 كمراجعة نهائية لـ HTTP / 1.0 لما تم استخدامه في السنوات الأربع السابقة كمسودة HTTP / 1.0 قياسية والتي تم استخدامها بالفعل من قبل العديد من متصفحات الويب وخوادم الويب. 

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

HTTP / 1.1
منذ أوائل عام 1996 ، بدأت متصفحات الويب ومطورو خوادم الويب الرئيسية أيضًا في تنفيذ ميزات جديدة محددة بواسطة مواصفات مسودات HTTP / 1.1 القياسية مسبقًا. كان اعتماد المستخدم النهائي للإصدارات الجديدة من المتصفحات والخوادم سريعًا. في مارس 1996 ، ذكرت إحدى شركات استضافة الويب أن أكثر من 40٪ من المتصفحات المستخدمة على الإنترنت تستخدم عنوان HTTP / 1.1 الجديد “Host” لتمكين الاستضافة الافتراضية . ذكرت نفس شركة استضافة الويب أنه بحلول يونيو 1996 ، كانت 65 ٪ من جميع المتصفحات التي تصل إلى خوادمها متوافقة مع بروتوكول HTTP / 1.1 القياسي مسبقًا. 

اقرأ ايضا :  ما هو عنوان URL وكيف يعمل

في يناير 1997 ، تم إصدار RFC 2068 رسميًا كمواصفات HTTP / 1.1. 

في يونيو 1999 ، تم إصدار RFC 2616 لتضمين جميع التحسينات والتحديثات بناءً على مواصفات HTTP / 1.1 السابقة (القديمة). 

W3C HTTP-NG الفريق العامل
استئناف خطة قديمة 1995 من الفريق العامل HTTP السابق، في 1997 و الفريق العامل HTTP-NG تم تشكيلها لوضع بروتوكول HTTP جديد يدعى HTTP-NG (HTTP الجيل الجديد). تم إنتاج عدد قليل من المقترحات / المسودات للبروتوكول الجديد لاستخدام تعدد إرسال معاملات HTTP داخل اتصال TCP / IP واحد ولكن في عام 1999 أوقفت المجموعة نشاطها عن طريق تمرير المشكلات الفنية إلى IETF. 3

تمت إعادة تشغيل مجموعة عمل IETF HTTP
في عام 2007 ، تمت إعادة تشغيل مجموعة عمل IETF HTTP (HTTP WG bis أو HTTP­bis) أولاً لمراجعة وتوضيح مواصفات HTTP / 1.1 السابقة وثانيًا لكتابة وتحسين مواصفات HTTP / 2 المستقبلية (المسماة http­bis). 

تحديث HTTP / 1.1 النهائي
في يونيو 2014 ، أصدرت مجموعة عمل HTTP تحديثًا محدثًا من ستة أجزاء لمواصفات HTTP / 1.1 التي عفا عليها الزمن RFC 2616 : 

  • RFC 7230 ، HTTP / 1.1 : بناء جملة الرسالة والتوجيه
  • RFC 7231 ، HTTP / 1.1 : الدلالات والمحتوى
  • RFC 7232 ، HTTP / 1.1 : الطلبات المشروطة
  • RFC 7233 ، HTTP / 1.1 : طلبات النطاق
  • RFC 7234 ، HTTP / 1.1 : التخزين المؤقت
  • RFC 7235 ، HTTP / 1.1 : المصادقة

SPDY : بروتوكول HTTP غير رسمي طورته Google
في عام 2009 ، أعلنت شركة Google ، وهي شركة خاصة ، أنها طورت واختبرت بروتوكول HTTP ثنائيًا جديدًا يسمى SPDY . كان الهدف الضمني هو تسريع حركة مرور الويب بشكل كبير (خاصة بين متصفحات الويب المستقبلية وخوادمها).

كان SPDY بالفعل أسرع بكثير من HTTP / 1.1 في العديد من الاختبارات ولذا تم اعتماده بسرعة بواسطة Chromi­um ثم من قبل متصفحات الويب الرئيسية الأخرى. 

تم أخذ بعض الأفكار حول تدفقات HTTP المتعددة عبر اتصال TCP / IP واحد من مصادر مختلفة ، بما في ذلك عمل مجموعة عمل W3C HTTP-NG.

HTTP / 2
في الفترة من يناير إلى مارس 2012 أعلنت مجموعة عمل HTTP (HTTP­bis) عن الحاجة إلى البدء في التركيز على بروتوكول HTTP / 2 جديد (أثناء الانتهاء من مراجعة مواصفات HTTP / 1.1) ، ربما مع الأخذ في الاعتبار الأفكار والعمل المنجز لـ SPDY .  8

بعد بضعة أشهر حول ما يجب القيام به لتطوير إصدار جديد من HTTP ، تقرر اشتقاقه من SPDY. 

في مايو 2015 ، تم نشر HTTP / 2 كـ RFC 7540 وتم اعتماده بسرعة من قبل جميع متصفحات الويب التي تدعم بالفعل SPDY وببطء أكثر بواسطة خوادم الويب. 

توقف HTTP / 0.9
منذ عام 2016 ، بدأ العديد من مديري المنتجات ومطوري وكلاء المستخدم (المتصفحات ، وما إلى ذلك) وخوادم الويب في التخطيط لإيقاف دعم بروتوكول HTTP / 0.9 ورفضه تدريجيًا ، وذلك للأسباب التالية بشكل أساسي : 

  • من الواضح أنه عفا عليه الزمن لأنه بسيط للغاية لدرجة أن أحداً لم يكلف نفسه عناء كتابة مستند RFC (لا يوجد سوى المستند الأصلي) ؛ 
  • لا يحتوي على رؤوس HTTP ويفتقر إلى العديد من الميزات الأخرى التي أصبحت مطلوبة في الوقت الحاضر لأسباب أمنية قليلة ؛
  • لم يتم استخدامه بالفعل منذ 1999..2000 (بسبب HTTP / 1.0 و HTTP / 1.1) ؛
  • يبدو أنه يتم استخدامه بشكل عشوائي فقط بواسطة بعض أجهزة الشبكة القديمة جدًا ، مثل أجهزة التوجيه ، وما إلى ذلك.

ملاحظة : في عام 2021 ، لم يتم إهمال دعم HTTP / 0.9 رسميًا ولا يزال موجودًا (حتى لو تم تعطيله عادةً) في العديد من خوادم ومتصفحات الويب (لاستجابات الخادم فقط) لذلك ليس من الواضح المدة التي سيستغرقها هذا التفكيك ، ربما سيتم إكماله أولاً في وكلاء المستخدم (المتصفحات ، إلخ) ثم في خوادم الويب.

HTTP / 3
في عام 2020 ، تم نشر المسودات الأولى لـ HTTP / 3 وبدأت متصفحات الويب وخوادم الويب الرئيسية في اعتماده.


ملخص إصدارات HTTP الرئيسية

عامإصدار
1991HTTP / 0.9
1996HTTP / 1.0
1997HTTP / 1.1
2015HTTP / 2
2020 (مسودة)HTTP / 3

تبادل بيانات HTTP 

HTTP هو بروتوكول على مستوى التطبيق عديم الحالة ويتطلب اتصال نقل شبكة موثوق به لتبادل البيانات بين العميل والخادم. في تطبيقات HTTP ، تُستخدم اتصالات TCP / IP باستخدام منافذ معروفة (عادةً المنفذ 80 إذا كان الاتصال غير مشفر أو المنفذ 443 إذا كان الاتصال مشفرًا ، انظر أيضًا قائمة أرقام منافذ TCP و UDP ). 2 3 في HTTP / 2 ، يتم استخدام اتصال TCP / IP + قنوات بروتوكول متعددة. في HTTP / 3 ، يتم استخدام بروتوكول نقل التطبيق QUIC + UDP.

رسائل الطلب والرد عبر الاتصالات 

يتم تبادل البيانات من خلال سلسلة من رسائل الطلب والرد التي يتم تبادلها بواسطة اتصال نقل طبقة الجلسة . يحاول عميل HTTP في البداية الاتصال بخادم يقوم بإنشاء اتصال (حقيقي أو افتراضي). يقبل خادم HTTP (S) الذي يستمع على هذا المنفذ الاتصال ثم ينتظر رسالة طلب العميل. يرسل العميل طلبه إلى الخادم. عند استلام الطلب ، يرسل الخادم رسالة استجابة HTTP (رأس بالإضافة إلى نص إذا كان مطلوبًا). عادةً ما يكون نص هذه الرسالة هو المورد المطلوب ، على الرغم من أنه قد يتم أيضًا إرجاع رسالة خطأ أو معلومات أخرى. في أي وقت (لأسباب عديدة) يمكن للعميل أو الخادم إغلاق الاتصال. عادةً ما يتم الإعلان عن إغلاق الاتصال مسبقًا باستخدام رأس HTTP أو أكثر في آخر رسالة طلب / استجابة تم إرسالها إلى الخادم أو العميل. 1

اتصالات مستمرة 

في HTTP / 0.9 ، يتم إغلاق اتصال TCP / IP دائمًا بعد إرسال استجابة الخادم ، لذلك لا يكون دائمًا .

في HTTP / 1.0 ، كما هو مذكور في RFC 1945 ، يجب دائمًا إغلاق اتصال TCP / IP بواسطة الخادم بعد إرسال الاستجابة. ملاحظة : منذ أواخر عام 1996 ، بدأ بعض مطوري متصفحات وخوادم HTTP / 1.0 الشائعة (خاصة أولئك الذين خططوا لدعم HTTP / 1.1 أيضًا) في نشر (كملحق غير رسمي) نوعًا من آلية البقاء على قيد الحياة (باستخدام رؤوس HTTP الجديدة) من أجل الحفاظ على اتصال TCP / IP مفتوحًا لأكثر من زوج طلب / استجابة وبالتالي لتسريع تبادل الطلبات / الاستجابات المتعددة. 

في HTTP / 1.1 ، تم تقديم آلية البقاء على قيد الحياة رسميًا بحيث يمكن إعادة استخدام الاتصال لأكثر من طلب / استجابة . تعمل هذه الاتصالات المستمرة على تقليل وقت استجابة الطلب بشكل ملحوظ لأن العميل لا يحتاج إلى إعادة التفاوض بشأن اتصال TCP 3‑Way-Hand­shake بعد إرسال الطلب الأول. من الآثار الجانبية الإيجابية الأخرى أنه ، بشكل عام ، يصبح الاتصال أسرع بمرور الوقت بسبب آلية البداية البطيئة لـ TCP .

أضاف HTTP / 1.1 أيضًا أنابيب HTTP من أجل تقليل وقت التأخير بشكل أكبر عند استخدام الاتصالات المستمرة من خلال السماح للعملاء بإرسال طلبات متعددة قبل انتظار كل استجابة. لم يتم اعتبار هذا التحسين آمنًا حقًا لأن عددًا قليلاً من خوادم الويب والعديد من الخوادم الوكيلة ، وخوادم الوكيل الشفافة بشكل خاص الموضوعة في الإنترنت / الإنترانت بين العملاء والخوادم ، لم تتعامل مع الطلبات المخططة بشكل صحيح (لقد خدموا الطلب الأول فقط مع تجاهل الآخرين ، وأغلقوا الاتصال لأنهم رأوا المزيد من البيانات بعد الطلب الأول أو حتى أن بعض الوكلاء أعادوا ردودًا خارج الترتيب وما إلى ذلك). إلى جانب هذا فقط HEAD وبعض طلبات GET (أي تقتصر على طلبات الملفات الحقيقية وهكذا مع عناوين URLدون الاستعلام السلسلة المستخدمة كأمر وغيرها) يمكن عبر خط انابيب في آمن و idem­po­tent واسطة. بعد سنوات عديدة من الكفاح مع المشاكل التي أدخلت عن طريق تمكين خطوط الأنابيب ، تم تعطيل هذه الميزة أولاً ثم إزالتها من معظم المتصفحات أيضًا بسبب اعتماد HTTP / 2 المعلن.

قام HTTP / 2 بتوسيع استخدام الاتصالات المستمرة من خلال مضاعفة إرسال العديد من الطلبات / الاستجابات المتزامنة من خلال اتصال TCP / IP واحد.

لا يستخدم HTTP / 3 اتصالات TCP / IP ولكن يستخدم QUIC + UDP (انظر أيضًا : نظرة عامة فنية ).

تحسينات استرداد المحتوى 

في HTTP / 0.9 ، تم دائمًا إرسال المورد المطلوب بالكامل.

أضاف HTTP / 1.0 رؤوسًا لإدارة الموارد المخزنة مؤقتًا بواسطة العميل للسماح بطلبات GET المشروطة ؛ من الناحية العملية ، يجب على الخادم إعادة المحتوى بالكامل للمورد المطلوب فقط إذا كان وقت التعديل الأخير غير معروف من قبل العميل أو إذا تم تغييره منذ آخر استجابة كاملة لطلب GET.

أضاف HTTP / 1.0 رأس “ترميز المحتوى” لتحديد ما إذا كان المحتوى الذي تم إرجاعه من المورد مضغوطًا أم لا .

اقرأ ايضا :  ماهي خدمة استضافة المواقع ... وكيف تعمل

في HTTP / 1.0 ، إذا لم يكن الطول الإجمالي لمحتوى المورد معروفًا مسبقًا (أي لأنه تم إنشاؤه ديناميكيًا ، وما إلى ذلك) ، فإن الرأس "Content-Length: number"لم يكن موجودًا في رؤوس HTTP وافترض العميل أنه عند إغلاق الخادم للاتصال ، تم إرسال المحتوى بالكامل. لم تتمكن هذه الآلية من التمييز بين نقل المورد الذي تم إكماله بنجاح وتلك التي تمت مقاطعتها (بسبب خطأ في الخادم / الشبكة أو أي شيء آخر).

أضاف HTTP / 1.1 رؤوسًا جديدة لتحسين إدارة الاسترداد الشرطي للموارد المخزنة مؤقتًا.

HTTP / 1.1 وعرض المقسم نقل ترميز للسماح للمحتوى ليتم بث في قطع من أجل إرسال موثوق به حتى عندما لا يعرف الخادم مقدما طوله (أي لأنه ديناميكيا، وما إلى ذلك).

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

احتفظ HTTP / 2 و HTTP / 3 بالميزات المذكورة أعلاه لـ HTTP / 1.1.

مصادقة HTTP 

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

يوفر HTTP إطارًا عامًا للتحكم في الوصول والمصادقة ، عبر مجموعة موسعة من أنظمة مصادقة التحدي والاستجابة ، والتي يمكن استخدامها من قبل الخادم لتحدي طلب العميل ومن قبل العميل لتوفير معلومات المصادقة. 4

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

مجالات المصادقة 

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

جلسة تطبيق HTTP 

HTTP هو بروتوكول عديم الحالة . لا يتطلب البروتوكول عديم الحالة من خادم الويب الاحتفاظ بالمعلومات أو الحالة حول كل مستخدم طوال مدة الطلبات المتعددة.

تحتاج بعض تطبيقات الويب إلى إدارة جلسات المستخدم ، بحيث تنفذ حالات أو جلسات جانب الخادم باستخدام ملفات تعريف الارتباط HTTP على سبيل المثال أو المتغيرات المخفية داخل نماذج الويب .

لبدء جلسة مستخدم التطبيق ، يجب إجراء مصادقة تفاعلية عبر تسجيل الدخول إلى تطبيق الويب . لإيقاف جلسة المستخدم ، يجب أن يطلب المستخدم عملية تسجيل الخروج . لا يستخدم هذا النوع من العمليات مصادقة HTTP ولكن مصادقة مخصصة لتطبيق الويب المُدار. 4

رسائل طلب HTTP / 1.1

يتم إرسال رسائل الطلب من قبل العميل إلى الخادم الهدف.

هذه مقدمة قصيرة لرسائل طلب HTTP / 1.1 (لها نفس الدلالات — أكثر أو أقل — مثل تلك الموجودة في HTTP / 1.0).

ملاحظة : HTTP / 2 و HTTP / 3 لهما تمثيل مختلف لطرق ورؤوس HTTP.

بناء جملة الطلب 

يرسل العميل رسائل طلب إلى الخادم ، والتي تتكون من : 

  • على خط طلب ، ويتألف من طريقة طلب لحالة الأحرف، و الفضاء ، وURL المطلوب، فضاء آخر، إصدار بروتوكول، و إرجاع ، و سطر تغذية ، على سبيل المثال :
GET /images/logo.png HTTP/1.1
  • صفر أو أكثر من حقول رأس الطلب (رأس واحد على الأقل أو أكثر في حالة HTTP / 1.1) ، يتكون كل منها من اسم حقل غير حساس لحالة الأحرف ، ونقطتان ، ومسافة بيضاء بادئة اختيارية ، وقيمة الحقل ، ومسافة بيضاء لاحقة اختيارية وتنتهي بـ إرجاع السطر وتغذية السطر ، على سبيل المثال :
Host: www.example.com
Accept-Language: en
  • سطر فارغ يتكون من حرف إرجاع وخط تغذية ؛
  • نص رسالة اختياري .


في بروتوكول HTTP / 1.1 ، تعد جميع حقول الرأس باستثناء حقول Host: hostnameاختيارية.

تقبل الخوادم سطر طلب يحتوي على اسم المسار فقط للحفاظ على التوافق مع عملاء HTTP قبل مواصفات HTTP / 1.0 في RFC 1945 . 

طرق الطلب 

بروتوكول نقل النص التشعبي HTTP ماهو وكيف يعمل, الملك التقنيتم إجراء طلب HTTP / 1.1 باستخدام tel­net. يتم تمييز رسالة الطلب وقسم رأس الاستجابة ونص الاستجابة.

يُعرِّف HTTP الأساليب (يشار إليها أحيانًا باسم الأفعال ، ولكن لا يذكر في أي موضع في المواصفات الفعل ، ولا يشير إلى الفعل المطلوب أو OPTIONS أو HEAD) للإشارة إلى الإجراء المطلوب الذي يتعين تنفيذه على المورد المحدد. ما يمثله هذا المورد ، سواء البيانات الموجودة مسبقًا أو البيانات التي يتم إنشاؤها ديناميكيًا ، يعتمد على تنفيذ الخادم. غالبًا ، يتوافق المورد مع ملف أو إخراج ملف تنفيذي موجود على الخادم. حددت مواصفات HTTP / 1.0 أساليب GET و HEAD و POST ومواصفات HTTP / 1.1 8تمت إضافة خمس طرق جديدة : PUT و DELETE و CONNECT و OPTIONS و TRACE. من خلال تحديدها في هذه الوثائق ، فإن دلالاتها معروفة ويمكن الاعتماد عليها. يمكن لأي عميل استخدام أي طريقة ويمكن تكوين الخادم لدعم أي مجموعة من الأساليب. إذا كانت الطريقة غير معروفة للوسيط ، فسيتم التعامل معها على أنها طريقة غير آمنة وغير فاعلة . لا يوجد حد لعدد الأساليب التي يمكن تعريفها وهذا يسمح بتحديد الطرق المستقبلية دون كسر البنية التحتية الحالية. على سبيل المثال، WEBDAV محددة سبع طرق جديدة و RFC 5789 تحديد رقعة الأسلوب. 

أسماء الطرق حساسة لحالة الأحرف.   هذا على عكس أسماء حقل رأس HTTP التي لا تتأثر بحالة الأحرف. احصل علىتطلب طريقة GET أن يقوم المورد المستهدف بنقل تمثيل لحالته. يجب أن تسترد طلبات GET البيانات فقط ويجب ألا يكون لها أي تأثير آخر. (وهذا ينطبق أيضا على بعض أساليب HTTP أخرى.) و W3C نشر مبادئ توجيهية بشأن هذا التمييز، وقال : ” تطبيق ويب يجب أن تكون على علم تصميم بالمبادئ المذكورة أعلاه، ولكن أيضا من القيود ذات الصلة.” انظر الطرق الآمنة أدناه.رئيستطلب طريقة HEAD أن ينقل المورد الهدف تمثيلًا لحالته ، مثل طلب GET ، ولكن بدون بيانات التمثيل المضمنة في نص الاستجابة. يفيد ذلك في استرداد البيانات الوصفية للتمثيل في رأس الاستجابة ، دون الحاجة إلى نقل التمثيل بالكامل.بريدو أسلوب POST طلبات أن الموارد المستهدفة بمعالجة التمثيل المغلقة في الطلب وفقا لدلالات الموارد المستهدفة. على سبيل المثال ، يتم استخدامه لنشر رسالة إلى منتدى عبر الإنترنت أو الاشتراك في قائمة بريدية أو إكمال معاملة تسوق عبر الإنترنت . 3وضعتطلب طريقة PUT أن يقوم المورد الهدف بإنشاء أو تحديث حالته بالحالة المحددة بواسطة التمثيل المضمن في الطلب. 4حذفيتطلب أسلوب DELETE حذف المورد الهدف حالته.الاتصالتطلب طريقة CONNECT من الوسيط إنشاء نفق TCP / IP إلى الخادم الأصلي المحدد بواسطة هدف الطلب. غالبًا ما يتم استخدامه لتأمين الاتصالات من خلال واحد أو أكثر من بروكسيات HTTP مع TLS .   راجع طريقة HTTP CONNECT .والخياراتتطلب طريقة OPTIONS أن يقوم المورد الهدف بنقل أساليب HTTP التي يدعمها. يمكن استخدام هذا للتحقق من وظائف خادم الويب عن طريق طلب “*” بدلاً من مورد معين.أثرتطلب طريقة TRACE أن يقوم المورد الهدف بنقل الطلب المستلم في نص الاستجابة. بهذه الطريقة يمكن للعميل معرفة التغييرات أو الإضافات (إن وجدت) التي تم إجراؤها بواسطة الوسطاء.رقعة قماشيةتطلب طريقة التصحيح أن يقوم المورد الهدف بتعديل حالته وفقًا للتحديث الجزئي المحدد في التمثيل المضمن في الطلب. 

يتعين على جميع خوادم الويب ذات الأغراض العامة تنفيذ أساليب GET و HEAD على الأقل ، وتعتبر جميع الطرق الأخرى اختيارية حسب المواصفات. 

طريقة الطلبRFCالطلب له جسم الحمولةالاستجابة لها جسم الحمولةآمنعديم الفاعليةقابل للتخزين المؤقت
احصل علىRFC 7231اختيارينعمنعمنعمنعم
رئيسRFC 7231اختياريلانعمنعمنعم
بريدRFC 7231نعمنعملالانعم
وضعRFC 7231نعمنعملانعملا
حذفRFC 7231اختيارينعملانعملا
الاتصالRFC 7231اختيارينعملالالا
والخياراتRFC 7231اختيارينعمنعمنعملا
أثرRFC 7231لانعمنعمنعملا
رقعة قماشيةRFC 5789نعمنعملالالا

طرق آمنة 

تكون طريقة الطلب آمنة إذا لم يكن للطلب بهذه الطريقة أي تأثير مقصود على الخادم. يتم تعريف طرق GET و HEAD و OPTIONS و TRACE على أنها آمنة. بعبارة أخرى ، يُقصد بالطرق الآمنة أن تكون للقراءة فقط . ومع ذلك ، فهي لا تستبعد الآثار الجانبية ، مثل إلحاق معلومات الطلب بملف سجل أو فرض رسوم على حساب إعلان ، حيث لا يطلبها العميل ، بحكم التعريف.

في المقابل ، فإن طرق POST و PUT و DELETE و CONNECT و PATCH ليست آمنة. قد يقومون بتعديل حالة الخادم أو يكون لديهم تأثيرات أخرى مثل إرسال بريد إلكتروني . لذلك لا يتم استخدام مثل هذه الأساليب عادةً عن طريق برامج روبوت الويب المتوافقة أو برامج زحف الويب ؛ يميل البعض غير المطابق إلى تقديم طلبات بغض النظر عن السياق أو العواقب.

اقرأ ايضا :  ماهو SSH وماهي استعمالاته

على الرغم من الأمان الموصوف لطلبات GET ، في الممارسة العملية ، لا يتم تقييد معالجتها بواسطة الخادم بأي شكل من الأشكال. لذلك ، يمكن أن تسبب البرمجة المهملة أو المتعمدة تغييرات غير تافهة على الخادم. لا ينصح هذا، لأنه يمكن أن يسبب مشاكل لل تخزين المؤقت على شبكة الإنترنت ، محركات البحث وكلاء الآلي الأخرى، التي يمكن أن تجعل تغييرات غير مقصودة على الخادم. على سبيل المثال ، قد يسمح موقع ويب بحذف مورد من خلال عنوان URL مثل https://example.com/article/1234/delete ، والذي ، إذا تم جلبه بشكل تعسفي ، حتى باستخدام GET ، سيؤدي ببساطة إلى حذف المقالة. 

أحد الأمثلة على حدوث ذلك عمليًا كان أثناء الإصدار التجريبي قصير المدى من Google Web Accel­er­a­tor ، والذي جلب عناوين URL عشوائية على الصفحة التي كان المستخدم يشاهدها ، مما تسبب في تغيير السجلات أو حذفها تلقائيًا بشكل جماعي . تم تعليق الإصدار التجريبي بعد أسابيع فقط من إطلاقه لأول مرة ، بعد انتقادات واسعة النطاق.  

طرق غير فعالة 

تكون طريقة الطلب غير فعالة إذا كان للعديد من الطلبات المتطابقة بهذه الطريقة نفس التأثير المقصود لطلب واحد من هذا القبيل. يتم تعريف الطرق PUT و DELETE والطرق الآمنة على أنها غير فعالة.

في المقابل ، فإن طرق POST و CONNECT و PATCH ليست بالضرورة معطلة ، وبالتالي فإن إرسال طلب POST متطابق عدة مرات قد يؤدي إلى تعديل حالة الخادم أو يكون له تأثيرات أخرى مثل إرسال بريد إلكتروني . في بعض الحالات ، قد يكون هذا مرغوبًا فيه ، ولكن في حالات أخرى قد يكون ذلك بسبب حادث ، مثل عندما لا يدرك المستخدم أن الإجراء الذي اتخذه سيؤدي إلى إرسال طلب آخر ، أو لم يتلق تعليقات كافية تفيد بأن طلبه الأول كان ناجح. بينما قد تعرض متصفحات الويب مربعات حوار تنبيه لتحذير المستخدمين في بعض الحالات التي قد تؤدي فيها إعادة تحميل الصفحة إلى إعادة إرسال طلب POST ، فإن الأمر متروك عمومًا لتطبيق الويب للتعامل مع الحالات التي لا ينبغي فيها تقديم طلب POST أكثر من مرة.

لاحظ أن ما إذا كانت الطريقة غير فعالة لا يتم فرضها بواسطة البروتوكول أو خادم الويب. من الممكن تمامًا كتابة تطبيق ويب يتم فيه (على سبيل المثال) إدخال قاعدة بيانات أو إجراء آخر غير ثابت بواسطة طلب GET أو طلب آخر. ومع ذلك ، قد يؤدي تجاهل هذه التوصية إلى عواقب غير مرغوب فيها ، إذا افترض وكيل المستخدم أن تكرار نفس الطلب آمن عندما لا يكون كذلك.

طرق التخزين المؤقت 

طريقة الطلب قابلة للتخزين المؤقت إذا كان من الممكن تخزين الردود على الطلبات بهذه الطريقة لإعادة استخدامها في المستقبل. يتم تعريف طرق GET و HEAD و POST على أنها قابلة للتخزين المؤقت.

في المقابل ، فإن الطرق PUT و DELETE و CONNECT و OPTIONS و TRACE و PATCH ليست قابلة للتخزين المؤقت.

طلب حقول الرأس 

راجع أيضًا : قائمة حقول رأس HTTP § حقول الطلب

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

رسائل استجابة HTTP / 1.1

يتم إرسال رسالة استجابة بواسطة الخادم إلى العميل كرد على رسالة الطلب السابقة.

هذه مقدمة قصيرة لرسائل استجابة HTTP / 1.1 (لها نفس الدلالات — أكثر أو أقل — مثل تلك الموجودة في HTTP / 1.0).

ملاحظة : HTTP / 2 و HTTP / 3 لهما تمثيل مختلف لحالة HTTP والرؤوس.

صيغة الاستجابة 

يرسل الخادم رسائل استجابة إلى العميل ، والتي تتكون من : 

  • و سطر الحالة ، ويتألف من إصدار بروتوكول، و الفضاء ، و رمز الحالة استجابة ، فضاء آخر، سبب العبارة ربما فارغة، و إرجاع و سطر تغذية ، على سبيل المثال :
HTTP/1.1 200 OK
  • صفر أو أكثر من حقول رأس الاستجابة ، يتكون كل منها من اسم الحقل غير الحساس لحالة الأحرف ، ونقطتان ، ومسافة بيضاء بادئة اختيارية ، وقيمة الحقل ، ومسافة بيضاء لاحقة اختيارية وتنتهي بحرف إرجاع وتغذية سطر ، على سبيل المثال :
Content-Type: text/html
  • سطر فارغ يتكون من حرف إرجاع وخط تغذية ؛
  • نص رسالة اختياري .

رموز حالة الاستجابة 

في HTTP / 1.0 ومنذ ذلك الحين ، يُطلق على السطر الأول من استجابة HTTP سطر الحالة ويتضمن رمز الحالة الرقمي (مثل ” 404 ”) وعبارة سبب نصية (مثل “غير موجود”). رمز حالة الاستجابة هو رمز صحيح مكون من ثلاثة أرقام يمثل نتيجة محاولة الخادم لفهم وتلبية طلب العميل المقابل. تعتمد الطريقة التي يتعامل بها العميل مع الاستجابة بشكل أساسي على رمز الحالة ، وثانيًا على حقول رأس الاستجابة الأخرى. قد لا يفهم العملاء جميع أكواد الحالة المسجلة ولكن يجب عليهم فهم فئتهم (المعطاة من الرقم الأول من رمز الحالة) والتعامل مع رمز الحالة غير المعترف به باعتباره مكافئًا لرمز الحالة x00 لتلك الفئة.

عبارات السبب القياسية هي مجرد توصيات ، ويمكن استبدالها بعبارة “مكافئات محلية” وفقًا لتقدير مطور الويب . إذا أشار رمز الحالة إلى وجود مشكلة ، فقد يعرض وكيل المستخدم عبارة السبب للمستخدم لتقديم مزيد من المعلومات حول طبيعة المشكلة. يسمح المعيار أيضًا لوكيل المستخدم بمحاولة تفسير عبارة السبب ، على الرغم من أن هذا قد يكون غير حكيم لأن المعيار يحدد صراحة أن أكواد الحالة يمكن قراءتها آليًا وأن عبارات السبب يمكن قراءتها بواسطة الإنسان.

يحدد الرقم الأول من رمز الحالة فئته :1XX (معلوماتية)تم استلام الطلب ، استمرار العملية.2XX (ناجح)تم استلام الطلب وفهمه وقبوله بنجاح.3XX (إعادة توجيه)يجب اتخاذ مزيد من الإجراءات لإكمال الطلب.4XX (خطأ العميل)يحتوي الطلب على بناء جملة غير صحيح أو لا يمكن تنفيذه.5XX (خطأ في الخادم)فشل الخادم في تلبية طلب يبدو صالحًا.

حقول رأس الاستجابة 

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

لكل حقل عنوان استجابة معنى محدد يمكن تحسينه من خلال دلالات طريقة الطلب أو رمز حالة الاستجابة.

HTTP / 1.1 مثال على معاملة الطلب / الاستجابة 

يوجد أدناه نموذج لمعاملة HTTP بين عميل HTTP / 1.1 وخادم HTTP / 1.1 يعمل على www.example.com ، المنفذ 80.

ملاحظة : يحتوي HTTP / 1.0 على نفس الرسائل باستثناء عدد قليل من الرؤوس المفقودة.

ملاحظة : يستخدم HTTP / 2 و HTTP / 3 نفس آلية الطلب / الاستجابة ولكن مع تمثيلات مختلفة لرؤوس HTTP.

طلب العميل 

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

طلب العميل (يتكون في هذه الحالة من سطر الطلب وعدد قليل من العناوين التي يمكن اختصارها إلى "Host: hostname"العنوان فقط ) متبوعًا بسطر فارغ ، بحيث ينتهي الطلب بنهاية سطر مزدوج ، كل منها في شكل حرف إرجاع متبوعًا بسطر تغذية . و "Host: hostname"يميز قيمة رأس بين مختلف DNS أسماء تقاسم واحد عنوان IP ، مما يسمح القائم على اسم المضيف الظاهري . بينما اختياري في HTTP / 1.0 ، فهو إلزامي في HTTP / 1.1. (عادة ما تجلب “/” (الشرطة المائلة) ملف /index.html إذا كان هناك واحد.)

استجابة الخادم 

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World, this is a very simple HTML document.</p>
  </body>
</html>

و إيتاغ يستخدم حقل رأس (علامة كيان) لتحديد ما إذا كان النسخة المخبأة من الموارد المطلوبة مطابق لالإصدار الحالي من الموارد على الخادم. "Content-Type"يحدد نوع وسائط الإنترنت للبيانات التي تنقلها رسالة HTTP ، بينما "Content-Length"يشير إلى طولها بالبايت. ينشر خادم الويب HTTP / 1.1 قدرته على الاستجابة لطلبات نطاقات بايت معينة من المستند عن طريق تعيين الحقل "Accept-Ranges: bytes". هذا مفيد ، إذا احتاج العميل إلى أجزاء معينة فقط 2 من مورد أرسله الخادم ، وهو ما يسمى خدمة بايت . عندما "Connection: close"يتم الإرسال ، فهذا يعني أن خادم الويب سيغلق TCPالاتصال مباشرة بعد انتهاء نقل هذه الاستجابة. 

معظم سطور الرأس اختيارية ولكن بعضها إلزامي. عندما "Content-Length: number"يكون العنوان مفقودًا في استجابة مع نص كيان ، يجب اعتبار هذا خطأ في HTTP / 1.0 ولكن قد لا يكون خطأ في HTTP / 1.1 إذا كان الرأس "Transfer-Encoding: chunked"موجودًا. يستخدم ترميز النقل المقسم حجمًا مقطعًا من 0 لوضع علامة على نهاية المحتوى. حذفت بعض التطبيقات القديمة لـ HTTP / 1.0 العنوان "Content-Length"عندما لم يكن طول الكيان الأساسي معروفًا في بداية الاستجابة ، وبالتالي استمر نقل البيانات إلى العميل حتى أغلق الخادم المقبس.

يمكن استخدام A لإعلام العميل بأن جزء كيان الجسم من البيانات المرسلة مضغوط بواسطة خوارزمية gzip. "Content-Encoding: gzip"

اتصالات مشفرة 

الطريقة الأكثر شيوعًا لإنشاء اتصال HTTP مشفر هي HTTPS . 3 توجد أيضًا طريقتان أخريان لتأسيس اتصال HTTP مشفر : بروتوكول نقل النص التشعبي الآمن ، واستخدام رأس ترقية HTTP / 1.1 لتحديد ترقية إلى TLS. دعم المستعرض لهذين الاثنين ، ومع ذلك ، يكاد يكون غير موجود. 

بروتوكولات مماثلة 

  • على بروتوكول غوفر هو بروتوكول توصيل المحتوى الذي شردهم HTTP في 1990s في وقت مبكر.
  • و SPDY البروتوكول هو بديل لHTTP المتقدمة في جوجل ، حلت محلها HTTP / 2 .
  • على بروتوكول الجوزاء هو بروتوكول مستوحاة غوفر والتي ايات الميزات المتعلقة بالخصوصية.

wikipedia

اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *