بروتوكول نقل النص المتشعب

قالب:HTTP هو بروتوكول يطبق على مستوى نظم المعلومات الموزعة والتعاونية و hypermedia information system. يستخدم لاسترجاع الموارد المرتبطة، وتدعى وثائق إلكترونية (hypertext document)،كما أدى إلى إنشاء الشبكة العالمية (world wide web) في عام 1990 من قبل عالم الفيزياء الإنكليزي تيم بيرنرز لي (Tim Berners-Lee). هناك إصداران رئيسيان، HTTP/1.0 الذي يستخدم اتصال منفصل لكل وثيقة وHTTP/1.1 الذي يمكن إعادة استخدامه بالسياق نفسه للتحميل، على سبيل المثال، الصور للصفحة المخدومة فقط. بالتالي HTTP/1.1 قد يكون أسرع لأنه يستغرق وقتا طويلا لاقامة مثل هذه الاتصالات.

تطوير معايير (HTTP) قد تم تنسيقها من قبل (World Wide Web Consortium) وفرقة هندسة الإنترنت ((Engineering Task Force (IETF)، وبلغت ذروتها في نشر سلسلة من طلبات التعليقات((Requests for Comments (RFCs)، وعلى الأخص RFC 2616(في يونيو 1999)، الذي يُعَرِّف HTTP/1.1، النسخة الشائعة الاستعمال من (HTTP).

الدعم لHTTP/1.1 بمعاييره الأولية انطلق من تطور RFC 2068 ثم سرعان ما اعتمد من قبل أعظم مطوري المتصفح في أوائل عام 1996. بحلول آذار / مارس 1996، HTTP/1.1 بمعاييره الأولية اعتمد من قبل Netscape، Netscape Navigator Gold 2.01، Mosaic 2.7، Lynx 2.5 و Internet Explorer 3.0 تكيف المستخدم الطرفي مع المتصفحات الجديدة كان سريعا. في آذار / مارس 1996، واحدة من شركات الاستضافة على الشبكة ذكرت أن أكثر من 40 ٪ من المتصفحات المستخدمة على شبكة الإنترنت كانت متوافقة مع HTTP 1.1. نفس الشركة ذكرت أنه بحلول يونيو 1996، 65 ٪ من المتصفحات التي تصل إلى خدمها(servers) كانت متوافقة معHTTP/1.1 معيار HTTP/1.1 على النحو المحدد في RFC 2068 تم إطلاقه رسميا في يناير 1997. التحسينات والتحديثات لمعيار HTTP/1.1 أطلقت بموجب RFC 2616 في حزيران / يونيو 1999.

اHTTP هومعيار طلب / استجابة كما هي الحال في حساب العميل- الخادم. العميل هو تطبيق (مثل متصفح الويب، العنكبوت، الخ) على أجهزة الكمبيوتر المستخدمة من قبل المستخدم الطرفي، والخادم هو تطبيق يعمل على الكمبيوتر الذي يستضيف الموقع على شبكة الإنترنت. العميل الذي يقدم طلبات ال(HTTP)، يطلق عليه وكيل المستخدم (user agent). الخادم الذي يخزن، أو يخلق موارد مثل ملفات وصور HTML، الملفات والصور، يمكن أن يسمى خادم الأصل (origin server). قد يكون بين وكيل المستخدم وخادم الأصل وسطاء عدة، مثل الوكلاء(proxies) والبوابات(gateways)، والأنفاق(tunnels).

HTTP ليس مقيد من حيث المبدأ باستخدام TCP/ IP، على الرغم من أن هذا هو التطبيق الأكثر شعبية عبر شبكة الإنترنت. بل يمكن أن يكون HTTP قد نفذ على رأس أي بروتوكول آخر على شبكة الإنترنت، أو على شبكات أخرى. HTTP يفترض فقط وجود النقل الموثوق به؛ أي بروتوكول ينص على ضمانات من هذا القبيل يمكن استخدامه.

الموارد التي يمكن الوصول إليها عن طريق HTTP يتم تحديدها باستخدام معرفات الموارد الموحدة (URIs)، أو بشكل أكثر تحديدا، معينات مواقع الموارد الموحدة (URLs) التي تستخدم في :http أو مخططات https:URI.

حزمة بروتوكولات الإنترنت
طبقة التطبيقات
بروتوكول المنافذ والتوجية · بروتوكول إعدادات الخوادم الديناميكي · بروتوكول أسماء النطاقات · بروتوكول نقل الملفات · خدمة الحزمة العامة الراديوية · بروتوكول نقل النصوص المهجنة · بروتوكول الوصول لرسائل البريد · بروتوكول المحادثة الجماعية  · البروتوكول الخفيف للوصول للدليل · Media Gateway Control Protocol (Megaco) · Media Gateway Control Protocol (MGCP) · برتوكول نقل أخبار الشبكة  ·  · بروتوكول صندوق البريد · Routing Information Protocol · نداء الإجراء البعيد  · Real-time Transport Protocol · بروتوكول سريان المعلومات في الزمن الحقيقي  · Session Description Protocol · Session Initiation Protocol · بروتوكول إرسال البريد البسيط  · بروتوكول إدارة الشبكات البسيط  · سواب  · قشرة آمنة  · تل نت · أمن طبقة النقل · Extensible Messaging and Presence Protocol · 
طبقة النقل
تي سي بي  · بروتوكول بيانات المستخدم  · بروتوكولات تقيم رابطة والبروتوكولات عديمة الرابطة · Stream Control Transmission Protocol · بروتوكول حجز الموارد · Explicit Congestion Notification · 
طبقة الانترنت
بروتوكول الانترنت (IPv4, IPv6) · Address Resolution Protocol · بروتوكول التحكم بالرسائل · ICMPv6 · فتح أقصر مسار أولا  · بروتوكول إدارة مجموعة الإنترنت · بروتوكول امن وسرية البيانات · 
طبقة الربط
Neighbor Discovery Protocol · بروتوكول النقل عبر الأنفاق ( Layer 2 Tunneling Protocol) · بروتوكول النقطة إلى النقطة  · طبقة التحكم بالوصول إلى الوسائط (إيثرنت, خط المشترك الرقمي , شبكة رقمية للخدمات المتكاملة , FDDI) · 
عرض · نقاش · تعديل

دورة (HTTP)

دورة HTTP هي سلسلة من عمليات الطلب والاستجابة تتم من خلال الشبكة. دورة HTTP هي سلسلة من عمليات الطلب والاستجابة تتم من خلال الشبكة. عندما يبدأ العميل الطلب فإنه يؤسس بروتوكول التحكم في الإرسال ((Transmission Control Protocol (TCP) يتصل بمنفذ خاص على المضيف (host) (عادة المنفذ 80، انظرالى لائحة TCP و UDP لأرقام المنافذ). ينصت الخادم(server) من خلال هذا المنفذ منتظراً طلب العميل. عند استلام الطلب، يرسل الخادم خط الوضع (status line)، مثل "HTTP/1.1 200 OK "، ورسالة منه قد تتضمن الموارد المطلوبة أو رسالة خطأ أو بعض المعلومات الأخرى.

رسالة طلب (request message)

رسالة الطلب تتألف من العناصر التالية :

  • سطر الطلب، مثل GET /images/logo.gif HTTP/1.1، والتي تطلب موردا

يسمى /images/logo.gif من الخادم

  • العناوين الرأسية(headers)، مثل: (Accept-Language: en)
  • سطر فارغ
  • نص الرسالة (اختياري)

سطر الطلب وجميع العناوين الرأسية يجب أن تنتهي ب

<CR><LF> (that is, a carriage return followed by a line feed). السطر الفارغ يجب أن يتكون من <CR><LF>فقط من غيرمسافات بيضاء(whitespaces) أخرى. في بروتوكول HTTP/1.1، جميع العناوين الرأسية اختيارية باستثناء ال(host).

سطر الطلب الذي لا يحتوي إلا على اسم المسارمقبول من الخوادم للحفاظ على التوافق مع عملاء (HTTP) وذلك قبل مواصفات HTTP/1.0 في (RFC1945).

دوال الطلب

ملف:Http request telnet ubuntu.png
طلب HTTP جعل باستخدام التلنت telnet. الطلب والعناوين الرأسية للاستجابة ونص الاستجابة ألقي الضوء عليها.

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

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


GET
تطلب عرض مورد محدد. علما أن GET ينبغي أن تستخدم من أجل العمليات التي تسبب آثار جانبية، مثل استخدامه لاتخاذ إجراءات في تطبيق الشبكة. أحد أسباب ذلك هو أن GET يمكن أن تستخدم بشكل اعتباطي من قبل الرجال الآليين(robots) أو الزواحف(crawlers)، والتي لا حاجة فيها للنظر إلى الآثار الجانبية التي يسببها الطلب. انظر الدوال الآمنة أدناه.
POST
تقدم البيانات التي سيتم معالجتها (على سبيل المثال، من نموذج html) إلى الموارد التي تم تحديدها. البيانات يتم تضمينها في نص الطلب. هذا قد يؤدي إلى خلق موارد جديدة أو تحديث الموارد الموجودة أو كلاهما.
PUT
يرسل تمثيل للمورد المحدد.
DELETE
يحذف المورد المحدد.
TRACE
يحاكي وصول الطلب وتنفيذه، بحيث يمكن للعميل معرفة ما أحدثته الخوادم الوسيطة من إضافة أو تغيير في الطلب.
OPTIONS
يرجع دوال HTTP التي يدعمها الخادم لعنوان محدد. ويمكن استخدامها للتحقق من وظيفة خادم الشبكة عن طريق الطلب '*' بدلا من مورد معين.
CONNECT
تحويل طلب الاتصال إلى نفق TCP/IP شفاف، عادة لتسهيل اتصالات SSL المشفرة (HTTPS) عن طريق وكيل HTTP غير مشفر.

خوادم (HTTP) مطلوبة على الأقل لتنفيذ الدوال (GET) و(HEAD)، وحيثما أمكن الدالة (OPTIONS) أيضاً.

الدوال الآمنة

بعض الدوال (على سبيل المثال، HEAD, GET, OPTIONS and TRACE) تعرّف بأنها آمنة، أي أنها تهدف لاسترجاع المعلومات فقط ولا تحدث أي تغييرفي حالة الخادم. إن إجراء الطلبات بشكل اعتباطي دون الاخذ بعين الاعتبار سياق حالة التطبيق يمكن اعتباره آمنا.

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

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

الدوال ال(Idempotent) وتطبيقات الشبكة

الدوال PUT، DELETE يتم تعريفها لتكون idempotent، مما يعني أن العديد من الطلبات المماثلة ينبغي أن يكون لها نفس الأثر كطلب واحد. الدوال GET, HEAD, OPTIONS، TRACE، توصف بأنها آمنة، كما ينبغي أن تكون HTTP ، idempotentهو بروتوكول عديم الحالة.

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

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

رموز الحالة

طالع أيضاً: List of HTTP status codes

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

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

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

طالع أيضاً: HTTP persistent connections

في HTTP/0.9 و HTTP/1.0، يتم إغلاق الاتصال بعد إتمام طلب واحد واستجابته. في HTTP/1.1 أُنتجت آلية المحافظة على الحياة (keep-alive-mechanism)، حيث يمكن استخدام الاتصال لأكثر من طلب واحد.

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

الإصدار 1.1 من البروتوكول عمل على تحسين عرض النطاق الترددي(the bandwidth) لHTTP/1.0. على سبيل المثال، قدم HTTP/1.1 تشفير النقل المقسم (chunked transfer encoding) للسماح للمحتوى بإجراء اتصالات مستمرة ليكون متدفقاً، بدلا من كونه مخففاً. النقل بواسطة خط أنابيب في (HTTP) يقلل من الوقت الضائع، مما يسمح للعملاء بإرسال طلبات متعددة قبل وصول استجابة الطلب الأول. هناك تحسن آخر في البروتوكول وهو خدمة البايت (byte serving)، وذلك عندما ينقل الخادم من الموارد فقط الجزء الذي قد طلب صراحة من قبل العميل.

حالة جلسة (HTTP)

HTTP هو بروتوكول عديم الحالة. ميزة بروتوكول عديم الحالة أن المضيفين(hosts) لا يحتاجون إلى الاحتفاظ بمعلومات عن المستخدمين في الفترات الفاصلة بين الطلبات، ولكن هذا يجبر مطوري الشبكة على استخدام أساليب بديلة للحفاظ على أوضاع المستخدمين. على سبيل المثال، عندما يحتاج المضيف لتخصيص محتوى موقع على شبكة الإنترنت للمستخدم، يجب كتابة تطبيق ويب لتتبع جولة المستخدم من صفحة إلى أخرى. الطريقة الشائعة لحل هذه المشكلة تتضمن إرسال واستقبال الكوكيز(Cookies). وتشمل الأساليب الأخرى التي تعتمد على الخادم الجلسات(sessions)، والمتغيرات الخفية، ومعلومات العنوان المشفرة مثل index.php?session_id=some_unique_session_code /

HTTP الآمن

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

مخطط HTTPS URI

طالع أيضاً: HTTPS

HTTPS : هو مخطط URI مطابق في بنائه لمخطط HTTP الذي يستخدم في اتصالات HTTP المعتادة، لكنه يشير للمتصفح باستخدام طبقة تشفير إضافية من SSL/TLS لحماية حركة المرور. SSL ملائمة بصفة خاصة للHTTP لأن بإمكانها أن توفر بعض الحماية حتى إذا كان جانب واحد فقط من الاتصال موثقاً. هذا هو الحال مع معاملات HTTP عبر الإنترنت، حيث يكون الخادم فقط موثقاً (عن طريق فحص العميل لشهادة الخادم).

رأس ترقية HTTP 1.1

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

العميل : 

GET /encrypted-area HTTP/1.1
                                  Host: www.example.com

الخادم : 

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

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

فوائد استخدام هذا الأسلوب لإنشاء اتصال آمن :

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

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

مثال الجلسة

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

طلب العميل

  GET /index.html HTTP/1.1
 Host: www.example.com

يتبع طلب العميل سطر فارغ، وذلك لأن كل طلب ينتهي ب CR يتبعه LF. العنوان الرأسي(HOST) يميز بين أسماء DNS المختلفة التي تتقاسم عنوان IP وحيد، وبالتالي يسمح بالاستضافة العملية بناء على الاسم. نجد ذلك اختياري في HTTP/1.0، لكنه إلزامي في HTTP/1.1.

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

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

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

أنظر أيضاً

المراجع

قراءات أخرى

وصلات خارجية

قالب:Semantic Web

af:HTTP az:HTTP bg:HTTP bn:হাইপার টেক্সট ট্রান্সফার প্রোটোকল bs:Hypertext Transfer Protocol ca:Protocol de transferència d'hipertext cs:Hypertext Transfer Protocol cy:HTTP da:HTTP de:Hypertext Transfer Protocol el:Πρωτόκολλο Μεταφοράς Υπερκειμένου Hypertext Transfer Protocol]] eo:Hiperteksto-Transiga Protokolo es:Hypertext Transfer Protocol et:Hüperteksti edastusprotokoll eu:HTTP fa:پروتکل انتقال ابرمتن fi:HTTP fr:Hypertext Transfer Protocol ga:Prótacal Aistrithe Hipirtéacs gl:HTTP he:Hypertext Transfer Protocol hr:HTTP hu:HTTP id:Hypertext Transfer Protocol is:Hypertext Transfer Protocol it:Hypertext Transfer Protocol ja:Hypertext Transfer Protocol kk:HTTP ko:HTTP lb:Hypertext Transfer Protocol lt:HTTP lv:HTTP ml:ഹൈപ്പര്‍ ടെക്സ്റ്റ്‌ ട്രാന്‍സ്ഫര്‍ പ്രോട്ടോകോള്‍ ms:HTTP nl:Hypertext Transfer Protocol nn:Hypertext Transfer Protocol no:HTTP pl:Hypertext Transfer Protocol pt:Hypertext Transfer Protocol ro:HTTP ru:HTTP sh:HTTP simple:Hypertext Transfer Protocol sk:Hypertext Transfer Protocol sl:HTTP sq:Hypertext Transfer Protocol sr:HTTP sv:HTTP ta:மீயுரை பரிமாற்ற நெறிமுறை th:เอชทีทีพี tl:HTTP tr:HTTP uk:HTTP vi:Hypertext Transfer Protocol zh:超文本传输协议 zh-yue:HTTP

مجلوبة من «https://3arf.org/w/index.php?title=بروتوكول_نقل_النص_المتشعب&oldid=683315»