أساسيات الشبكات تطبيقات الشبكات الحاسوبية: شبكة الويب العالمية

لقد حققت شبكة الويب العالمية نجاحًا كبيرًا وجعلت الإنترنت في متناول العديد من الأشخاص، بحيث تظهر أحيانًا أنها مرادفٌ للإنترنت. لقد بدأ تصميم النظام الذي أصبح الويب لاحقًا حوالي عام 1989، أي بعد فترةٍ طويلةٍ من انتشار الإنترنت على نطاقٍ واسع، وكان الهدف الأصلي للويب هو إيجاد طريقةٍ لتنظيم واسترجاع المعلومات بالاعتماد على أفكارٍ حول النص الترابطي hypertext، أو الوثائق المترابطة interlinked documents التي كانت موجودة منذ الستينيات على الأقل.

وترجع جذور تاريخٍ قصيرٍ من الويب الذي قدّمه اتحاد شبكة الويب العالمية إلى مقالٍ صادرٍ في عام 1945 شرح الروابط بين مستندات البطاقات المجهرية التي تُعرَف بالميكروفيش microfiche. تتمحور فكرة النص الترابطي حول امكانية ربط مستندٍ بمستند آخر، وقد صُمِّم بروتوكول HTTP ولغة المستند التي هي لغة HTML لتحقيق هذا الهدف.

من بين الطرق المفيدة للتفكير في الويب؛ وجود مجموعةٍ من العملاء والخوادم المتعاونة، التي تتحدث جميعها نفس اللغة، وهي بروتوكول HTTP. يُعرض الويب على معظم الأشخاص من خلال برنامج عميٍل رسومي أو متصفح ويب، مثل Safari أو Chrome أو Firefox أو Internet Explorer.

يوضح الشكل التالي متصفح Safari قيد الاستخدام، ويعرض صفحة معلومات من جامعة برينستون.

إذا أردت تنظيم المعلومات في نظامٍ من المستندات أو الكائنات المرتبطة، فيجب أن تكون قادرًا على استرداد مستندٍ واحدٍ للبدء، كما أن أي متصفح ويب لديه وظيفةٌ تسمح للمستخدم بالحصول على كائنٍ ما عن طريق فتح محدِّد موقع URL، حيث أصبحت محددات مواقع الموارد الموحَّدة Uniform Resource Locators أو اختصارًا URLs مألوفةً جدًا لمعظمنا، وتوفّر معلوماتٍ تسمح بتحديد موقع الكائنات على الويب، وتكون كما يلي:

http://www.cs.princeton.edu/index.html

إذا فتحت محدّد URL هذا، فسيفتح متصفح الويب اتصال TCP بخادم الويب على جهاز يسمى www.cs.princeton.edu، ثم يَسترد ويعرض الملف المسمّى index.html على الفور. تحتوي معظم الملفات الموجودة على الويب على صورٍ ونصوص، ويحتوي العديد منها على كائناتٍ أخرى مثل مقاطع الصوت والفيديو، وأجزاءٍ من شيفرة وغير ذلك، كما تشتمل أيضًا على محدّدات URL التي تشير إلى ملفاتٍ أخرى قد تكون موجودةً على أجهزةٍ أخرى، والتي تُعَد جوهر مصطلح النص الترابطي hypertext الموجود ضمن بروتوكول HTTP ولغة HTML.

يحتوي متصفح الويب على طريقةٍ يمكنك من خلالها التعرف على محدّدات URL وتكون غالبًا عن طريق إبراز بعض النصوص أو وضع خطٍ تحتها، ويمكنك مطالبة المتصفح بفتحها، حيث تسمَّى محدّدات URL المضمَّنة هذه روابط النصوص الترابطية hypertext links. وإذا طلبت من متصفح الويب فتح أحد محدّدات URL المضمَّنة من خلال التأشير والنقر عليه بالفأرة على سبيل المثال، فسيفتح المتصفح اتصالًا جديدًا ويسترجع ملفًا جديدًا ويعرضه، ويُسمى هذا متابعة الرابط following a link، وبالتالي سيصبح التنقل من جهازٍ إلى آخر على الشبكة أمرًا سهلًا جدًا من خلال متابعة الروابط لجميع أنواع المعلومات.

يمكنك تكوين أساسٍ لنظام النص الترابطي، بمجرد أن يكون لديك وسيلةٌ لتضمين رابطٍ في مستند والسماح للمستخدم بمتابعة هذا الرابط للحصول على مستندٍ آخر.

إذا طلبت من متصفحكَ عرض صفحة، فسيجلب المتصفح أو العميل الصفحة من الخادم باستخدام بروتوكول HTTP الذي يعمل عبر بروتوكول TCP. ويُعَد بروتوكول HTTP بروتوكولًا موجّهًا بالنصوص مثل SMTP. وHTTP في جوهره هو بروتوكول طلب / استجابة request/response، حيث يكون لكل رسالةٍ الشكل العام التالي:

START_LINE <CRLF>
MESSAGE_HEADER <CRLF>
<CRLF>
MESSAGE_BODY <CRLF>

يشير الرمز <CRLF> إلى carriage-return+line-feed كما ذكرنا سابقًا، ويحدّد السطر الأول START_LINE ما إذا كانت هذه الرسالة رسالة طلبٍ أو استجابة، كما يحدّد أيضًا الإجراءَ البعيد remote procedure الذي سيُنفَّذ إذا كانت رسالة طلب، أو حالة status الطلب إذا كانت رسالة استجابة. وتحدد مجموعة الأسطر الأخرى مجموعةً من الخيارات والمعامِلات المُؤهلة للطلب أو الاستجابة.

لا تتواجد سطور MESSAGE_HEADER إطلاقًا أو يمكن أن يتواجد سطرٌ أو أكثر منتهٍ بسطرٍ فارغ، حيث يظهر كل سطرٍ منها كأنه سطر ترويسة header في رسالة البريد الإلكتروني. يُعرِّف بروتوكول HTTP العديد من أنواع الترويسات المحتملة، حيث يتعلّق بعضها برسائل الطلب، والبعض الآخر برسائل الاستجابة؛ اما البعض الآخر، فيتعلق بالبيانات المنقولة في جسم الرسالة.

سنقدّم فقط عددًا قليلًا من الأمثلة، بدلًا من إعطاء المجموعة الكاملة لأنواع الترويسات الممكنة. أخيرًا، تأتي بعد السطر الفارغ محتويات الرسالة المطلوبة MESSAGE_BODY؛ فهذا الجزء من الرسالة هو المكان الذي يضع فيه الخادم الصفحة المطلوبة عند الاستجابة لطلبٍ ما، ويكون عادةً فارغًا في رسائل الطلب.

لماذا يعمل بروتوكول HTTP عبر بروتوكول TCP؟ لم يكن على المصممين فعل ذلك بهذه الطريقة، لكن بروتوكول TCP يوفر تطابقًا جيدًا مع احتياجات بروتوكول HTTP، لا سيما من خلال توفير توصيلٍ موثوق، حيث لا يريد أحدٌ صفحة ويب بها بياناتٌ مفقودة، وكذلك التحكم في التدفق والازدحام، لكن كما سنرى أدناه، هناك بعض المشاكل التي يمكن أن تحدث من إنشاء بروتوكول طلب / استجابة فوق بروتوكول TCP، خاصةً إذا تجاهلت التفاصيل الدقيقة للتفاعلات بين بروتوكولات طبقتَي التطبيق والنقل.

رسائل الطلب Request Messages

يحدّد السطر الأول من رسالة طلب HTTP ثلاثة أشياء هي العملية المُراد تنفيذها، وصفحة الويب التي يجب تنفيذ العملية عليها، وإصدار بروتوكول HTTP المُستخدَم. يحدّد بروتوكول HTTP مجموعةً متنوعةً من عمليات الطلب الممكنة، بما في ذلك عمليات الكتابة التي تسمح بنشر صفحة ويب على الخادم، لكن العمليتين الأكثر شيوعًا، هما عملية GET لجلب صفحة الويب المحدَّدة، والعملية HEAD لجلب معلومات الحالة حول صفحة الويب المحدّدة؛ حيث تُستخدَم العملية GET عندما يريد متصفحك استرداد صفحة ويب وعرضها؛ أما العملية HEAD فهي لاختبار صلاحية رابط النص الترابطي، أو لمعرفة ما إذا عُدِّلت صفحةٌ معينة منذ آخر مرةٍ جلبها المتصفح. يلخّص الجدول الآتي المجموعة الكاملة من العمليات، ويسبب الأمر POST الكثير من الضرر على الإنترنت بما في ذلك البريد المزعج spam.

يخبرنا سطر START_LINE التالي على سبيل المثال بأن العميل يريد من الخادم إعادة الصفحة المسمّاة index.html.

GET http://www.cs.princeton.edu/index.html
HTTP/1.1

يستخدم هذا المثال محدّد URL مطلق absolute، ويمكن أيضًا استخدام معرّف نسبي relative وتحديد اسم المضيف في أحد سطور MESSAGE_HEADER كما في السطر التالي:

GET index.html HTTP/1.1
Host: www.cs.princeton.edu

حقل المضيف Host هنا هو أحد حقول ترويسة الرسالة MESSAGE_HEADER الممكنة، وأهم حقلٍ هو الحقل If-Modified-Since الذي يمنح العميل طريقةً لطلب صفحة ويب بصورةٍ مشروطة، حيث لا يرجع الخادم الصفحة إلا إذا كانت مُعدَّلة منذ الوقت المحدد في سطر الترويسة.

رسائل الاستجابة

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

HTTP/1.1 202 Accepted

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

HTTP/1.1 404 Not Found

توجد خمسة أنواعٍ عامة من رموز الاستجابة، حيث يشير الرقم الأول من الرمز إلى نوعه. يلخّص الجدول التالي الأنواع الخمسة لهذه الرموز:

تكون كيفية استخدام رسائل الاستجابة المختلفة عمليًا أمرًا غير متوقَّع، كما هو الحال مع العواقب غير المتوقعة لرسالة طلب POST، حيث تبيّن أن إعادة توجيه الطلب (الرمز 302 تحديدًا) على سبيل المثال، يُعَد آليةً فعالةً تلعب دورًا كبيرًا في شبكات توزيع المحتوى Content Distribution Networks، أو اختصارًا CDNs من خلال إعادة توجيه الطلبات إلى ذاكرة مخبئية cache قريبة.

يمكن أن تحتوي رسائل الاستجابة على سطرٍ واحد أو أكثر من سطور MESSAGE_HEADER كما هو الحال مع رسائل الطلب، حيث تنقل هذه الأسطر معلوماتٍ إضافية إلى العميل. يحدّد سطر ترويسة الموقع Location على سبيل المثال بأن محدّد URL المطلوب متاحٌ في موقع آخر، وبالتالي إذا نُقلت صفحة الويب الخاصة بقسم علوم الحاسوب CS في جامعة برينستون من العنوان

http://www.cs.princeton.edu/index.html

إلى العنوان الآتي:

 http://www.princeton.edu/cs/index.html

على سبيل المثال، فقد يستجيب الخادم صاحب العنوان الأصلي بما يلي:

HTTP/1.1 301 Moved Permanently
Location: http://www.princeton.edu/cs/index.html

ستحمل رسالة الاستجابة أيضًا الصفحة المطلوبة، وهذه الصفحة هي مستند HTML، ولكن قد تحتوي على بياناتٍ غير نصية مثل صورة GIF، لذلك تُشفَّر باستخدام معيار MIME. تعطي بعض أسطر MESSAGE_HEADER سمات محتويات الصفحة بما في ذلك عدد بايتات المحتويات، والسمة Expires للدلالة الوقت الذي تُعَد فيه المحتويات قديمة، ووقت تعديل المحتويات آخر مرةٍ على الخادم.

معرفات الموارد الموحدة Uniform Resource Identifiers

تُعَد محدّدات URL التي يستخدمها بروتوكول HTTP مثل عناوين، نوعًا من معرّفات الموارد الموحَّدة Uniform Resource Identifier أو اختصارًا URI؛ وهي سلسلة أحرف تحدد موردًا، ومن الممكن أن يكون المورد أي شيء له هوية مثل مستندٍ أو صورةٍ أو خدمة.

تسمح صيغة معرّفات URI بأنواعٍ مختلفة أكثر تخصصًا من معرّفات الموارد لتُدمَج ضمن حيّز معرّفات URI. يكون الجزء الأول من معرّف URI واصفًا scheme يسمّي طريقةً معينة لتحديد نوعٍ معين من الموارد، مثل واصف mailto لعناوين البريد الإلكتروني أو واصفfile لأسماء الملفات؛ أما الجزء الثاني من معرّف URI المفصول عن الجزء الأول بنقطتين، فهو الجزء الخاص بالواصِف scheme-specific part، وهو معرّف موردٍ متوافق مع الواصف في الجزء الأول، كما هو الحال في المعرّفَين الآتيين:

• mailto:santa@northpole.org.
• file:///C:/foo.html.

يجب أن يكون المورد غير قابلٍ للاسترداد أو الوصول إليه، فلقد رأينا مثالًا سابقًا تحدِّد فيه معرّفاتُ URI مساحاتِ أسماء لغة التوصيف الموسّعة extensible markup language أو اختصارًا XML، حيث تشبه معرّفات URI كثيرًا محدّدات URL، ولكنها بالمعنى الدقيق للكلمة؛ ليست محدّدات مواقع لأنها لا تخبرك بكيفية تحديد موقع شيء ما؛ حيث توفّر فقط معرّفًا فريدًا عالميًا لمساحة الأسماء.

لا يوجد أي أمرٍ يمكّنك من استرداد شيءٍ من معرّف URI المُعطَى على أنه مساحة أسماء الهدف لمستند XML. سنرى مثالًا آخر لمعرّف URI، ولكنه ليس بمحدّد URL لاحقًا.

اتصالات TCP

أنشأ الإصدار الأصلي رقم 1.0 من بروتوكول HTTP اتصال TCP منفصل لكل عنصر بياناتٍ يُسترَد من الخادم. من السهل أن نرى أن هذه الآلية غير فعالةٍ للغاية، حيث يجب تبادل رسائل إعداد الاتصال ورسائل تفكيكه بين العميل والخادم حتى لو كان كل ما يريده العميل هو التحقق من أن لديه أحدث نسخةٍ من الصفحة، وبالتالي فإن استرداد صفحةٍ تحتوي على بعض النصوص وعشرات الأيقونات أو غيرها من الرسوم البيانية الصغيرة سيؤدي إلى إنشاء 13 اتصال TCP منفصلٍ وإغلاقها.

يوضح الشكل الآتي تسلسل الأحداث لجلب صفحةٍ تحتوي على كائنٍ واحدٍ فقط؛ فتشير الخطوط الملونة إلى رسائل TCP، بينما تشير الخطوط السوداء إلى طلبات واستجابات HTTP، ولا تظهر بعض إشعارات TCP لتجنب ازدحام الصورة. هنا يمكنك أن ترى الحاجة إلى وقتين ذهابًا وإيابًا من أجل إعداد اتصالات TCP، بينما نحتاج إلى وقتين آخرين على الأقل للحصول على الصفحة والصورة. بالإضافة إلى تأثير زمن الاستجابة، هناك أيضًا تكلفةُ المعالجة على الخادم للتعامل مع إنشاء اتصال TCP الإضافي وإنهائه.

لقد قدّم الإصدار رقم 1.1 من بروتوكول HTTP مفهوم الاتصالات الدائمة persistent connections للتغلب على الموقف السابق، حيث يمكن للعميل والخادم تبادل رسائل طلب / استجابة متعددة عبر نفس اتصال TCP.

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

يوضح الشكل التالي المعامَلة من الشكل السابق باستخدام اتصالٍ دائم في الحالة التي يكون فيها الاتصال مفتوحًا، والمُرجَّح أن يكون ذلك بسبب الوصول المُسبَق لنفس الخادم.

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

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

لا يزال الإصدار 1.1 مدعومًا على نطاقٍ واسع، ولكن وافقت منظمة IETF رسميًا على إصدارٍ جديد هو 2.0 في عام 2015. يُعرف الإصدار الجديد باسم HTTP / 2، وهو متوافقٌ مع الإصدار السابق 1.1، حيث يعتمد نفس صياغة حقول الترويسة ورموز الحالة ومعرّفات URI، لكنه يضيف ميزتين جديدتين.

الميزة الأولى هي تقديم التسهيلات لخوادم الويب بتقليل المعلومات التي تُرسَل مرةً أخرى إلى متصفحات الويب، فإذا نظرت عن كثبٍ إلى تركيبة لغة HTML في صفحة ويب نموذجية، فستجد عددًا كبيرًا من الإشارات إلى بتاتٍ وأجزاءٍ أخرى مثل الصور والنصوص وملفات الأنماط التي يحتاجها المتصفح لعرض الصفحة. فبدلًا من إجبار العميل على طلب هذه البتات والأجزاء المعروفة تقنيًا باسم الموارد resources في الطلبات اللاحقة، يوفر الإصدار HTTP / 2 وسيلةً للخادم لتجميع الموارد المطلوبة ودفعها استباقيًا إلى العميل دون تكبد تأخير الرحلة ذهابًا وإيابًا بسبب إجبار العميل على طلبها.

تقترن هذه الميزة بآلية ضغط تقلل من عدد البايتات الواجب دفعها، والهدف منها هو تقليل وقت الاستجابة الذي يواجهه المستخدم النهائي من اللحظة التي ينقر فيها على رابطٍ ترابطي حتى عرض الصفحة بالكامل.

ميزة إصدار HTTP / 2 الثانية هي دمج عدة طلباتٍ على اتصال TCP واحد، وهذا يتجاوز ما يدعمه الإصدار 1.1 الذي يسمح بسلسلةٍ من الطلبات لإعادة استخدام اتصال TCP، من خلال السماح لهذه الطلبات بالتداخل مع بعضها بعضًا. يجب أن تكون الطريقة التي يؤدي بها الإصدار HTTP / 2 هذا الأمر مألوفة؛ حيث تحدّد هذه الطريقة تجريد القناة channel وتسمَّى القنوات تدفقات streams من الناحية التقنية، وتسمح بأن تكون التدفقات المتزامنة المتعددة نشطةً في وقتٍ معين، حيث يُعطى كلٌّ منها معرّف تدفقٍ stream id فريد، وتقيّد هذه الطريقة كل تدفقٍ fاستخدام تبادل طلب / رد نشط واحدٍ في كل مرة.

التخبئة Caching

استراتيجية التطبيق المهمة التي تمكّن الويب من أن يكون أكثر قابليةً للاستخدام هي تخبئة cache صفحات الويب، والتي لها فوائد عديدة، حيث يمكن من وجهة نظر العميل عرض الصفحة التي يمكن استردادها من ذاكرة مخبئية قريبة بسرعةٍ أكبر بكثير مما لو جُلِبت من جميع أنحاء العالم؛ بينما من وجهة نظر الخادم، يؤدي استخدام الذاكرة المخبئية وتلبية الطلب إلى تقليل الحِمل على الخادم.

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

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

يُرجَّح في الحالة التي يدعم الموقع فيها ذاكرةً مخبئية واحدةً على مستوى الموقع أن يعرف المستخدمون داخل الموقع الجهازَ الذي يخزّن الصفحات ضمن ذاكرةٍ مخبئية نيابةً عن الموقع، فيضبطون متصفحاتهم للاتصال مباشرةً بمضيف التخبئة، وتسمَّى هذه العقدة أحيانًا وكيلًا proxy؛ بينما قد لا تدرك المواقع التي تتصل بمزود خدمة الإنترنت أنه يخزّن الصفحات ضمن ذاكرةٍ مخبئية، فتمر طلبات HTTP الصادرة من مواقع مختلفة عبر موجّه ISP مشترك، حيث يمكن لهذا الموجّه إلقاء نظرةٍ خاطفةٍ على رسالة الطلب وعلى محدّد URL للصفحة المطلوبة.

إذا احتوى هذا الموجّه على الصفحة في ذاكرته المخبئية، فسيعيدُها؛ أما إذا لم يكن الأمر كذلك، فسيُمرِّر الطلب إلى الخادم ويراقب الاستجابة في الاتجاه الآخر، وعند حدوث ذلك، سيحفظ الموجّه نسخةً على أمل أن يتمكن من استخدامها لتلبية طلبٍ في المستقبل.

تُعَد القدرة على تخبئة صفحات الويب مهمةً بما يكفي بغض النظر عن مكان تخبئتها، وذلك لأن بروتوكول HTTP قد صُمِّم لتسهيل الأمور. تحتاج الذاكرة المخبئية إلى التأكد من أنها لا تستجيب مع إصدارٍ قديم من الصفحة، حيث يمكن أن يسند الخادم مثلًا تاريخ انتهاء صلاحية في حقل الترويسة Expires لكل صفحةٍ يرسلها مرةً أخرى إلى العميل أو إلى الذاكرة المخبئية بين الخادم والعميل. ستتذكّر الذاكرة المخبئية هذا التاريخ وتعلم أنها لا تحتاج إلى إعادة التحقق من الصفحة في كل مرةٍ تُطلَب إلا بعد مرور تاريخ انتهاء الصلاحية.

يمكن للذاكرة المخبئية بعد ذلك الوقت أو إذا لم يُضبَط حقل الترويسة Expires استخدامَ عملية HEAD أو عملية GET الشرطية، أي عملية GET مع سطر ترويسة للتحقق من أن لديها أحدث نسخةٍ من الصفحة.

هناك مجموعةٌ من توجيهات الذاكرة المخبئية cache directives التي يجب أن تلتزم بها جميع آليات التخبئة على طول سلسلة الطلب / الاستجابة، حيث تحدّد هذه التوجيهات ما إذا كان يمكن تخبئة المستند أم لا، ومدة تخبئته، ومدى حداثة المستند وغير ذلك. وسنلقي نظرةً على المشكلة ذات الصلة بشبكات CDN الموزَّعة بصورةٍ فعالة في قسمٍ لاحق.

ترجمة -وبتصرّف- للقسم Traditional Applications من فصل Applications من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• الخدمات المميزة لتطبيق جودة الخدمة ضمن الشبكات الحاسوبية
• بيانات شبكات طرف إلى طرف الحاسوبية
• أمثلة عن أنظمة أمن الشبكات الحاسوبية