اسمحوا لي أن أبدأ
بإعطائكم مقدمة سريعة لمدة 10 دقائق عن أساسيات الشبكات.
وبالنظر إلى أن الوقت المتاح لدينا محدود،
فإنني سأركز على تقديم
الضروريات التي تحتاجونها لفهم كل موضوع من المواضيع.
الآن، ما نغطيه في هذه الوحدة بالذات سيتطلب
على الأقل فهمًا بدائيًا لكيفية
عمل شبكات الكمبيوتر قبل أن نفهم لماذا نحتاج إلى استخدام HTTP،
ولماذا نتواصل مع الخادم،
وما هو سبب التأخير عندما تتحدث إلى خادم وما إلى ذلك.
وأيضا، البروتوكولات المختلفة التي
تحتاج إلى أن تكون على بينة من قبل أن تتمكن حتى من التواصل مع الخادم.
لذلك، مع وضع كل هذا في الاعتبار
، مقدمة سريعة لمدة 10 دقائق لأساسيات الشبكات.
نبدأ في إدراك أن تطبيقات الويب لم تعد قائمة بذاتها.
لديهم دائما اقتباس غير الاقتباس سحابة الخلفية دعم تطبيق الويب الخاص بك.
الآن في هذه الأيام، كل شيء على السحابة.
قريبا جدا سوف تكون على سحابة أيضا،
على الأقل على سحابة تسعة مع بطانة الفضة.
ولكن، بالنظر إلى أننا بحاجة إلى
دعم جانب الخادم لتطبيقنا الزاوي للعمل بشكل صحيح،
فسوف تستضيف الخادم.
وفي هذه الأيام، يتم استضافة الخادم
بسهولة تامة باستخدام إحدى خدمات البنية التحتية المستندة إلى السحابة،
أشياء مثل خدمات الويب الأمازون أو Heroku أو Digital
Ocean أو العديد من الخدمات الأخرى التي توفر دعم الخادم المستند إلى السحابة.
لذا، ما هو متاح بالضبط على جانب الخادم؟
عادة ما يكون لديك واجهة الخادم التي تتحدث إلى التطبيق الزاوي الخاص بك،
بحيث هو منطق الخادم وخلف الكواليس يتواصل منطق الخادم مع
تخزين مستمر مثل قاعدة بيانات حيث يتم تخزين البيانات الخاصة بك واستردادها من.
عندما تدخل إلى عالم الشبكات،
سوف يتم قصفها قريبا جدا مع 304 مختصرات صغيرة،
أشياء كنت تعتقد أنك تعرف ما هي عليه من اللغة الإنجليزية العادية أو لديهم
معنى أو
غرض مختلف تماما عندما تواجههم في عالم الشبكات.
لذلك دعونا نفحص عدد قليل منهم.
لذلك في عالم الشبكات سوف تسمع الناس يتحدثون عبر بروتوكول HTTP.
البروتوكول الذي يتم استخدامه للاتصال بين العميل والخادم.
هذا هو بروتوكول طبقة التطبيق الذي سوف
نتحدث لفترة وجيزة عن أكثر قليلا في بقية هذه المحاضرة.
يحتاج بروتوكول HTTP لكي يعمل إلى عنوان URL ليتم توفيره إليه، وهو
محدد موقع الموارد الموحد.
لذلك هذه عبارة عن سلسلة من الأحرف مفصولة بخطوط مائلة،
مع نقطتين HTTP أو نقطتين HTTPS مرفقة أمامه.
وأنا متأكد من أنك إذا كنت قد استخدمت الشبكة العالمية،
فأنت على دراية كبيرة بما تبدو عليه عناوين URL.
الآن بالإضافة إلى ذلك، ستسمع الناس يتحدثون عن JSON،
وليس صديقك Jason ولكن ترميز كائن JavaScript.
لذا فإن تدوين كائن JavaScript
هو إحدى طرق ترميز البيانات التي يتم شحنها من جانب الخادم إلى جانب العميل أو العكس.
وأيضا سوف تسمع الناس يتحدثون عن XML بعد طريقة أخرى
لترميز البيانات بينما هو في الشحن العابر بين العميل والجانب الخادم.
الآن، أيضا سوف تسمع الناس يتحدثون عن بروتوكولات مستوى أعلى تسمى SOAP،
وليس النوع الذي تستحم به ولكن SOAP كبروتوكول
يسمح بالاتصال بين كيانات التوزيع داخل شبكتهم.
وأيضا، سوف تسمع الناس يتحدثون عن ريست،
وليس شيئا أن تحصل على الكثير من الذهاب من خلال هذه الدورة معينة،
ريست أو نقل الدولة التمثيلية.
سيكون لدي محاضرة أقصر
مكرسة خصيصا لريست قليلا في وقت لاحق في هذه الوحدة.
وفي عالم HTTP،
ستسمع الناس يتحدثون عن GET و
PUT و POST و DELETE وستتساءل،
ماذا تعني جميعًا؟
دعونا نتعلم قليلا عن هذه في
هذه المحاضرة وأيضا محاضرة عن ريست التي سترى قليلا في وقت لاحق.
أحد الأشياء الهامة التي تحتاج إلى فهمها عند
الاتصال بخادم هو أن اتصال خادم العميل
يسبب كمية غير متوقعة من التأخير أو كمية غير محددة من التأخير
أثناء جلب البيانات أو تحميلها إلى الخادم من موقع العميل.
وهذا يعني أنه داخل تطبيق موقع العميل الخاص بك،
تحتاج إلى إبقاء المستخدم
على علم بحقيقة أن شيئا ما يحدث وراء الكواليس وتكون
قادرة على التعامل مع التأخير
وربما لا تكون قادرة على الحصول على البيانات من جانب الخادم.
من المحتمل جداً أنه عند محاولة الاتصال بخادم،
قد يفشل اتصال الخادم، قد يقوم الخادم
بإرجاع بيانات غير صحيحة أو قد يتسبب في حدوث خطأ في الاتصال.
كل هذه يجب التعامل معها على جانب العميل الخاص بك بشكل مناسب بحيث
يستمر التطبيق الخاص بك في العمل حتى في وجود هذه المشاكل.
القفز إلى بروتوكول طبقة التطبيقات الأكثر شعبية
المستخدمة للاتصال بين العميل والخادم،
بروتوكول نقل النص التشعبي.
ولكن هذا هو بروتوكول اتصال خادم العميل.
الآن قد يكون ذلك أو لا يكون له معنى كبير بالنسبة
لك إلا إذا كان لديك خلفية كافية في الشبكات،
ولكن هذا هو بروتوكول يستخدم لترميز الرسائل التي
تبادلتها بين تطبيق العميل الخاص بك
وهو تطبيق الزاوي في هذه الحالة وجانب الخادم.
لذلك يسمح لك بروتوكول HTTP هذا
باسترداد المستندات المستندة إلى النص التشعبي من جانب الخادم، ويتم
ترميز المعلومات التي يتم تنزيلها من جانب الخادم بشكل متزايد في أحد تنسيقات الترميز القياسية مثل JSON أو XML.
ولكي تتمكن من التحدث إلى خادم،
لديك الدعم من إجراءات HTTP المختلفة أو ما نشير إليه على أنه أفعال HTTP،
الرأس، GET، POST، PUT،
DELETE، TRACE، OPTIONS، و CONNECT.
سنرى على وجه الخصوص
الأفعال GET و PUT و POST و DELETE بمزيد من التفصيل عندما نفحص بروتوكول REST API بعد ذلك بقليل.
كيف يعمل بروتوكول HTTP؟
في بروتوكول HTTP،
تقوم بإرسال طلب GET من تطبيق العميل الخاص بك إلى الخادم.
ويتم ترميز هذا في شكل رسالة طلب HTTP.
عادةً ما تحمل رسالة الطلب عنوان URL
في رسالة الطلب تشير إلى ما تريد أن يرسل لك جانب الخادم.
وهذه عادة رسالة GET إذا كنت تريد
تنزيل البيانات من جانب الخادم.
ستحدد أيضًا الخادم المحدد الذي تتصل به.
عندما يتلقى الخادم طلبك،
سيقوم الخادم باسترداد البيانات من تخزين البيانات الخاصة به،
عادة قاعدة بيانات على جانب الخادم،
ثم قم بحزم هذه البيانات
بتنسيق مناسب وإرسال البيانات مرة أخرى إليك على جانب العميل الخاص بك.
إذا كنت تحصل على شفرة HTML و CSS
و JavaScript القياسية من جانب الخادم،
فسيكون متصفحك قادرًا على تقديم ذلك.
ولكن مع تطبيقات مثل Angular،
فأنت تتصل في المقام الأول بالخادم ثم
تسترد البيانات في شكل إما JSON أو XML في معظم الأحيان.
باستثناء التنزيل الأولي لجميع الموارد المطلوبة
لتطبيق Angular الخاص بك ليتم تنفيذها داخل متصفحك.
لذلك كما رأينا سابقًا،
يتطلب تطبيق HTTP إرسال رسائل بين العميل والخادم.
يتم إرسال رسالة طلب عادةً من العميل إلى الخادم
وتتكون رسالة الطلب من سطر طلب بالإضافة إلى مجموعة من الرؤوس،
حيث تقوم بتوفير معلومات إضافية لتأهيل الطلب.
سنرى استخدام مختلف الرؤوس والإعدادات
في الرؤوس ونحن نذهب من خلال بعض التمارين في هذه الوحدة بالذات.
يتم فصل سطر الطلب والرؤوس من نص
رسالة الطلب بواسطة سطر فارغ واحد.
قد يحتوي نص الرسالة على بيانات إضافية
خاصة إذا كان العميل يرسل البيانات إلى جانب الخادم.
على سبيل المثال عند إرسال نموذج،
يتم ترميز المعلومات داخل النموذج في
تنسيق JSON ثم يتم إرسالها إلى جانب الخادم من جانب العميل.
بحيث يتم ذلك باستخدام رسالة POST أو PUT.
بالنظر إلى التفاصيل الأكثر قليلاً لرسالة طلب HTTP،
ستحتوي رسالة الطلب النموذجية في سطر الطلب على الطريقة التي تكون إما GET أو PUT أو POST
أو DELETE أو بعض الأفعال الأخرى التي رأيتها سابقًا،
ثم يتبعها عنوان URL وإصدار بروتوكول HTTP الذي تستخدمه للاتصال من العميل إلى جانب الخادم.
عادةً ما يحتوي حقل الرأس
على اسم حقل رأس ونقطتين وقيمة حقل الرأس هذا.
ويمكن ترميز محتويات الجسم، كما ذكرت، إما بتنسيق JSON أو XML.
في ما يلي مثال
على رسالة طلب HTTP النموذجية التي قد يتم إرسالها إلى الخادم من العميل.
لذا في رسالة الطلب هذه،
نطلب من الخادم الاحتفاظ بصفحة index.html
من جانب الخادم إلى جانب العميل بحيث
يمكن عرضها في المتصفح على جانب العميل.
عادةً ما يحتوي طلب مثل هذا على نص فارغ في رسالة الطلب.
سيتم ترميز معظم المعلومات في
سطر الطلب بالإضافة إلى رؤوس رسالة الطلب.
عندما يرسل العميل الطلب إلى الخادم.
سيقوم الخادم بمعالجة الطلب ثم إرسال رد إلى جانب العميل.
يتم تنظيم رسالة الرد مرة أخرى، ثلاثة أجزاء،
سطر حالة حيث يتم
تخزين بعض المعلومات حول كيفية معالجة الطلب وما يتم إرساله مرة أخرى إلى العميل،
وسوف تحتوي الرؤوس على تفاصيل إضافية لما هو
موجود في رسالة الاستجابة ثم متبوعًا بخط فارغ،
ثم النص الفعلي للرسالة.
مثال على ما يمكن أن يتم تضمينه عادة
في رسالة استجابة HTTP، في هذه الحالة، رسالة الاستجابة هذه تعود مع 200،
وهو رمز حالة للرسالة.
إذا رأيت 200 في سطر الطلب كرمز حالة،
فهذا يعني أن طلبك كان ناجحًا وأن الخادم قادر
على إرجاع البيانات التي طلبتها من جانب الخادم.
ثم سيحتوي الرأس على توجيهات إضافية
إلى جانب العميل بما
في ذلك معلومات حول كيفية ترميز النص الفعلي للرسالة.
ثم قد يحتوي النص الأساسي،
إذا كنت قد طلبت صفحة index.html،
سيحتوي نص الرسالة على رمز HTML
لصفحة index.html كما ترى في هذا المثال هنا.
واحدة من أجزاء من المعلومات في سطر الحالة التي أشير إليها باسم رمز الحالة.
إذا كان الخادم قادرًا على معالجة طلبك بشكل
صحيح، فسيرسل ردًا برمز حالة 200،
مما يعني أن كل شيء على ما يرام على جانب الخادم
ويقوم جانب الخادم بإرجاع البيانات بشكل صحيح.
إذا كان الخادم غير قادر على معالجة الطلب لأي سبب من الأسباب،
فسيتم ترميز هذه المعلومات في
رمز الحالة في سطر الحالة الخاص برسالة الرد.
تتضمن رموز الحالة المختلفة عادةً التي ستواجهها عند تلقي رد من جانب الخادم 201،
مما يعني أنه عند محاولة إنشاء
كائن على جانب الخادم، تم إنشاؤه بنجاح،
أو 301 مما يعني أن كل ما تطلبه قد نقل بشكل
دائم إلى موقع جديد
وسيتم إرجاع عنوان URL للموقع الجديد لهذا المورد إلى جانب العميل الخاص بك.
400s و 500s عادة ما تشير إلى أن هناك بعض المشاكل على جانب الملقم.
404 هو شيء غالباً ما
تصادفه عند طلب شيء غير موجود على جانب الخادم.
وبالمثل، يعني 500 أن الخادم هو مجرد التخلي،
فإنه غير قادر على معالجة طلبك ومن ثم يرسل مرة أخرى خطأ خادم داخلي.
هذه هي اثنين من رموز الخطأ الشائعة التي سوف تواجهها.
الباقية لها معنى محدد كما هو مذكور في هذا الجدول هنا.
هناك أكثر من رموز الحالة التي أعطيتها لك في هذا الجدول،
ولكن هذه بعض من رموز الحالة الأكثر شيوعًا التي
ستواجهها في رسالة رد قادمة من جانب الخادم.
نقطة أخرى ذكرتها هي حقيقة أن الخادم قد ترميز
البيانات بتنسيق معين مثل XML أو لغة الترميز الموسعة أو JSON،
تنسيق ترميز كائن JavaScript.
الآن عادة، في هذه الدورة بالذات،
سنتعامل مع البيانات التي يتم ترميزها بشكل رئيسي في JSON.
تتصل معظم التطبيقات من جانب العميل بما في ذلك تطبيقات الجوال هذه الأيام عادةً
بالخادم ويكون تنسيق تبادل البيانات هو JSON افتراضيًا في معظم الحالات.
هذا هو السبب في أنني سأقضي بضع دقائق في شرح لك حول JSON.
إن تدوين كائن JavaScript أو JSON هو تنسيق تبادل بيانات خفيف الوزن.
السبب في تنسيق بيانات JSON هو على وجه التحديد من
اهتمامنا في هذه الدورة هو أن تدوين كائن جافا سكريبت،
كما يوحي الاسم،
خرائط بسهولة جدا إلى كائن جافا سكريبت الذي تستخدمه مع أي شفرة جافا سكريبت.
لذا فإن
تحويل كائن JavaScript إلى تدوين JSON والعكسي واضح للغاية.
تدوين JSON هو ما نسميه بأنه
وصف ذاتي ويسهل فهمه تدوين.
في تنسيق ترميز كائن JavaScript،
يتم تنظيم البيانات بطريقة نظيفة ومحددة للغاية.
يتم تنظيم هذا كمجموعة من الأسماء
وأزواج القيم، وهذا منظم كقائمة مرتبة من القيم.
يمكنك أن ترى مثالا على ذلك على الجانب الأيمن هنا.
لقد استخدمنا بالفعل بيانات JSON هذه داخل تطبيقنا الزاوي بالفعل في وقت سابق.
لذلك، الآن ترى لماذا يتم تنظيم البيانات بهذه الطريقة.
وأنت تدرك أيضًا أنه من السهل جدًا التعامل مع
هذه البيانات داخل JavaScript أو رمز TypeScript الخاص بك في تطبيق Angular الخاص بك.
بهذا، أكمل نظرة عامة سريعة على أساسيات الشبكات.