الجزء 3. HTTP/HTTPS

هذه المادة جزء من سلسلة "مقدمة لتطوير المشاريع". المقالات السابقة:

أهلاً! سنتعرف اليوم على بروتوكولي HTTP وHTTPS. لكن أولاً، دعونا نوضح نقطة واحدة: نحن نتحدث عن بروتوكولات إرسال البيانات عبر الشبكة على مستوى التطبيق لنموذج OSI. ولعلكم تتذكرون أننا تعرفنا على نموذج OSI في إحدى المقالات السابقة. إذا كنت لا تتذكر ذلك، فها هو .

ما هو بروتوكول اتصالات البيانات؟

وهذا ما نسميه مجموعة القواعد المتفق عليها والتي تسمح لمطوري الخدمات المختلفة بإرسال المعلومات بتنسيق يمكن للآخرين فهمه. على سبيل المثال، يمكنك استخدام Google Chrome للحصول على معلومات من كل من Facebook وTwitter، لأن المطورين يرسلونها باستخدام بروتوكول HTTP القياسي، والذي يسمح لمتصفحك بمعالجتها. تعتبر القواعد الموحدة ملائمة جدًا للأشخاص الذين يقومون بتطوير جزء الخادم: هناك الكثير من المكتبات التي يمكنها تحويل المعلومات لك وإرسالها باستخدام البروتوكول المناسب. تم تصميم HTTP في البداية كبروتوكول لإرسال صفحات HTML. هذه هي الطريقة التي تم استخدامها لفترة طويلة، ولكن الآن غالبًا ما يستخدمها المبرمجون لإرسال كل من السلاسل وملفات الوسائط. بشكل عام، هذا البروتوكول مقبول عالميًا ومتعدد الاستخدامات، كما أنه سهل الاستخدام حقًا. والآن سنبحث في كيفية استخدامه.

هيكل HTTP

يجب أن نلاحظ على الفور أن بروتوكول HTTP يتكون فقط من النص. أكثر ما يهمنا هو بنية هذا النص. تتكون كل رسالة من ثلاثة أجزاء:

خط البداية - يحدد هذا بعض بيانات التدبير المنزلي.
الرؤوس - تصف معلمات الرسالة.
الجسم - هذا هو محتوى الرسالة. يجب فصل النص عن الرؤوس بخط فارغ.

يتم استخدام بروتوكول HTTP لإرسال الطلبات إلى الخادم وتلقي الاستجابات من الخادم. تختلف معلمات الطلبات والاستجابات قليلاً.

إليك ما يبدو عليه طلب HTTP البسيط:

GET / HTTP/1.1
Host: codegym.cc
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)

يشير خط البداية إلى:

الحصول على - طريقة الطلب
/ — مسار الطلب
HTTP/1.1 — إصدار البروتوكول

ثم تأتي العناوين:

المضيف - المضيف الذي يتم توجيه الطلب إليه
وكيل المستخدم - العميل الذي يرسل الطلب

نص الرسالة مفقود. في طلب HTTP، يلزم فقط سطر البداية ورأس "المضيف". الآن دعونا نلقي نظرة على كل شيء خطوة بخطوة. يجب أن يحتوي طلب HTTP على بعض الطرق. هناك تسعة منها: GET، POST، PUT، OPTIONS، HEAD، PATCH، DELETE، TRACE، CONNECT. الأكثر شيوعًا هي GET و POST. ستكون هاتان الطريقتان كافيتين في البداية. GET - تطلب هذه الطريقة المحتوى من الخادم. وفقًا لذلك، لا تحتوي الطلبات التي تستخدم أسلوب GET على نص رسالة. ولكن إذا كنت بحاجة إلى ذلك، يمكنك تمرير المعلمات عبر المسار (في سطر البداية) بالتنسيق التالي:


https://cdn.codegym.cc/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2

حيث يكون codegym.cc هو المضيف، و/send هو مسار الطلب، و ? هو فاصل يشير إلى أن معلمات الاستعلام تتبع. في النهاية، يتم إدراج أزواج المفتاح والقيمة ("المفتاح = القيمة")، مفصولة بعلامة العطف. POST — تقوم هذه الطريقة بنشر المعلومات على الخادم. يمكن لطلب POST إرسال أنواع مختلفة من المعلومات: المعلمات كأزواج "مفتاح = قيمة"، أو JSON، أو كود HTML، أو حتى ملفات. يتم إرسال جميع المعلومات في نص الرسالة. على سبيل المثال:

POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: codegym.cc

{
  "Id": 12345,
  "User": "John"
}

يتم إرسال الطلب إلى codegym.cc/user/create/json، وإصدار البروتوكول هو HTTP/1.1. يشير "قبول" إلى تنسيق الاستجابة الذي يتوقع العميل تلقيه. يشير "نوع المحتوى" إلى تنسيق نص الرسالة المرسلة في الطلب. "طول المحتوى" هو عدد الأحرف في النص. يمكن أن يحتوي طلب HTTP على الكثير من الرؤوس المختلفة. لمزيد من المعلومات، قم بإلقاء نظرة على مواصفات البروتوكول .

استجابات HTTP

بعد تلقي الطلب، يقوم الخادم بمعالجته وإرسال الرد إلى العميل:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World</p>
  </body>
</html>

يحتوي سطر بداية الاستجابة على إصدار البروتوكول (HTTP/1.1)، ورمز الحالة (200)، ووصف الحالة (OK). تتضمن رؤوسها نوع المحتوى وطوله. يحتوي نص الاستجابة على كود HTML الذي يعرضه المتصفح كصفحة HTML.

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

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

1xx - إعلامية. تم استلام الطلب. الخادم جاهز للمتابعة.
2xx - ناجح. تم استلام الطلب وفهمه ومعالجته.
3xx - إعادة التوجيه. يجب تنفيذ إجراءات إضافية لمعالجة الطلب.
4xx — خطأ العميل. يحتوي الطلب على أخطاء أو لا يتوافق مع البروتوكول.
5xx — خطأ في الخادم. تمت كتابة الطلب بشكل صحيح، لكن الخادم لم يتمكن من معالجته.

يشير الرقمان الثاني والثالث في الكود إلى استجابة أكثر تحديدًا. على سبيل المثال:

200 موافق — تم استلام الطلب ومعالجته بنجاح.
201 تم الإنشاء — تم استلام الطلب ومعالجته بنجاح، مما أدى إلى إنشاء مورد أو مثيل جديد.
301 تم النقل بشكل دائم - تم نقل المورد المطلوب بشكل دائم. وينبغي تقديم الطلبات اللاحقة إليه باستخدام العنوان الجديد.
307 إعادة التوجيه المؤقتة - تم نقل المورد مؤقتًا. في الوقت الحالي، يمكن الوصول إليه باستخدام إعادة التوجيه التلقائي.
403 ممنوع - تم فهم الطلب، ولكن التفويض مطلوب.
404 لم يتم العثور عليه - لم يعثر الخادم على المورد على هذا العنوان.
501 لم يتم تنفيذه — الخادم لا يدعم الوظيفة المطلوبة للرد على الطلب.
505 إصدار HTTP غير مدعوم - الخادم لا يدعم الإصدار المحدد من بروتوكول HTTP.

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

الفرق بين HTTPS وHTTP

من حيث بناء الجملة، HTTPS مطابق لبروتوكول HTTP. أي أنه يستخدم نفس خطوط البداية والرؤوس. الاختلافات الوحيدة هي التشفير الإضافي والمنفذ الافتراضي (443) . يتم تشفير HTTPS بين HTTP وTCP، أي بين طبقات التطبيق والنقل. إذا نسيت ما يعنيه ذلك، فاطلع على المقالة الخاصة بنموذج OSI . معيار التشفير اليوم هو TLS. لن نخوض في هذا الموضوع كثيرًا، لكن تذكر أن التشفير يحدث قبل وصول المعلومات إلى طبقة النقل . في HTTPS، يتم تشفير كافة المعلومات تمامًا، باستثناء المضيف والمنفذ الذي يتم إرسال الطلب إليه. لا يتطلب تحويل الخادم لاستخدام بروتوكول HTTPS بدلاً من HTTP استخدامه لتغيير رمز الخادم. يتم تمكين هذه الميزة في حاويات servlet، والتي سنناقشها في المقالات اللاحقة. وهذا كل شيء لهذا اليوم. في الواقع، انتظر لحظة. للحصول على بعض طلبات HTTP، افتح Google Chrome، واضغط على F12، ثم حدد علامة التبويب "الشبكة". سيتم عرض جميع الطلبات والردود المرسلة/المستلمة بواسطة متصفحك هنا. الجزء 4. أساسيات Maven الجزء 5. Servlets وJava Servlet API. كتابة تطبيق ويب بسيط الجزء 6. حاويات Servlet الجزء 7. تقديم نمط MVC (Model-View-Controller)

تعليقات

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION