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

HTTP- بروتوكول نقل بيانات مستخدم على نطاق واسع، مخصص في الأصل لنقل مستندات النص التشعبي (أي المستندات التي قد تحتوي على روابط تسمح بالتنقل إلى مستندات أخرى).

يشير الاختصار HTTP إلى بروتوكول نقل النص التشعبي، "بروتوكول نقل النص التشعبي". وفقًا لمواصفات OSI، فإن HTTP عبارة عن بروتوكول طبقة تطبيق (العلوية والسابعة). الحالي على هذه اللحظةتم وصف إصدار البروتوكول، HTTP 1.1، في مواصفات RFC 2616.

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

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

يُستخدم HTTP أيضًا غالبًا كبروتوكول نقل لبروتوكولات طبقة التطبيقات الأخرى مثل SOAP وXML-RPC وWebDAV. في هذه الحالة، يُقال إن بروتوكول HTTP يُستخدم كـ "نقل".

واجهات برمجة التطبيقات للكثيرين منتجات البرمجياتيتضمن أيضًا استخدام HTTP لنقل البيانات - يمكن أن تكون البيانات نفسها بأي تنسيق، على سبيل المثال، XML أو JSON.

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

كيفية إرسال طلب HTTP؟

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

لنفترض أنه دخل شريط العنوانالتالي:

http://alizar.site/

وبناء على ذلك، أنت، كمتصفح ويب، تحتاج الآن إلى الاتصال بخادم الويب على alizar.site.

لهذا يمكنك استخدام أي فائدة مناسبةسطر الأوامر. على سبيل المثال التلنت:

تلنت العزار موقع 80

اسمحوا لي أن أوضح على الفور أنه إذا غيرت رأيك فجأة، فاضغط على Ctrl + "]" ثم أدخل - وهذا سيسمح لك بإغلاق اتصال HTTP. بالإضافة إلى Telnet، يمكنك تجربة NC (أو NCA) - حسب ذوقك.

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

من أجل إنشاء طلب HTTP، تحتاج إلى إنشاء سطر بداية وتعيين على الأقلرأس واحد هو رأس المضيف، وهو إلزامي ويجب أن يكون موجودًا في كل طلب. الحقيقة هي أن تحويل اسم المجال إلى عنوان IP يتم من جانب العميل، وبالتالي، عند فتح اتصال TCP، لا يحتوي الخادم البعيد على أي معلومات حول العنوان الذي تم استخدامه للاتصال: يمكن أن يكون، على سبيل المثال، عنوان alizar..ru أو m.. ومع ذلك، في الواقع، يتم فتح اتصال الشبكة في جميع الحالات باستخدام العقدة 212.24.43.44، وحتى لو لم يكن عنوان IP هذا في البداية عند فتح الاتصال، ولكن بعض اسم النطاق، فلن يتم إبلاغ الخادم بهذا بأي شكل من الأشكال - ولهذا السبب يجب تمرير هذا العنوان في رأس المضيف.

يتكون سطر طلب البداية (الأولي) لـ HTTP 1.1 وفقًا للمخطط التالي:

على سبيل المثال (قد يشير خط البداية هذا إلى أن الصفحة الرئيسية للموقع مطلوبة):

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

حظا سعيدا والتعلم المثمر!

العلامات:

• http
• alizar
• com.spy

اضف اشارة

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

العناوين؟

"بروتوكول نقل النص التشعبي" هو بالضبط ما تتم ترجمته، وبفضل وجوده، أصبح الاتصال بين العميل والخادم ممكنًا. بعبارات بسيطة، يرسل مستخدم المتصفح طلبًا، ويبدأ الاتصال بالخادم. وينتظر الأخير، افتراضيًا، طلبًا من العميل، ويعالجه ويرسل المعلومات أو الاستجابة النهائية. في شريط البحثيقوم المستخدم "بإدخال" عنوان موقع الويب الذي يبدأ بـ http:// ويتلقى النتيجة في شكل صفحة تفتح.

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

بشكل عام، رؤوس http فعالة جدًا. وهي غير مرئية في ترميز HTML؛ ويتم إرسالها قبل المعلومات المطلوبة. يتم إرسال العديد من الرؤوس تلقائيًا بواسطة الخادم. من أجل إرسالها إلى لغة PHP، يجب عليك استخدام وظيفة الرأس.

التفاعل بين المتصفح والموقع

التفاعل بين المتصفح والموقع بسيط للغاية. لذلك، يبدأ رأس http سطر الطلب، والذي يتم إرساله بعد ذلك إلى الخادم. الجواب هو المعلومات التي يحتاجها العميل. بالمناسبة، كان بروتوكول http هو الأكثر استخدامًا على الإنترنت منذ سبعة عشر عامًا. إنها بسيطة وموثوقة وسريعة ومرنة. المهمة الرئيسية لـ http هي طلب المعلومات من خادم الويب. العميل هو المتصفح، والخادم هو ligthttp وApache وnginx. إذا كان الاتصال بينهما ناجحا، يتلقى الخادم استجابة للطلب معلومات ضرورية. تحتوي معلومات http على نص، ملفات الصوت، فيديو.

يمكن أن يكون البروتوكول وسيلة نقل للآخرين. يتكون طلب العميل من ثلاثة أجزاء:

• سطر البداية (نوع الرسالة)؛
• الرؤوس (معلمات الرسالة)؛
• نص المعلومات (رسالة مفصولة بسطر فارغ).

يعد سطر البداية عنصرًا مطلوبًا لطلب حقل رأس http. يتكون هيكل طلب المستخدم من ثلاثة أجزاء رئيسية:

1. طريقة. يتم استخدامه للإشارة إلى نوع الطلب.
2. طريق. هذه هي سلسلة URL التي تتبع المجال.
3. البروتوكول المستخدم. وهو يتألف من بروتوكول ونسخة http.

تستخدم المتصفحات الحديثة الإصدار 1.1. فيما يلي الرؤوس بتنسيق "الاسم: القيمة".

التخزين المؤقت HTTP

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

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

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

وصف رؤوس http

إحدى أهم آليات التخزين المؤقت هي رؤوس انتهاء صلاحية http. تشير هذه الرؤوس إلى تاريخ انتهاء صلاحية المعلومات المقدمة في الرد. تشير إلى الوقت والتاريخ الذي سيتم فيه اعتبار ذاكرة التخزين المؤقت قديمة. على سبيل المثال، يبدو هذا الرأس بالطريقة الآتية: تنتهي: Wen، 30 نوفمبر 2016، الساعة 13:45:00 بتوقيت جرينتش. هذا الهيكليتم استخدامه في كل مكان تقريبًا، بما في ذلك التخزين المؤقت للصفحات والصور. إذا قام المستخدم بتحديد تاريخ قديم، فلن يتم تخزين المعلومات مؤقتًا.

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

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

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

كيف يمكنني رؤية الرؤوس؟

لرؤية رأس http، تحتاج إلى تثبيت المكونات الإضافية للمتصفح، على سبيل المثال، فايرفوكس:

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

بمجرد تثبيت المكونات الإضافية، قم بتشغيلها في متصفحك.

طرق الاستعلام

تشبه الأساليب المستخدمة في HTTP الإرشادات التي يتم إرسالها كرسالة إلى الخادم. هذا كلمة خاصةباللغة الإنجليزية.

• الحصول على الطريقة. يتم استخدامه لطلب معلومات من أحد الموارد. هذا هو المكان الذي تبدأ فيه جميع الإجراءات.
• بريد. يتم استخدامه لإرسال البيانات. على سبيل المثال، يتم وضع رسالة على إحدى الشبكات الاجتماعية أو تعليق في نص طلب POST بواسطة المتصفح وإرسالها إلى الخادم.
• رأس. الطريقة مشابهة للطريقة الأولى، ولكنها تؤدي وظيفة سهلة. فهو يطلب فقط البيانات الوصفية، باستثناء الرسالة من الرد. يتم استخدام هذه الطريقة إذا كنت تريد الحصول على معلومات حول الملفات دون تنزيلها. يتم استخدامه إذا كانوا يريدون التحقق من وظائف الروابط الموجودة على الخادم.
• يضع. يقوم بتحميل البيانات إلى عنوان URL. ينقل كميات كبيرة من البيانات.
• خيارات. يعمل مع تكوينات الخادم.
• URI. يحدد المورد ويحتوي على عنوان URL.

هيكل استجابة HTTP

يستجيب الخادم لطلبات العميل برسائل طويلة. تتكون الاستجابة من عدة أسطر تشير إلى إصدار البروتوكول ورمز حالة الخادم (200). يخبرك بما تغير على الخادم أثناء معالجة الطلب الوارد:

1. تشير الحالة "مئتان" إلى المعالجة الناجحة للمعلومات. ثم يرسل الخادم المستند إلى العميل. تشير الأسطر المتبقية من الطلب إلى معلومات أخرى حول المعلومات التي يتم إرسالها.
2. إذا لم يتم العثور على الملف أو كان غير موجود، يرسل الخادم رمز 404 إلى العميل، ويسمى أيضًا خطأ.
3. يشير الرمز 206 إلى تنزيل جزئي للملف، والذي يمكن استئنافه بعد مرور بعض الوقت.
4. يشير الرمز 401 إلى أنه تم رفض التفويض. وهذا يعني أن الصفحة المطلوبة محمية بكلمة مرور يجب إدخالها لتأكيد الإدخال.
5. يشير الرمز 403 إلى حظر الوصول إلى الملفات أو مقاطع الفيديو أو تنزيلها، وهو رد شائع على الإنترنت.
6. هناك أيضًا إصدارات أخرى من الأكواد: الحركة المؤقتة للملف المطلوب، خطأ داخلي في الخادم، الحركة الدائمة. في هذه الحالة، سيتم إعادة توجيه المستخدم. إذا ظهر الكود 500 فهذا يعني أن هناك مشاكل في الخادم.

URL - ما هو؟

عنوان URL هو قلب التواصل عبر الويب بين العميل والخادم. عادةً ما يتم إرسال الطلب عبر عنوان URL - محدد موقع الموارد الموحد. هيكل طلب عنوان url بسيط للغاية. وهو يتألف من عدة عناصر: بروتوكول http (الرأس)، والصوت (عنوان الموقع)، والمنفذ، ومسار المورد، والاستعلام.

البروتوكول متاح أيضًا للتأمين اتصالات httpsوتبادل المعلومات. يحتوي عنوان URL على معلومات حول موقع موقع معين على الإنترنت. يتضمن العنوان اسم المجال والمسار إلى الصفحة وعنوانها.

العيب الرئيسي للعمل مع عناوين URL هو التفاعل غير المريح مع الأبجدية اللاتينية، وكذلك الأرقام والرموز. يلعب التحسين دورًا مهمًا في تحسين محركات البحث.

قد لا يرغب مستخدمو ومطورو الكمبيوتر النشطون في التعرف على البعض التوصيات المهنيةيقدمها خبراء في هذا المجال:

• الإشارة إلى تواريخ انتهاء الملفات والمستندات مع مراعاة التحديثات. المعلومات الإحصائيةالمشار إليها في قيم الحد الأقصى للعمر الكبيرة.
• يجب أن يكون الوصول إلى مستند واحد متاحًا على عنوان URL واحد فقط.
• إذا كنت تقوم بتحديث ملف سيتم تنزيله بواسطة المستخدم، فقم بتغيير اسمه واربطه. وهذا يضمن تنزيل مستند جديد وليس مستندًا قديمًا.
• يجب أن تتوافق عناوين آخر تعديل مع التاريخ الفعلي الذي تم فيه آخر تعديل للمحتوى. لا يجب عليك إعادة حفظ الصفحات والمستندات إلا إذا قمت بتغييرها.
• استخدم طلبات POST فقط عند الضرورة. حافظ على عمل SSL إلى الحد الأدنى.
• يجب التحقق من الرؤوس باستخدام مكون REDbot الإضافي قبل إرسالها بواسطة الخادم.

HTTP هو بروتوكول لنقل النص التشعبي بين الأنظمة الموزعة. في الأساس، http هو العنصر الأساسي الويب الحديث. كمطوري ويب يحترمون أنفسهم، يجب أن نعرف أكبر قدر ممكن عنها.

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

سأشير أيضًا في هذه المقالة بشكل أساسي إلى معيار RFC 2616: بروتوكول نقل النص التشعبي - HTTP/1.1.

أساسيات HTTP

يتيح HTTP الاتصال بين العديد من المضيفين والعملاء ويدعم أيضًا خط كاملاعدادات الشبكة.

بشكل أساسي، يتم استخدام TCP/IP للاتصالات، ولكن هذا ليس الخيار الوحيد الممكن. افتراضيًا، يستخدم TCP/IP المنفذ 80، ولكن يمكن استخدام منفذ آخر.

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

الإصدار الحالي من بروتوكول HTTP هو 1.1، حيث تم تقديم بعض الميزات الجديدة. وأهمها في رأيي: الدعم المستمر اتصال مفتوح، آلية جديدة لنقل البيانات، ترميز النقل المقسم، رؤوس جديدة للتخزين المؤقت. وسنتناول بعضًا من هذا في الجزء الثاني من هذه المقالة.

عنوان URL

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

يمكن أن يكون البروتوكول http للاتصالات العادية أو https لتبادل البيانات بشكل أكثر أمانًا. المنفذ الافتراضي هو 80. ويتبع ذلك المسار إلى المورد الموجود على الخادم وسلسلة من المعلمات.

طُرق

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

الطرق الموجودة:

يحصل: وصول الموارد الموجودة. يسرد عنوان URL الكل معلومات ضرورية، حتى يتمكن الخادم من العثور على المورد المطلوب وإعادته كاستجابة.

بريد: يستخدم لإنشاء مورد جديد. طلب ما بعديحتوي عادةً على كافة المعلومات الضرورية لإنشاء مورد جديد.

يضع: تحديث المورد الحالي. يحتوي طلب PUT على البيانات المراد تحديثها.

يمسح: يستخدم لحذف مورد موجود.

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

يدعم HTTP أيضًا طرقًا أخرى:

رأس: مشابه لـ GET. والفرق هو أنه مع هذا النوع من الطلب لا يتم إرسال أي رسالة. يتلقى الخادم الرؤوس فقط. يُستخدم، على سبيل المثال، لتحديد ما إذا كان المورد قد تم تعديله.

يتعقب: أثناء الإرسال، يمر الطلب عبر العديد من نقاط الوصول والخوادم الوكيلة، كل منها يدخل معلوماته الخاصة: IP، DNS. باستخدام هذه الطريقة، يمكنك رؤية جميع المعلومات الوسيطة.

خيارات: يستخدم لتحديد إمكانيات الخادم وإعداداته وتكوينه لمورد معين.

رموز الحالة

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

1xx: رسائل المعلومات

تم تقديم مجموعة من هذه الرموز في HTTP/1.1. يمكن للخادم إرسال طلب من النموذج: توقع: 100-متابعة، مما يعني أن العميل لا يزال يرسل بقية الطلب. يتجاهل العملاء الذين يقومون بتشغيل HTTP/1.0 هذه الرؤوس.

2xx: رسائل النجاح

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

• 202 مقبول: تم قبول الطلب، ولكن قد لا يحتوي على المورد في الاستجابة. وهذا مفيد للطلبات غير المتزامنة من جانب الخادم. يحدد الخادم ما إذا كان سيتم إرسال المورد أم لا.
• 204 لا يوجد محتوى: لا توجد رسالة في نص الاستجابة.
• 205 إعادة ضبط المحتوى: يأمر الخادم بإعادة ضبط العرض التقديمي للمستند.
• 206 المحتوى الجزئي: الرد يحتوي على جزء فقط من المحتوى. تحدد الرؤوس الإضافية الطول الإجمالي للمحتوى والمعلومات الأخرى.

3xx: إعادة التوجيه

نوع من الرسائل الموجهة إلى العميل حول ضرورة اتخاذ إجراء آخر. حالة الاستخدام الأكثر شيوعًا هي إعادة توجيه العميل إلى عنوان آخر.

• 301 منقول بشكل دائم: يمكن الآن العثور على المورد على عنوان URL مختلف.
• 303 انظر أخرى: يمكن العثور على المورد مؤقتًا على عنوان URL مختلف. يحتوي رأس الموقع على عنوان URL مؤقت.
• 304 لم يتم تعديله: يحدد الخادم أن المورد لم يتم تعديله ويحتاج العميل إلى استخدام النسخة المخزنة مؤقتًا من الاستجابة. للتحقق من هوية المعلومات، يتم استخدام ETag (تجزئة علامة الكيان)؛

4xx: أخطاء العميل

يتم استخدام فئة الرسالة هذه بواسطة الخادم إذا قرر أن الطلب قد تم إرساله عن طريق الخطأ. الرمز الأكثر شيوعًا هو 404 غير موجود. هذا يعني أنه لم يتم العثور على المورد على الخادم. الرموز المحتملة الأخرى:

• 400 اقتراح غير جيد : تم صياغة السؤال بشكل غير صحيح.
• 401 غير مصرح به: المصادقة مطلوبة لتقديم طلب. يتم إرسال المعلومات من خلال رأس التفويض.
• 403 ممنوع: الخادم لم يسمح بالوصول إلى المورد.
• 405 الطريقة غير مسموح بها: تم استخدام أسلوب HTTP غير صالح للوصول إلى المورد.
• 409 الصراع: لا يمكن للخادم معالجة الطلب بشكل كامل بسبب تحاول تغيير المزيد نسخة جديدةالموارد. يحدث هذا غالبًا مع طلبات PUT.

5xx: أخطاء الخادم

سلسلة من الرموز المستخدمة لاكتشاف خطأ الخادم عند معالجة الطلب. الأكثر شيوعا: 500 الخادم الداخليخطأ. خيارات أخرى:

• 501 لم ينفذ: الخادم لا يدعم الوظيفة المطلوبة.
• 503 الخدمة غير متوفرة: يمكن أن يحدث هذا إذا كان الخادم به خطأ أو كان مثقلًا. عادةً في هذه الحالة، لا يستجيب الخادم، وينتهي الوقت المحدد للاستجابة.

تنسيقات رسائل الطلب/الرد

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

دعونا ننظر إلى الهيكل رسالة مرسلةعبر HTTP:

الرسالة = *() CRLF [ ] = سطر الطلب | خط الحالة = اسم الحقل ": "قيمة الحقل

بين رأس ونص الرسالة يجب أن يكون هناك خط فارغ. يمكن أن يكون هناك عدة عناوين:

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

العناوين العامة

فيما يلي عدة أنواع من الرؤوس المستخدمة في كل من الطلبات والاستجابات:

رأس عام = التحكم في ذاكرة التخزين المؤقت | اتصال | التاريخ | براغما | مقطورة | ترميز النقل | ترقية | عبر | تحذير

لقد تناولنا بالفعل بعض الأمور في هذه المقالة، وسنناقش بعضها بمزيد من التفصيل في الجزء الثاني.

يتم استخدام الرأس via في طلب TRACE، ويتم تحديثه بواسطة كافة الخوادم الوكيلة.

يتم استخدام رأس Pragma لسرد الرؤوس المخصصة. على سبيل المثال، Pragma: no-cache هو نفس التحكم في Cache-Control: no-cache. سنتحدث أكثر عن هذا في الجزء الثاني.

يتم استخدام رأس التاريخ لتخزين تاريخ ووقت الطلب/الاستجابة.

يتم استخدام رأس الترقية لتغيير البروتوكول.

يهدف ترميز النقل إلى تقسيم الاستجابة إلى أجزاء متعددة باستخدام ترميز النقل: مقسم. هذه ميزة جديدة في HTTP/1.1.

رؤوس الكيانات

تنقل رؤوس الكيانات معلومات تعريفية حول المحتوى:

رأس الكيان = السماح | ترميز المحتوى | لغة المحتوى | طول المحتوى | موقع المحتوى | المحتوى-MD5 | نطاق المحتوى | نوع المحتوى | تنتهي | آخر تعديل

جميع الرؤوس مسبوقة بالمحتوى - توفر معلومات حول بنية نص الرسالة وترميزها وحجمها.

يحتوي رأس انتهاء الصلاحية على وقت انتهاء الصلاحية وتاريخ الكيان. القيمة "لا تنتهي صلاحيته أبدًا" تعني الوقت + رمز واحد من اللحظة الحالية. يحتوي "آخر تعديل" على الوقت والتاريخ اخر تغيرجوهر.

باستخدام هذه الرؤوس، يمكنك تحديد المعلومات اللازمة لمهامك.

تنسيق الطلب

الطلب يبدو مثل هذا:

سطر الطلب = طريقة SP URI SP HTTP-إصدار CRLF طريقة = "خيارات" | "الرأس" | "احصل على" | "بوست" | "وضع" | "حذف" | "يتعقب"

SP هو الفاصل بين الرموز المميزة. تم تحديد إصدار HTTP في إصدار HTTP. يبدو الطلب الفعلي كما يلي:

الحصول على /articles/http-basics HTTP/1.1 المضيف: www.articles.com الاتصال: التحكم في ذاكرة التخزين المؤقت المستمر: no-cache براغما: no-cache قبول: text/html,application/xhtml+xml,application/xml; ف=0.9,*/*;ف=0.8

قائمة رؤوس الطلب المحتملة:

رأس الطلب = قبول | قبول-محارف | قبول الترميز | قبول-اللغة | إذن | توقع | من | المضيف | إذا تطابق | إذا-تم التعديل-منذ | إذا لم يكن هناك تطابق | إذا المدى | إذا-غير معدلة-منذ | ماكس إلى الأمام | تفويض الوكيل | النطاق | المرجع | تي | وكيل المستخدم

يحدد رأس القبول ما هو مدعوم أنواع التمثيل الصامت، اللغة، ترميز الأحرف. تحتوي رؤوس From وHost وReferer وUser-Agent على معلومات حول العميل. إذا - البادئات تهدف إلى خلق الظروف. إذا لم ينجح الشرط، فسيحدث خطأ 304 غير معدل.

تنسيق الاستجابة

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

سطر الحالة = إصدار HTTP SP، رمز الحالة SP، عبارة السبب CRLF

• نسخة HTTP
• رمز الحالة
• رسالة حالة يمكن قراءتها بواسطة الإنسان

تبدو الحالة الطبيعية كما يلي:

HTTP/1.1200 موافق

يمكن أن تكون رؤوس الاستجابة كما يلي:

رأس الاستجابة = قبول النطاقات | العمر | إيتاج | الموقع | مصادقة الوكيل | إعادة المحاولة بعد | الخادم | تختلف | مصادقة WWW

• العمر هو الوقت بالثواني الذي تم فيه إنشاء الرسالة على الخادم.
• كيانات ETag MD5 للتحقق من التغييرات والتعديلات على الاستجابة.
• يتم استخدام الموقع لإعادة التوجيه ويحتوي على عنوان URL الجديد.
• يحدد الخادم الخادم الذي تم إنشاء الاستجابة فيه.

أعتقد أن هذه نظرية كافية لهذا اليوم. الآن دعونا نلقي نظرة على الأدوات التي يمكننا استخدامها لمراقبة رسائل HTTP.

أدوات للكشف عن حركة مرور HTTP

هناك العديد من الأدوات لمراقبة حركة مرور HTTP. وهنا عدد قليل منهم:

الأكثر استخدامًا هي أدوات مطوري Chrome:

إذا تحدثنا عن مصحح الأخطاء، فيمكنك استخدام Fiddler:

لمراقبة حركة مرور HTTP، ستحتاج إلى أدوات curl وtcpdump وtshark.

مكتبات العمل مع HTTP - jQuery AJAX

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

من خلال تمرير كائن إعدادات واستخدام وظيفة رد الاتصال beforeSend، يمكننا تعيين رؤوس الطلب باستخدام طريقة setRequestHeader().

$.ajax(( URL: "http://www.articles.com/latest"، النوع: "GET"، قبل الإرسال: الوظيفة (jqXHR) ( jqXHR.setRequestHeader("Accepts-Language"، "en-US,en "); ) ));

إذا كنت تريد معالجة حالة الطلب، فيمكنك القيام بذلك على النحو التالي:

$.ajax(( رمز الحالة: ( 404: الوظيفة () ( تنبيه ("لم يتم العثور على الصفحة"); ) ) ));

الحد الأدنى

ها هي جولة حول أساسيات بروتوكول HTTP. وسيكون هناك المزيد في الجزء الثاني حقائق مثيرة للاهتماموالأمثلة.

هذه التدوينة عبارة عن إجابة لسؤال طرحته في إحدى مقالاتي.

في هذه المقالة أريد أن أخبرك ما هي طرق HTTP GET/POST/PUT/DELETE وغيرها، ولماذا تم اختراعها وكيفية استخدامها وفقًا لـ REST.

HTTP

إذًا، ما هو أحد البروتوكولات الرئيسية للإنترنت؟ سأرسل الأطفال إلى RFC2616، وسأخبر الباقي بشكل إنساني :)

يصف هذا البروتوكول التفاعل بين جهازي كمبيوتر (العميل والخادم)، المبني على أساس رسائل تسمى الطلب (Request) والاستجابة (Response). تتكون كل رسالة من ثلاثة أجزاء: سطر البداية، والعناوين، والنص. في هذه الحالة، مطلوب فقط خط البداية.

خطوط البداية للطلب والاستجابة هي تنسيق مختلف- نحن مهتمون فقط بسطر بداية الطلب، والذي يبدو كالتالي:

طريقة URI HTTP/ إصدار ,

حيث METHOD هي طريقة طلب HTTP، وURI هو معرف المورد، وVERSION هو إصدار البروتوكول (الإصدار 1.1 حاليًا هو الحالي).

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

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

مثال تفاعل HTTP

لنلقي نظرة على مثال.

طلب:
احصل على /index.php HTTP/1.1 المضيف: example.com وكيل المستخدم: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 قبول: نص/html الاتصال: إغلاق
السطر الأول هو سطر الاستعلام، والباقي عبارة عن رؤوس؛ نص الرسالة مفقود

إجابة:
HTTP/1.0 200 OK الخادم: nginx/0.6.31 لغة المحتوى: ru نوع المحتوى: نص/html; charset=utf-8 طول المحتوى: 1234 الاتصال: إغلاق... صفحة HTML نفسها...

الموارد والأساليب

دعنا نعود إلى سطر البداية للطلب ونتذكر أنه يحتوي على معلمة مثل URI. يشير هذا إلى معرف المورد الموحد - معرف المورد الموحد. المورد، كقاعدة عامة، هو ملف على الخادم (مثال URI في هذه الحالة هو "/styles.css")، ولكن بشكل عام يمكن أن يكون المورد أيضًا كائنًا مجردًا ("/blogs/webdev/" - نقاط إلى تطوير كتلة "الويب" بدلاً من ملف محدد).

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

للتمييز بين الإجراءات والموارد على مستوى أساليب HTTP، تم اختراع الخيارات التالية:

• الحصول على - الحصول على الموارد
• ما بعد - إنشاء الموارد
• وضع - تحديث الموارد
• حذف - حذف مورد

يرجى ملاحظة أن مواصفات HTTP لا تتطلب من الخادم فهم جميع الطرق (التي يوجد منها في الواقع أكثر من 4 طرق) - مطلوب GET فقط، كما أنه لا يخبر الخادم بما يجب عليه فعله عند تلقي طلب باستخدام محدد معين. طريقة. وهذا يعني أن الخادم يستجيب لطلب DELETE /index.php HTTP/1.1 غير ملزم بذلكاحذف صفحة Index.php الموجودة على الخادم، تمامًا كما هو الحال في الحصول على الطلب/index.php HTTP/1.1 غير ملزم بذلكيرجع لك صفحة Index.php ممكن يحذفها مثلا :)

REST يأتي دوره

REST (نقل الحالة التمثيلية) هو مصطلح تم تقديمه في عام 2000 بواسطة Roy Fielding، أحد مطوري بروتوكول HTTP، كاسم لمجموعة مبادئ لبناء تطبيقات الويب. بشكل عام، يغطي REST مساحة أكبر من HTTP - ويمكن استخدامه أيضًا في شبكات أخرى مع بروتوكولات أخرى. تصف REST مبادئ التفاعل بين العميل والخادم، بناءً على مفاهيم "المورد" و"الفعل" (يمكن فهمها على أنها موضوع ومسند). في حالة HTTP، يتم تعريف المورد من خلال URI الخاص به، والفعل هو طريقة HTTP.

يقترح REST تجنب استخدام نفس عناوين URI لـ موارد مختلفة(أي أن عناوين مقالتين مختلفتين مثل /index.php?article_id=10 و /index.php?article_id=20 ليست REST-way) واستخدم أساليب HTTP مختلفة لإجراءات مختلفة. أي أن تطبيق الويب المكتوب باستخدام نهج REST سيحذف المورد عند الوصول إليه باستخدام طريقة HTTP DELETE (بالطبع، هذا لا يعني أنه من الضروري إتاحة الفرصة لحذف كل شيء وكل شخص، ولكن أييجب أن يستخدم طلب الحذف الخاص بالتطبيق طريقة HTTP DELETE).

يمنح REST المبرمجين القدرة على كتابة تطبيقات ويب موحدة وأجمل قليلاً من ذي قبل. باستخدام REST، لن يكون URI لإضافة مستخدم جديد هو /user.php?action=create (أسلوب GET/POST)، ولكن ببساطة /user.php (أسلوب POST فقط).

ونتيجة لذلك، من خلال الجمع بين مواصفات HTTP الحالية ونهج REST، تصبح طرق HTTP المختلفة منطقية في النهاية. GET - يُرجع موردًا، POST - يُنشئ موردًا جديدًا، PUT - يُحدث موردًا موجودًا، DELETE - يحذفه.

مشاكل؟

نعم، هناك مشكلة صغيرة في استخدام REST عمليًا. هذه المشكلة تسمى HTML.

يمكن إرسال طلبات PUT/DELETE باستخدام XMLHttpRequest، عن طريق الاتصال بالخادم يدويًا (على سبيل المثال، عبر curl أو حتى عبر telnet)، ولكن لا يمكنك إنشاء نموذج HTML يرسل طلب PUT/DELETE كاملاً.

المشكلة هي أن مواصفات HTML لا تسمح لك بإنشاء نماذج ترسل بيانات بخلاف GET أو POST. لذلك ل عملية عاديةمع طرق أخرى عليك تقليدها بشكل مصطنع. على سبيل المثال، في Rack (الآلية التي على أساسها تتفاعل Ruby مع خادم الويب؛ يتم إنشاء Rails وMerb وأطر عمل Ruby الأخرى باستخدام Rack)، يمكنك إضافة حقل مخفي إلى النموذج بالاسم "_method"، و حدد اسم الطريقة كقيمة (على سبيل المثال، "PUT") - في هذه الحالة، سيتم إرسال طلب POST، لكن سيكون بإمكان Rack التظاهر بأنه تلقى PUT بدلاً من POST.

إذا كنت تريد معرفة كيفية نقل البيانات عبر الإنترنت، فهذا المقال لك. سأخبرك بكل ما أعرفه عن بروتوكولي HTTP وHTTPS، وأبين الفرق والاختلاف بينهما. استمتع بالقراءة!

HTTP 1.1 - ما هو هذا البروتوكول؟

HTTP (بالإنجليزية: Hypertext Transfer Protocol) - بروتوكول الشبكة افضل مستوىلنقل النص التشعبي والبيانات التعسفية على الإنترنت.

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

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

النسخة الحاليةالبروتوكول - 1.1. وصفه موجود في مواصفات RFC.

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

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

علاوة على ذلك، غالبًا ما يعمل HTTP كبروتوكول نقل لنقل بروتوكولات التطبيقات الأخرى وواجهات برمجة التطبيقات الخاصة بها: WebDAV، وXML-RPC، وREST، وSOAP. حسنًا، يمكن أن تحتوي البيانات المرسلة عبر واجهة برمجة التطبيقات (API) على تنسيقات متنوعة: XML وJSON وغيرها.

كيف يتم نقل هذه البيانات؟ في أغلب الأحيان عبر اتصال TCP/IP: يستخدم تطبيق العميل منفذ TCP رقم 80 بشكل افتراضي، ويمكن للخادم استخدام أي منفذ آخر، ولكن عادةً ما يكون هذا المنفذ أيضًا هو المنفذ 80.

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

الميزة الثانية لـ HTTP هي أنه لا يحفظ الحالة بين أزواج الطلب والاستجابة المتعاقبة. ولكن هذه ليست مشكلة لأن مكونات التطبيق موجودة على العميل أو جانب الخادميمكنهم تخزين معلومات حول حالة الطلبات والاستجابات الأخيرة. من جانب العميل، تسمى هذه المعلومات ملفات تعريف الارتباط، من جانب الخادم - الجلسات.

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

يمكن للوسطاء (الخوادم الوكيلة) أيضًا المشاركة في نقل البيانات من أجل التمييز بين الوكلاء والخوادم النهائية (ما يسمى "الخادم المصدر").

يبدأ السحر عندما يتمكن نفس البرنامج (العميل أو الخادم) من أداء وظائف الوسيط أو العميل أو الخادم - اعتمادًا على المهام.

HTTP/2 - ما نوع هذا البروتوكول؟

ظهرت النسخة الأصلية من بروتوكول HTTP في CERN في عام 1991. بالفعل في عام 1992، تم نشر الإصدار العام من HTTP 0.9 ومواصفاته، والتي بفضلها تم نشر قواعد التفاعل بين العميل و تطبيقات الخادم، بالإضافة إلى تحديد واضح للوظيفة.

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

مر الوقت ومع تطور الإنترنت، زاد حجم الصفحات، ونما عدد الطلبات - وكانت هناك حاجة إلى المزيد والمزيد من الموارد. ومن هنا نشأت الحاجة إلى بروتوكول جديد.

وبعد ستة عشر عاما، في عام 2015، تم نشره الاصدار الاخيرمشروع المواصفات الإصدار التاليالبروتوكول - HTTP/2. يعد البروتوكول الثنائي HTTP/2 أكثر استعدادًا له الحقائق الحديثةمن سلف HTTP 1.1 لأنه بروتوكول جديديحل المشكلة الأكثر أهمية في نقل البيانات عبر الإنترنت - الاتصالات المفتوحة المتعددة.

وكل ذلك لأن المواقع الحالية تقوم بتحميل الكثير من العناصر، سواء من خادمها أو من CDN: نصوص JS وأنماط CSS والخطوط والصور. عند النقل مجموعة كاملةالملفات باستخدام بروتوكول HTTP 1.1، يتم إنشاء اتصالات متعددة. إذا قمنا في المستقبل بالتبديل إلى بروتوكول HTTP/2، فسيتم النقل ضمن اتصال واحد بين العميل والخادم، مما سيؤدي إلى تسريع وتحسين تحميل محتوى الموقع بشكل كبير.

دلائل الميزات HTTP/2، والذي سيكون مفيدًا للمواقع:

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

بالطبع، الشيء الرئيسي هنا هو تعدد الإرسال. من السهل شرح مبدأ التشغيل: يتم خلط حزم اتصال TCP/IP في اتصال واحد. وبالتالي، في الوضع المختلط، يتم توصيل العديد من "عربات البيانات" في "قطار" واحد، ويتم فصلها "عند الوصول". في السابق، كانت "السيارات" تضطر إلى السفر لفترة أطول وبشكل منفصل، لكنها الآن ستسافر معًا وبشكل أسرع.

ستسمح المزايا المذكورة أعلاه لبروتوكول HTTP/2 لمطوري الويب بالتنفس بعمق والتخلي عن "العكازات" مثل:

• الاستخدام أكثرالمجالات ذات الصلة لضمان إنشاء عدد كبير من اتصالات TCP/IP (لتنزيل الملفات)؛
• الصور المتحركة - عندما يتم دمج الصور في ملف واحد لتقليل عدد الطلبات إلى خادم الويب (والملف نفسه "ينتفخ" لأنه يحتوي على المزيد من الصور);
• الجمع بين ملفات CSS وJS، والتي تم تصميمها أيضًا لتقليل الطلبات.

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

في كلمة واحدة، سوف نعيش!

تم إنشاء HTTP/2 وتطويره استنادًا إلى مسودة بروتوكول SPDY/3 (Google) وتجاوزه - أدركت Google مزايا HTTP/2 باعتبارها أكثر واعدة وستتخلى عن دعم SPDY/2 في المستقبل.

سيكون التسارع المتوقع لاستجابة الخادم عبر بروتوكول HTTP/2 حوالي 30%، - اختبارات حقيقيةلقد أظهرت بالفعل سرعات أعلى بنسبة 19-23٪ وهذا ليس الحد الأقصى.

وفقًا لنتائج الاختبارات التي أجراها Airi.rf، فإن زيادة السرعة من مجرد تمكين بروتوكول HTTP/2 هي 13-18% (بدون تحسين). لماذا هو مهم؟

على الرغم من أن دعم الموقع لبروتوكول HTTP/2 حاليًا لا يؤثر بشكل مباشر على تصنيف المواقع في Google وYandex، إلا أن المواضع في نتائج البحث تتأثر بسرعة التحميل. وبما أن البروتوكول يظهر سرعة تنزيل أعلى (وهو عامل مهم إلى حد ما)، فإنه يؤثر بشكل غير مباشر على الترتيب.

أولا وقبل كل شيء بسبب العوامل السلوكية. يتيح تسريع التحميل للمستخدمين أن يكونوا أقل تعبًا وأكثر تركيزًا على استكشاف الموقع: عرض المزيد من الصفحات وعدم مغادرة الموقع بسبب وقت تحميل طويل(يتم تقليل الفشل).

تدعم معظم المتصفحات الحديثة بالفعل HTTP/2 - حيث تمر عبرها حوالي 70% من حركة مرور الإنترنت:

• Chrome 41-52 وChrome 46+ على نظام Android؛
• Firefox 36-48 وFirefox 41+ على نظام Android؛
• Opera 28-34 وOpera 30+ على نظام Android؛
• Safari 9 وSafari في iOS 9.1؛
• IE 11 على نظامي التشغيل Windows 10 و متصفح الحافة 12, 13.

ليس من الواضح حتى الآن متى سيحدث الانتقال الكامل إلى HTTP/2 - على الأرجح في المستقبل القريب جدًا. الشيء الرئيسي هو أنه لن يتخلى أحد على عجل عن HTTP/1.x. وكما يقولون: "إذا نجح فلا تلمسه".

ماذا يعني بروتوكول HTTPS وأين يتم استخدامه؟

حسنًا، أنت تعرف بالفعل كل شيء عن تبادل البيانات باستخدام بروتوكول HTTP: يتم تنفيذ أي نقل للبيانات من خلال الطلبات باستخدام بروتوكول النقل هذا. لماذا إذن نحتاج إلى HTTPS وما هو؟ بعد كل شيء، عشنا بشكل طبيعي بدونه؟

المشكلة هي أن البيانات عبر HTTP غير محمية ويتم نقلها إليها شكل مفتوح. الإنترنت عبارة عن شبكة عالمية موزعة من العقد. وإذا قمت بنقل البيانات المفتوحة عبر بروتوكول غير آمن (تنطبق شبكة Wi-Fi في مركز التسوق هنا أيضًا)، فيمكن لإحدى هذه العقد اعتراضها.

ليس عن قصد، بالطبع، يمكن أن يكون مجرد اختراق من قبل المجرمين. تم إنشاء HTTPS للتأكد من أن الاتصال آمن ويتم نقل البيانات في شكل مشفر باستخدام بروتوكول التشفير SSL/TLS. هذا عبارة عن "غلاف" خاص أعلى HTTP؛ فهو يقوم بتشفير البيانات، مما يجعل الوصول إليها غير ممكن للمهاجمين و الغرباء.

HTTPS - الإنجليزية " بروتوكول آمننقل النص التشعبي."

لذلك، على عكس المنفذ الافتراضي 80 في HTTP، يستخدم HTTPS منفذ TCP 443 ويحتوي على مفتاح تشفير. يمكن أن يكون طول المفتاح 40 أو 56 أو 128 أو 256 بت؛ ويبدأ المستوى الكافي من الأمان حاليًا بمفاتيح 128 بت.

الآن تدعم جميع المتصفحات HTTPS - ويتم تشغيله تلقائيًا عندما يكون ذلك ممكنًا ويتطلب الخادم ذلك.

من الضروري استخدام HTTPS في الخدمات التالية:

• أنظمة الدفع الإلكترونية (البنوك، النقود الإلكترونية، وغيرها)؛
• الخدمات التي تتلقى وترسل المعلومات الخاصة والبيانات الشخصية، على سبيل المثال، لدى Yandex: Passport وTaxi وDirect وMetrica وMail وMoney وWebmaster وغيرها؛
• وسائل التواصل الاجتماعيو حسابات شخصيةفي خدمات الإنترنت؛
• محركات البحث.

يعمل HTTPS ببساطة. سأشرح بمثال.

تضع معلومات مهمة(تسجيل الدخول، كلمة المرور، تفاصيل البطاقة، البيانات الشخصية) في خلية، "قفلها بمفتاح": تقوم الخلية بتشفير بياناتك باستخدام هذا المفتاح.

أرسله الآن بالبريد إلى المرسل إليه. يتلقى المرسل إليه خلية الطرود، لكنه لا يستطيع فتحها - فهو ليس لديه المفتاح. ثم يقوم بقفل (تشفير) الخلية بقفل ثانٍ ويعيد الطرد إليك. تتلقى طردًا به قفلين، ولكن لديك مفتاح أحدهما. يمكنك الآن فتح قفلك (فك تشفير البيانات) وإرسال الحزمة مرة أخرى إلى المستلم الأصلي.

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

هذا كل شيء - هذه هي الطريقة التي يعمل بها HTTPS.

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

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

للقيام بذلك، تتلقى الخوادم شهادات أمان HTTPS خاصة من مراكز الاعتماد، والتي تؤكد "نهائية" الوجهة (أن الموقع ليس عقدة تنقل البيانات بشكل أكبر) ووظيفة تقنية تشفير SSL/TLS، أي. أمان الاتصال.

وهذا ما تبدو عليه الشهادة نفسها:

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

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

ماذا تعني أيقونة HTTPS المشطوبة؟ أيقونة خضراء HTTPS، ما الفرق؟ في أمان. اللون الأخضر آمن، والأحمر والمشطوب غير آمن.

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

ما هو الأفضل HTTP 1.1 أم HTTP/2 أم HTTPS؟

لتلخيص ذلك، سأتطرق إلى موضوع الاستخدام المفضل للبروتوكولات.

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

ومع ذلك، فمن غير المحتمل أن تتحول جميع المواقع إلى HTTPS، وذلك لأغراض الاستهلاك محتوى ترفيهيالتشفير لا طائل منه. نعم، الآن 10% من المواقع تستخدم HTTPS في تصنيف Alexa لموارد الويب الأكثر زيارة. لكن هذا يمثل عشرة بالمائة فقط، بما في ذلك عمالقة مثل Google وPayPal وAmazon وAliexpress وغيرها. أي أن هناك العديد من المواقع التي يعني عدم استخدام HTTPS فيها انتهاك حق مستخدم الإنترنت في أمان البيانات وسلامتها.

لكن المواقع العادية مثل مدونة المدونين السبعة لا تحتاج إلى HTTPS - لا يوجد استقبال للبيانات الشخصية أو بيانات الدفع، ولا تسجيل وإرسال رسائل مهمة.

لذلك، في المستقبل القريب، سنبتعد تدريجيًا عن HTTP 1.1 لصالح HTTP/2 وHTTPS.