المحتوى عن 'tcp/ip'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • التجارة الإلكترونية
  • مقالات ريادة أعمال عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML5
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات تصميم عامة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 4 نتائج

  1. إذا التقى شخصان في قرى الهيمالايا، حيِّا أحدهما الآخر قائلًا: "هل جسدك معافى؟" وأما في اليابان فقد ينحنيان أحيانًا، وفي عُمان يطبع كلّ منهما قبلة على أنف الآخر بعد التصافح، في كمبوديا وتايلاند، يضمّ كلّ منهما يديه وكأنّه يدعو. كل هذه الوسائل هي "بروتوكولات" للتواصل، أي سلسلة بسيطة من الرموز ذات المعنى والّتي تمهّد لتبادل حديث مُفيد. في عالم الويب، لدينا بروتوكول فعّال جدًّا على مستوى التّطبيقات يُمهّد الحواسيب حول العالم لتبادل الأحاديث النّافعة، واسمه Hypertext Transfer Protocol، أو HTTP اختصارًا؛ وهو بروتوكول يُصنّف ضمن طبقة التّطبيقات فوق TCP/IP، وهو أيضًا بروتوكول للتواصل. كثيرًا ما يغيب شرح HTTP في دروس التصميم والتطوير للويب، وهذا أمرٌ مُخزٍ: ففهمه يُعينك في تحسين تفاعل المستخدم وتحقيق أداء أفضل للموقع وإنشساء أدوات فعّالة لإدارة المعلومات على الويب. هذا المقال هو الجزء الأول من سلسلة تهدف إلى تعليم أساسيّات HTTP، وكيف يمكن استخدامه بفعّاليّة أكبر. سنطّلع في هذا الدّرس على محلّ HTTP من الإنترنت. ما معنى بروتوكول تواصل؟ قبل الدّخول في التفاصيل، لنتخيّل موقفًا بسيطًا يحدث فيه تواصل بين طرفين، ولكي يحدث هذا التواصل، فإن على الطّرفين (برنامجين كانا أم جهازين أم شخصين... إلخ.) أن يتّفقا على: الصياغة (تنسيق البيانات) الدلالات (معلومات التحكم والتعامل مع الأخطاء) التوقيت (تطابق السرعة والتتالي) عندما يلتقى اثنان، فإنّهما يتفاهمان من خلال بروتوكل تواصل: ففي اليابان مثلًا، يؤدي أحدهما حركة جسدية، كأن يحني ظهره. وهذه هي الصياغة المعتمدة في التواصل. وفي عادات اليابان، تدل حركة الانحناء هذه (وحركات أخرى مشابهة) على التّحيّة. وبحركة انحناء أحد الشخصين للآخر تنطلق سلسلة من الأحداث بينهما مرتبة بتوقيت معيّن. يتركّب بروتوكل التواصل عبر الشبكات من المكوّنات ذاتها. فأمّا الصّياغة فهي سلسلة من الحروف كالكلمات المفتاحيّة المُستخدمة في كتابة البروتوكول، وأمّا الدلالات فهي المعاني المُرتبطة بكلّ من هذه الكلمات، وأمّا التوقيت فهو ترتيب تبادل هذه الكلمات بين الطّرفين. ما محلّ HTTP من الإنترنت؟ يقوم HTTP نفسه فوق بروتوكولات أخرى. فعند الاتصال بموقع ويب مثل www.example.org، يستخدم وكيل المستخدم (user agent) مجموعة بروتوكولات TCP/IP، والتي صُمّمت في عام 1970 مؤلّفة من 4 طبقات: طبقة الوصلة (Link)، والتي تصف الوصول إلى الوسيط المادّي (كاستخدام بطاقة الشبكة مثلًا) طبقة الإنترنت، والتي تصف كيفيّة تغليف البيانات وتوجيهها (IP أو Internet Protocol) طبقة النقل (Transport)، والتي تصف كيفية نقل البيانات من نقطة الانطلاق إلى الوجهة (TCP وUDP) طبقة التطبيقات (Application)، والتي تصف معنى وصياغة الرسائل المنقولة (HTTP) فـ HTTP إذًا هو بروتوكول على مستوى التطبيقات يقوم على الطبقات السابقة، لا تنسَ هذه الفكرة. يُساعد فصل هذا النّموذج في طبقات على تطوير أجزاءه بصورة منفصلة دون الحاجة لإعادة تصميمها جميعًا. فمثلًا، يمكن تطوير TCP، باعتباره بروتوكولًا في طبقة النّقل، دون الحاجة لتعديل HTTP كونه برتوكولًا في طبقة التّطبيقات. لكن الواقع العمليّ يجعل التفاصيل أكثر تعقيدًا عند الحاجة للوصول إلى تواصل ذي أداء عالٍ. سنركّز في الأجزاء الأولى من هذه السّلسلة على فصل الطّبقات كما هو مُعرَّف في نموذج TCP/IP. صُمِّم HTTP بغرض تبادل المعلومات بين برنامجين من خلال رسائل تُسمّى رسائل HTTP، وتؤثّر طريقة تشكيل هذه الرسائل في العميل (client) والخادوم (server) والأطراف الوسيطة (كالخواديم الوكيلة proxies). لنتواصل مع خادوم! يُعتبر المنفذ رقم 80 المنفذ المبدئيّ للاتّصال بخواديم الويب، ويمكن التأكّد من ذلك بتجربة نُجريها من الطّرفيّة. افتح الطّرفية (أو سطر الأوامر) وجرّب الاتصال بـ www.opera.com على المنفذ 80 مُستخدمًا الأمر التالي: telnet www.opera.com 80 من المُفترض أن يكون الناتج: Trying 195.189.143.147... Connected to front.opera.com. Escape character is '^]'. Connection closed by foreign host. كما نرى فإن الطرفيّة تحاول الاتصال بالخادوم ذي عنوان IP‏ 195.189.143.147. إن لم نفعل شيئًا آخر سيغلق الخادوم الاتصال بنفسه. من الممكن بالطّبع استخدام منفذ آخر بل وحتّى بروتوكول تواصل آخر، ولكن هذه هي الإعدادات الشّائعة. لنتحدّث بلغة HTTP! لنحاول ثانية التواصل مع الخادوم. أدخل الرسالة التالية في الطرفية (أو سطر الأوامر): telnet www.opera.com 80 ما إن يُؤسّس الاتصال، اكتب رسالة HTTP التالية بسرعة (قبل أن يُغلق الخادوم الاتصال بنفسه)، ثم اضغط Enter مرّتين: GET / HTTP/1.1 Host: www.opera.com تُحدّد هذه الرسالة: GET: أي أننا نريد "الحصول على" تمثيل البيانات. /: أي أنّ المعلومات التي نريدها مخزنة في جذر الموقع. HTTP/1.1: أي أننا نتحدث ببروتوكول HTTP ذي الإصدارة 1.1. Host:: أي أننا نريد الوصول إلى الموقع المُحدّد. www.opera.com: اسم الموقع هو www.opera.com. على الخادوم الآن أن يُجيب طلبنا. من المفترض أن تمتلئ نافذة الطرفية بمحتوى مشابه لما يلي: HTTP/1.1 200 OK Date: Wed, 23 Nov 2011 19:41:37 GMT Server: Apache Content-Type: text/html; charset=utf-8 Set-Cookie: language=none; path=/; domain=www.opera.com; expires=Thu, 25-Aug-2011 19:41:38 GMT Set-Cookie: language=en; path=/; domain=.opera.com; expires=Sat, 20-Nov-2021 19:41:38 GMT Vary: Accept-Encoding Transfer-Encoding: chunked <!DOCTYPE html> <html lang="en"> ... يقول الخادوم هنا: "أنا أتحدث HTTP الإصدارة 1.1. نجحَ طلبك، لذا أجبت بالرمز 200." الكلمة OK ليست إلزامية والهدف منها شرح معنى الرمز للبشر - وهي تُشير في حالتنا إلى أن الأمور تسير على ما يرام وأن رسالتنا قُبلت. يلي ذلك سلسلة من "ترويسات HTTP" التي تُرسل لتصف الرسالة، وكيف يجب أن تُفهم. أخيرًا نجد محتويات الصفحة المُستضافة على جذر الموقع، والّتي تبدأ بـ <!DOCTYPE html>.
  2. إن بروتوكول التحكم في نقل البيانات (Transmission Control Protocol) وبروتوكول الإنترنت (Internet Protocol) المسمى اختصارًا TCP/IP هو معيار يضم مجموعة بروتوكولاتٍ مطورةً في نهاية السبعينات من القرن الماضي من وكالة مشاريع أبحاث الدفاع المتقدمة (Defense Advanced Research Projects Agency‏ [DARPA])، كطرق للتواصل بين مختلف أنواع الحواسيب وشبكات الحواسيب؛ إن بروتوكول TCP/IP هو العصب المحرك للإنترنت، وهذا ما يجعله أشهر مجموعة بروتوكولات شبكيّة على وجه الأرض. TCP/IPالمكونان الرئيسيان من مكونات TCP/IP يتعاملان مع مختلف نواحي شبكة الحاسوب؛ بروتوكول الإنترنت -جزء «IP» من TCP/IP- هو بروتوكول عديم الاتصال (connectionless) يتعامل مع طريقة توجيه (routing) الرزم الشبكية مستخدمًا ما يسمى «IP Datagram» كوحدة رئيسية للمعلومات الشبكية؛ تتكون IP Datagram من ترويسة، يتبعها رسالة. إن بروتوكول التحكم في نقل البيانات هو «TCP» من TCP/IP، ويُمكِّن مضيفي الشبكة من إنشاء اتصالاتٍ يستطيعون استخدامها لتبادل مجاري البيانات (data streams)؛ ويَضمَن أيضًا بروتوكول TCP أن البيانات التي أُرسِلَت بواسطة تلك الاتصالات ستُسَلَّم وتصل إلى مضيف الشبكة المُستقبِل كما أُرسِلَت تمامًا وبنفس الترتيب من المُرسِل. ضبط TCP/IPيتكون ضبط TCP/IP من عدِّة عناصر التي يمكن أن تُغيَّر بتعديل ملفات الإعدادات الملائمة، أو باستخدام حلول مثل خادوم «بروتوكول ضبط المضيف الديناميكي» (Dynamic Host Configuration Protocol‏ [DHCP])، الذي يمكن أن يُضبَط لتوفير إعدادات TCP/IP صالحة لعملاء الشبكة تلقائيًا، يجب أن تُضبط قيم تلك الإعدادات ضبطًا صحيحًا لكي تساعد في عمل الشبكة عملًا سليمًا في نظام أوبنتو عندك. عناصر الضبط الخاصة ببروتوكول TCP/IP ومعانيها هي: عنوان IP: هو سلسة نصية فريدة يُعبَّر عنها بأربع مجموعات من أرقام تتراوح بين الصفر (0)، ومئتان وخمسٌ وخمسون (255)، مفصولةٌ بنقط، وكل أربعة أرقام تمثل ثمانية (8) بتات من العنوان الذي يكون طوله الكامل اثنان وثلاثون (32) بتًا، تُسمى هذه الصيغة باسم «dotted quad notation». قناع الشبكة: قناع الشبكة الفرعية (أو باختصار: قناع الشبكة [netmask])، هو قناع ثنائي يفصل قسم عنوان IP المهم للشبكة، عن قسم العنوان المهم للشبكة الفرعية (Subnetwork)؛ على سبيل المثال، في شبكة ذات الفئة C‏ (Class C network)، قناع الشبكة الافتراضي هو 255.255.255.0، الذي يحجز أول ثلاثة بايتات من عنوان IP للشبكة، ويسمح لآخر بايت من عنوان IP أن يبقى متاحًا لتحديد المضيفين على الشبكة الفرعية. عنوان الشبكة: يمثل عنوان الشبكة (Network Address) البايتات اللازمة لتمثيل الجزء الخاص من الشبكة من عنوان IP، على سبيل المثال، المضيف صاحب العنوان 12.128.1.2 في شبكة ذات الفئة A يستطيع استخدام 12.0.0.0 كعنوان الشبكة، حيث يمثل الرقم 12 البايت الأول من عنوان IP (جزء الشبكة)، وبقية الأصفار في البايتات الثلاثة المتبقية تمثل قيم مضيفين محتملين في الشبكة؛ وفي مضيف شبكة يستخدم عنوان IP الخاص 192.168.1.100 الذي يستخدم بدوره عنوان الشبكة 192.168.1.0 الذي يحدد أول ثلاثة بايتات من شبكة ذات الفئة C والتي هي 192.168.1، وصفرًا الذي يُمثِّل جميع القيم المحتملة للمضيفين على الشبكة. عنوان البث: عنوان البث (Broadcast Address) هو عنوان IP يسمح لبيانات الشبكة بأن تُرسَل إلى كل المضيفين معًا في شبكة محلية بدلًا من إرسالها لمضيف محدد. العنوان القياسي العام للبث لشبكات IP هو 255.255.255.255، لكن لا يمكن استخدام هذا العنوان لبث الرسائل لكل مضيف على شبكة الإنترنت، لأن الموجهات (routers) تحجبها؛ ومن الملائم أن يُضبَط عنوان البث لمطابقة شبكة فرعية محددة، على سبيل المثال، في شبكة خاصة ذات الفئة C،‏ أي 192.168.1.0، يكون عنوان البث 192.168.1.255؛ تُولَّد رسائل البث عادةً من بروتوكولات شبكيّة مثل بروتوكول استبيان العناوين (Address Resolution Protocol‏ [ARP])، وبروتوكول معلومات التوجيه (Routing Information Protocol‏ [RIP]). عنوان البوابة: إن عنوان البوابة (Gateway Address) هو عنوان IP الذي يمكن الوصول عبره إلى شبكة معينة أو إلى مضيف معين على شبكة؛ فإذا أراد أحد مضيفي الشبكة التواصل مع مضيفٍ آخر، ولكن المضيف الآخر ليس على نفس الشبكة، فيجب عندئذٍ استخدام البوابة؛ في حالات عديدة، يكون عنوان البوابة في شبكةٍ ما هو الموجه (router) على تلك الشبكة، الذي بدوره يُمرِّر البيانات إلى بقية الشبكات أو المضيفين كمضيفي الإنترنت على سبيل المثال. يجب أن تكون قيمة عنوان البوابة صحيحةً، وإلا فلن يستطيع نظامك الوصول إلى أي مضيف خارج حدود شبكته نفسها. عنوان خادوم الأسماء: عناوين خادوم الأسماء (Nameserver Addresses) تمثل عناوين IP لخواديم خدمة أسماء المضيفين DNS، التي تستطيع استبيان (resolve) أسماء مضيفي الشبكة وتحويلها إلى عناوين IP؛ هنالك ثلاث طبقات من عناوين خادوم الأسماء، التي يمكن أن تُحدَّد بترتيب استخدامها: خادوم الأسماء الرئيسي (Primary)، وخادوم الأسماء الثانوي (Secondary)، وخادوم الأسماء الثلاثي (Tertiary)، ولكي يستطيع نظامك استبيان أسماء أسماء مضيفي الشبكة وتحويلها إلى عناوين IP الموافقة لهم، فيجب عليك تحديد عناوين خادوم الأسماء الذي تثق به لاستخدامه في ضبط TCP/IP لنظامك؛ في حالاتٍ عديدة، تُوفَّر هذه العناوين من موزع خدمة شبكتك، لكن هنالك خواديم أسماء عديدة متوفرة مجانًا للعموم، كخواديم Level3‏ (Verizon) بعناوين IP تتراوح بين 4.2.2.1 إلى 4.2.2.6. تنبيه: إن عنوان IP، وقناع الشبكة، وعنوان الشبكة، وعنوان البث، وعنوان البوابة تُحدَّد عادةً بالإمكان الملائمة لها في ملف ‎/etc/network/interfaces، عناوين خادوم الأسماء تُحدَّد عادة في قسم nameserver في ملف ‎/etc/resolve.conf، للمزيد من المعلومات، راجع صفحة الدليل لكلٍ من interfaces و resolv.conf على التوالي وبالترتيب، وذلك بكتابة الأوامر الآتية في محث الطرفية: للوصول إلى صفحة دليل interfaces، اكتب الأمر الآتي: man interfacesوللوصول إلى صفحة دليل resolv.conf: man resolv.confتوجيه IPيمثِّل توجيه IP‏ (IP Routing) الوسائل اللازمة لتحديد واكتشاف الطرق في شبكات TCP/IP بالإضافة إلى تحديد بيانات الشبكة التي ستُرسَل، يَستخدِم التوجيه ما يسمى «جداول التوجيه» (routing tables) لإدارة تمرير رزم بيانات الشبكة من مصدرها إلى وجهتها؛ وذلك عادة بواسطة عقد شبكيّة وسيطة تسمى «موجهات» (routers)؛ وهنالك نوعان رئيسيان من توجيه IP: التوجيه الثابت (static routing)، والتوجيه الديناميكي (dynamic routing). يشتمل التوجيه الثابت على إضافة توجيهات IP يدويًّا إلى جدول توجيهات النظام، ويتم ذلك عادةً بتعديل جدول التوجيهات باستخدام الأمر route؛ يتمتع التوجيه الثابت بعدِّة مزايا تميزه عن التوجيه الديناميكي، كسهولة استخدامه في الشبكات الصغيرة، وقابلية التوقع (يُحسَب جدول التوجيهات مسبقًا دائمًا، وهذا ما يؤدي إلى استخدام نفس المسار في كل مرة)، ويؤدي إلى حِملٍ قليل على الموجهات الأخرى ووصلات الشبكة نتيجةً لعدم استخدام بروتوكولات التوجيه الديناميكي؛ لكن يواجه التوجيه الثابت بعض الصعوبات أيضًا؛ فعلى سبيل المثال، التوجيهُ الثابتُ محدودٌ للشبكات الصغيرة، ولا يمكن أن يتوسَّع توسعًا سهلًا، ويصعب عليه التأقلم مع نقصان أو فشل معدات الشبكة في الطريق المسلوك نتيجةً للطبيعة الثابتة لذاك الطريق. يُعتَمَد على التوجيه الديناميكي في الشبكات الكبيرة ذات احتمالات عديدة للطرق الشبكية المسلوكة من المصدر إلى الوجهة، وتُستخدَم بروتوكولات توجيه خاصة، كبروتوكول معلومات الموجه (Router Information Protocol [RIP])، الذي يتولَّى أمر التعديلات التلقائية في جداول التوجيه، مما يجعل من التوجيه الديناميكي أمرًا ممكنًا؛ وللتوجيه الديناميكي مزايا عدّة عن التوجيه الثابت، كإمكانية التوسع بسهولة، والتأقلم مع نقصان أو فشل معدات الشبكة خلال الطريق المسلوك في الشبكة، بالإضافة إلى الحاجة لإعداداتٍ قليلةٍ نسبيًا لجداول التوجيه، ﻷن الموجهات تعلم عن وجود وتوفر بعضها بعضًا؛ وهذه الطريقة تمنع حدوث مشاكل في التوجيه نتيجةً لخطأ بشري في جداول التوجيه. لكن التوجيه الديناميكي ليس كاملًا، ويأتي مع عيوب، كالتعقيد، والحِمل الزائد على الشبكة بسبب التواصل بين الموجهات، التي لا تفيد المستخدمين المباشرين فوريًا، وتستهلك التراسل الشبكي. بروتوكولَي TCP و UDPإن بروتوكول TCP هو بروتوكول مبني على الاتصال (connection-based)، ويوفر آليةً لتصحيح الأخطاء، وضمانةً لتسليم البيانات عبر ما يُعرَف بالمصطلح «التحكم في الجريان» (flow control)، يُحدِّد التحكم في الجريان متى يجب إيقاف نقل البيانات، وإعادة إرسال الرزم التي أُرسِلَت سابقًا والتي واجهة مشاكل كالتصادمات (collisions)؛ إذ أنَّ التأكيد على الوصول الدقيق والكامل للبيانات عبر بروتوكول TCP هو أمر جوهري في عملية تبادل البيانات المهمة كالتحويلات في قواعد البيانات. أما بروتوكول UDP‏ (User Datagram Protocol) على الجهة الأخرى، هو بروتوكول عديم الاتصال (connectionless)، الذي نادرًا ما يتعامل مع عمليات نقل البيانات المهمة لأنه يفتقر إلى التحكم في جريان البيانات أو أيّة طريقة أخرى للتأكد من توصيل البيانات عمليًا؛ لكن بروتوكول UDP يُستخدَم استخدامًا شائعًا في التطبيقات كتدفق (streaming) الصوت والصورة، حيث أنه أسرع بكثير من TCP ﻷنه لا يحتوي على آليةٍ لتصحيح الأخطاء والتحكم في الجريان، وفي الأماكن التي لا يهم فيها فقدان بعض الرزم الشبكية كثيرًا. بروتوكول ICMPإن بروتوكول ICMP‏ (Internet Control Messaging Protocol) هو إضافة إلى بروتوكول الإنترنت (IP) الذي يُعرَّف في RFC‏‏ (Request For Comments) ذي الرقم ‎#792 ويدعم التحكم في احتواء الرزم الشبكية والأخطاء ورسائل المعلومات، يُستخدَم بروتوكول ICMP بتطبيقات شبكيّة كأداة ping، التي تستطيع تحديد إذا ما كان جهازٌ ما متاحًا على الشبكة، أمثلة عن رسالة الخطأ المُعادَة من ICMP -التي تكون مفيدةً لمضيفي الشبكة وللأجهزة كالموجهات- تتضمن رسالتَي «Destination Unreachable» و «Time Exceeded». العفاريتالعفاريت (Daemons) هي تطبيقات نظام خاصة التي تعمل عادةً عملًا دائمًا في الخلفية، وتنتظر طلبياتٍ للوظائف التي توفرها من التطبيقات الأخرى، يتمحور عمل العديد من العفاريت حول الشبكة، وبالتالي فإن عددًا كبيرًا من العفاريت التي تعمل في الخلفية في نظام أوبنتو تُوفِّر وظائف تتعلق بالشبكة؛ بعض الأمثلة عن عفاريت الشبكة تتضمن «عفريت بروتوكول نقل النص الفائق» (HyperText Transport Protocol Daemon‏ [httpd])، الذي يوفر وظيفة خادوم الويب؛ و «عفريت الصدفة الآمنة» (Secure SHell Daemon‏ [sshd])، الذي يوفر طريقةً للدخول الآمن عن بُعد وإمكانيات نقل الملفات؛ و «عفريت بروتوكول الوصول إلى رسائل الإنترنت» (Internet Message Access Protocol Daemon‏ [imapd]) الذي يوفر خدمات البريد الإلكتروني... مصادرتتوفر صفحات دليلٍ لبروتوكولي TCP و IP التي تحتوي على معلومات قيمّة.راجع أيضًا المصدر الآتي من IBM‏: «TCP/IP Tutorial and Technical Overview».مصدرٌ أخرى هو كتاب «TCP/IP Network Administration» من O'Reilly.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Networking TCP/IP.
  3. icnd1/ccent 100-101

    الوظيفة الرئيسية لطبقة النقل هي إخفاء تعقيدات الشبكة عن الطبقات العليا (التطبيق والعرض والجلسة)، مُتيحةً لمُطورِيّ التطبيقات تطويرَ البرمجيات دون التفكير في طريقة التعامل مع الشبكة. مما يوفِّر استقلاليّةً في نشر (deployment) وتطوير المكونات (components) في تجميعة بروتوكول IP. يتوفَّر بروتوكولان في طبقة النقل هما: UDP ‏(User Datagram Protocol)، و TCP ‏(Transmission Control Protocol). يقوم كلاهما بالإرسال المتعدد للجلسة (session multiplexing)، الذي هو أحد الوظائف الرئيسية لطبقة النقل، الذي يعني أنه يتمّكن جهازٌ ما يستعمل عدِّة جلسات أو عدِّة اتصالات من استخدام عنوان IP ذاته للتواصل مع الشبكة. مثال: تتمكن الخواديم التي توفِّر خدمات الويب وFTP من استخدام نفس عنوان IP. ميزةٌ أخرى هي«التقطيع» (segmentation) التي تُحضِّر وحدات المعلومات (units of information) من طبقة التطبيقات وتُقسِّمها إلى قطع لتغليفها في رزم لإرسالها عبر الشبكة. وقد تتأكد طبقة النقل -اختياريًّا- أن تلك الرزم قد وصلت إلى الوجهة عبر آليات التحكم في الجريان (flow control). ما سبق اختيارٌ لأنَّ بروتوكول TCP هو من يوفِّر تلك الخدمة فقط، لأنه بروتوكولٌ يعتمد على الاتصالات (connection-oriented)؛ على عكس UDP الذي هو بروتوكول عديم الاتصال (connectionless)، ويُستخدَم عندما تكون السرعةُ عاملًا مهمًّا، حيث يؤدي التحكم في الجريان والوثوقية (reliability) إلى إبطاء سرعة الاتصال. فإذا أردنا أن نقارن بروتوكولَي طبقة النقل، فسيكون بروتوكول TCP معتمدًا على الاتصالات، وهو بروتوكولٌ ذو وثوقيةٍ عالية، ويوفِّر آلياتٍ مثل ترقيم الرزم وإعادة تجميعها في الوجهة بنفس الترتيب، وآليةٌ كاملةٌ لتحديد التوقيت لضمان تسليم الرزم... أما UDP فهو بروتوكولٌ عديم الاتصال، ولا يوفِّر أي ترتيبٍ للرزم ولا أي نوعٍ من ضمانة توصيلها. هذا يشبه إلى حدٍ كبير المكالمات الهاتفيّة، حيث عليك أن تطلب الرقم وتُنشِئ اتصالًا قبل أن تبدأ بالتكلّم، وهذا مثل TCP؛ أو توصيل البريد العادي، حيث لا تضمن أن رسائلك ستصل إلى وجهتها، فإنِّك تُرسِل الرزم الشبكيّة آملًا أن تصل إلى هناك، وهذا مثل UDP. لكن قد تتعامل الطبقات العليا مع بروتوكول UDP بطريقةٍ مختلفة، وتزيد من وثوقية توصيله للرزم. أمثلة على استخدام كلي البروتوكولَين: تَستخدم خدمات البريد الإلكتروني ونقل الملفات والتنزيل بروتوكول TCP ذا الوثوقيّة العالية؛ أما اتصالات الصوت والفيديو فستستفيد من التخلص من عبء التحقق من الوصول والوثوقية مما يؤدي إلى تسريع تسليم الرزم، حيث تستطيع تلك التطبيقات التعامل مع فقدان بعض الرزم الشبكيّة. الوثوقية أفضل جهد (Best-Effort) البروتوكول TCP UDP نوع الاتصال ذو اتصال عديم الاتصال ترتيب الرزم نعم لا الاستخدامات البريد الإلكتروني مشاركة الملفات تنزيل الملفات تدفق الصوت تدفق الفيديو الخدمات التي تعمل بالوقت الحقيقي خصائص بروتوكول UDPهو بروتوكولٌ عديم الاتصال، حيث يوفِّر تحققًا محدودًا من الأخطاء، فلا توجد ميزات لاستعادة البيانات عند فقدان بعض الرزم، ولهذا لا يوفِّر ميزة إعادة إرسال الرزم، إذ تستفيد التطبيقات التي تستخدم UDP من قلة الإجراءات المُتّبَعة عند استخدام هذا البروتوكول، لأنه لا توجد آليات للتحقق من وثوقية وصول البيانات؛ نقصد بالتحقق المحدود من الأخطاء أنَّ هنالك بعض التحقق من الأخطاء على شكل مجموعات اختبارية (checksums) للتحقق من سلامة البيانات الموجودة في هذه الرزم؛ وهنالك أيضًا ترويسة صغيرة تتضمن المنافذ في المصدر والوجهة، فلو لم تكن هنالك خدمةٌ تعمل على جهاز الوجهة، فسيُعيد بروتوكول UDP رسالة خطأ تقول أنَّ الخدمة غير متوفرة. تحتوي ترويسة UDP على المنافذ في المصدر والوجهة، التي تُحدِّد التطبيقات التي تتصل عبر UDP، ويوجد أيضًا طول الحمولة (payload) وطول الترويسة والمجموع الاختباري للتحقق من سلامة البيانات. خصائص بروتوكول TCPيُوفِّرُ بروتوكولٌ يعتمد على الاتصالات، مثل TCP، وثوقيةً واكتشافًا للأخطاء وتصحيحًا لها، ويَضمن أيضًا توصيل الرزم؛ ولهذه الأسباب، سيكون أكثر تعقيدًا من UDP؛ إذ يُوفِّر تحققًا من الأخطاء على شكل مجموعات اختباريّة (checksums) بالإضافة إلى ترقيم كل رزمة لكي تتأكد الوجهة من الترتيب وتبحث عن الأجزاء أو الرزم الناقصة؛ يشبه اتصال TCP محادثةً تتم عبر الجهاز اللاسلكي (walkie-talkie)؛ حيث تتضمن إشعاراتٍ (acknowledgments) من كل طرف أنَّ الطرفَ الآخر قد استلم البيانات، وسيتم إكمال إرسال البيانات بعد استلام تأكيد بأنَّ الرزم السابقة قد وصلت. ولدى هذا البروتوكول آليةٌ لكي يعيد إرسال البيانات؛ فإن فُقِدَت رزمةٌ ما أثناء النقل، فيمكن إعادة إرسالها بمعرفة رقمها التسلسلي. لن تؤدي العملية السابقة إلى المزيد من الإجراءات والبروتوكولات -مثل حساب الأرقام التسلسلية وآلية «sliding windows»- فحسب، بل وستؤدي أيضًا إلى وجود المزيد من المعلومات التي يجب تضمينها في الترويسة؛ ففي بروتوكول TCP، لن نشاهد منافذ المصدر والوجهة في الترويسة فقط، وإنما سنشاهد أيضًا الأرقام التسلسلية، وأرقام إشعارات الاستلام. يُحدَّد حجم النافذة (window size) لتسهيل عملية تأكيد وصول عدِّة رزم في مرة واحدة؛ وسيضمن المجموع الاختباري سلامة البيانات المنقولة. وهنالك أنماطٌ مختلفةٌ من التوصيل عبر استعمال «مؤشِّر الرزم المُستعجَلة» (urgent pointer)، والخيارات، والرايات (flags). لمحة عن طبقة التطبيقات في TCP/IPمهمة طبقة النقل هي إخفاء تعقيد الشبكة عن التطبيقات في الطبقة العليا؛ يمكن بناء تلك التطبيقات باستخدام TCP أو UDP اعتمادًا على حاجاتها، فيما إذا كانت تريد اتصالًا ذو وثوقيةٍ عالية، أو كانت تفضِّل سرعة النقل؛ مثالٌ عن التطبيقات هو تطبيقات FTP، و TFTP، وNFS لنقل الملفات؛ وSTMP، و POS3 للبريد الإلكتروني؛ ومختلف تطبيقات الوصول عن بُعد؛ و SNMP لإدارة الشبكة؛ وخدمة DNS لتحويل أسماء المضيفين إلى عناوين IP. أحد أهم المفاهيم الأساسية لأي نموذج متعدد الطبقات هو التفاعل بين الطبقات؛ والطبقتان 3 و 4 من نموذج OSI ليستا استثناءً؛ فمثلًا، لو استقبل جهازٌ معيّن رزمًا من الشبكة وعالجها عبر بروتوكول IP في الطبقة الثالثة، فسيحتاج إلى مزيدٍ من المعلومات لتحديد البروتوكول الملائم لمعالجة تلك الرزمة، هل هو TCP أم UDP؛ بكلامٍ آخر، ما هو بروتوكول طبقة النقل الذي يجب أن يتوَّلى أمر الرزمة من هنا؟ يَستخدم IP حقل «البروتوكول» لتحديد بروتوكول طبقة النقل المُستخدَم؛ فمثلًا، الرقم «6» في حقل البروتوكول يعني أن TCP هو بروتوكول طبقة النقل الذي يجب أن يُعالِج تلك الرزمة، بينما «17» يعني أنَّ UDP هو البروتوكول الذي عليه معالجة الرزمة. وبشكلٍ مشابه، سيحتاج بروتوكولَيّ TCP و UDP إلى المزيد من المعلومات ليعلما أيُّ تطبيقٍ في الطبقات العليا سيستلم الرزم الموجَّهة إليه؛ وذلك عبر أرقام المنافذ التي ستُذكَر في ترويسة طبقة النقل؛ على سبيل المثال، يُمثِّل المنفذ 21 خدمة FTP، و23 خدمة Telnet، بينما 80 يُمثِّل خدمة الويب على شكل بروتوكول HTTP؛ أما 53 فلخدمة DNS، و69 لخدمة TFTP، و 161 لخدمة SNMP؛ يجب أن تكون تلك الأرقام فريدةً، وهي مُسندةٌ من هيئة IANA؛ تكون أرقام المنافذ الشهيرة تحت 1023، لكن هنالك مجالاتٌ أخرى للمنافذ المُسجَّلة لكنّها تتبع للتطبيقات الاحتكاريّة؛ وحتى هنالك مجالاتٌ متوفرة للمنافذ التي تُحدَّد ديناميكيًا. إنشاء اتصالبروتوكول TCP مسؤولٌ عن إنشاء الاتصالات قبل إرسال الرزم؛ سيُستعمَل هذا الاتصال من كلي الطرفين لإنشاء جلسة معيّنة وإخفاء تعقيد الشبكة عنهما؛ بكلامٍ آخر، سيرى المُضيفان مُعرِّف الاتصال (connection identifier) وليس الشبكة المعقدة التي تقع «تحت» ذاك الاتصال؛ ومن واجبات بروتوكول TCP أيضًا إنشاء، وإدارة، وإنهاء الاتصالات بعد الانتهاء منها. عملية «إنشاء الاتصال ثلاثية الاتجاه» (three-way handshake) هي عملية لمزامنة (synchronizing) جهازَين ليعلما أنهما متصلان عبر TCP؛ تَستخدِم هذه العملية رزمًا خاصةً التي تستعمل حقول التحكم (control fields) وترويسة TCP؛ حقول التحكم تلك مُعرَّفةٌ بالكلمة المفتاحية CTL في المخطط البياني التالي. ويبدأ الأمر بأكمله بإرسال رزمةٍ لها رقمٌ تسلسليٌ معيّن؛ وبكل تأكيد، سيكون «بت» التحكم هو SYN؛ ستُرسَل الرزمة وتعالجها النهاية المُستقبِلة وتُرسِل ما يُعرَف بإشعار SYN، التي (أي رزمة ذاك الإشعار) تكون فيها راية SYN ‏(SYN flag) وراية الإشعار. وتُستخدَم أيضًا الأرقام التسلسلية لإشعار استلام السلسلة التالية من البتات؛ يُنشَأ الاتصال بشكل كامل عندما يُرسَل الإشعار النهائي من المستلم؛ بت التحكم المُستخدم في الإشعار النهائي هو راية الإشعار فقط. وهذا يُشبِه محادثة الهاتف حيث نبدأ المحادثة بقول «مرحبًا» ويُرَدُّ علينا بالجملة «أهلًا، أنا هنا» ثم سيقول المُرسِل «حسنًا، لقد أنشَأنا الاتصال، لنبدأ التحدث». التحكم في الجريان (Flow Control)تؤدي آلية التحكم في الجريان في طبقة النقل والبروتوكولات مثل TCP إلى وظيفتين مستقلتين لكن توجد علاقةٌ تربط بينهما؛ أولاهما هي إشعارات استلام الرزم؛ والإشعارات ما هي إلا رزمٌ خاصةٌ تمثِّل تأكيدًا أن البيانات قد وصلت إلى وجهتها؛ ولن يُكمِل المُرسِل إرسال بياناتٍ إضافيةٍ ما لم يحصل على إشعارٍ باستلام البيانات المُرسَلة سابقًا. الآلية الثانية هي «النوافذ» (windows)، التي تخدم هدف إرسال إشعار باستلام قطع من البيانات؛ بكلامٍ آخر، بدلًا من إرسال إشعار باستلام كل رزمة؛ فسنطلب من المُرسِل أن يُرسِل سلسلةً من الرزم دفعةً واحدة، بدلًا من إرسالها مُتفرِّقةً. وتُساهِم هذه الآلية بزيادة التحكم بكمية البيانات المُرسَلة، فعندما يُرسِل المُستقبِل حجم نافذة مساوٍ للقيمة 0، فإنه يقول للمُرسِل: «حافظتي ممتلئة، لا أستطيع معالجة أيّة بياناتٍ إضافيةً، أتمنى أن تنتظر حتى إشعارٍ آخر»، وعندما تصبح حافظة المستقبِل فارغةً ويصبح بمقدوره استلام المزيد من الرزم، فسيُستأنَف نقل البيانات عبر إرسال حجم نافذة مختلف؛ وفي هذه النقطة، سيُعيد المُرسِل تهيئة عملية النقل مجددًا. حجم النافذة ما هو إلا مقدار المعلومات التي لم يُرسَل إشعارٌ باستلامها التي يمكن أن تكون قيد الإرسال؛ فعندما يُرسِل المُرسِل قطعة (chunk) البيانات رقم 1 (وتُعرَّف تلك القطعة بعدد البايتات أو الكيلوبايتات التي ستُرسَل)، فسيعمله المُستقبِل بذلك عبر تحديد القطعة التالية التي يتوقع وصولها؛ بكلامٍ آخر، لن يقول المُستقبِل: «أنا أعلمك أنني استلمت القطعة رقم 1 من البيانات»، بل سيقول: «أرسِل لي قطعة البيانات رقم 2 الآن»؛ يكون حجم النافذة في المثال السابق هو «1»، أي أننا نُرسِل إشعارًا باستلام كل قطعة، وهذا سيصبح أمرًا معقّدًا ويسبب بطئًا في الشبكة؛ حيث يلزم المزيد من الإشعارات للتحكم في التدفق ولإكمال الإرسال. فمن المهم أن نفهم أنَّ ما نسميّه «قطعًا» (chunks) يكون على شكل «segments» في طبقة النقل، وتكون تلك القطعة بوحدة بايت أو كيلوبايت. لا يُسبِّب إشعارٌ واحدٌ لكل وحدة بيانات حِملًا ثقيلًا على الشبكة فحسب، بل يُبطِئ أيضًا من سرعة الاتصال؛ وهذا يشبه كثيرًا قول كلمة «حوِّل» (في مثالنا عن «اتصال الراديو» السابق) بعد كل كلمة يقولها المُرسِل: «أهلًا حوِّل»، «بِك حوِّل» ...إلخ. يتضمّن بروتوكول TCP آليةً للنوافذ، التي تسمح بزيادة عدد القطع المُرسَلة قبل إشعار استلامها؛ وبهذا، تستطيع أن تقول «أهلًا بِك» ثم تقول كلمة «حوِّل» في نهاية الجملة. يُمثِّل حجم النافذة عدد البايتات أو الكيلوبايتات التي يمكن أن تُرسَل دفعةً واحدة؛ ففي المخطط الآتي، ستُرسَل ثلاث قطع، ثم سيُرسِل المُستقبِل إشعارًا بالاستلام بقوله: «أرسل لي الرقم 4». وبهذا نكون قد أرسلنا إشعارًا باستلام أول ثلاث قطع دفعةً واحدة. يكون حجم النافذة في الحياة العملية بوحدة الكيلوبايت، أي ستكون طريقة زيادة حجم النافذة كالآتي: «كنت أُرسِل 64 كليوبايت، وأنا الآن أُرسِل 128 كيلوبايت، ويمكنك إرسال إشعار باستلام 128 كيلوبايت بدلًا من 64». لا يُفضَّل استخدام نافذةٌ ذات حجمٍ ثابت للمُستقبِل والمُرسِل لملائمة ازدحام الشبكة (network congestion) والتأقلم تبعًا له؛ يسمح لك حجم نافذة محجوزٌ ديناميكيًا (ويُعرَف أيضًا بالمصطلح «sliding window») بالتأقلم دون التسبب بازدحامٍ في الشبكة ويعمل أيضًا كآلية للتحكم بالجريان (flow control mechanism). تكتمل آلية التحكم عبر استخدام أرقام تسلسلية وأرقام إشعارات الاستلام؛ لاحظ أنه في هذا الرسم التوضيحي تكون الأرقام التسلسلية أكثر واقعيةً حيث تَظهِر كميّة البيانات بوحدة البايت التي ستُرسَل في كل قطعة؛ أي أنَّ الرقم التسلسلي «10» يعني أنَّه قد أُرسِل 10 بايتات من البيانات؛ ورقم إشعار الاستلام 11 يعني أن أول 10 بايتات قد اُستُلِمَت ويتوقع المُستقبِل إرسال القطعة التي تلي تلك البايتات؛ التبادل التالي ذو الرقم 260 يعني أن 250 بايتًا من البيانات قد أُرسِل، أي أن الرقم التسلسلي يمثِّل إزاحةً لها علاقة بالقطعة التي أُرسِلت في البداية. لاحظ أن المُرسِل والمُستقبِل يعلمان عن هذه المحادثة ويمكن أن يعتبرانها اتصالًا واحدًا بناءً على المنافذ المُستخدَمة في المصدر والوجهة. يُولَّد منفذ المصدر عشوائيًا وقت الاتصال، لكن يجب معرفة منفذ الوجهة مسبقًا، الذي يُعرِّف تطبيقًا معيّنًا، وهو Telnet في هذا الرسم التوضيحي: ترجمة -وبتصرّف- للمقال Understanding The TCP/IP Transport Layer.
  4. pre { direction: ltr; }تعلمنا في الجزء السابق أن HTTP بروتوكول على مستوى التطبيقات. حان الوقت لنفهم كيفية استخدام هذا البروتوكول للتواصل بين العميل والخادوم. جلب الأشياء من الويبتذكر أن عميل HTTP (وهو المتصفح عادةً) هو الطرف الذي يبدأ بإرسال الطلب إلى الخادوم. يسمح بروتوكول HTTP للعميل بالتعبير عن نيّته من خلال بضعة مُكوّنات: الرابط (URI)، وأفعال HTTP، وترويساته. تسمية الأشياءتمثّل الروابط (URIs) حجر الأساس في الويب، لأنّها تحل مشكلة مهمّة على مستوى الإنترنت بكاملها، وهي مشكلة منح الأشياء مُعرّفًا تنفرد به على الشّبكة. افترض أنّك سألت شخصًا أن يجلب لك شيئًا ويُحضره إليك، يمكن عدّ الطرق الممكنة للطلب على الأصابع. فعادةً ما تُعرّف الكلمات الّتي تستخدمها الشيء الّذي تريده. بإمكانك أن تطلب من صديقك قائلًا: "اجلب لي الكتاب."قد يجيبك صديقك: "حاضر. ولكن أي كتاب؟".فتقول أنت: "الكتاب في الغرفة الأخرى."فيذهب صديقك إلى الغرفة ويسأل: "أي كتاب قلت؟"فتقول أنت وقد شعرت بالضّيق: "الأخضر!"ليقول صديقك: "تمهّل لحظة... هناك كتابان أخضران في الغرفة!"وعندها تنهض لتحضر الكتاب بنفسك. كان الأمر ليكون أكثر بساطة لو أننا وحدنا طريقة نُحدّد فيها الأشياء بطريقة مميّزة للوصول إليها لاحقًا. إحدى الوسائل الممكنة هي الاعتماد على الذاكرة. كيف نعطي الأوامر لشخص ما ليحضر إلينا الغرض المطلوب؟ لنُنشئ نظامًا لذلك: قص ورقات صغيرة أو استخدم ورق الملاحظات اللّصّاق.ضع هذه الأوراق على الأغراض في الغرفة المجاورة أو على الطّاولة (كالكتب مثلًا).اكتب مُعرّفًا مُميِّزًا على كل ورقة.كرّر العملية في غرفة مجاورة أو على طاولة مجاورة.تذكّر أن هذا النّظام لا يقتصر على أغراضك، بل يمتد ليسمح بنوعٍ من التّواصل بين الأغراض جميعها. طبّقت هذا النّظام على أغراضي، فكتبت على كل قطعة ورق واحدًا من المُعرّفات التالية: myRoom.org/table/book/001 myRoom.org/shelf/book/002 otherRoom.org/cup/001 otherRoom.org/flower/001 otherRoom.org/book/001أعتقد أنك الآن فهمت ما أقصد. لدينا الآن نظام من اللصاقات الّتي تستخدم لتحديد كل شيء في المكان بدقة. في الويب، نحن نتعامل مع فضاء معلومات واللصاقات المُستخدمة ليست سوى الروابط (URIs). الوصول إلى الأشياء المُسمَّاةشرحنا كيف يُبنى طلب HTTP في المقال السابق من خلال الطرفية. استخدمنا بناءً بسيطًا مع فعل HTTP المُسمّى GET مع ترويسة واحدة: Host. GET / HTTP/1.1 Host: www.opera.comالقائمة الكاملة لأفعال HTTP الحالية هي: OPTIONS، GET، HEAD، POST، PUT، DELETE، TRACE، CONNECT. لكل فعل دورٌ مختلف عن الأفعال الأخرى وسنشرح ذلك في المقالات التالية. أكثر الأفعال استخدامًا هو GET، ففي كلّ مرة نُدخل عنوان HTTP في شريط العناوين في المتصفح، فإنّنا نرسل طلب GET إلى خادوم. في عالم الويب يُرسل العميل معلومات أكثر (المزيد من ترويسات HTTP) إلى الخادوم للتفاهم على المطلوب. يستغل الخادوم هذه المعلومات ليُعدّل الجواب بما يناسب الترويسات. تتوفّر أداة عمليّة جدًا في Opera Dragonfly لإنشاء طلبات HTTP مُخصّصة وفحص إجابة الخادوم. يمكنك إيجادها في قسم Network في تبويب "Make Request". هنالك ثلاث مناطق في تبويب Make Request: الرابط (URL): مُعرّف المُحتوى (أو عنوان الويب)متن الطّلب (Request body): ما سيُرسله العميل إلى الخادوم (يُرسل الزّر "Send request" الطّلب إلى الخادوم عبر الشّبكة)الجواب (Response): جواب الخادوم بعد إرسال الطّلبتخصيص طلب HTTPانسخ http://www.opera.com/ إلى قسم URL.انسخ والصق طلب HTTP التّالي إلى قسم "Request body" في تبويب Network. أضفنا الترويسة Accept-Language إلى طلب HTTP السابق.اضغط الزر "Send request".GET / HTTP/1.1 Host: www.opera.com Accept-Language: enسيُجيب خادوم Opera بجواب HTTP مؤلّف من بضع ترويسات يليها محتوى المستند. قد تحتاج إلى تمرير النافذة، لأن الجواب قد يكون طويلًا. لاحظ أن المُستند باللغة الإنكليزيّة، ليس فقط من حيث اللغة الّتي كتب بها، بل أيضًا يُنصّ على ذلك صراحةً في خاصّة lang على ال عنصر html: <!DOCTYPE html> <html lang="en">لنُجرّب الفرنسيّة: GET / HTTP/1.1 Host: www.opera.com Accept-Language: frسُيجيب الخادم هذه المرة بالفرنسيّة، ويتبيّن ذلك في نص المستند وفي مصدره: <!DOCTYPE html> <html lang="fr">لاحظ أنّنا استخدمنا الرابط نفسه بالضّبط (http://www.opera.com/) ولكنّنا تلقّينا إجابتين مُختلفتين لا لشيء إلا لأننا غيّرنا الترويسة Accept-Language. لاحظ أيضًا أنّ الخادوم أجاب بترويسات كثيرة تُعطينا معلوماتٍ عن حالة المحتوى ونوعه... إلخ. يسمح هذا للعميل بتعديل أسلوب معالجة المستند. يمكنك تجربة لغات مُختلفة مثل اليابانية (ja) والألمانية (de)... إلخ. ما الذي يحدث إن طلبنا لغة غير موجودة على الخادوم؟ جرّب مثلًا الصّينيّة (zh): GET / HTTP/1.1 Host: www.opera.com Accept-Language: zhستتلقى النسخة الإنكليزية من الموقع. هل هذا مُحيّر؟ الحقيقة أنّ هذا الأمر يعتمد على تصميم الموقع ذاته. فقد يُصمم جواب HTTP بأسلوب آخر، كأن يُجيب الخادوم "لا، ما من نسخة صينية من الموقع لدينا"، أو "ليست لدينا نسخة صينية، ولكن لدينا اللغات التالية: ...). ولكن فريق تجربة المستخدمين في Opera قرر إرسال النسخة الإنكليزية من الموقع عند طلب لغة غير مُتوفّرة. المسألة مسألة اختيار، فلا قاعدة تُفرض على المواقع بهذا الشأن. ولهذا السّبب أقوم عادةً بتعليم مُصمّمي تجربة الاستخدام ومُطوّري الواجهات بعض أساسيّات HTTP، فهو بروتوكول يتوسّط التفاعل بين العميل والخادوم، وعليه فإنّ فهمه يُساعد في تصميم تفاعلات ذات معنى عند بناء المواقع، وذلك للبشر والآلات معًا (كالبرامج الّتي تستخدم الواجهات البرمجيّة (APIs) وما شابهها... إلخ). تذكّرURI: نظام لتعريف المعلومات على الشبكة.أفعال HTTP: يتضمّن البروتوكول حاليًا الأفعال التّالية: OPTIONS، GET، HEAD، POST، PUT، DELETE، TRACE، CONNECT. وقد تعرّفنا في هذه المقالة على أكثرها استخدامًا وهو GET. ترويسات HTTP:** الترويسات هي بيانات إضافية يُرسلها العميل لإعطاء معلومات أكثر عن البيانات المُتبادلة بين العميل والخادوم. تُفيد بعض هذه الترويسات الخادوم بحيث يختار الأسلوب الأفضل للإجابة.ترجمة (بشيء من التّصرّف) لمقال HTTP: Let’s GET It On! لصاحبه Karl Dubosy.