تُدخَل أحيانًا أخطاء البت في الإطارات، ويحدث هذا على سبيل المثال بسبب التداخل الكهربائي (electrical interference) أو التّشويش الحراري (thermal noise)، وعلى الرّغم من ندرة الأخطاء خاصًّة على الروابط الضوئيّة، إلا أنّ هناك حاجة إلى بعض الآليات لاكتشاف هذه الأخطاء، وذلك من أجل اتخاذ الإجراءات الصحيحة، بينما يُترك المستخدم النهائي بخلاف ذلك يتساءل عن سبب ظهور خطأ صياغي (syntax error) فجأةً في برنامج مكتوب بلغة C يكون قد صُرِّف بنجاح منذ لحظة واحدة فقط، رغم أنّ كلّ ما حدث في غضون ذلك هو نسخه عبر نظام ملفّات الشبكة.

هناك تاريخ طويل من تقنيّات التعامل مع أخطاء البت في أنظمة الحاسوب، حيث يعود تاريخه إلى الأربعينات على الأقل، وتُعَد شيفرات هامينغ (Hamming) وريد-سولومون (Reed-Solomon) مثالين بارزين طُوِّرا للاستخدام في قارئات البطاقات المُثقَّبة (punch card readers) عند تخزين البيانات على أقراص مغناطيسيّة (magnetic disks) وفي الذواكر الأساسيّة القديمة، حيث يشرح هذا القسم بعض تقنيّات اكتشاف الأخطاء الأكثر استخدامًا في الشبكات.

يُعدّ اكتشاف الأخطاء جزءًا من المشكلة فقط، والجزء الآخر هو تصحيح الأخطاء بمجرد اكتشافها، ويمكن اتّباع طريقتين أساسيّتين عندما يكتشف مستلم الرسالة خطأً، والطريقة الأولى هي إبلاغ المرسل بأن الرسالة تالفة حتّى يتمكّن المرسل من إعادة إرسال نسخة من الرسالة، وبالتالي إذا كانت أخطاء البت ناذرة، فمن المحتمل أن تكون النسخة المعاد إرسالها خاليةً من الأخطاء؛ أمّا الطريقة الثانية، فتتمثّل في سماح بعض أنواع خوارزميّات اكتشاف الأخطاء للمستلم بإعادة بناء الرسالة الصحيحة حتّى بعد تلفها، حيث تعتمد مثل هذه الخوارزميات على شيفرات تصحيح الأخطاء (error-correcting codes) الموضّحة أدناه. وواحدة من أكثر التقنيّات شيوعًا لاكتشاف أخطاء الإرسال هي تقنيّة تُعرف باسم فحص التّكرار الدوري (cyclic redundancy check ويختصر إلى CRC)، والتي تُستخدم في جميع بروتوكولات مستوى الربط التي ستناقَش في هذا المقال تقريبًا، حيث سيوضّح هذا القسم خوارزميّة CRC الأساسيّة، ولكنّه سيشرح أوّلًا مخطّط المجموع الاختباري (checksum) الأبسط الذي تستخدمه العديد من بروتوكولات الإنترنت.

الفكرة الأساسيّة وراء أيّ مخطّط اكتشاف أخطاء هي إضافة معلومات زائدة إلى إطار، بحيث يمكن استخدامها لتحديد فيما إذا كانت الأخطاء قد أُدخلت أم لا، ويمكنك تخيّل إرسال نسختين كاملتين من البيانات في أسوأ الأحوال، فإذا كانت النسختان متطابقتين في المستقبل، فمن المحتمل أن تكون كلتا النسختين صحيحتين، وإذا اختلفتا، فقد أُدخِل خطأٌ في إحدى النسختين (أو كلتيهما) وبالتالي يجب إهمالها، لكن هذا يُعدّ مخطّطًا سيّئًا إلى حدّ ما لاكتشاف الأخطاء وذلك لسببين، أوّلهما إرسال هذا المخطّط n بت زائدة (redundant) لرسالة بحجم n بت، وثانيهما عدم اكتشاف العديد من الأخطاء مثل أيّ خطأٍ يحدث لإتلاف مواضع البت نفسها في النسختين الأولى والثانية من الرسالة، ولكن هدف شيفرات اكتشاف الأخطاء هو توفير احتمال كبير لاكتشاف الأخطاء مع عدد قليل نسبيًّا من البتّات الزائدة (redundant bits)، ولحسن الحظ يمكن القيام بأفضل بكثير من هذا المخطط البسيط، حيث يمكن توفير قدرة قويّة جدًّا لاكتشاف الأخطاء مع إرسال k بتّ زائدة فقط لرسالة بحجم n بت، حيث k أصغر بكثير من n، ففي شبكة إيثرنت على سبيل المثال لا يتطلّب الإطار الذي يحمل ما يصل إلى 12000 بتًّا (1500 بايت) من البيانات سوى شيفرة CRC مؤلّفة من 32 بتًا، أو كما يُعبَّرعنها CRC-32، حيث ستلتقط مثل هذه الشيفرة الغالبيّة العظمى من الأخطاء كما سترى لاحقًا.

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

توجد ملاحظةٌ واحدة حول المصطلحات الخاصّة بهذه البتات الإضافيّة، حيث يشار إليها باسم شيفرات اكتشاف الأخطاء، وقد يطلق عليها في حالات محدّدة، عندما تعتمد الخوارزميّة على الجمع (addition) لإنشاء الشيفرة مثلًا، اسم المجموع الاختباري (checksum)، حيث سترى أنّ المجموع الاختباري للإنترنت قد سُمي بطريقة مناسبة، فهو فحص خطأ يستخدم خوارزميّة جمع، ولكن لسوء الحظ تُستخدَم غالبًا كلمة المجموع الاختباري بصورة غير دقيقة للإشارة إلى أي نوع من أنواع شيفرة اكتشاف الأخطاء بما في ذلك شيفرات CRC، وبالتالي قد يكون هذا محيّرًا، لذلك يمكنك استخدام المجموع الاختباري للتطبيق على الشيفرات التي تستخدم الجمع بالفعل، ويمكنك استخدام شيفرة اكتشاف الأخطاء للإشارة إلى صنف الشيفرات العامّة الموضّحة في هذا القسم.

خوارزمية مجموع الإنترنت الاختباري (Internet Checksum Algorithm)

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

يمكنك تخيّل العديد من الاختلافات حول فكرة المجموع الاختباري الأساسيّة، ويعمل المخطط الذي تستخدمه بروتوكولات الإنترنت على النحو التالي: افترض أنّ البيانات التي سيطبّق عليها المجموع الاختباري هي سلسلة من الأعداد الصحيحة المؤلفة من 16 بتًا، ثم اجمعهم معًا باستخدام متمّم الواحد (ones’ complement) ذو 16 بت (الموضح أدناه)، ثم خذ متمّم الواحد للنتيجة، فهذا الرقم المؤلّف من 16 بتًا هو المجموع الاختباري، حيث يُمثَّل العدد الصحيح السالب -x باستخدام متمّم الواحد كمتمم للعدد x، أي يُقلَب كل بت من x، ويجب إضافة حِمل من البت الأكثر أهميّةً إلى النتيجة عند جمع الأعداد باستخدام مُتمّم الواحد. افترض على سبيل المثال جمع العددين -5 و -3 باستخدام مُتمّم الواحد على أعداد صحيحة مؤلّفة من 4 بتات: +5هي 0101 لذا -5 هي 1010، و +3 هي 0011 لذا -3 يساوي 1100. إذا جمعت العددين 1010، و1100، مع تجاهل الحمل، ستحصل على 0110. لكن بسبب حقيقة أنّ هذه العمليّة تسببت في حمل من البت الأكثر أهميّة باستخدام متمّم الواحد لذلك يجب زيادة النتيجة، قتصبح 0111، وهو تمثيل متمّم الواحد للعدد -8 الذي تحصل عليه من خلال قلب بتات العدد 1000.

تعطي الشيفرة الآتية تطبيقًا مباشرًا لخوارزمية مجموع الإنترنت الاختباري، ويعطي الوسيط count طول المتغيّر buf المُقاس بطول 16 بت، حيث تفترض الشيفرة أنّ المتغيّر buf محشوٌّ أصفارًا إلى حد 16 بت:

u_short
cksum(u_short *buf, int count)
{
    register u_long sum = 0;

    while (count--)
    {
            sum += *buf++;
            if (sum & 0xFFFF0000)
            {
                    /* ظهر حِمل في البت الأعلى أهميةً، لذلك أضف واحدًا إلى المجموع */
                    sum &= 0xFFFF;
                    sum++;
            }
    }
    return ~(sum & 0xFFFF);
}

تضمن الشيفرة السابقة استخدام العمليّة الحسابيّة لمتمّم الواحد بدلًا من المتمّم الثنائي المستخدم في معظم الأجهزة، ويمكنك ملاحظة استخدام عبارة if داخل حلقة while، وإذا وُجِد حِمل في البت الأعلى من 16 بت في المتغيّر sum الذي يُمثّل المجموع، فيجب زيادة المجموع كما في المثال المذكور سابقًا، وتحقق خوارزمية المجموع الاختباري نتائجًا جيّدةً عند استخدام عددٍ قليل من البتّات الزائدة، 16 بتًا فقط لأية رسالةٍ ذات أيّ طول، ولكنها لا تحقق نتائجًا جيدة للغاية بالنسبة لاكتشاف الأخطاء الأقوى، إذ لن يُكتشَف على سبيل المثال زوجٌ من الأخطاء أحاديّة البت، أحدهما يزيد كلمةً والآخر ينقص كلمةً أخرى بنفس المقدار، ويعود سبب استخدام مثل هذه الخوارزميّة رغم كون حمايتها ضعيفةً نسبيًّا ضدّ الأخطاء (مقارنةً بخوارزميّة CRC على سبيل المثال)، هو أنها خوارزميّة بسيطة، فهذه الخوارزميّة تُعدّ أسهل بكثير في التطبيق ضمن البرمجيّات، وقد أشارت التجربة إلى أنّ المجموع الاختباري (checksum) لهذا النموذج مناسب، ولكن أحد أسباب عدّه مناسبًا يعود لكون المجموع الاختباري بمثابة خطّ الدفاع الأخير في بروتوكول نقطة لنقطة، حيث تلتقط خوارزميّاتٍ أقوى لاكتشاف الأخطاء، مثل خوارزمية CRC، باكتشافها لغالبيّة الأخطاء على مستوى الروابط.

فحص التكرار الدوري (Cyclic Redundancy Check أو اختصارًا CRC)

يجب أن يكون واضحًا الآن أن الهدف الرئيسي في تصميم خوارزميات اكتشاف الأخطاء هو تكبير احتمالية اكتشاف الأخطاء إلى الحدّ الأقصى باستخدام عدد صغير فقط من البتّات الزائدة، حيث تُستخدم خوارزميّة فحص التكرار الدوري بعض الحسابات القويّة إلى حدّ ما لتحقيق هذا الهدف، وتوفّر خوارزميّة CRC ذات 32 بتًا على سبيل المثال حمايةً قويّةً ضدّ أخطاء البت الشائعة الموجودة في الرسائل التي يبلغ طولها آلاف البايتات. الأساس النظري لهذه الخوارزمية مُتجذّر في فرعٍ من فروع الرياضيات يسمّى الحقول المحدودة (finite fields). قد يبدو هذا صعبًا، ولكن يمكن فهم الأفكار الأساسيّة بسهولة، ابدأ بافتراض أن رسالةً مؤلّفةً من (n + 1) بت ممثّلةٌ بواسطة كثير حدود (polynomial) من الدّرجة n، أي كثير الحدود الذي حدّه الأعلى رتبةً هو xⁿ. تُمثَّل الرسالة بواسطة كثير حدود باستخدام قيمة كلّ بت في الرسالة كمعاملٍ لكلّ حدٍ من كثير الحدود، بدءًا من البت الأعلى أهميّةً لتمثيل الحدّ الأعلى رتبةً، حيث تتكوّن رسالةٌ مؤلّفة من 8 بتات، وهي البتات 10011010 على سبيل المثال التي تتوافق مع كثير الحدود التالي:

بالتالي يمكن التفكير في المرسل والمستقبل على أنهما يتبادلان كثيرات الحدود مع بعضهما البعض. يجب على المرسل والمستقبل الاتفاق على كثير الحدود القاسم (divisor polynomial) الذي يُرمز له C (x) لحساب CRC، حيث C (x) هو كثير حدود من الدرجة k. افترض أن C (x) = x³ + x² + 1 على سبيل المثال، حيث k = 3 في هذه الحالة؛ أمّا الإجابة على السؤال (من أين أتى كثير الحدود C (x)؟) هي (ابحث عنه في السلسلة)، فإن اختياره له تأثير كبير على أنواع الأخطاء التي يمكن اكتشافها بطريقة موثوقة. هناك عدد قليل من كثيرات الحدود القاسمة التي تُعد اختيارات جيدة جدًا لبيئات مختلفة، ويُضاف ذلك الاختيار الدقيق كجزءٍ من تصميم البروتوكول، كما يستخدم معيار إيثرنت على سبيل المثال كثير الحدود المعروف ذو الدرجة 32.

إذا أراد المرسل إرسال رسالة M (x) بطول n + 1 بت، فما يُرسَل بالفعل هو الرسالة التي طولها (n + 1) بت بالإضافة إلى k بت. وتدعى الرسالة المرسلة بالكامل بما في ذلك البتات الزائدة P (x). يجب جعل كثير الحدود الذي يمثّل P (x) قابلًا للقسمة تمامًا على C (x)، فإذا أُرسل P (x) عبر رابط دون حدوث أخطاء أثناء الإرسال، فيجب أن يكون المستقبل قادرًا على قسمة P (x)على C (x) تمامًا بلا باقٍ. ومن ناحية أخرى، إذا حدث خطأٌ ما في P (x) أثناء الإرسال، فلن يقبل كثير الحدود المستقبل القسمة تمامًا علىC (x)، وبالتالي سيحصل المستقبل على باقٍ غير صفريّ مما يعني حدوث خطأ.

سيساعدك فهم ما يلي إذا كنت تعرف القليل عن حساب كثيرات الحدود، فهو يختلف قليلًا عن حساب الأعداد الصحيحة العاديّة، حيث ستتعامل هنا مع صنفٍ خاصّ من حساب كثيرات الحدود، فقد تكون المعامِلات (coefficients) واحدًا أو صفرًا فقط، وتُجرى العمليّات على المعاملات باستخدام نظام الحساب modulo 2، الذي يُشار إليه باسم نظام حساب modulo 2 لكثير الحدود. لكن نظرًا لأن هذه السلسلة عن الشبكات، وليست عن الرياضيات، فيجب التركيز فقط على الخصائص الرئيسيّة لهذا النوع من الحساب (والتي نطلب منك قبولها بناءً على الثّقة):

• يمكن تقسيم أيّ كثير حدود B (x) على كثير الحدود القاسم C (x) إذا كان B (x) من درجة أعلى من C (x).
• يمكن تقسيم أيّ كثير حدود B (x) مرةً واحدة بواسطة كثير الحدود القاسم C (x) إذا كان B (x) من نفس درجة C (x).
• ينتج باقي قسمة B (x) على C (x) من خلال إجراء عمليّة XOR على كلّ زوج من المعاملات المتطابقة.

يمكن قسمة كثير الحدود x³ + 1 مثلًا على كثير الحدود x³ + x² + 1 (لأنّ كليهما من الدرجة 3) والباقي هو ‎0×x³+1×x²+0×x¹+0×x⁰=x² (الذي نتج عن طريق إجراء عملية XOR على معاملات كل حد)، وبالتالي يمكن القول أنهّ يمكن قسمة 1001 على 1101 مع باقٍ هو 0100 (يجب أن تكون قادرًا الآن على رؤية أن الباقي هو مجرد تطبيق لعمليّة XOR ثنائيّة على الرسالتين)، وبعد أن عرفت القواعد الأساسيّة لتقسيم كثيرات الحدود، يمكنك إجراء قسمة طويلة، وهو أمر ضروري للتعامل مع الرسائل الأطول.

تذكر أنك تريد إنشاء كثير حدود للإرسال مشتق من الرسالة الأصلية M (x)، فهل k بت أطول من M (x)، وهل M (x) قابلة للقسمة تمامًا على C (x)؟ يمكنك القيام بذلك بالطريقة التالية:

1. اضرب M (x) بـ x^k وهذا يعني إضافة k صفرًا في نهاية الرسالة. ادعُ هذه الرسالة الصفرية الموسعة T (x).
2. اقسم T (x) على C (x) وجِد الباقي.
3. اطرح الباقي من T (x).

يجب أن يكون واضحًا أن ما تبقّى في هذه المرحلة هو رسالة قابلة للقسمة تمامًا على C (x)، وقد تلاحظ أيضًا أنّ الرسالة الناتجة تتكوّن من M (x) متبوعةً بالباقي الناتج عن الخطوة 2، فعند طرح الباقي (والذي لا يمكن أن يزيد طوله عن k بت)، فكأنّك أجريت عمليّة XOR فقط للباقي مع k صفرًا التي أُضيفت في الخطوة 1، وسيصبح هذا الجزء أوضح بمثال:

افترِض أنّ الرسالة هي x⁷ + x⁴ + x³ + x¹ أو 10011010. ابدأ بالضرب بـ x³، فكثير الحدود القاسم هو من الدرجة 3، وهذا يعطي 10011010000، ثمّ اقسم النتيجة السابقة على C (x) الذي يقابل 1101 في هذه الحالة. يوضح الشكل الآتي عمليّة قسمة كثير حدود طويلة، وبالنظر إلى قواعد حساب كثيرات الحدود الموصوفة سابقًا، تستمر عمليّة القسمة الطويلة كما لو كنت تقسم الأعداد الصحيحة، وهكذا ترى في الخطوة الأولى من المثال أنّ المقسوم عليه 1101 يُقسم عليه مرّةً واحدةً أوّل أربعة بتات من الرسالة (1001)، نظرًا لأنهما من نفس الدرجة، والباقي هو 100، أو (1101 XOR 1001). تتمثّل الخطوة التالية في إنزال رقم من كثير حدود الرسالة لتحصل على كثير حدود آخر بنفس درجة C (x)، وفي هذه الحالة هو 1001، ثمّ تحسب الباقي مرّةً أخرى وهو (100) وتستمر حتّى اكتمال الحساب. لاحظ أنّ نتيجة القسمة الطويلة (long division)، التي تظهر في الجزء العلويّ من الحساب، ليست ذات أهميّة كبيرة حقيقةً، وإنّما الباقي (remainder) في النهاية هو المهم.

يمكنك الرّؤية في أسفل الشّكل الآتي أنّ باقي القسمة هو 101، لذلك ستعلم أنّ 10011010000 ناقص 101 سيكون قابلًا للقسمة تمامًا على C (x)، وهذا الذي سيُرسَل. عمليّة الطرح في حساب كثير الحدود هي عمليّة XOR منطقية، لذلك ما يُرسَل فعليًّا هو 10011010101، والذي هو عبارة عن الرسالة الأصلية فقط ملحوقًا بها باقي حساب القسمة الطويلة. يقسم المستقبل كثير الحدود المستلَم على C (x)، وإذا كانت النتيجة 0، فسيستنتج عدم وجود أخطاء؛ أمّا إذا كانت النتيجة غير صفريّة، فقد يكون من الضروري تجاهل الرسالة التالفة، ولكن قد يكون من الممكن تصحيح خطأٍ صغير مع وجود بعض الشيفرات (إذا أثر الخطأ على بت واحد فقط على سبيل المثال). يُطلق على الشيفرة التي تفعّل تصحيح الخطأ شيفرة تصحيح الخطأ (error-correcting code أو اختصارًا ECC).

ولكن من أين أتى كثير الحدود C (x)؟ تكمن الفكرة في اختيار كثير الحدود هذا، بحيث لا يمكن تقسيم رسالة بها أخطاء عليه، فإذا كانت الرسالة المرسلة هي P (x)، فيمكن افتراض أنّ إدخال الأخطاء هو عبارة عن إضافة كثير حدود آخر هو E (x)، لذلك يرى المستقبل P (x) + E (x). الطريقة الوحيدة التي قد يمرّ بها الخطأ دون اكتشافه هي إذا كان من الممكن تقسيم الرّسالة المستلمة على C (x)، وبما أنك تعلم أن P (x) يمكن تقسيمها على C (x)، فقد يحدث هذا فقط إذا أمكن قسمة E (x) على C (x) أيضًا، ولكن الحل هو اختيار C (x) بحيث يكون غير محتملٍ جدًا بالنسبة لأنواع الأخطاء الشائعة، فمن بين أنواع الأخطاء الشائعة هو الخطأ أحادي البت (single-bit error)، والذي يمكن التعبير عنه بـ E (x) = xⁱ عندما يؤثّر على موضع البت i إذا اخترت كثير الحدود ،C (x) بحيث يكون الحدّ الأوّل والأخير (أي الحدان x^k و x⁰) غير صفريّين، فعندئذ يكون لديك بالفعل حدَّا كثير حدود لا يمكن تقسيمهما على حدٍّ واحد E (x)، وبالتالي يستطيع C (x) اكتشاف جميع الأخطاء أحادية البت. من الممكن إثبات أن الأنواع التالية من الأخطاء يمكن اكتشافها بواسطة كثير الحدود C (x):

• جميع الأخطاء أحادية البت (single-bit errors)، طالما أنّ الحدين x^k وx⁰ لهما معاملات غير صفريّة.
• جميع أخطاء البت المضاعفة (double-bit errors)، طالما أنّ كثير الحدود C (x) له معامل بثلاثة حدود على الأقلّ.
• أيّ عدد فردي من الأخطاء (odd number of errors)، طالما يتضمّن كثير الحدود C (x) المعامل (x + 1).

من الممكن استخدام الشيفرات التي لا تكتشف وجود الأخطاء فحسب، بل تتيح أيضًا تصحيح الأخطاء، ولن نتناول تفاصيل هذه الشيفرات هنا نظرًا لأنها تتطلّب رياضيات أعقد من تلك المطلوبة لفهم خوارزميّة CRC، ومع ذلك يجب معرفة مزايا تصحيح الأخطاء مقابل اكتشافها، فقد يبدو تصحيح (correction) الأخطاء للوهلة الأولى أفضل دائمًا من اكتشافها (detection)، لأنه يجب التخلّص من الرسالة عند اكتشاف الأخطاء، ثمّ طلب إرسال نسخةٍ أخرى، وبالتالي يُستهلك حيّز النطاق التراسلي وقد يؤدّي إلى التأخير أثناء انتظار إعادة الإرسال، لكن هناك جانب سلبي للتصحيح، إذ يتطلّب عمومًا عددًا أكبر من البتّات الزائدة لإرسال شيفرة تصحيح أخطاء قويّة (أي قادرة على التعامل مع نفس نطاق الأخطاء) مثل الشيفرة التي تكتشف أخطاءً فقط، وبالتالي بينما يتطلّب اكتشاف الخطأ إرسال مزيدٍ من البتّات عند حدوث أخطاء، فيتطلّب تصحيح الخطأ إرسال مزيدٍ من البتات طوال الوقت، لذلك يميل تصحيح الخطأ إلى أن يكون ذو فائدة أكبر عندما: (1) تكون الأخطاء محتملةً تمامًا، مثل البيئة اللّاسلكية على سبيل المثال، أو (2) تكلفة إعادة الإرسال مرتفعة للغاية، بسبب احتواء التأخير إعادة إرسال رزمة عبر رابط فضائي على سبيل المثال.

يُشار أحيانًا إلى استخدام شيفرات تصحيح الأخطاء في الشبكات باسم تصحيح الأخطاء الأمامي (forward error correction أو اختصارًا FEC)، لأن تصحيح الأخطاء يُعالَج مسبقًا عن طريق إرسال معلومات إضافية، بدلًا من انتظار حدوث الأخطاء والتعامل معها لاحقًا عن طريق إعادة الإرسال، حيث يشيع استخدام آلية FEC في الشبكات اللاسلكية، مثل: 802.11. أي رشقة (burst) أخطاء (أي سلسلة بتات خاطئة متعاقبة) يكون طول الرشقة فيها أقل من k بت (معظم أخطاء الرشقات ذات طول أكبر من k يمكن أيضًا اكتشافها).

تُستخدم ستّة إصدارات من كثير الحدود C (x)على نطاق واسع في بروتوكولات مستوى الرابط، حيث يستخدم الإيثرنت آليّة CRC-32 على سبيل المثال، والذي يُعرَّف على النحو التالي:

لاحظ أخيرًا أنّ خوارزميّة CRC، رغم أنّها تبدو معقدة، ولكنها تُطبَّق بسهولة في العتاد باستخدام مسجّل إزاحة بحجم k بت وبوّابات XOR، فعدد البتات في مسجل الإزاحة يساوي درجة كثير الحدود المولد (k)، ويوضح الشّكل الآتي العتاد الذي سيستخدمه المولّد x³ + x² + 1 من المثال السابق. حيث تُزاح الرسالة من اليسار بدءًا من البت الأكثر أهميّة وتنتهي بسلسلة k صفرًا المرفقة بالرسالة، فكما في مثال القسمة الطويلة إذا أُزيحت جميع البتّات وطُبِّق عليها XOR بطريقة مناسبة، فسيحتوي المسجّل على الباقي، وهذه هي خوارزميّة CRC (البت الأعلى أهميّةً على اليمين). يُحدَّد موضع بوابات XOR على النحو التالي: إذا سُميَّت البتات في مسجل الإزاحة من 0 إلى k − 1 من اليسار إلى اليمين، فضع بوّابة XOR أمام البت n إذا كان هناك حد xⁿ في كثير الحدود المولّد، وبالتالي ترى بوابة XOR أمام الموضعين 0 و2 للمولد x³ + x² + x⁰.

ترجمة -وبتصرّف- للقسم Error Detection من فصل Direct Links من كتاب Computer Networks: A Systems Approach

التشفير (Encoding)

تتمثّل الخطوة الأولى في تحويل العُقد (nodes) والرّوابط (links) إلى لبنات أساسيّة قابلة للاستخدام من خلال فهم كيفيّة توصيلها بطريقة يمكن بها نقل البتّات من عقدة إلى أخرى، حيث تنتشر الإشارات عبر الرّوابط الفيزيائية، وتُشفَّر البيانات الثنائية التي تريد العقدة المصدر إرسالها إلى إشارات تستطيع الرّوابط حملها، ثم يُفكّ تشفير الإشارة مرّةً أخرى إلى البيانات الثّنائية المقابلة في العقدة المستقبلّة، يمكن تجاهل تفاصيل التّعديل (modulation) وافتراض أنّك تعمل مع إشارتين منفصلتين: مرتفعة ومنخفضة، ولكن قد تتوافق هذه الإشارات من الناّحية العمليّة مع جهدين (voltages) مختلفين على رابط نحاسي، أو مستويين مختلفين من القدرة (power) على رابط ضوئيّ، أو سعتين (amplitudes) مختلفتين على الإرسال الراديوي، وتُنفَّذ معظم الوظائف الموجودة في هذا المقال بواسطة محوّل الشّبكة (network adaptor) الذي هو عبارة عن قطعة عتاد تصل بين عقدةٍ ورابط، ويحتوي محوّل الشّبكة على مكوّن إشارة (signalling component) يشفّر فعليًّا البتّات إلى إشارات عند عقدة الإرسال ويفكّ تشفير الإشارات إلى بتات في عقدة الاستقبال، حيث تنتقل الإشارات عبر رابط بين مكوّنَي الإشارة، وتتدفّق البتات بين محوّلات الشّبكة (network adaptors) كما هو موضّح في الشّكل التّالي:

بالعودة إلى مشكلة تشفير البتات إلى إشارات، فالشيء الواضح الذي يجب فعله هو ربط القيمة 1 بالإشارة المرتفعة (high signal) والقيمة 0 بالإشارة المنخفضة (low signal)، وهذا هو بالضّبط ما يستخدمه مخطّط تشفير (encoding scheme) مشفَّرٌ بدرجة كافية يدعى عدم العودة إلى الصّفر (non-return to zero ويختصر إلى NRZ)، ويوضّح الشّكل التّالي على سبيل المثال بيانيًّا إشارة NRZ المشفَّرة (في أسفل الشّكل) التي تقابل إرسال سلسلة محدّدة من البتات (في أعلى الشّكل):

تكمن مشكلة ترميز NRZ بوجود سلسلة واحدات متعاقبة والتي تعني بقاء الإشارة مرتفعة على الرّابط لمدّة طويلة من الزّمن، وبالمثل يشير وجود عدّة أصفار متعاقبة إلى بقاء الإشارة منخفضةً لمدّة طويلة. توجد مشكلتان أساسيّتان تسبّبهما سلاسل الواحدات أو الأصفار الطّويلة، حيث تؤدّي المشكلة الأولى إلى حالةٍ تدعى التجوّل الأساسي (baseline wander)، حيث يحتفظ المستقبِل على وجه التّحديد بمتوسّط الإشارة التي شاهدها حتى الآن، ثمّ يستخدم هذا المتوسّط للتّمييز بين الإشارات المنخفضة والمرتفعة، فيستنتج المستقبِل أنه قد رأى صفرًا للتّو عندما تكون الإشارة أقلّ بكثير من هذا المتوسط، وبالمثل تُفسَّر الإشارة التي تكون أعلى بكثير من المتوسّط على أنّها 1. تكمن المشكلة بالطبع في أن عددًا كبيرًا جدًا من الواحدات أو الأصفار المتعاقبة يتسبّب في تغيير هذا المتوسّط، مما يجعل اكتشاف تغيير كبير في الإشارة أمرًا صعبًا.

تتمثل المشكلة الثّانية في أنّ التّحولات المتكرّرة من الأعلى إلى الأسفل والعكس ضروريّة لتفعيل استعادة السّاعة (clock recovery)، فتتمثل مشكلة استعادة الساّعة في أن كلًا من عمليات التّشفير وفكّ التّشفير مُساقة بواسطة ساعة، حيث يرسل المرسل بتًا ويستقبل المستقبل بتًا في كل دورة ساعة. يجب أن تكون ساعات المرسل والمستقبل متزامنة بدقّة من أجل استعادة المستقبل لنفس البتات التي يرسلها المرسل، فإذا كانت ساعة المستقبل أسرع أو أبطأ قليلًا من ساعة المرسل، فلن يستطيع فكّ تشفير الإشارة بصورة صحيحة. يمكنك تخيل إرسال السّاعة إلى المستقبل عبر سلك منفصل، ولكن يجب تجنب ذلك إذ سيزيد من تكلفة توصيل الكابلات مرّتين، لذلك بدلًا من ذلك يستخرج المستقبل السّاعة من الإشارة المستقبلة حيث تدعى هذه العمليّة بعمليّة استعادة السّاعة، حيث يعرف المستقبل أنّه على حدود دورة ساعة عندما تتغيّر الإشارة كما هو الحال عند الانتقال من القيمة 1 إلى القيمة 0 أو من القيمة 0 إلى القيمة 1، وبالتالي يستطيع المستقبل إعادة مزامنة نفسه، ومع ذلك يؤدّي مرور فترة طويلة من الزّمن دون حدوث مثل هذا الانتقال إلى انجراف السّاعة (clock drift)، وبالتالي تعتمد استعادة السّاعة على وجود الكثير من الانتقالات في الإشارة بغضّ النّظر عن البيانات التي تُرسَل.

تجعل إحدى الطّرق التي تعالج هذه المشكلة المرسل ينتقل من الإشارة الحاليّة من أجل تشفير القيمة ،1 ويبقى عند الإشارة الحاليّة من أجل تشفير القيمة 0، وتدعى هذه الطّريقة عدم العودة إلى الصفر المعكوس (non-return to zero inverted ويُختصر إلى NRZI)، حيث تحلّ هذه الطّريقة مشكلة الواحدات المتعاقبة، ولكن من الواضح أنّها لا تفعل شيئًا بالنسبة للأصفار المتعاقبة، ويوضّح الشّكل التّالي ترميز NRZI. يوجد بديل يدعى ترميز مانشستر (Manchester encoding) الذي يقوم بأمرٍ أوضح لدمج السّاعة مع الإشارة خلال إرسال عمليّة "أو" المقصورة (exclusive OR أو اختصارًا XOR) لبيانات NRZ المشفَّرة والساعة.

يمكنك التّفكير بالسّاعة المحليّة كإشارة داخليّة تتناوب من المنخفض إلى المرتفع، حيث يُعدّ الزّوجُ (منخفض / مرتفع) دورةَ ساعةٍ واحدة. ويوضح الشّكل الآتي ترميز مانشستر أيضًا، حيث يُرمَّز ترميز مانشستر الذي ينتج عنه القيمة 0 على أنّه انتقالٌ من منخفض إلى مرتفع ويُرمَّز ترميز مانشستر الذي ينتج عنه القيمة 1 على أنّه انتقال من مرتفع إلى منخفض، ويمكن استعادة السّاعة بفعاليّة في المستقبل لأن كلًّا من القيمتين 0 و1 يسبّبان الانتقال إلى الإشارة. ويوجد أيضًا ترميز مغاير عن ترميز مانشستر، يُسمى تفاضل مانشستر (Differential Manchester)، حيث تساوي القيمةُ 1 المُشفَّرة مع النّصف الأوّل من الإشارة النصفَ الأخير من إشارة البت السابق، وتعاكس القيمةُ 0 المُشفَّرة مع النصف الأوّل من الإشارة النصفَ الأخير من إشارة البت السابق.

تكمن مشكلة مخطّط ترميز مانشستر في أنّه يضاعف معدّل انتقالات الإشارة على الرابط، مما يعني أنّه لدى المستقبل نصف الوقت لاكتشاف كلّ نبضة إشارة، ويُطلق على المعدّل الذي تتغيّر به الإشارة بمعدل الباود (baud rate) للرابط، ويكون معدّل البت في حالة ترميز مانشستر نصف معدّل الباود، لذلك يُعَد الترميز فعّالًا بنسبة 50% فقط. ضع في حساباتك أنه إذا كان المستقبل قادرًا على مواكبة معدّل الباود الأسرع الذي يتطلّبه ترميز مانشستر في الشّكل السابق، فيمكن لكلّ من ترميزَي NRZ وNRZI إرسال ضعف عدد البتّات في نفس الفترة الزمنيّة.

لاحظ أنه ليس بالضرورة أن يكون معدل البت أقل من معدّل الباود أو يساويه كما يوحي ترميز مانشستر، فإذا كان مخطّط التعديل قادرًا على استخدام (والتعرف على) أربع إشارات مختلفة بدلًا من اثنتين فقط (مرتفعة ومنخفضة على سبيل المثال)، فمن الممكن تشفير بتّين في كلّ فترة ساعة، مما ينتج عنه معدّل بت يعادل ضعف معدّل الباود. تعني القدرة على التعدّيل بين ثماني إشارات مختلفة القدرةَ على إرسال ثلاثة بتات لكلّ فترة ساعة، ومن المهمّ وضعك في بالك لوجود تعديلٍ مبسّط بإفراط، وهو أعقد من إرسال إشارات مرتفعة ومنخفضة، فمن المألوف تغيير مجموعة أطوار وسعات إشارة، مما يؤدي إلى تشفير 16 أو حتى 64 نمطًا مختلفًا، غالبًا رموز مظلمة (dalled symbols)، خلال كلّ فاصل زمنيّ على مدار السّاعة، حيث تعديل سعة التربيع (Quadrature Amplitude Modulation ويختصر إلى QAM) هو مثال مستخدم على نطاق واسع لمخطط التعديل هذا.

يحاول التّرميز النهائي المسمّى 4B / 5B، معالجة عدم كفاءة ترميز مانشستر دون المعاناة من مشكلة تمديد فترات الإشارات المرتفعة أو المنخفضة، وتتمثّل فكرة ترميز 4B / 5B في إدخال بتات إضافية إلى مجرى البتات لتفكيك سلاسل طويلة من الأصفار أو الواحدات، وتُشفَّر كل 4 بتات من البيانات الفعليّة في شيفرة مكوّنة من 5 بتات تُرسَل بعد ذلك إلى المستقبل، حيث جاء الاسم 4B / 5B من ذلك. تُحدَّد الشيفرات المكونة من 5 بتات بحيث لا يحتوي كلّ منها على أكثر من صفرٍ واحد في بدايتها ولا يزيد عن صفرين في النهاية، وبالتالي لا ينتج عن أيّ زوج من الشيفرات ذات 5 بتات إرسال أكثر من ثلاثة أصفار متعاقبة وذلك عند الإرسال بالتّتالي، ثم تُرسَل الشيفرات ذات الـ 5 بتات الناتجة باستخدام ترميز NRZI، وهذا ما يفسّر سبب اهتمام الشيفرة بالأصفار المتعاقبة فقط، حيث يحلّ ترميز NRZI مشكلة الوحدات المتعاقبة. لاحظ أنّ ترميز 4B / 5B ينتج كفاءةً بنسبة 80%. يعطي الجدول التّالي شيفرات 5 بتات التي تتوافق مع كلّ رمز من 16 رمزًا من بيانات ذات 4 بتات ممكنة:

لاحظ أن 5 بتّات كافية لترميز 32 شيفرة مختلفة حيث تُستخدم 16 شيفرة منها فقط للبيانات، فهناك 16 شيفرة متبقّية يمكن استخدامها لأغراض أخرى من بينها الشيفرة 11111 التي تُستخدم عندما يكون الخطّ خاملًا بدون عمل، وتقابل الشيفرة 00000 ما يشير إلى تعطُّل الخطّ (dead)، وتُفسَّر الشيفرة 00100 بأن الخطّ مقطوع (halt)، ويوجد 7 شيفرات من بين 13 شيفرةً متبقية غير صالحة لأنها تنتهك قاعدة وجود صفر واحد في البداية وصفرين في النهاية، وتمثل الـ 6 شيفرات الأخرى رموز تحكم مختلفة. تستخدم بعض بروتوكولات التأطير (framing protocols) الموضحة لاحقًا في هذا المقال رموز التحكم هذه.

التأطير (Framing)

فكّر في السيناريو الموجود في الشكل الآتي بعد معرفتك بكيفية نقل سلسلة من البتّات عبر رابط نقطة لنقطة أو من محوّل إلى محوّل، وتذكّر أننا نركز على شبكات تبديل الرّزم (packet-switched networks)، ممّا يعني أن كتل البيانات تسمى إطارات (frames) عند هذا المستوى، وليس مجرى بتات تتبادلها العُقد، حيث يمكّن محوّل الشبكة العُقد من تبادل الإطارات، وتخبر العقدة A محوّلها بإرسال إطار من ذاكرة العقدة عندما ترغب في إرسال إطار إلى العقدة B، فينتج عن هذا سلسلة من البتات تُرسَل عبر الرابط. ثم يجمع المحوّل الموجود على العقدة B سلسلة البتات الواصلة إلى الرابط معًا ويودِع الإطارَ المقابل في ذاكرة العقدة B، ويُعدّ التعرف على مجموعة البتات التي تشكّل إطارًا بالضبط، أي تحديد مكان بدء الإطار ونهايته، هو التّحدي الأساسي الذي يواجهه المحوّل.

توجد عدّة طرق لمعالجة مشكلة التأطير، حيث يستخدم هذا القسم ثلاثة بروتوكولات مختلفة لذلك. لاحظ أنه بينما نناقش مشكلة التأطير في سياق الرّوابط من نقطة لنقطة، فهذه المشكلة هي مشكلة أساسيّة ويجب معالجتها أيضًا في شبكات الوصول المتعدّد (multiple-access)، مثل: شبكات الإيثرنت، والشبكات اللّاسلكية.

البروتوكولات الموجّهة بالبايت (Byte-Oriented Protocols مثل بروتوكول PPP)

إحدى أقدم الطرق المستخدمة للتأطير والتي لها جذورها في توصيل الطرفيات بالحواسيب المركزيّة هي التي تَعدّ كل إطار على أنه مجموعة من البايتات أو الأحرف بدلًا من كونها مجموعة من البتات، ومن الأمثلة القديمة لهذه البروتوكولات الموجَّهة بالبايت بروتوكول الاتصال الثنائي المتزامن (Binary Synchronous Communication ويختصر إلى BISYNC) الذي طورته شركة IBM في أواخر الستينات، وبروتوكول رسائل اتصالات البيانات الرقمية (Digital Data Communication Message Protocol واختصارًا DDCMP) المستخدم في بروتوكولات DECNET التي أنشأتها شركة Digital Equipment Corporation، وبنت شركات الحواسيب الكبيرة، مثل: شركتي IBM، وDEC ذات مرّة أيضًا شبكاتٍ خاصةً لعملائها، وبروتوكول نقطة لنقطة (Point-to-Point Protocol واختصارًا PPP) المستخدم على نطاق واسع هو مثال حديث للطرق المستخدمة للتأطير.

توجد طريقتان للتأطير الموجّه بالبايت على مستوى عالٍ، الطريقة الأولى هي استخدام أحرف خاصّة معروفة باسم الأحرف الحارسة (sentinel characters) لتحديد مكان بدء الإطارات ونهايتها، والفكرة هي الإشارة إلى بداية الإطار عن طريق إرسال حرفٍ خاصّ بالتزامن هو SYN. ويُحتوى أحيانًا جزء البيانات من الإطار بين حرفين خاصّين آخرين هما: STX (بداية النصّ)، وETX (نهاية النصّ)، ويستخدم بروتوكول الاتصال الثنائي المتزامن BISYNC هذه الطّريقة، تكمن مشكلة طريقة الحارس (sentinel approach) في أن أحد الأحرف الخاصّة قد يظهر في جزء البيانات من الإطار، الطّريقة القياسيةّ للتغلّب على هذه المشكلة عن طريق تحويل هذا الحرف بوضع حرف تحويل رابط البيانات (data-link-escape أو اختصارًا DLE) قبله كلّما ظهر في جسم الإطار، حيث يجري تخطّي حرف DLE أيضًا (بوضع حرف DLE إضافي قبله) في جسم الإطار. قد يلاحظ مبرمجو لغة البرمجة C تشابه هذا مع الطريقة التي تحوَّل بها علامة الاقتباس (quotation mark) بواسطة الشرطة المائلة العكسيّة (backslash) عند ظهورها داخل سلسلة (string)، ويُطلق على هذا الأسلوب غالبًا حشو الأحرف (character stuffing) بسبب إدخال أحرف إضافيّة في جزء البيانات من الإطار.

بديل اكتشاف نهاية إطار باستخدام قيمة حارسة (sentinel value) هو تضمين عدد بايتات الإطار في بداية الإطار وتحديدًا في ترويسة الإطار، حيث يستخدم بروتوكول DDCMP هذه الطريقة، ويتمثّل أحد مخاطر هذه الطريقة ، في إمكانيّة إفساد خطأ الإرسال لحقل العدّ (count field)، وفي هذه الحالة لن يُكتشف نهاية الإطار بصورة صحيحة. توجد مشكلة مماثلة مع الطريقة القائمة على الحارس إذا فسد حقل ETX، فإذا حدث ذلك، فسيجمّع المستقبل عدد البايتات كما يشير حقل العدّ التالف، ثم يستخدم حقل اكتشاف الخطأ لتحديد تلف الإطار، ويسمى هذا أحيانًا بخطأ التأطير (framing error)، ثمّ سينتظر المستقبل حتّى يرى حرف SYN التالي ليبدأ بجمع البايتات التي تُشكّل الإطار التالي، لذلك من الممكن تسبب خطأ التأطير في تلقّي إطارات متتالية بصورة غير صحيحة، ويستخدم بروتوكول نقطة لنقطة (Point-to-Point Protocol أو اختصارًا PPP)، والذي يشيع استخدامه لنقل رزم بروتوكول الإنترنت (Internet Protocol) عبر أنواع مختلفة من روابط نقطة لنقطة، ولنقل الحرّاس (sentinels)، وحشو الأحرف (character stuffing). تجد صيغة إطار PPP في الشّكل التالي:

يعرض الشّكل السّابق الرّزمة مثل سلسلة من الحقول المصنَّفة، ويوجد فوق كلّ حقل رقمٌ يشير إلى طول هذا الحقل بالبتات، ولاحظ أنّ الرّزم تُرسَل بدءًا من الحقل الموجود في أقصى اليسار، فحرف بداية النصّ (start-of-text) الخاصّ الذي يُشار إليه على أنه حقل الراية Flag هو 01111110، ويحتوي حقلًا العنوان Address والتّحكم Control عادةً قيمًا افتراضية وبالتالي فهي غير مهمّة. ويُستخدم حقل البروتوكول (Protocol) لفكّ تعدُّد الإرسال، حيث يحدّد البروتوكول عالي المستوى مثل بروتوكول IP. يمكن التفاوض على حجم حِمل (payload) الإطار، ولكنّه يبلغ 1500 بايت افتراضيًا. يكون حقل المجموع الاختباري Checksum إمّا 2 (افتراضيًا) أو 4 بايتات. لاحظ أنه على الرّغم من الاسم الشائع لهذا الحقل إلا أنه في الواقع عبارة عن CRC، وليس checksum (كما سنوضّح لاحقًا).

تختلف صيغة إطار بروتوكول PPP في مسألة التفاوض على العديد من أحجام الحقول بدلًا من إصلاحها، حيث يُجرى هذا التفاوض بواسطة بروتوكول يُسمّى بروتوكول التحكّم بالرابط (Link Control Protocol ويختصر إلى LCP). يعمل كلّ من بروتوكولي PPP، وLCP جنبًا إلى جنب، فيرسل بروتوكول LCP رسائل تحكّم مغلَّفة ضمن إطارات بروتوكول PPP، ويشار إلى هذه الرسائل بواسطة معرّف LCP في حقل PPP (حقل Protocol)، ثم يغيّر بروتوكول LCP صيغة إطار PPP استنادًا إلى المعلومات الواردة في رسائل التحكم هذه، ويشارك بروتوكول LCP أيضًا في إنشاء رابط بين نظيرين (peers) عندما يكتشف كلا الجانبين أن الاتّصال عبر هذا الرّابط ممكن (عندما يكتشف كلّ مستقبل ضوئي إشارةً واردةً من الألياف التي يتّصل بها على سبيل المثال).

البروتوكولات الموجّهة بالبت (Bit-Oriented Protocols مثل بروتوكول HDLC)

لا تهتمّ البروتوكولات الموجّهة بالبتّ بحدود البايت على عكس البروتوكولات الموجّهة بالبايت، حيث تنظر البروتوكولات الموجّهة بالبتّ ببساطة إلى الإطار على أنه مجموعة من البتات، وقد تأتي هذه البتات من بعض مجموعات الأحرف كنظام ASCII، وقد تكون قيم بكسلات في صورة، كما قد تكون تعليمات ومُعامَلات من ملف تنفيذيّ. بروتوكول التّحكم في رابط البيانات المتزامن (Synchronous Data Link Control الذي يختصر إلى SDLC) الذي طوّرته شركة IBM هو مثال على بروتوكولٍ موجَّه بالبت. وحّدت منظّمة ISO لاحقًا بروتوكول SDLC مثل بروتوكول التحكم في رابط البيانات عالي المستوى (High-Level Data Link Control واختصارًا HDLC). وستجد صيغة إطار HDLC في الشّكل التالي:

يشير بروتوكول HDLC إلى بداية ونهاية الإطار مع سلسلة بتات مميّزة هي 01111110، وتُرسَل هذه السّلسلة أيضًا أثناء أيّ وقت يكون فيه الرّابط خاملًا بحيث يمكن للمرسل والمستقبل إبقاء ساعاتهما متزامنةً، باستخدام كلا البروتوكولين بهذه الطريقة طريقةَ الحارس (sentinel approach)، ونظرًا لأنّ سلسلة البتات هذه قد تظهر في أيّ مكان في جسم الإطار، فقد تعبر البتّات 01111110 حدود البايت، حيث تستخدم البروتوكولات الموجَّهة بالبتّ حرف DLE التناظري، وهي تقنيّة تُعرّف باسم حشو البتات (bit stuffing).

يعمل حشو البتات في بروتوكول HDLC على النحو التالي: تُرسل خمسة واحدات متعاقبة على جانب الإرسال في أيّ وقت من نصّ الرسالة (باستثناء عندما يحاول المرسل إرسال السلسلة المميزة 01111110)، ويحشو المرسل 0 قبل إرسال البتّ التالي؛ أمّا على الجانب المستقبل وفي حالة وصول خمسة واحدات متعاقبة، فيتّخذ المستقبل قراره بناءً على البتّ التالي الذي يراه (أي البت الذي يتبع الواحدات الخمسة)، فإذا كان البت التالي يساوي 0، فلابدّ أنّها محشوّة وبالتالي يزيلها المستقبل، وإذا كان البت التالي 1، فسيكون أحد الأمرين صحيحًا، فإمّا أن تكون هذه علامة نهاية الإطار، أوقد أُدخِل خطأٌ في مجرى البتات، ويمكن للمستقبل التمييز بين هاتين الحالتين بالنظر إلى البت التالي، فإذا شاهد 0 (أي أنّ آخر 8 بتات نظر إليها هي01111110) فهذا يعني أنهّا علامة نهاية الإطار، وإذا شاهد 1 (أي أن آخر 8 بتات نظر إليها هي01111111)، فلا بد من وجود خطأ ثم يتجاهل الإطار بأكمله. يتعيّن على المستقبل في الحالة الأخيرة انتظار السلسلة 01111110 التالية قبل بدئه في الاستلام مرّةً أخرى، ونتيجةً لذلك هناك احتمال فشل المستقبل في استلام إطارين متتاليين. ومن الواضح أنه لا تزال هناك طرق يمكن من خلالها عدم اكتشاف أخطاء التأطير، كما هو الحال عند إنشاء نمط نهاية الإطار الزائف بالكامل بسبب الأخطاء، ولكن هذه الإخفاقات غير مُرجّحة نسبيًّا، وستناقش الطرق القوية لاكتشاف الأخطاء في قسم لاحق.

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

التأطير المعتمد على الساعة (Clock-Based Framing مثل معيار SONET)

يمثّل معيار الشّبكة الضوئيّة المتزامنة (Synchronous Optical Network أو اختصارًا SONET) الطريقةَ الثالثة للتأطير، ويشار إلى هذه الطريقة ببساطة على أنّها تأطير معتمد على الساعة لعدم وجود مصطلح عامّ مقبول على نطاق واسع. اقترحت أبحاث بيل للاتصالات (Bell Communications Research أو Bellcore) معيار SONET لأوّل مرّة، ثمّ طوّره المعهد القومي الأمريكي للمواصفات القياسيّة (American National Standards Institute وتُختصر إلى ANSI) للإرسال الرقمي عبر الألياف الضوئيّة، واعتمده الاتحاد الدولي للاتصالات ITU-T منذ ذلك الحين، وكان معيار SONET لسنوات عديدة هو المعيار المهيمن لنقل البيانات لمسافات طويلة عبر الشبكات الضوئيّة.

يجب توضيح نقطة مهمّة حول معيار SONET وهي أنّ مواصفاته الكاملة أكبر بكثير من هذا الكتاب، وبالتالي ستغطّي المناقشة التالية النقاط الهامّة للمعيار فقط. يعالج معيار SONET كلًا من مشكلة التأطير ومشكلة التشفير، كما أنه يعالج مشكلة مهمّةً جدًّا لشركات الهاتف وهي مشكلة دمج (multiplexing) عدّة روابط منخفضة السّرعة على رابطٍ واحد عالي السّرعة، يعكس تصميم هذا المعيار في الواقع حقيقة أنّ شركات الهاتف يجب عليها الاهتمام بدمج أعداد كبيرة من القنوات التي تبلغ سرعتها 64 كيلوبت في الثانية والتي تُستخدم تقليديًا للمكالمات الهاتفيّة.

يحتوي إطار SONET على بعض المعلومات الخاصّة التي تخبر المستقبل بمكان بدء الإطار ونهايته كما هو الحال مع مخطّطات الإطارات التي نوقشت سابقًا، ومع ذلك فهذا هو وجه التّشابه الوحيد بينهما، ومن الجدير بالذّكر أنه لا يستخدم حشو البتات، بحيث لا يعتمد طول الإطار على البيانات المرسلة، لذا فالسؤال الذي يجب طرحه هو كيف يعرف المستقبل أين يبدأ كلّ إطار وأين ينتهي؟ يُعدّ هذا السؤال مرتبطًا برابط SONET الأقلّ سرعةً، والذي يُعرف باسم STS-1 ويعمل بسرعة 51.84 ميجابت في الثانية، حيث يظهر إطار STS-1 في الشكل الآتي، وهو مُرتَّب على شكل 9 صفوف ويأخذ كل صفّ 90 بايتًا، وتكون البايتات الثلاثة الأولى من كلّ صفّ بايتات إضافيّة (overhead)، وتتاح باقي البايتات للبيانات المرسَلة عبر الرّابط. يحتوي البايتان الأوّليان من الإطار على نمط بت خاصّ، وهذه البايتات هي التي تُمكّن المستقبل من تحديد مكان بدء الإطار، ولا يوجد سبب لعدم ظهور هذا النّمط أحيانًا في جزء الحمولة (payload) من الإطار، نظرًا لعدم استخدام حشو البتات، لذلك يبحث المستقبل عن نمط البت الخاصّ باستمرار على أمل رؤيته مرةً واحدة كلّ 810 بايت، لأنّ كلّ إطار يبلغ طوله 9 × 90 = 810 بايتات، وبالتالي يستنتج المستقبل أنه متزامن ويمكنه بعد ذلك تفسير الإطار بصورة صحيحة عندما يظهر النمط الخاصّ في المكان المناسب مراتٍ كافية.

أحد الأشياء التي لن نشرحها بسبب تعقيد معيار SONET هو الاستخدام التفصيلي لجميع البايتات الإضافية (overhead) الأخرى، وقد يُعزى جزء من هذا التّعقيد إلى حقيقة أنّ معيار SONET يعمل عبر شبكة المشغّل الضّوئية، وليس عبر رابط واحد فقط، تذكّر أنّنا نتخلى عن حقيقة أنّ شركات الاتصالات تنفّذ شبكة، ونركز بدلًا من ذلك على حقيقة قدرتنا على استئجار رابط SONET منها، ثم استخدام هذا الرّابط لبناء شبكتنا الخاصّة ذات نوع تبديل الرّزم (packet-switched). يأتي تعقيدٌ إضافي من حقيقة أنّ هذا المعيار يوفّر مجموعة خدمات أكثر ثراءً من مجرد نقل البيانات، حيث تُخصَّص على سبيل المثال 64 كيلوبت في الثانية من سعة رابط SONET لقناةٍ صوتية تُستخدم للصيانة.

تُرمَّز بايتات إطار SONET الإضافية باستخدام ترميز NRZ، وهو التّرميز البسيط الذي نوقش سابقًا، حيث تكون سلسلة الواحدات مرتفعة وسلسلة الأصفار منخفضة، ويجب خلط (scrambled) بايتات الحِمل لضمان وجود الكثير من الانتقالات للسّماح للمستقبل باستعادة ساعة المرسل، حيث يتمّ ذلك عن طريق حساب عمليّة XOR للبيانات المراد إرسالها باستخدام نمط بتّات معروف. يحتوي نمط البت الذي يبلغ طوله 127 بتًّا على الكثير من الانتقالات من 1 إلى 0، لذلك من المحتمل أن ينتج عن عملية XOR لنمط البتّ مع البيانات المرسلَة إشارةٌ ذات انتقالات كافية لتفعيل استعادة الساعة.

يدعم معيار SONET دمج عدّة روابط منخفضة السرعة بالطريقة التالية: يعمل رابط SONET المحدّد بمعدّلٍ من مجموعة محدودة من المعدّلات المحتملة، والتي تتراوح من 51.84 ميجابت في الثانية (STS-1) إلى 39813120 ميجابت في الثانية (STS-768). لاحظ أنّ كلّ هذه المعدّلات عبارة عن مضاعفات STS-1 العددية الصحيحة. تكمن أهمية التأطير في أن إطار SONET الواحد قد يحتوي على إطارات فرعيّة لقنوات متعدّدة ذات معدّلات أقلّ؛ أمّا الميزة الثانية فهي أن كلّ إطار يبلغ طوله 125 ميكرو ثانية، وهذا يعني أنّ طول إطار SONET يبلغ 810 بايت في معدلات STS-1، بينما في معدلات STS-3 يبلغ طول كلّ إطار SONET حوالي 2430 بايت. لاحظ الارتباط بين هاتين الميزتين حيث: 3 × 810 = 2430، مما يعني تلاؤم ثلاثة إطارات STS-1 تمامًا مع إطار STS-3 واحد. ترمز STS إلى إشارة النقل المتزامن (Synchronous Transport Signal)، وهي الطريقة التي يتحدّث بها معيار SONET عن الإطارات، ويوجد مصطلحٌ موازٍ هو الناقل الضوئي (Optical Carrier واختصارًا OC) الذي يُستخدم للتّحدث عن الإشارة الضوئية الأساسيّة التي تحمل إطارات SONET. يمكن القول أنّ هذين المصطلحين متوازيان لأن STS-3 و OC-3 على سبيل المثال يشيران إلى معدّل إرسال يبلغ 155.52 ميجابت في الثانية. سنلتزم بـالمصطلح STS نظرًا لأنّنا نركّز على التأطير هنا، ولكن من المرجح أن تسمع شخصًا يشير إلى رابط ضوئي باسم OC.

يمكن القول بأنّ إطار STS-N يتكوّن من N إطار من النّوع STS-1، حيث تكون البايتات في هذه الإطارات متداخلة (interleaved)، أي يرسَل بايت من الإطار الأول، ثمّ يرسَل بايت من الإطار الثاني وهكذا. والسبّب في تداخل (interleaving) البايتات في كلّ إطار STS-N هو التأكّد من أنّ البايتات في كلّ إطار STS-1 موجودة بالتساوي، أي أنّ البايتات تظهر في المستقبل بسرعة تبلغ 51 ميجابت في الثانية بسهولة، بدلًا من تجميعها بالكامل خلال 1 / Nth من الفاصل الزّمني 125 ميكرو ثانية.

يمكن ربط حِمل إطارات STS-1 معًا لتكوين حِمل STS-N أكبر على الرّغم من صحّة افتراض أنّ إشارة STS-N تُستخدم لتجميع N إطار من النّوع STS-1، مثل الإشارة إلى هذا الرّابط باستخدام STS-Nc ،على التّسلسل (concatenated)، حيث يُستخدَم أحد الحقول الموجودة في القسم الإضافي للإطار لهذا الغرض. يبين الشّكل السّابق بيانيًا التسلسل (concatenation) في حالة ثلاثة إطارات STS-1 متسلسلة في إطار STS-3c واحد. تكمن أهميّة رابط SONET في كونه من النوع STS-3c بدلًا من النوع STS-3، فيمكن لمستخدم هذا الرّابط في الحالة الأولى مشاهدته على أنه أنبوب واحد بسرعة 155.25 ميجابت في الثانية، بينما يجب عرض الرابط STS-3 على شكل ثلاثة روابط بسرعة 51.84 ميجابت في الثانية تُستخدَم لمشاركة الألياف.

وأخيرًا، وصفُ معيار SONET السابق بسيطٌ جدًا فهو يفترض أنّ حِمل كلّ إطار موجود بالكامل داخل الإطار، إذًا لماذا لا يحدث ذلك؟ يجب في الواقع عرض إطار STS-1 الموصوف للتّو على أنه مجرّد عنصرٍ نائب للإطار، حيث قد يطفو الحمل الفعلي (actual payload) خارج حدود الإطار، ويوضح الشّكل السابق هذه الحالة، فيطفو هنا كلٌ من حِمل الإطار STS-1 بين إطاري STS-1 و يزيح الحِمل عددًا من البايتات إلى اليمين، وبالتالي تلتفّ هذه البايتات. يشير أحد الحقول الموجودة في قسم الإطار الإضافي إلى بداية الحِمل، فتكمن أهميّة هذه الإمكانية في أنها تبسّط مهمّة مزامنة الساعات المستخدمة عبر شبكات شركات الاتصالات، حيث تقضي شركات الاتصالات الكثير من وقتها قلقةً بشأن مزامنة الساعات.

ترجمة -وبتصرّف- للقسمين Encoding و Framing من فصل Direct Links من كتاب Computer Networks: A Systems Approach

المشكلة: الاتصال بشبكة (Connecting to a Network)

تتكوّن الشبّكات الحاسوبيةّ من عُقدٍ (nodes) متّصلة عن طريق روابط (links) كما لاحظتَ في المقال الأوّل من هذه السلسلة، أساسيات الشبكات، فمن بين المشاكل الأساسيةّ التي يمكن مواجهتها هي كيفية توصيل عقدتين مع بعضهما، ولاحظت أيضًا تقديم تجريد السّحابة (cloud abstraction) لتمثيل الشّبكة دون كشف تعقيدات الشّبكة الدّاخلية، لذلك يجب أيضًا معالجة مشكلة مشابهة تتمثّل في توصيل مضيفٍ بسحابة، وهذه هي المشكلة التي يواجهها كلّ مزوّد خدمة إنترنت (Internet Service Provider ويختصَر إلى ISP) عندما يريد توصيل عميلٍ جديد بشبكته.

يجب معالجة مجموعة شائعة من المشاكل سواءً عند بناء شبكة بسيطة مؤلّفة من عقدتين ورابطٍ بينهما، أو عند توصيل المضيف المليار إلى شبكة موجودة مسبقًا مثل الإنترنت، حيث تحتاج أوّلًا إلى وسيط فيزيائي (physical medium) يمكنك إجراء الاتّصال من خلاله، فقد يكون هذا الوسيط عبارةً عن جزءٍ من سلك (wire)، أو قطعة من ألياف ضوئيّة (optical fiber) أو وسيطًا غير ملموس مثل الهواء الذي يمكن نقل الإشعاع الكهرومغناطيسي، مثل موجات الراديو، خلاله. وقد تغطّي هذه الشّبكة مساحةً صغيرةً، مثل: مبنى، أو مساحة واسعة مثل المساحة العابرة للقارّات (transcontinental).

لا يُعدّ توصيل عقدتين بوسيطٍ مناسبًا إلّا الخطوةَ الأولى، فيجب معالجة خمس مشكلات إضافية قبل تمكُّن العقد من تبادل الرّزم (packets) بنجاح، وستوفرّ معالجة هذه المشاكل اتصال الطّبقة 2 (L2)، باستخدام مصطلحات من معماريّة OSI. المشكلة الأولى هي ترميز (encoding) البتات ضمن وسيط الإرسال (transmission medium)، بحيث قد تفهمها عقدة الاستقبال (receiving node)؛ أمّا والمشكلة الثّانية، فهي مسألة تحديد سلسلة البتات المنقولة عبر الرّابط (link) ضمن رسائل كاملة يمكن تسليمها إلى العقدة النّهائية، حيث تدعى هذه المشكلة بالتّأطير (framing)، وتدعى الرّسائل التي يمكن توصيلها إلى المضيفين النهّائيين أحيانًا بالإطارات (frames)، وبالرّزم (packets) أحيانًا أخرى؛ بينما المشكلة الثالثة، ونظرًا لتعرّض الإطارات أحيانًا للتّلف أثناء الإرسال، فمن الضّروري اكتشاف هذه الأخطاء واتخاذ الإجراء المناسب، وهذه هي مشكلة كشف الأخطاء (error detection)؛ في حين تتمثّل المشكلة الرّابعة في ظهور الرّابط على أساس رابطٍ موثوق، على الرّغم من حقيقة إفساده للإطارات من وقتٍ لآخر. وفي المشكلة الخامسة والأخيرة وهي في الحالات التي يتشارك فيها مضيفون متعدّدون بنفس الرّابط، مثل الرّوابط اللاّسلكية (wireless links)، فمن الضّروري التوسّط في الوصول إلى هذا الرّابط، وهذه هي مشكلة التحّكم بالوصول إلى الوسائط (media access control).

على الرّغم من إمكانيّة مناقشة هذه المشاكل الخمس، التّرميز (encoding)، والتّأطير (framing)، وكشف الأخطاء (error detection) والتّسليم الموثوق (reliable delivery)، وتوسّط الوصول (access mediation)، إلّا أنها تُعدّ مشاكلًا حقيقيّة تُعالَج بطرقٍ مختلفة باستخدام تقنيّات شبكيّة مختلفة، وسيتناول هذا المقال هذه المشاكل في سياق تقنيّات شبكيّة محدّدة، مثل روابط الألياف نقطةً لنقطة (point-to-point fiber links)، والمثال السّائد عنها شبكات SONET، وشبكات الوصول المتعدّد باستشعار الحامل (Carrier Sense Multiple Access واختصارًا CSMA)، والمثال الأشهر عنها شبكات إيثرنت (Ethernet)، والشّبكات اللّاسلكية (Wi-Fi) التّقليديّة، وتقنيّة ليف إلى المنزل (fiber-to-the home)، التي تَعدّ تقنية PON هي المعيار السّائد عنها، وشبكات الهاتف المحمول اللّاسلكية (mobile wireless)، حيث تتحوّل الآن شبكة 4G إلى شبكة 5G بسرعة.

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

المخطط التقني (Technology Landscape)

من المفيد أوّلًا الحصول على موقعٍ على أرض الواقع قبل الخوض في التّحديات الموضّحة في عرض المشكلة في بداية هذا المقال، حيث يتضمّن هذا الموقع مصفوفةً واسعةً من تقنيّات الرّبط، وهذا يرجع جزئيًّا إلى الظّروف المتنوّعة التي يحاول المستخدمون توصيل أجهزتهم في ظلّها، ويجب على مشغّلي الشّبكات الذين يُنشئون شبكات عالميّة (global networks) في أحد طرفيّ الشّبكة، التّعامل مع الرّوابط (links) التي تمتدّ لمئات وآلاف الكيلومترات، والتي تربط موجّهاتٍ (routers) بحجم الثّلاجة؛ أمّا في الطّرف الآخر، فيستعمل المستخدم العاديّ الروابطَ غالبًا مثل وسيلةٍ لربط الحاسوب بالإنترنت الموجود، ويكون هذا الرّابط أحيانًا لاسلكيًّا (Wi-Fi) مثل الرّوابط الموجودة في المقاهي، ويكون أحيانًا رابط إيثرنت (Ethernet) مثل الرّوابط الموجودة في مبنى مكتبيّ، أو في الجامعة؛ أو قد يكون هاتفًا ذكيًا متّصلًا بشبكة خلويّة (cellular network)؛ كما قد يكون الراّبط أليافًا ضوئيّةً (fiber optic) يوفّرها مزوّد خدمة الانترنت ISP لشريحة كبيرة من النّاس، ويستخدم العديد من النّاس روابطًا ذات أسلاك نحاسيّة (copper wire) أو كابلات، وتوجد عدّة استراتيجيّات شائعة مستخدمة مع هذه الرّوابط المختلفة، بحيث يمكن جعلها موثوقةً ومفيدةً للطّبقات الأعلى من البروتوكول المستخدم، حيث سيشرح هذا المقال تلك الاستراتيجياّت جميعها.

يوضّح الشّكل السّابق أنواع الرّوابط المختلفة التي يمكن وجودها ضمن شبكة الإنترنت اليوم، فتجد يسار الشّكل السّابق مجموعةً متنوّعةً من أجهزة المستخدم النّهائي (end-user) التي تتراوح من الهواتف الذّكية (smartphones) إلى الأجهزة اللّوحيّة (tablets)، وحتّى أجهزة الحاسوب الكاملة (full-fledged computers) المتّصلة بمزوّد خدمة الانترنت عبر وسائل مختلفة. قد تستخدم هذه الرّوابط تقنيّات مختلفة ولكنّها تبدو متشابهةً مع الشّكل السّابق، إذ يربط خطٌ مستقيم الجهاز بموجّه، وتوجد روابط تربط الموجّهات مع بعضها البعض داخل مزوّد خدمة الإنترنت، بالإضافة إلى وجود روابط تربط مزوّد خدمة الانترنت مع بقيةّ شبكة الانترنت (rest of the Internet) التي تتكون من الكثير من مزوّدي خدمة الإنترنت الآخرين، والمضيفين الذين يتّصلون بهم. تبدو جميع هذه الرّوابط متشابهةً، وهذا ليس فقط لأننا لسنا فنانين جيّدين جدًّا، بل لأن جزءًا من دور معماريّة الشّبكة هو توفير تجريدٍ مشترك لشيء معقّد ومتنّوع مثل الرّوابط (links)، فلا يجب على حاسوبك المحمول أو هاتفك الذّكي الاهتمام بنوع الرّابط المتصّل به، والشّيء الوحيد المهم هو امتلاكه لرابط بشبكة الإنترنت، ولا يتعيّن على الموجّه (router) أيضًا الاهتمام بنوع الرّابط الذي يربطه مع الموجهات الأخرى، حيث قد يرسل الموجّه رزمةً عبر الرّابط مع توقّعٍ جيّد بأن الرّزمة ستصل إلى الطّرف الآخر من الرّابط، لكن كيف يمكن جعل جميع هذه الأنواع المختلفة من الرّوابط متشابهةً بدرجة كافية للمستخدمين النّهائيين والموجّهات؟

يجب أوّلًا التّعامل مع جميع قيود الرّوابط الفيزيائيّة ونقاط ضعفها الموجودة في العالم الحقيقي، حيث أظهرت فقرة المشكلة في بداية هذا المقال بعضًا من هذه المشاكل، ولكن يجب أوّلًا تقديم بعضٍ من الفيزياء البسيطة قبل مناقشتها. تُصنع جميع هذه الرّوابط من بعض المواد الفيزيائيةّ التي يمكنها نشر الإشارات، مثل: الأمواج الراديويّة، أو أنواع أخرى من الإشعاع الكهرومغناطيسي. ولكنّ ما تحتاجه حقًّا هو إرسال البِتّات. سترى كيفية تشفير البتّات لإرسالها، من خلال وسيط فيزيائي في الأقسام اللّاحقة من هذا المقال وبعض المشاكل الأخرى ثم ستفهم كيفيّة إرسال رزمٍ كاملة عبر أيّ نوع من الرّوابط بنهاية هذا المقال بغضّ النّظر عن الوسيط الفيزيائيّ المُستخدَم. تتمثّل إحدى طرق توصيف الرّوابط في الوسيط (medium) الذي تستخدمه عادةً، مثل: الأسلاك النحاسيّة (copper wire)، ومنها مثلا: السّلك المزدوج الملتوي (twisted pair) الذي تستخدمه بعض شبكات الإيثرنت والهواتف الأرضيّة، أو السّلك المحوري (coaxial) الذي يستخدمه الكابل (cable)؛ أو مثل الألياف الضّوئية (optical fiber) التي تستخدمها تقنيّة ليف إلى منزل (fiber-to-the-home)، والعديد من الرّوابط بعيدة المدى ضمن بنية شبكة الإنترنت الأساسيّة (Internet’s backbone)؛ أو مثل الهواء (air)، أو الفراغ (free space) الذي تستخدمه الرّوابط اللّاسلكية (wireless links).

يُعدّ التّردّد (frequency) من خصائص الرّوابط المهمّة الأخرى الذي يُقاس بوحدة الهرتز (hertz)، والذي تهتزّ به الموجات الكهرومغناطيسيّة، وتسمّى المسافة بين زوجٍ من حدود الموجة القصوى أو الصغرى المتجاورة بطول الموجة الموجيّ (wavelength) ويُقاس بالمتر. تنتقل جميع الموجات الكهرومغناطيسيّة بسرعة الضّوء، والتي تعتمد بدورها على الوسيط (medium)، حيث يساوي الطّول الموجيّ السّرعةَ مقسومةً على تردّد الموجة، فيحمل خطّ الهاتف للدّرجة الصّوتية (voice-grade telephone line) إشاراتٍ كهرومغناطيسيّة مستمرةً تتراوح بين 300 هرتز، و3300 هرتز، وقد يكون للموجة ذات التّردّد 300 هرتز التي تنتقل عبر النّحاس طولًا موجيًّا يساوي سرعة الضّوء في النّحاس مقسومةً على التّردد، بحيث يساوي:

= 2/3 × 3 × 108 / 300 = 667 × 103 متر

تمتدّ الموجات الكهرومغناطيسيّة على نطاق أوسع بكثير من التّرددات بدءًا بالموجات الراديويّة، ثم ضوء الأشعّة تحت الحمراء (infrared light)، ثم الضّوء المرئيّ (visible light)، ثم الأشعّة السّينيّة (x-rays)، وأشعّة جاما (gamma rays)، ويبيّن الشّكل التاّلي الطّيف الكهرومغناطيسي، ويوضح الوسائط الشّائعة المستخدمة لحمل نطاقات التّردد:

لا يُظهر الشّكل السّابق المكانَ المناسب للشّبكة الخلويّة، فهذا أمر معقّد بعض الشّيء لأن نطاقات التّردد المحدّدة المرخَّصة للشّبكات الخلويّة تختلف حول العالم، وهو أمرٌ أعقد من حقيقة أن مشغّلي الشّبكات غالبًا يدعمون التّقنيات القديمة، أو السّابقة وتقنيّات الجيل الجديد أو التالي، حيث يشغَل كلّ منها نطاقَ تردّد مختلفًا. ويمكننا القول باختصار أنّ التّقنيات الخلويّة التّقليديّة تتراوح بين 700 ميجاهرتز إلى 2400 ميجاهرتز مع تخصيصاتٍ متوسّطة الطّيف وجديدةٍ تحدث عند 6 جيجاهرتز الآن، وتخصيصات الموجة المليمتريّة (millimeter-wave وتُختصر إلى mmWave) المفتوحة فوق 24 جيجاهرتز، حيث من المحتمل أن يصبح نطاق الموجة المليمتريّة هذا جزءًا مهمًّا من شبكة الهاتف المحمول 5G.

يمكن فهم الرّابط على أنّه وسيط فيزيائي يحمل إشارات على شكل موجات كهرومغناطيسيّة، وتوفّر هذه الرّوابط أساس إرسال جميع أنواع المعلومات بما في ذلك نوع البيانات التي نهتمّ بنقلها، والتي هي البيانات الثّنائيّة (أصفار وواحدات)، ويمكن القول بأنّ البيانات الثنائية مشفّرةٌ في الإشارة، فمشكلة تشفير البيانات الثّنائية على الإشارات الكهرومغناطيسيّة موضوعٌ معقّد، ويمكن جعل ذلك أكثر قابليّةً للإدارة من خلال التّفكير في تشفير البيانات الثّنائية على أنّه مقسَّم إلى طبقتين، حيث تُعنى الطّبقة السّفلية بالتعّديل (modulation)، أيّ تغيير تردّد (frequency)، أو سعة (amplitude)، أو طور (phase) الإشارة للتّأثير على إرسال المعلومات، فتغيير قدرة (power) أو سعة (amplitude) طولٍ موجيّ هو مثالٌ بسيط عن التّعديل (modulation)، وهذا يكافئ تشغيل وإطفاء النور، فمسألة التّعديل ثانويّةً بالنّسبة للرّوابط التي تُعَد لبنةً أساسيّةً في الشّبكات الحاسوبيّة، لذلك يمكن الافتراض ببساطة أنّه من الممكن إرسال زوج من الإشارات القابلة للتمّييز، حيث يمكن عَد زوج الإشارات كإشارة مرتفعة (high signal)، وأخرى منخفضة (low)؛ أمّا الطّبقة العلويّة، وهي الطّبقة التي تهمّنا الآن، فتهتم بالمشكلة الأبسط بكثير وهي تشفير البيانات الثّنائية على هاتين الإشارتين.

يمكن تصنيف الرّوابط بطريقة أخرى وذلك من حيث طريقة استخدامها، حيث تميل الأمور الاقتصاديّة وقضايا النّشر المختلفة إلى التّأثير على مكان وجود أنواع روابط مختلفة، فيتفاعل معظم المستخدمين مع الإنترنت إمّا من خلال الشّبكات اللّاسلكية الموجودة في المقاهي، والمطارات، والجامعات وما إلى ذلك؛ أو من خلال ما يسمى روابط الميل الأخير (last-mile links)؛ أو شبكات الوصول (access networks) بدلًا من ذلك، والتي يوفّرها مزود خدمة الإنترنت. لُخّصت أنواع هذه الرّوابط في الجدول الآتي، وقد اختيرت هذه الأنواع لأنها طرق فعّالة من حيث التّكلفة للوصول إلى ملايين المستخدمين، فتقنيّة خطّ المشترك الرّقمي (Digital Subscriber Line واختصارها DSL) على سبيل المثال هي تقنية قديمة نُشرت على الأسلاك النّحاسية المزدوجة الملتوية الموجودة مسبقًا لخدمات الهاتف القديمة العاديّة؛ أمّا تقنيّة G.Fast، فهي تقنيّة قائمة على النّحاس تُستخدم عادةً في المباني السّكنية متعدّدة المساكن، وتقنيّة الشّبكة الضّوئية السّلبية (Passive Optical Network واختصارها PON) هي تقنيّة أحدث تُستخدم عادةً لربط المنازل والشّركات عبر الألياف التي نُشرت مؤخّرًا.

ويوجد أيضًا شبكة الهاتف المحمول (mobile) أو الشّبكة الخلويّة (cellular)، حيث يشار إليها باسم 4G ولكنّها تتطوّر بسرعة إلى شبكة 5G في وقت ترجمة هذه السلسلة، التي تربط أجهزة الهاتف المحمولة بالإنترنت، حيث يمكن لهذه التقّنية أيضًا العمل مثل وصلة الإنترنت الوحيدة في المنازل أو المكاتب، ولكنّها تأتي مع ميزة إضافية تتمثّل في السّماح بالحفاظ على الاتّصال بالإنترنت أثناء الانتقال من مكان إلى آخر. تُعدّ هذه التّقنيات خيارات شائعة لاتّصال الميل الأخير بمنزلك أو عملك، ولكنّها ليست كافيةً لبناء شبكة كاملة من البداية، لذلك ستحتاج أيضًا إلى بعض الرّوابط الأساسيّة أو روابط شبكة العمود الفقري بعيدة المدى (long-distance backbone links) لتوصيل المدن، فالرّوابط الأساسية الحديثة هي عبارة عن ألياف فقط تقريبًا اليوم، والتي تستخدم عادةً تقنيّةً تسمّى الشّبكة الضّوئية المتزامنة (Synchronous Optical Network وتختصر إلى SONET)، والتي طُوّرت في الأصل لتلبية المتطلّبات ذات الإدارة الصّعبة لشركات الهاتف. ويوجد، بالإضافة إلى روابط الميل الأخير (last-mile) والرّوابط الأساسيّة (backbone) وروابط شبكة الهاتف المحمول (mobile links)، روابطٌ تجدها داخل مبنى أو داخل جامعة ويشار إليها عمومًا باسم الشّبكات المحلّية (local area networks وتختصر إلى LANs)، حيث تُعَد تقنيّة الإيثرنت والتّقنية اللّاسلكية (Wi-Fi) من التّقنيات المهيمنة في هذا المجال.

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

ترجمة -وبتصرّف- للقسم Technology Landscape من فصل Direct Links من كتاب Computer Networks: A Systems Approach

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

حيز النطاق التراسلي (Bandwidth) ووقت الاستجابة (Latency)

يُقاس أداء الشبكة بطريقتين أساسيتين: حيز النطاق التراسلي (bandwidth) ويسمى أيضًا الإنتاجية (throughput)، ووقت الاستجابة (latency) ويسمى أيضًا التأخير (delay). يعبّر عن حيز نطاق الشبكة التراسلي بعدد البِتات التي يمكن إرسالها عبر الشبكة في فترة زمنية معيّنة. على سبيل المثال، قد يكون للشبكة حيز نطاق تراسلي يبلغ 10 مليون بت في الثانية (Mbps)، مما يعني أنها قادرة على توصيل 10 مليون بِت في الثانية. من المفيد أحيانًا التفكير في حيز النطاق التراسلي من حيث المدة التي يستغرقها إرسال كل جزء من البيانات. يستغرق 0.1 ميكروثانية (μs) لإرسال كل بِت على شبكة بسرعة 10 ميجابت في الثانية على سبيل المثال.

حيز النطاق التراسلي والإنتاجية هما مصطلحان مختلفان اختلافًا دقيقًا. بدايةً، حيز النطاق التراسلي هو بالمعنى الحرفي قياسٌ لعرض نطاق التردد. على سبيل المثال، كانت خطوط الهاتف القديمة من الدرجة الصوتية تدعم نطاق تردد يتراوح بين 300 إلى 3300 هرتز؛ وكان يقال أنّ حيز النطاق التراسلي هو : 3300 هرتز - 300 هرتز = 3000 هرتز. إذا رأيت مصطلح حيز النطاق التراسلي (bandwidth) مستخدمًا في حالةٍ يقاس فيها بالهرتز، فمن الراجح أنه يشير إلى نطاق الإشارات التي يمكن استيعابها.

عندما نتحدث عن حيز النطاق التراسلي لرابط اتصالٍ، فإننا نشير عادةً إلى عدد البِتات في الثانية التي يمكن إرسالها على الرابط. يُسمى هذا أحيانًا أيضًا معدّل البيانات (data rate). يمكن أن نقول أنّ حيز النطاق التراسلي لرابطٍ إثيرنت هو 10 ميجابت في الثانية. ومع ذلك، نستطيع أيضًا أن نميّز على نحو مفيدٍ بين الحدّ الأقصى لمعدل البيانات المتاح على الرابط وعدد البِتات في الثانية التي يمكننا بالفعل إرسالها عبر الرابط من الناحية العملية. نميل إلى استخدام كلمة الإنتاجية للإشارة إلى الأداء المُقَاس للنظام. وبالتالي، وبسبب أوجه القصور المختلفة في التنفيذ، قد يحقّق زوج من العقد متصل عبر رابط بجيز نطاق تراسلي يبلغ 10 ميجابت في الثانية إنتاجيةً لا تتجاوز 2 ميجابت في الثانية فقط. وهذا يعني أن التطبيق على أحد المضيفين يمكن أن يرسل البيانات إلى المضيف الآخر بسرعة 2 ميجابت في الثانية.

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

رغم أنّنا نستطيع أن نتكلّم عن حيز النطاق التراسلي للشبكة بأكملها، فإنّنا في بعض الأحيان نرغب أن نكون أكثر دقة بالتركيز مثلًا على حيز النطاق التراسلي لرابط فيزيائي واحدٍ أو قناة منطقية من عمليةٍ لعملية. على المستوى الفيزيائي، يتحسّن حيز النطاق التراسلي باستمرار، وبلا نهاية في الأفق. بصورة بديهية، إذا نظرت إلى ثانية من الزمن على أنّها مسافة يمكنك قياسها باستخدام المسطرةِ وإلى حيز النطاق التراسلي على أنّه عدد البِتات التي تتناسب مع هذه المسافة، فيمكنك التفكير في كل بِت على شكل نبضةٍ ذات عرض معيّن. على سبيل المثال في رابطٍ 1 ميجابت في الثانية كما في القسم (أ) من الشكل الآتي، وسيكون عرض كل بِت هو 1 ميكرو ثانية، بينما في رابطٍ 2 ميجابت في الثانية كما في القسم (ب) من الشكل الآتي، وسيكون عرض كل بت هو 0.5 ميكرو ثانية. كلما كانت تقنية الإرسال والاستقبال أعقد، كلما أصبح كل بِت أضيق، وبالتالي كلما زاد حيز النطاق التراسلي. بالنسبة للقنوات المنطقية من عملية لعملية، يتأثر جيز النطاق التراسلي أيضًا بعوامل أخرى، بما في ذلك عدد المرات التي يجب على البرنامج الذي ينفّذ القناة التعاملَ فيها مع كل بِت من البيانات، وربما تحويله.

يتوافق مقياس الأداء الثاني، أي وقت الاستجابة (latency)، مع المدّة التي تستغرقها رسالةٌ للانتقال من أحد طرفي الشبكة إلى الطرف الآخر. (وكما هو الحال مع حيز النطاق التراسلي، يمكن أن نركّز على وقت الاستجابة على رابطٍ واحدٍ أو قناة من طرف لطرف)، حيث يُقاس وقت الاستجابة بدقّة نسبة إلى الزمن. على سبيل المثال، يمكن أن يكون وقت الاستجابة لشبكةٍ عابرةٍ للقارات 24 ميلي ثانية (ms)؛ وهذا يعني أنّ الرسالة تستغرق 24 ميلي ثانية للانتقال من أحد ساحلي أمريكا الشمالية إلى الساحل الآخر. هناك العديد من المواقف التي يكون فيها مهمًّا للغاية معرفةُ الوقت المستغرق لإرسال رسالة من أحد طرفي الشبكة إلى الطرف الآخر والعكس كذلك عوض وقت الاستجابة في اتجاه واحدٍ. نسمي ذلك وقت الذهاب والإياب (round-trip time أو اختصارًا RTT) للشبكة.

غالبًا ما ننظر إلى وقت الاستجابة على أنه يتكوّن من ثلاث عناصر. العنصر الأول هو تأخير انتشار سرعة الضوء، ويحدث هذا التأخير لأنه لا يوجد شيء، بما في ذلك بِتٌ يتنقل عبر سلكٍ، يمكنه أن يتجاوز سرعة الضوء. إذا كنت تعرف المسافة بين نقطتين، فيمكنك حساب وقت الاستجابة لسرعة الضوء، ولكن يجب عليك توخي الحذر لأن الضوء ينتقل عبر وسائط مختلفة بسرعات مختلفة: فهو ينتقل بسرعة 3.0 × 108 m/s في الفراغ، وبسرعة 2.3 × 108 m/s في الكابل النحاسي و 2.0 × 108 m/s في الألياف البصرية. العنصر الثاني هو مقدار الوقت المستغرق لإرسال وحدة بيانات، وهو تناسبٌ بين حيز النطاق التراسلي للشبكة وحجم الرزمة التي تُنقَل البيانات فيها. أمّا العنصر الأخير فهو التأخير الذي قد يكون في طابورٍ داخل الشبكة نظرًا لأن المبدّلات تحتاج عمومًا إلى تخزين الرزَم لبعض الوقت قبل إعادة توجيهها على رابطٍ صادرٍ. وعلى أساس ما سبق، يمكننا تحديد وقت الاستجابة الإجمالي على النّحو التالي :

اقتباس

وقت الاستجابة (Latency) = الانتشار (Propagation) + الإرسال (Transmit) + الطابور (Queue)

الانتشار (Propagation) = المسافة (Distance) / سرعة الضوء (SpeedOfLight)

الإرسال (Transmit) = الحجم (Size) / حيز النطاق التراسلي (Bandwidth)

تُعبِّر المسافة Distance هنا عن طول السلك الذي ستنتقل عليه البيانات، وسرعة الضوء SpeedOfLight هي السرعة الفعلية للضوء على هذا السلك، والحجم هو حجم Size رزمة البيانات، وحيز النطاق التراسلي Bandwidth هو حيز النطاق التراسلي الذي تُرسَل الرزمة عليه. لاحظ أنه إذا كانت الرسالة تحتوي على بِتٍ واحدٍ فقط وكنّا نتحدث عن رابط واحد (وليس الشبكة بأكملها)، فإن عنصري الإرسال Transmit والطابور Queue لا تكون لهما قيمة، وعليه يُوافق وقتُ الاستجابة تأخيرَ الانتشار فحسب.

يُحدّد مفهوما حيز النطاق التراسلي ووقت الاستجابة معًا خصائصَ الأداء لرابط أو قناة معينة. ومع ذلك، تعتمد أهميتهما النسبية على التطبيق. فبالنسبة لبعض التطبيقات، يهيمن وقت الاستجابة على حيز النطاق التراسلي. على سبيل المثال، العميل الذي يرسل رسالةً مؤلفة من بايتٍ واحد إلى خادومٍ ويتلقى رسالةً مؤلفة من بايت واحدٍ في المقابل يكون محدودًا في وقت الاستجابة. إذا افترضنا أنه لا توجد حوسبةٌ حقيقية في عملية إعداد الرّد، فإن التطبيق سيعمل بصورة مختلفة كثيرًا على قناة عابرة للقارات بزمنٍ RTT يساوي 100 ميلي ثانية مقارنةً بقناةٍ عبر الغرفة بزمنٍ RTT يساوي 1 ميلي ثانية. سواءٌ كانت القناة 1 ميجابت في الثانية أو 100 ميجابت في الثانية فهذا غير مهمّ نسبيًا، رغم أنّ الأوّل يشير إلى أن وقت إرسال البايت Transmit هو 8 ميكرو ثانية والأخير يشير إلى وقت إرسالٍ Transmit هو 0.08 ميكرو ثانية.

في المقابل، لنأخذ برنامج مكتبة رقمية يُطلب منه إحضار صورة بحجم 25 ميجا بايت، كلّما زاد حيز النطاق التراسلي المتوفر، كلما زادت قدرته على إرسال الصورة إلى المستخدم بصورةٍ أسرع. في هذه الحالة، يهيمن حيز النطاق التراسلي للقناة على الأداء. لرؤية هذا الأمر، نفترض أن القناة لديها حيز نطاق تراسلي يبلغ 10 ميجابت في الثانية، سيستغرق الأمر 20 ثانية لإرسال الصورة (25×106×8 بِت) / (10×106 بِت في الثانية) = 20 ثانية، ولهذا لن يكون الأمر ذا أهمّية نسبيًا سواءٌ كانت الصورة على الجانب الآخر من قناة 1 ميلي ثانية أو من قناةٍ 100 ميلي ثانية، لأن الفرق بين زمن استجابة 20.001 ثانية وزمن استجابة 20.1 ثانية لا يكاد يذكر.

يُعطي الشكل التالي فكرةً عن الكيفية التي يمكن أن يهيمن بها وقت الاستجابة أو حيز النطاق التراسلي على الأداء في ظروف مختلفة. ويوضح الرسم البياني المدة التي يستغرقها نقل الكائنات ذات الأحجام المختلفة (1 بايت، 2 كيلوبايت، 1 ميجابايت) عبر الشبكات بأزمنةِ RTT تتراوح من 1 إلى 100 ميلي ثانية وسرعات روابط تبلغ 1.5 أو 10 ميجابت في الثانية. ونستخدم المقاييس اللوغاريتمية لإظهار الأداء النسبي. بالنسبة لكائن 1 بايت (ضغطةٌ على لوحة المفاتيح مثلًا)، يظل وقت الاستجابة مساويًا تمامًا تقريبًا لزمن RTT، إذ لا يمكنك التمييز بين شبكة 1.5 ميجابت في الثانية وشبكة 10 ميجابت في الثانية. بالنسبة لكائنٍ 2 كيلوبايت (على سبيل المثال مثلًا) ، فإن سرعة الرابط تحدث فرقًا كبيرًا على شبكةٍ ذات زمن RTT يبلغ 1 ميلي ثانية ولكن الفرق لا يذكر على شبكةٍ ذات زمن RTT يساوي 100 ميلي ثانية. وبالنسبة لكائن 1 ميجابايت (صورة رقمية مثلًا)، فإن RTT لا يشكّل أيّ فرقٍ، إنها سرعة الرابط هي التي تسيطر على الأداء عبر المجال الكامل لزمن RTT.

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

نشير هنا كذلك إلى أنّ أجهزة الحاسوب أصبحت سريعةً جدًا لدرجة أنه عندما نربطها بالشبكات، يكون من المفيد أحيانًا التفكير، مجازيًا على الأقل، بما يمكن أن نسمّيه التعليمات لكلّ ميل. خُذ ما يحدث عندما يرسل جهاز حاسوب قادر على تنفيذ 100 مليار تعليمة في الثانية رسالةً على قناة ذات زمن RTT هو 100 ميلي ثانية. (لتسهيل العملية الحسابية، افترض أن الرسالة تغطي مسافة 5000 ميل). إذا كان هذا الحاسوب يبقى في وضع الخمول خلال المدّة 100 ميلي ثانية انتظارًا لرسالة الرّد، فإنّه ضيّع الفرصة لتنفيذ 10 مليار تعليمة، أو 2 مليون تعليمة لكل ميل. وكان من الأفضل بالنّسبة له الخروج من الشبكة لتجاوز هذا الهدر.

جداء التأخير في حيز النطاق التراسلي (Delay × Bandwidth Product)

من المفيد أيضًا التحدث عن جداء هذين المقياسين، الذي يسمى غالبًا جداء حيز النطاق التراسلي في وقت الاستجابة (delay × bandwidth product). بصورة بديهية، إذا نظرنا إلى قناةٍ بين زوج من العمليات على شكل أنبوب مجوف كما في الشكل التالي، إذ يقابل وقتُ الاستجابة طولَ الأنبوب ويمثّل قطرُ الأنبوب حيزَ النطاق التراسلي، فإن جداء حيز النطاق التراسلي في وقت الاستجابة سيعطي حجم الأنبوب، أي الحدّ الأقصى لعدد البِتات التي يمكن أن تمرّ عبر الأنبوب في أي لحظة معينة. يُمكن أن نعبّر عنها بطريقة أخرى، إذا كان وقت الاستجابة (الذي يقاس بالزمن) يتوافق مع طول الأنبوب، فعندما تعطي عرض كل بِت (يقاس أيضًا بالزمن)، فيمكنك حساب عدد البِتات التي ستملأ الأنبوب. على سبيل المثال، يمكن لقناة عابرة للقارات ذات وقت استجابة في اتجاه واحد قدره 50 ميلي ثانية وحيز نطاق تراسلي يبلغ 45 ميجابت في الثانية أن تستوعب ما مقداره:

50 × 10-3 × 45 × 106 bits/sec = 2.25 × 106 bits

أو حوالي 280 كيلو بايت من البيانات. وبعبارة أخرى، فإن هذه القناة (الأنبوب) في المثال يمكنها أن تَسَعَ نفس عدد بايتات ذاكرة حاسوب شخصي من فترة أوائل الثمانينات.

تُعدّ معرفة جداء حيز النطاق التراسلي في وقت الاستجابة أمرًا مهمًّا عند إنشاء شبكات عالية الأداء لأنه يتوافق مع عدد البِتات التي يجب أن يرسلها المرسل قبل وصول البِت الأول إلى جهاز الاستقبال. إذا كان المُرسِل يتوقع من الجهاز المُستقبِل أن يشير بطريقة ما إلى أن البِتات قد بدأت في الوصول، وكان الأمر يستغرق وقت استجابة آخر تعيد فيه القناة هذه الإشارة إلى المرسل، فيمكن أن يكون هذا الأخير قد أرسل ما يُعادل جداء حيز النطاق التراسلي في الزمن RTT من البيانات قبل أن يسمع من المُستقبِل أن كل شيء على ما يرام. يُقال هنا أن البِتات في الأنبوب "في حالة طيران"، مما يعني أنه إذا طلب المُستقبِل من المُرسِل التوقف عن الإرسال، فقد يتلقى ما مقداره جداء حيز النطاق التراسلي في الزمن RTT من البيانات قبل أن يتمكن المرسل من الاستجابة. في المثال أعلاه، يُعادل هذا المقدار 5.5 × 106 بِت (671 كيلوبايت) من البيانات. من ناحية أخرى، إذا لم يملأ المرسل الأنبوب، أي لم يرسل بيانات تُعادل في مقدارها جداء حيز النطاق التراسلي في الزمن RTT قبل توقّفه لانتظار الإشارة، فإن المرسل لن يكون استخدم الشبكة بالكامل.

لاحظ أننا نهتمّ في معظم الوقت بسيناريو RTT، والذي نشير إليه ببساطة على أنه يُعادل جداء حيز النطاق التراسلي في التأخير، دون أن نقول صراحةً أن "التأخير" هو RTT (أي ضِعف التأخير في اتجاه واحد). عادة ما يبيّن السياق هل يعني "التأخير" في الجداء (التأخير×حيز النطاق التراسلي) وقت استجابةٍ أحادي الاتجاه أو زمنًا RTT. ويوضح الجدول التالي بعض الأمثلة على جداءات (حيز النطاق التراسلي×التأخير) لبعض روابط الشبكة النموذجية.

الشبكات عالية السرعة (High-Speed Networks)

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

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

لتقدير أهمية زيادة حيز النطاق التراسلي مقابل وقت الاستجابة الثابت، انظر إلى ما يتطلّبه إرسال ملف حجمه 1 ميجا بايت عبر شبكة 1 ميجابت في الثانية مقابل شبكة 1 جيجابت في الثانية، وكلاهما لهما زمن RTT يساوي 100 ميلي ثانية . في حالة شبكة 1 ميجابت في الثانية، تحتاج إلى 80 مرة ذهابًا وإيابًا لإرسال الملف؛ فخلال كل RTT، يُرسَل 1.25% من حجم الملف. وعلى النقيض، لا يكاد نفس الملف ذو الحجم 1 ميجابايت يشغل قيمة زمن RTT واحدٍ للرابط 1 جيجابت في الثانية، والذي قيمة جداء التأخيرxحيز النطاق الترسلي هي 12.5 ميجا بايت.

يوضح الشكل التالي الفرق بين الشبكتين. في الواقع، يبدو ملف 1 ميجا بايت وكأنه تدفقٌ من البيانات التي يجب إرسالها عبر شبكة 1 ميجابت في الثانية، بينما يبدو وكأنه مجرّد رزمة واحدة على شبكة 1 جيجابت في الثانية. لمساعدتك في فهم هذه النقطة، لاحظ أن ملف 1 ميجا بايت لشبكة 1 جيجابت في الثانية يمكنه أن يمثّل رزمة 1 كيلوبايت لشبكة 1 ميجابت في الثانية.

هناك طريقة أخرى للنظر إلى هذه المسألة هي أنه يمكن إرسال المزيد من البيانات خلال كل زمنٍ RTT على شبكة عالية السرعة، لدرجة أن زمن RTT واحدًا يصبح مقدارًا كبيرًا من الوقت. وبالتالي، في حين أنك لن تبالي بالفرق بين نقل الملفات الذي يستغرق 101 ضعفٍ لزمن RTT عوض 100 ضعفٍ لزمن RTT (فالفرق النسبي هو 1% فقط)، فإنّ الفرق بين ضعفٍ واحدٍ لزمن RTT و ضعفين لزمن RTT يصبح كبيرًا بصورة مفاجئة، بزيادةٍ بنسبة 100%. وبعبارة أخرى، فإن معيار وقت الاستجابة يبدأ في الهيمنة على تفكيرنا حول تصميم الشبكة عوضَ معيار الإنتاجية.

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

اقتباس

الإنتاجية (Throughput) = حجم النقل (TransferSize) \ زمن النقل (TransferTime)

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

اقتباس

TransferTime = RTT + 1/Bandwidth x TransferSize

نستخدم في هذه العلاقة لحساب رسالة طلب تُرسَل عبر الشبكة والبيانات التي ترسَل في الردّ عليها. على سبيل المثال، لنأخذ موقفًا يريد فيه المستخدم إحضار ملف 1 ميجا بايت عبر رابطٍ 1 جيجابت في الثانية مع زمن ذهاب وإياب يبلغ 100 ميلي ثانية. يتضمن هذا كلاً من وقت الإرسال لـ 1 ميجا بايت (1 \ 1 جيجابت في الثانية × 1 ميجابايت = 8 ميلي ثانية) وزمن RTT الذي هو 100 ميلي ثانية، بزمن نقل إجمالي يبلغ 108 ميلي ثانية. هذا يعني أن الإنتاجية الفعلية ستكون : 1 ميجا بايت \ 108 ميلي ثانية = 74.1 ميجابت في الثانية، وليس 1 جيجابت في الثانية.

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

متطلّبات أداء التطبيق الفعال

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

ومع ذلك، فإن بعض التطبيقات قادرة على تعيين حدّ أعلى لمقدار حيز النطاق التراسلي الذي تحتاجه. تطبيقات الفيديو هي مثال رئيسي. لنفترض أنك ترغب في تدفق مقطع فيديو بحجم ربع شاشة التلفزيون القياسية؛ أي أنه يحتوي على دقة 352×240 بكسل. إذا مثّلنا كل بكسل بـ 24 بِت من المعلومات، كما هو الحال بالنسبة للألوان 24 بِت، فسيكون حجم كل إطار (352 × 240 × 24) / 8 = 247.5 كيلوبايت. إذا كان التطبيق يحتاج إلى دعم معدّل إطارات بمقدار 30 إطارًا في الثانية، فإنه قد يطلب معدل إنتاجية يبلغ 75 ميجابت في الثانية. وهكذا، فإن قدرة الشبكة على توفير المزيد من حيز النطاق التراسلي ليست ذات فائدة لمثل هذا التطبيق لأنه يحتوي فقط على الكثير من البيانات لإرسالها في فترة زمنية معينة.

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

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

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

ومثلما يحتاج عرض النطاق التراسلي للتطبيق أن يكون شيئًا مختلفًا عن "كلّ ما يمكن الحصول عليه"، قد تكون متطلبات التأخير الخاص بالتطبيق أعقد من مجرد "أقلّ قدرٍ ممكن من التأخير". في حالة التأخير، لا يهم أحيانًا ما إذا كان زمن الوصول الأحادي للشبكة هو 100 ميلي ثانية أو 500 ميلي ثانية بقدر أهمّية الاختلاف في وقت الاستجابة من رزمةٍ إلى أخرى. يسمى هذا الاختلاف في وقت الاستجابة التقلقل (jitter).

لنأخذ الحالة التي يرسل فيها المصدر رزمةً مرة كل 33 ميلي ثانية، كما هو الحال بالنسبة لتطبيق فيديو يرسل إطارات 30 مرة في الثانية. إذا وصلت الحرزم إلى الوجهة متباعدة بمسافة 33 ميلي ثانية بالضبط، فيمكننا أن نستنتج أن التأخير الذي واجهته كل رزمة في الشبكة كان هو نفسه تمامًا. إذا كان التباعد بين وقت وصول الرزم إلى الوجهة، الذي يسمى أحيانًا الفجوة بين الرزَم (inter-packet gap)، متغيرًا، فيجب أن يكون التأخير الذي يحدثه تسلسل الرزم متغيرًا أيضًا، ويقال أن الشبكة أدخلت تقلقلًا في تدفق الرزمة، كما هو موضح في الشكل التالي. لا يدخل هذا الاختلاف بصفة عامة في رابط فيزيائي واحدٍ، ولكن يمكن أن يحدث عندما تواجه الرزم تأخيرات مختلفة في طابور شبكة تبديل الرزم متعدّدة العُقَد التوجيهية. يتوافق هذا التأخير في الطابور مع عنصر وقت الاستجابة المحدّد مسبقًا في هذا القسم، والذي يتغيّر مع الوقت.

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

منظور الفصل الأول: سرعة الميزة (Feature Velocity)

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

من بين هذه العوامل، يكون السوق هو الأكثر تأثيرًا، ويتوافق مع التفاعل بين مشغلي الشبكات (AT&T و Comcast و Verizon و DT و NTT وChina Unicom على سبيل المثال) ومورّدي معدّات الشبكة (مثل Cisco و Juniper و Ericsson و Nokia و Huawei وNEC) ومزوّدي التطبيقات والخدمات (مثل Facebook و Google و Amazon و Microsoft و Apple و Netflix و Spotify)، وبطبيعة الحال كذلك المشتركين والعملاء (أي الأفراد، ولكن أيضًا المؤسّسات والشركات). لا تكون الخطوط بين هؤلاء الفاعلين واضحة دائمًا، إذ تلعب العديد من الشركات أدوارًا متعددة. وأبرز مثال على ذلك هو مزودو الخدمات السحابية الضخمة، الذين (a) يبنون معدات شبكاتهم الخاصة باستخدام مكوناتٍ قليلة التكلفة، (b) وينشرون ويديرون شبكاتهم الخاصة، (c) ويقدّمون خدمات وتطبيقات للمستخدم النهائي على الشبكة.

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

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

بالنسبة للنقطة الثانية، فإن الشركات التي تبني الشبكات دائمًا ما تكون هي نفسها التي تديرها. وهي تُعرف إجمالًا باسم مشغلي الشبكات (network operators)، وتشمل الشركات المدرجة أعلاه. ولكن إذا نظرنا مرة أخرى إلى مفهوم السحابة للاستلهام منه، فإننا نرى أن مسألة التطوير-مع-التشغيل ليس معمولًا بها على مستوى الشركة فقط، ولكن أيضًا في كيفية تنظيم شركات الخدمات السحابية السريعة لفرقها الهندسية حول نموذج DevOps. (إذا لم تكن لديك دراية بمفهوم DevOps، ننصحك بالاطّلاع على هذين المقالين "ما المقصود بـ DevOps؟" و "لماذا ينبغي على فرق التطوير تبنّي ثقافة DevOps؟" لأخذ فكرة عنه وعن كيفية عمله وتطبيقه).

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

يُطلق على هذا التحول أحيانًا "إضفاء الطابع السّحابي (cloudification)" أو "إضفاء الطابع البرمجي (softwarization)" على الشبكة، ورغم أن الإنترنت كان لديها دائمًا نظام بيئي قوي للبرمجيات، إلا أنّه كان مقصورًا تاريخيًا على التطبيقات التي تعمل في المستوى الأعلى للشّبكة (مثل استخدام واجهة Socket API). ما تغيّر في الوقت الحالي هو تطبيق نفس الممارسات الهندسية المستوحاة من السحابة على الأجزاء الداخلية للشبكة. وتمثّل هذه المقاربة الجديدة، المعروفة بالشبكات المعرّفة برمجيًّا Software) Defined Networks أو اختصارًا SDN)، عاملًا مغيّرًا للعبة، ليس من حيث كيفية التعامل مع التحديات التقنية الأساسية للتأطير والتوجيه والتجزئة/إعادة التجميع وجدولة الرزم والتحكم في الاحتقان والأمن وما إلى ذلك. ولكن من حيث سرعة تطوّر الشبكة لدعم الميزات الجديدة.

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

اقتباس

نوصي لمعرفة المزيد حول DevOps بما يلي: Site Reliability Engineering: How Google Runs ProductionSystems, 2016

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

تُعدّ معماريات الشبكة وتوصيفات البروتوكول من الأمور الأساسية، لكن المخطط الجيد ليس كافيًا لتفسير النجاح الهائل للإنترنت: لقد زاد عدد أجهزة الحاسوب المتصلة بالإنترنت بصورة هائلة على مدار أكثر من ثلاثة عقود (رغم صعوبة الحصول على أرقام دقيقة). إذ قُدِّر عدد مستخدمي الإنترنت بحوالي 4.5 مليار بنهاية عام 2019، أي ما يفوق نصف سكان العالم.

فما الذي يفسر نجاح الإنترنت؟ هناك بالتأكيد العديد من العوامل المساهمة (بما في ذلك البنية الجيدة)، ولكن هناك شيء واحد أعطى للإنترنت هذا النجاح الهائل، وهو أن الكثير من وظائفها تُوفِّرها البرامج التي تعمل على أجهزة الحاسوب ذات الأغراض العامة. وتكمن أهمية ذلك في إمكانية إضافة وظائف جديدة بسهولة من خلال "مجرد مسألة برمجيّة صغيرة". ونتيجة لذلك، ظهرت التطبيقات والخدمات الجديدة بوتيرة لا تصدق.

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

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

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

واجهة برمجة التطبيقات API (المقابس Sockets)

عندما يتعلّق الأمر بتنفيذ تطبيق شبكي، تكون نقطة البداية هي الواجهة التي تصدّرها الشبكة. ونظرًا لأن معظم بروتوكولات الشبكة موجودة في البرمجيات (خاصة تلك الموجودة في المستوى الأعلى في مجموعة البروتوكولات)، ولأن جميع أنظمة الحاسوب تقريبًا تنفذ بروتوكولات الشبكة كجزءٍ من نظام التشغيل، فعندما نشير إلى الواجهة "التي تصدّرها الشبكة"، فإننا نشير بصفة عامة إلى الواجهة التي يوفّرها نظام التشغيل لنظامه الفرعي الخاصّ بالشبكات. غالبًا ما تسمى هذه الواجهة واجهة برمجة التطبيقات (Application Programming Interface أو اختصارًا API) في الشبكة.

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

قبل توصيف واجهة المقبس، من المهم أن تبقي المسألتين التاليتين منفصلتين في ذهنك. المسألة الأولى أن كل بروتوكول يوفر مجموعة معينة من الخدمات (services)، والثانية أن API توفر صياغة نحوية (syntax) يمكن من خلالها استدعاء هذه الخدمات على نظام حاسوبٍ معين. بعد ذلك يكون التنفيذ مسؤولًا عن ربط (mapping) مجموعة العمليات والكائنات الملموسة المحددة بواسطة واجهة برمجة التطبيقات (API) مع مجموعة الخدمات المجرّدة التي يحددها البروتوكول. إذا أنجزت عملًا جيدًا في تعريف الواجهة، فسيكون من الممكن استخدام الصياغة النحوية للواجهة من أجل استدعاء خدمات العديد من البروتوكولات المختلفة. لقد كان هذا الشّمول بالتأكيد هدفًا رئيسيًا لاستخدام واجهة المقبس رغم أنّه بعيد عن الكمال.

ليس مستغربًا أن يكون التجريد الرئيسي لواجهة المقبس هو المقبس (socket). إن أفضل وسيلة لفهم المقبس هي النظر إليه كالنقطة التي ترتبط فيها عمليةُ تطبيقٍ محليٍّ بالشبكة. تحدّد الواجهة عمليات إنشاء المقبس، وربط المقبس بالشبكة، وإرسال واستقبال الرسائل من خلال المقبس، وفصل المقبس. لتبسيط الحديث، سنقتصر على إظهار كيفية استخدام المقابس على بروتوكول TCP:

تتمثّل الخطوة الأولى في إنشاء مقبس باستخدام العملية التالية:

int socket(int domain, int type, int protocol);

تأخذ هذه العملية ثلاث وسائط لسببٍ مهمٍّ هو أنّ واجهة المقبس مصمَّمة لتكون عامة بما يكفي لدعم أي مجموعة بروتوكولات أساسية. على وجه التحديد، يحدّد الوسيط النطاق domain عائلةَ البروتوكولات التي ستُستخدَم : يشير PF_INET إلى عائلة الإنترنت، ويشير PF_UNIX إلى مجموعة تعليمات يونيكس، ويشير PF_PACKET إلى الوصول المباشر إلى واجهة الشبكة (أي أنه يتجاوز رزمة البروتوكولات TCP/IP). يشير الوسيط النوع type إلى دلالات الاتصال، إذ يستخدم SOCK_STREAM للإشارة إلى تدفق بايتات، أمّا SOCK_DGRAM فهو بديل يشير إلى خدمة موجهة للرسالة، مثل تلك التي يوفرها بروتوكول UDP، وحدّد الوسيط protocol البروتوكولَ المحدد الذي سيُستخدَم هنا. في حالتنا هذه، سيكون الوسيط هو UNSPEC لأن الجمع بين PF_INET و SOCK_STREAM يعني TCP. أخيرًا، تكون القيمة المُعادة من socket مِقبضًا (handle) للمقبس الجديد الذي أُنشِئ، أي معرّفًا يمكننا من خلاله الرجوع إلى المقبس في المستقبل، ويمكن إعطاؤه كوسيط للعمليات اللاحقة على هذا المقبس.

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

int bind(int socket, struct sockaddr *address, int addr_len);
int listen(int socket, int backlog);
int accept(int socket, struct sockaddr *address, int *addr_len);

تربط عملية الربط bind، كما يوحي اسمها، على ربط المقبس الجديد الذي أُنشِئ بالعنوان address المحدد. هذا هو عنوان الشبكة الخاصّ بالطرف المحلي أي الخادوم. لاحظ أنه عند استخدامه في بروتوكولات الإنترنت، يكون وسيط العنوان address عبارةً عن بنية بيانات يتضمن عنوان IP الخاص بالخادوم ورقم منفذ TCP. تُستخدَم المنافذ لتحديد العمليّات بطريقة غير مباشرة، فهي شكلٌ من أشكال مفاتيح demux. ويكون رقم المنفذ في العادة عبارةً عن بعض الأرقام التي يُعرَف جيّدًا أنّها خاصّة بالخدمة المقدمة؛ على سبيل المثال، تقبل خواديم الويب عادةً الاتصالات على المنفذ 80.

تحدّد عملية الاستماع listen بعد ذلك عدد الاتصالات التي يمكن أن تكون معلّقةً على المقبس المحدّد. وأخيرًا، تقوم وظيفة القبول accept بالفتح السلبي. إنها عمليةٌ حاجزة (blocking operation) لا تُرجِع أي قيمة إلا بعد أن يُنشِئ طرفٌ بعيدٌ اتصالًا، وعندما يكون الأمر كذلك، فهي تُرجِع مقبسًا جديدًا يتوافق مع هذا الاتصال الذي أُنشِئ لتوّه، ويتضمّن وسيط العنوان address عنوان طرف الاتصال البعيد. لاحظ أنه عندما تُرجِع العملية accept، يكون المقبس الأصلي الذي قُدّم كوسيط مازال موجودًا وما زال يتوافق مع الفتح السلبي؛ إنّه يُستخدَم في الاستدعاءات المستقبلية للعملية accept. تؤدي عملية التطبيق إلى فتحٍ نشط على جهاز العميل؛ أي أنّ العميل يصرّح بمن يريد التواصل معه باستدعاء العملية التالية:

int connect(int socket, struct sockaddr *address, int addr_len);

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

بمجرد إنشاء الاتصال، تستدعي عمليات التطبيق العمليتين التاليتين لإرسال البيانات وتلقيها:

int send(int socket, char *message, int msg_len, int flags);
int recv(int socket, char *buffer, int buf_len, int flags);

ترسل العملية الأولى الرسالة message المحدّدة عبر المقبس socket المحدد، بينما تتلقى العملية الثانية رسالةً من المقبس socket المحدد في المخزَن المؤقت buffer المحدد. تأخذ كلتا العمليتين مجموعةً من الرايات flags التي تتحكم في تفاصيل معيّنة للعملية.

ثورة التطبيقات المدعَّمة بالمقابس

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

مثال تطبيقي

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

طرف العميل (Client)

نبدأ مع جانب العميل، الذي يأخذ اسم الجهاز البعيد كوسيط. ثم يستدعي أداة لينكس لترجمة هذا الاسم إلى عنوان IP للمضيف البعيد. الخطوة التالية هي إنشاء بنية بيانات العنوان (sin) الذي تترقّبه واجهة المقبس. لاحظ أن بنية البيانات هذه تحدّد أننا سنستخدم المقبس للاتصال بالإنترنت (AF_INET). في مثالنا، نستخدم منفذ TCP ذي الرّقم 5432 على أنّه منفذ الخادوم المعروف؛ هذا يعني أنّه منفذٌ لم يُعيّن لأي خدمة إنترنت أخرى. الخطوة الأخيرة في إعداد الاتصال هي استدعاء العملتيين socket و connect. عندما تعيد العملية، يُؤسَّس الاتصال مباشرةً بعد ذلك ويَدخل برنامج العميل في حلقته الرئيسية (main loop)، والتي تقرأ النص من المدخل الاعتيادي وترسله عبر المقبس.

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

#define SERVER_PORT 5432
#define MAX_LINE 256

int
main(int argc, char * argv[])
{
FILE *fp;
struct hostent *hp;
struct sockaddr_in sin;
char *host;
char buf[MAX_LINE];
int s;
int len;

if (argc==2) {
host = argv[1];
}
else {
fprintf(stderr, "usage: simplex-talk host\n");
exit(1);
}

/* ترجمة اسم المضيف إلى عنوان أي بي النظير */    
hp = gethostbyname(host);
if (!hp) {
fprintf(stderr, "simplex-talk: unknown host: %s\n", host);
exit(1);
}

/* بناء بينة بيانات العنوان */
bzero((char *)&sin, sizeof(sin));
sin.sin_family = AF_INET;
bcopy(hp->h_addr, (char *)&sin.sin_addr, hp->h_length);
sin.sin_port = htons(SERVER_PORT);

/* active open */
if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) {
perror("simplex-talk: socket");
exit(1);
}
if (connect(s, (struct sockaddr *)&sin, sizeof(sin)) < 0)
{
perror("simplex-talk: connect");
close(s);
exit(1);
}
/* الحلقة الرئيسية: الحصول على سطور من النص وإرسالها */
while (fgets(buf, sizeof(buf), stdin)) {
buf[MAX_LINE-1] = '\0';
len = strlen(buf) + 1;
send(s, buf, len, 0);
}
}

طرف الخادوم (Server)

يجري الأمر كذلك في الخادوم بنفس البساطة. فهو يُنشِئ أولًا بنية بيانات العنوان عبر تحديد رقم المنفذ الخاص به (SERVER_PORT). وبما أنّه لا يُحدّد عنوان IP، فإن برنامج التطبيق يكون على استعدادٍ لقبول الاتصالات على أيّ عنوان IP للمضيف المحلي. بعد ذلك، يُجري الخادوم الخطوات الأولية التي يتضمّنها الفتح السلبي؛ إذ يُنشِئ المقبس، ويربطه بالعنوان المحلّي، ويُعيّن الحد الأقصى لعدد الاتصالات المعلّقة المسموح بها. وأخيرًا، تترقّب الحلقة الرئيسية محاولة الاتصال من مضيف بعيدٍ، وعندما يتمّ ذلك، فهي تتلقى الحروف التي تصل عند الاتصال وتطبعها:

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

#define SERVER_PORT  5432
#define MAX_PENDING  5
#define MAX_LINE     256

int
main()
{
struct sockaddr_in sin;
char buf[MAX_LINE];
int buf_len, addr_len;
int s, new_s;

/* بناء بنية بيانات العنوان */
bzero((char *)&sin, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = INADDR_ANY;
sin.sin_port = htons(SERVER_PORT);

/* إعداد الفتح السلبي */
if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) {
perror("simplex-talk: socket");
exit(1);
}
if ((bind(s, (struct sockaddr *)&sin, sizeof(sin))) < 0) {
perror("simplex-talk: bind");
exit(1);
}
listen(s, MAX_PENDING);

/* انتظر الاتصال، ثم استقبل النص اطبعه */
while(1) {
if ((new_s = accept(s, (struct sockaddr *)&sin, &addr_len)) < 0) {
perror("simplex-talk: accept");
exit(1);
}
while (buf_len = recv(new_s, buf, sizeof(buf), 0))
fputs(buf, stdout);
close(new_s);
}
}

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

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

طوَّر مصممو الشبكات للمساعدة في التعامل مع هذا التعقيد مخططات عامة، تسمى عادةً معماريات الشبكات (network architectures)، والتي توجّه تصميم الشبكات وتنفيذها. يحدّد هذا القسم بعناية أكبر ما نعنيه بمعمارية الشبكة من خلال تقديم الأفكار المركزية المشتركة بين جميع معماريات الشبكة. كما يعرض أيضًا معماريتين من أكثر المعماريات المرجعية انتشارًا في عالم الشبكات وهما معمارية OSI أو معمارية الطبقات السبع ومعمارية الإنترنت.

الطبقات (Layering) والبروتوكولات (Protocols)

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

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

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

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

إذا اعتمدنا على هذه المناقشة للطبقات كأساسٍ، سنكون على استعداد لمناقشة معمارية الشبكة بصورة أدق. بالنسبة للمبتدئين، تسمى الكائنات المجردة التي تشكل طبقات نظام الشبكة بالبروتوكولات. أي أن البروتوكول يوفر خدمة اتصال تستخدمها كائنات المستوى الأعلى (مثل عمليات التطبيق، أو ربما بروتوكولات المستوى الأعلى) لتبادل الرسائل. على سبيل المثال، يمكننا أن نتخيل شبكةً تدعم بروتوكول الطلب/الاستجابة وبروتوكول تدفق الرسائل، المطابقين لقنوات الطلب/الاستجابة وتدفّق الرسائل التي ناقشناها سابقًا.

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

ثانيًا، يحدّد البروتوكول واجهة نظيرٍ (peer interface) من أجل نظيره على جهازٍ آخرٍ. تحدد هذه الواجهة الثانية شكل ومعنى الرسائل المتبادلة بين نظراء البروتوكول لتنفيذ خدمة الاتصال. وهذا سيحدّد الطريقة التي يتواصل بها بروتوكول الطلب/الاستجابة على أحد الأجهزة مع نظيره على جهاز آخر. في حالة HTTP، على سبيل المثال، تحدّد مواصفات البروتوكول بالتفصيل كيفية تنسيق الأمر GET، والوسائط التي يمكن استخدامها مع الأمر، وكيف ينبغي أن يستجيب خادوم الويب عندما يتلقى مثل هذا الأمر.

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

باستثناء مستوى العتاد الذي يتواصل فيه النظراء بصفة مباشرة فيما بينهم عبر وسيط فيزيائي، يكون الاتصال من نظير لنظير بصفة غير مباشرة، إذ يتواصل كلّ بروتوكول مع نظيره عن طريق تمرير الرسائل إلى أحد بروتوكولات المستوى الأدنى، والذي يسلمها بدوره إلى نظيره. وعلاوة على ذلك، من المحتمل أن يكون هناك أكثر من بروتوكول واحد على أي مستوى معين، يقدم كل منها خدمة اتصال مختلفة. لذلك فإننا نمثل مجموعة البروتوكولات التي تشكل نظام شبكة برسم بياني للبروتوكول (protocol graph). تتوافق عُقد الرسم البياني مع البروتوكولات، وتمثل الأضلاع (edges) علاقة اعتمادية (depends on). على سبيل المثال، يوضّح الشكل التالي رسمًا بيانيًا للبروتوكول لنظام الطبقات الافتراضي الذي ناقشناه، إذ ينفّذ البروتوكولان RRP (بروتوكول الطلب / الاستجابة (Request/Reply Protocol)) و MSP (بروتوكول تدفّق الرسائل (Message Stream Protocol)) نوعين مختلفين من قنوات عمليةٍ لعملية، ويعتمد كلاهما على بروتوكول مضيفٍ لمضيف (Host-to-Host Protocol أو اختصارًا HHP) الذي يوفّر خدمة اتصال من مضيف لمضيف.

في هذا المثال، نستطيع أن نفترض أن برنامج الوصول إلى الملفات على المضيف 1 يريد إرسال رسالة إلى نظيره في المضيف 2 باستخدام خدمة الاتصال التي يقدمها بروتوكول RRP. في هذه الحالة، يطلب تطبيق الملف من بروتوكول RRP إرسال الرسالة نيابة عنه. وللتواصل مع نظيره، يستدعي بروتوكولُ RRP خدماتِ بروتوكول HHP، والذي بدوره ينقل الرسالة إلى نظيره على الجهاز الآخر. بمجرد وصول الرسالة إلى نسخة بروتوكول HHP على المضيف 2، يمرّر بروتوكول HHP الرسالة إلى بروتوكول RRP، والذي بدوره يُسلّمها إلى تطبيق الملف. في هذه الحالة الخاصّة، يُقال أن التطبيق يستخدم خدمات رزمة البروتوكولات RRP/HHP.

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

نستطيع أن نتخيل العديد من البروتوكولات والرسوم البيانية للبروتوكولات المختلفة التي تلبي متطلبات الاتصال لمجموعة من التطبيقات. لحسن الحظ، توجد هيئات دولية للتقييس، مثل فرقة العمل المعنية بهندسة الإنترنت (IETF) ومنظمة المعايير الدولية (ISO)، والتي تضع معايير الرسم البياني الخاص بالبروتوكول. نسمي مجموعة القواعد التي تحكم شكل ومحتوى الرسم البياني للبروتوكول بنية الشبكة. ورغم أنّ هذا لا يدخل في نطاق هذا الكتاب، فقد وضعت هيئات التقييس إجراءات محددة بدقّة لتقديم البروتوكولات، والتحقّق منها، والموافقة عليها في هياكلها الخاصّة. سوف نَصِف فيما بعد باختصارٍ المعماريات التي حددتها IETF و ISO، ولكن هناك قبل ذلك أمران إضافيان نحتاج إلى شرحهما حول آليات وضع البروتوكول ضمن طبقات.

التغليف (Encapsulation)

لنأخذ ما يحدث عندما يرسل أحد البرامج التطبيقية رسالة إلى نظيره عبر تمرير الرسالة إلى RRP. من زاوية النظر للبرتوكول RRP، فإن الرسالة التي يقدّمها التطبيق هي سلسلة من البايتات غير المُفسَّرة. إنّ بروتوكول RRP لا يهتمّ بنوعية هذه البايتات، هل تمثّل مجموعة من الأعداد الصحيحة أو رسالة بريد إلكتروني أو صورة رقمية أو أيا كان؛ فهو ببساطة مسؤول عن إرسالها إلى نظيره. ومع ذلك، يتوجّب على بروتوكول RRP توصيل معلومات التحكّم إلى نظيره، وتوجيهه لكيفية التعامل مع الرسالة عند تلقّيها، وذلك عبر إرفاق ترويسةٍ بالرسالة. بصورة عامّة، تكون الترويسة عبارة عن بنية بيانات صغيرة، تتراوح بين بضعة بايتات إلى بضع عشرات من البايتات، تستخدمها النظراء للتواصل فيما بينها. وكما يوحي اسمها، تُرفَق الترويسة (header) عادةً في مقدمة الرسالة. ومع ذلك، في بعض الحالات، تُرسَل معلومات التحكم هذه من نظير إلى نظيرٍ في نهاية الرسالة، وفي هذه الحالة تسمى تذييلًا (trailer). يُحدّد بروتوكول RRP الصيغةَ الدقيقة للترويسةِ المرفقة من خلال مواصفات البروتوكول الخاصة به. وتسمى بقية الرسالة، أي البيانات التي تُرسَل نيابة عن التطبيق، نصّ (body) أو حمولة (payload) الرسالة. وهكذا، نقول أنّ بيانات التطبيق مُغلّفة في الرسالة الجديدة التي أنشأها بروتوكول RRP.

بعد ذلك، تتكرّر عملية التغليف هذه في جميع مستويات الرسم البياني للبروتوكول. فمثلًا، يغلّف البروتوكول HHP رسالة RRP بترويسة مرفقة خاصّة به. وإذا افترضنا أنّ HHP يرسل الرسالة إلى نظيره عبر الشبكة، فعندما تصِل الرسالة إلى المضيف الوجهة، فإنّ معالجتها الآن تتمّ بالترتيب المعاكس: أي أنّ HHP يفسّر ترويسة نظيره HHP التي في مقدمة الرسالة أولًا (هذا يعني أنّه يتّخذ الإجراء المناسبَ بناءً على محتوى الترويسة)، ثمّ تمرّر حمولة الرسالة وليس ترويسة HHP إلى البروتوكول RRP. ويتّخذ هذا الأخير بدوره أي إجراء تشير إليه ترويسة RRP التي ألحقها نظيره بالرسالة وتمرّر حمولة الرسالة و ليس ترويسة RRP إلى البرنامج التطبيقي. تبقى الرسالة التي مرّرها RRP إلى التطبيق على المضيف 2 هي نفسها تمامًا التي مرّرها التطبيق إلى RRP على المضيف 1. إذ لا تظهر للتطبيق أي ترويسة مرفقة بالرسالة بغرض تنفيذ خدمات الاتصال ذات المستوى الأدنى. ويوضّح الشكل التالي هذه العملية بالكامل. لاحظ أنه في هذا المثال، يمكن أن تفحص العُقد الموجودة في الشبكة (الموجّهات والمبدّلات، على سبيل المثال) ترويسةَ HHP الموجودة في مقدمة الرسالة:

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

3.3.1 الدمج أو تعدد الإرسال (Multiplexing) وفكّ الدمج أو فك تعدد الإرسال (Demultiplexing) ينبغي التذكير أن الفكرة الأساسية لتبديل الرزم هي دمج تدفقات البيانات المتعدّدة عبر رابطٍ فيزيائي واحد. وتنطبق هذه الفكرة نفسها صعودًا ونزولًا على الرسم البياني للبروتوكول، وليس فقط لتبديل العقد. يمكننا التفكير في بروتوكول RRP على أنه ينفّذ قناة اتصال منطقية، مع إرسال رسائل من تطبيقين مختلفين تُدمَج عبر هذه القناة في المضيف المصدر ثم يُفَكّ دمجها مرة أخرى نحو التطبيق المناسب في المضيف الوِجهَة.

هذا يعني من الناحية العملية، ببساطةٍ أن الترويسة التي يُلحِقها RRP برسائله تحتوي على معرّف يحدّد التطبيق الذي تنتمي إليه الرسالة. نسمي هذا المعرّف مفتاح فكّ دمج (demultiplexing) بروتوكول RRP، أو مفتاح demux للاختصار. في المضيف المصدر، يُضَمِّن بروتوكول RRP مفتاح demux المناسب في ترويسته. وعندما تُسلَّم الرسالة إلى بروتوكول RRP على المضيف الوجهة، فإنه يكشف عن الترويسة، ويفحص مفتاح demux، ويفكّ دمج الرسالة نحو التطبيق المناسب.

ليس البروتوكول RRP فريدًا في دعمه للدمج (أو تعدّد الإرسال)، فكل البروتوكولات تقريبا تنفّذ هذه الآلية. على سبيل المثال، يحتوي بروتوكول HHP على مفتاح demux خاصٍّ به لتحديد الرسائل التي تُمرّر إلى بروتوكول RRP وأيها ستُمرّر إلى بروتوكول MSP. ومع ذلك، لا يوجد اتفاقٌ موحّد بين البروتوكولات، حتى تلك الموجودة داخل معمارية شبكة واحدة، على محتوى مفتاح demux بالضبط. تستخدم بعض البروتوكولات حقلَ 8 بِتات (بمعنى أنها يمكن أن تدعم 256 بروتوكولًا عالي المستوى فقط)، بينما يستخدم البعض الآخر حقول 16 أو 32 بِت. وكذلك، تحتوي بعض البروتوكولات على حقل واحدٍ لفكّ الدمج في ترويستها، بينما يحتوي البعض الآخر منها على زوجٍ من حقول فكّ الدمج. في الحالة الأولى، يُستخدَم نفس مفتاح demux على جانبي الاتصال، بينما يستخدم كل طرفٍ في الحالة الثانية مفتاحًا مختلفًا لتحديد البروتوكول عالي المستوى (أو برنامج التطبيق) الذي ستُسلَّم الرسالة إليه.

نموذج OSI ذو الطبقات السبع

تعدّ منظّمة ISO واحدة من أوائل المؤسسات التي حددت بصفة رسميّة طريقة مشتركة لتوصيل أجهزة الحاسوب. ويوضّح الشكل التالي البنية التي وضعتها، والتي يطلق عليها معمارية OSI اختصارًا للعبارة Open Systems Interconnection أي ربط الأنظمة المفتوحة، وهي تُقسّم وظائف الشبكة إلى سبع طبقات، إذ يُنفّذ بروتوكول واحد أو أكثر الوظيفة المعيّنة لطبقة معينة. بهذا المعنى، فإن الرسم التخطيطي الوارد ليس هو الرسم البياني للبروتوكول، في حد ذاته، بل هو نموذج مرجعي للرسم البياني للبروتوكول. وغالبًا ما يشار إليه باسم نموذج الطبقات السبع. ورغم أنّه لا توجد شبكة قائمة على OSI تعمل اليوم، إلا أنّ المصطلحات التي حددتها لا تزال تُستخدَم على نطاق واسع، لذلك لا تزال تستحق أن نلقي عليها نظرة سريعة.

إذا بدأنا من الأسفل واتجهنا صعودًا، نجد أنّ الطبقة المادية (أو الفيزيائية) (physical layer) تعالج إرسال البِتات الخام عبر رابطٍ للاتصال. ثم تجمع طبقة ربط البيانات (data link layer) تدفقًا من البِتات في مجموعة أكبر تُسمى إطارًا (frame). ويتجسّد في العادة مستوى ربط البيانات من خلال مبدّلات الشبكة إلى جانب برامج تشغيل الأجهزة التي تعمل في نظام تشغيل العقدة. هذا يعني أن الإطارات هي التي تُسلَّم فعليًا إلى المضيفين، وليست البِتات الخام. ثمّ تعالج طبقة الشبكة (network layer) التوجيه بين العقد داخل شبكة تبديل الرزم. في هذه الطبقة، تُسمى وحدة البيانات المتبادلة بين العُقَد عادة رزمةً (packet) عوضًا عن الإطار، رغم أنّها نفس الشيء أساسًا. تُنَفَذ الطبقات الثلاث السفلية على جميع عُقَد الشبكة، بما في ذلك المبدّلات داخل الشبكة والمضيفات المتصلة بالجزء الخارجي للشبكة. بعد ذلك، تُنفِّذ طبقة النقل (transport layer) ما سمّيناه لحدّ الآن قناةَ عمليةٍ لعملية. تسمى وحدة البيانات المتبادلة هنا بصفة شائعة رسالةَ (message) عوضًا عن رزمة أو إطار. تعمل طبقة النقل والطبقات الأعلى في العادة فقط على المضيفين النهائيين وليس على المبدّلات الوسيطة أو الموجهات.

وإذا قفزنا إلى الطبقة العليا (أي السابعة) واتجهنا نزولًا، فسنجد طبقة التطبيق (application layer). وتتضمن بروتوكولات طبقة التطبيق أشياء مثل بروتوكول نقل النص الترابطي (HTTP) الذي يُعدّ أساس شبكة الويب العالمية إذ يُمَكّن متصفحات الويب من طلب صفحات من خواديم الويب. ثم هناك طبقة العرض (presentation layer) التي تهتمّ بتنسيق البيانات المتبادلة بين النظراء. فهي تبيّن، على سبيل المثال، ما إذا كان عددٌ صحيحٌ مبنيًا على 16 أو 32 أو 64 بِتًا، أو هل يُنقَل البايت الأكثر أهمية في الأول أم في الأخير، أو كيف يكون تنسيق تدفّق الفيديو… وما إلى ذلك. ونجد أخيرًا طبقة الجلسة (session layer) التي توفّر مساحةً اسمية تُستخدم لربط مسارات النقل المختلفة المحتملة التي تشكّل جزءًا من تطبيق واحد. على سبيل المثال، قد تعمل على إدارة تدفقٍ صوتي وتدفقٍ للفيديو يندمجان معًا في تطبيق مؤتمرات عن بعد.

معمارية الإنترنت (Internet Architecture)

يوضّح الشكل السابق بنية الإنترنت، والتي تسمى أحيانًا بنية TCP/IP نسبةً إلى بروتوكوليها الرئيسيين TCP وIP. ويرد تمثيل بديل لها في الشكل التالي. وقد تطوّرت معمارية شبكة الإنترنت بناءً على تجارب سابقةٍ لشبكةٍ لتحويل الرزم كانت تُسمى آربانيت (ARPANET). أتى تمويل الإنترنت وآربانيت من وكالة مشاريع البحث المتقدم (Advanced Research Projects Agency أو اختصارًا ARPA)، وهي واحدةٌ من وكالات تمويل البحث والتطوير التابعة لوزارة الدفاع الأمريكية. وكانت شبكتا الإنترنت وآربانيت موجودتان قبل معمارية OSI، وكان للخبرة المكتسبة من بنائهما تأثيرٌ كبيرٌ على نموذج OSI المرجعي. يوضح الشكل التالي الرسم البياني لبروتوكول الإنترنت:

مع أنّه يمكن تطبيق نموذج OSI المكوّن من 7 طبقات، بقليلٍ من القدرة على التّخيل، على شبكة الإنترنت، فإنّه غالبًا ما تُستخدَم عوضًا عن ذلك مجموعةٌ أبسط. يوجد في المستوى الأدنى مجموعةٌ متنوعة من بروتوكولات الشبكة، يرمز لها على النحو التالي: NET1 وNET2 وإلى ما ذلك. من الناحية العملية، تُنفَّذ هذه البروتوكولات من خلال مجموعة من العتاد (مثل مبدّل الشبكة) والبرمجيات (مثل برنامج تشغيل جهاز الشبكة). على سبيل المثال، قد تجد بروتوكولات خاصة الإيثرنت (Ethernet) أو بالشبكة اللاسلكية (مثل معايير واي فاي 802.11) في هذه الطبقة. (قد تتضمن هذه البروتوكولات بدورها العديد من الطبقات الفرعية، لكن لا تفترض معمارية الإنترنت أي شيءٍ بخصوصها). تتكون الطبقة التالية من بروتوكول واحد، هو بروتوكول الإنترنت (IP). هذا هو البروتوكول الذي يدعم الربط البيني لتقنيات الشبكات المتعدّدة في شبكة متشابكة منطقية واحدة. تحتوي الطبقة الموجودة أعلى طبقة IP على بروتوكولين رئيسيين، هما بروتوكول التحكم في الإرسال (Transmission Control Protocol أو اختصارًا TCP) وبروتوكول مخطّط بيانات المستخدم (User Datagram Protocol أو اختصارًا UDP). يوفر بروتوكولا TCP وUDP قنوات منطقية بديلة لبرامج التطبيق، إذ يوفّر بروتوكول TCP قناة موثوقة لتدفق البايتات، ويوفّر بروتوكول UDP قناة غير موثوقةٍ لتسليم مخطط البيانات (يمكن عد مخطط البيانات بمثابة مرادف للرسالة). في لغة الإنترنت، يُطلق على بروتوكولي TCP وUDP أحيانًا بروتوكولات من طرفٍ لطرف رغم صحة الإشارة إليهما على أنهما بروتوكولا نقل.

يعمل فوق طبقة النقل مجموعة من بروتوكولات التطبيق، مثل HTTP وFTP وTelnet (تسجيل الدخول عن بُعد (remote login)) وSMTP (بروتوكول نقل البريد البسيط (Simple Mail Transfer Protocol))، والتي تتيح التشغيل البيني للتطبيقات الشائعة. لكي تفهم الفرق بين التطبيق وبروتوكول طبقة التطبيق، فكّر في جميع متصفحات الويب المختلفة المتاحة حاليًا أو التي كانت متاحة في السابق (على سبيل المثال فايرفوكس وكروم وسفاري وموزايك وإنترنت إكسبلورر). هناك عدد كبير مماثل من التطبيقات المختلفة لخواديم الويب. إنّ ما يُتيح لك استخدام أيّ من برامج التطبيقات هذه للوصول إلى موقع معين على الويب هو أنها تتوافق جميعها مع بروتوكولِ طبقة التطبيق نفسه أي بروتوكول HTTP. لكن، أحيانًا ينطبق المصطلح نفسه بصورة مربكة على كلّ من التطبيق وبروتوكول طبقة التطبيق الذي يستخدمه (على سبيل المثال، غالبًا ما يُستخدم بروتوكول FTP كاسمٍ لتطبيق يقوم على البروتوكول FTP). يوضح الشكل الآتي شكلًا بديلًا لمعمارية الإنترنت، حيث يشير مصطلح طبقة "الشبكة الفرعية (subnetwork)" على ما تشير إليه طبقة "الشبكة (network)" والتي ترمز الآن إلى "الطبقة 2" (تيمّنًا بنموذج OSI).

إنّ معظم الأشخاص الذين يعملون بنشاط في مجال الشبكات على دراية بكلّ من معمارية الإنترنت ومعمارية OSI ذات الطبقات السبع، وهناك اتفاق عام حول كيفية توافق الطبقات بين المعماريتين. إذ تُماثل طبقة التطبيق في معمارية الإنترنت الطبقة 7 في معمارية OSI، وتماثل طبقة النقل الطبقة 4، أمّا طبقة IP (طبقة الشبكة) فهي الطبقة 3، وطبقة الرّبط أو الطبقة الفرعية أسفل IP فهي الطبقة 2.

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

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

الميزة الثالثة لمعمارية الإنترنت (أو بصورة أدقّ، لثقافة IETF) هي أنّه من أجل تضمين بروتوكول جديد بصفة رسمية في المعمارية، يجب أن يكون هناك توصيفٌ للبروتوكول وعلى الأقل تمثيل تطبيقي واحدٌ للتوصيف (ويفضّل أن يكون اثنان). ويعدّ وجود تطبيقات عمليّة للمعايير أمرًا ضروريًا لكي تعتمَدها IETF. يساعد هذا الجانب الثقافي لدى مُجتمع التصميم على ضمان إمكانية تنفيذ بروتوكولات المعمارية بكفاءة. ربّما يكون أفضل مثال على القيمة التي توليها ثقافة الإنترنت للبرامج العملية هي ذلك الاقتباس المكتوب على القمصان التي تُلبس عادةَ في اجتماعات IETF:

اقتباس

"نحن نرفُض الملوك والرؤساء وعملية التصويت. إنّنا نُؤمِن بتوافق الآراء بالشيفرة المصدريّة السليمة". (ديفيد كلارك)

التقييس (Standardization) و منظمة IETF

رغم أننا نسميها "معمارية الإنترنت" عوضًا عن "معمارية IETF"، إلا أنه من الإنصاف القول أن IETF هي هيئة التقييس الأساسية المسؤولة عن تعريفها وعن تحديد العديد من بروتوكولاتها، مثل TCP وUDP، وIP، وDNS ، وBGP. لكن هندسة الإنترنت تشمل أيضًا العديد من البروتوكولات التي تحدّدها المنظمات الأخرى، بما في ذلك معايير إيثرنت 802.11 و الواي فاي الخاصة بمنظمة IEEE، ومواصفات الويب HTTP/HTML الخاصة بمنظمة W3C، ومعايير الشبكات الخلوية 4G و 5G الخاصة بمنظمة 3GPP، ومعايير ترميز الفيديو H.232 الخاصة بمنظمة ITU-T، وغيرها الكثير.

بالإضافة إلى تعريف البنى وتحديد البروتوكولات، هناك منظمات أخرى تدعم الهدف الأكبر وهو التشغيل البيني (interoperability). أحد الأمثلة على ذلك هو IANA (هيئة أرقام الإنترنت المخصّصة Internet Assigned Numbers Authority)، والتي كما يوحي اسمها، مسؤولة عن تسليم المعرّفات الفريدة اللازمة لجعل البروتوكولات تعمل. وتعدّ IANA، بدورها، قسمًا داخل ICANN (مؤسسة الإنترنت للأسماء والأرقام المُخصصة Internt Corporation for Assigned Names and Numbers)، وهي منظمة غير ربحية مسؤولة عن الإشراف العام على الإنترنت.

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

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

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

أصحاب المصلحة (Stakeholders)

مثلما ذكرنا سابقًا، يمكن للطالب الذي يدرس الشبكات أن يأخذ عدة وجهات نظر. عندما أُلِّفَت الطبعة الأولى الإنجليزية من هذا الكتاب، لم يكن لدى غالبية السكان اتصال بالإنترنت على الإطلاق، وأولئك الذين حصلوا عليه تمكّنوا من ذلك أثناء العمل أو في الجامعة أو عن طريق مودِم الاتصال الهاتفي (dial-up modem) في المنزل. كانت التطبيقات الشائعة حينذاك تعَدّ على أصابع اليد الواحدة. وهكذا، مثل معظم الكتب في ذلك الوقت، ركّز الكتاب على منظور شخصٍ يعمل على تصميم معدّات وبروتوكولات الشبكات. وسوف نواصل التركيز على هذه الرّؤية، ونأمل أنه بعد قراءة هذا الكتاب، سوف تعرف كيفية تصميم معدّات وبروتوكولات الشبكات المستقبلية.

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

• مبرمجُ التطبيق (application programmer): يعرض قائمةَ الخدمات التي يحتاجها تطبيقه على سبيل المثال، ضمان تسليم كل رسالة يرسلها التطبيق دون خطأٍ في غضون فترة زمنية معيّنة أو القدرة على التبديل بأمان بين الاتصالات المختلفة بالشبكة عندما يتنقّل المستخدم بينها.
• مُشغّل الشبكة (network operator): يعرض خصائص النظام الذي يسهل تدبيره وإدارته على سبيل المثال، حيث يمكن عزل الأخطاء بسهولة، ويمكن إضافة أجهزة جديدة إلى الشبكة وإعدادها بصفة صحيحة، ويكون من السّهل حساب مقدار الاستخدام.
• مصمّم الشبكة (network designer): يعرض خصائص التصميم الفعّال نسبةً إلى التكلفة على سبيل المثال، أن يكون استخدام موارد الشبكة بكفاءة وتخصيصها إلى حدّ ما لمختلف المستخدمين. ومن الرّاجح أيضًا أن تكون لمسألة الأداء أهمّية في هذا السياق.

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

الاتصال القابل للتوسع (Scalable Connectivity)

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

لفهم متطلبات الاتصال بصورة كاملة، نحتاج إلى إلقاء نظرة فاحصة على كيفية توصيل أجهزة الحاسوب في الشبكة. إذ يحدث الاتصال على العديد من المستويات المختلفة. في المستوى الأدنى، يمكن أن تتكوّن الشبكة من جهازي حاسوب أو أكثر متصلة مباشرة ببعض الوسائط الفيزيائية، مثل الكابل المِحوري (coaxial cable) أو الألياف البصرية. نسمي مثل هذا الوسيط الفيزيائي رابطًا (link)، وغالبًا ما نشير إلى أجهزة الحاسوب التي تربطها هذه الوسائط بالعُقَد (nodes). (أحيانًا لا تكون العقدة جهاز حاسوب بل قطعةً فيزيائية أكثر تخصيصًا في الجهاز، لكننا نتجاهل هذا التمييز لأغراض هذه المناقشة). كما هو موضّح في الشّكل التالي، تقتصر الروابط الفيزيائية أحيانًا على عُقدتين (يُسمّى مثل هذا الرابط "من نُقطة لِنُقطة" point-to-point) كما هو موضح في القسم (أ) من الشكل التالي، بينما في حالات أخرى قد تشترك أكثر من عقدتين في رابطٍ فيزيائي واحد (ويُسمّى مثل هذا الرابط متعدّد الوصول) كما هو موضح في القسم (ب) من الشكل التالي. تعدّ الروابط اللاسلكية، مثل تلك التي توفرها الشبكات الخلوية وشبكات الواي فاي، فئةً مهمة من روابط الوصول المتعدد. دائمًا ما يكون حجم روابط الوصول المتعدد محدودًا، من حيث المسافة الجغرافية التي يمكن أن تغطيها وعدد العقد التي يمكنها توصيلها. لهذا السبب، يطبّقون في الغالب ما يسمى بقاعدة الميل الأخير، ويربطون المستخدمين النهائيين ببقية الشبكة.

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

يُظهر الشكل التالي مجموعةً من العُقد، كلّ منها مرتبط بواحد أو أكثر من الروابط من نقطة لنقطة. تعمل هذه العقد المرفقة برابطين على الأقل على تشغيل البرامج التي تعيد توجيه البيانات التي يجري تلقيها على رابط واحد من رابطٍ آخر. إذا نُظِّمت بطريقة منظمة، فإن عُقد التوصيل هذه تُشكّل شبكة تبديل (switched network). وهناك أنواع عديدة من شبكات التبديل، لكن أكثرها شيوعًا هي شبكات تبديل الدارات (circuit switched) وتبديل الرزم (packet switched). يُستخدَم النوع الأول بصفة خاصّة في نظام الهاتف، بينما يُستخدَم النوع الثاني في الغالبية العظمى في شبكات الحواسيب، وهو ما سيكون محور هذا الكتاب. (ومع ذلك، نلاحظ عودة نسبية لنظام تبديل الدارات في مجال الشبكات البصرية، والذي اتضحت أهمّيته بحكم تزايد الطلب على سعة الشبكة باستمرار). وتتجلى الميزة المهمّة في شبكات تبديل الرزم في أنّ العُقَد في هذه الشبكات ترسل كُتلًا منفصلة من البيانات فيما بينها. فَكّر في هذه الكتل من البيانات على أنها تتطابق مع جزء من بيانات التطبيق مثل ملف أو جزء من بريد إلكتروني أو صورة. نحن نسمي كل كتلة من البيانات إما رزمة أو رسالة، والآن نستخدم هذه المصطلحات بصفةٍ تبادليةٍ.

تستخدم شبكاتُ تبديل الرزَم (Packet-switched networks) في العادة إستراتيجيةً تسمى خزّن وأعِد التوجيه (store-and-forward). ومثلما يوحي هذا الاسم، تتلقى كل عقدة في شبكة التخزين وإعادة التوجيه أولًا رزمة كاملة عبر رابطٍ ما، وتُخزّن الرزمة في ذاكرتها الداخلية، ثم تُعيد توجيه الحزمة الكاملة إلى العقدة التالية. على النقيض من ذلك، تُنشِئ شبكة تبديل الدارات أولًا دارةً مُخصّصة عبر سلسلة من الروابط ثم تسمح للعقدة المصدر بإرسال مجرىً من البِتات عبر هذه الدارة إلى عقدةٍ وِجهةٍ. إنّ الدافع الرئيسي لاستخدام تبديل الرزم عوضًا عن تبديل الدارات في الشبكة الحاسوبية هو عنصر الكفاءة، الذي نناقشه في القسم الفرعي التالي.

تُميز السحابة في الشكل السابق بين العُقد الموجودة في الداخل التي تُزوّد الشبكة (ويطلق عليها عادة مُبدّلات (switches)، ووظيفتها الأساسية هي تخزين الرزم وإعادة توجيهها) والعُقَد الموجودة خارج السحابة التي تستخدم الشبكة (فتُسمى عادةً المضيفين (hosts)، وهم الذين يدعمون المستخدمين ويديرون برامج التطبيقات). ينبغي الإشارة أيضًا أنّ السحابة هي واحدة من أهم رموز شبكات الحواسيب. نستخدم سحابة للدلالة على أي نوع من الشبكات، سواء كان رابطًا واحدًا من نقطة لنقطة، أو رابطًا متعدّد الوصول، أو شبكة تبديل. وبالتالي، كلّما رأيت سحابة مستخدمة في الشكل، يمكنك التفكير فيها كعنصر يمثّل أيًّا من تقنيات الشبكات التي يغطيها هذا الكتاب.

اقتباس

لقد كان استخدامُ السحب لتمثيل الشبكات سابقًا لظهور مصطلح الحوسبة السحابية (cloud computing) بعقدين من الزمن على الأقلّ، ولكنّ هناك اتصالًا وثيقًا بصورة متزايدة بين هذين الاستخدامين، وهو ما نستكشفه في مناقشة المنظور في نهاية كل فصل.

يُظهر الشكل التالي الطريقة الثانية التي يمكن من خلالها توصيل مجموعة من الحواسيب بصفة غير مباشرة. في هذه الحالة، هناك مجموعة من الشبكات المستقلة (السحابات) المتصلة بعضها ببعضٍ لتشكيل شبكة متشابكة (internetwork) أو بمعنى آخر شبكة إنترنت. نعتمد اصطلاح إنترنت للإشارة إلى شبكة متشابكةٍ عامة من الشبكات بحرف "i" صغير في المفردة الإنجليزية (internet)، ونعتمد لشبكة الإنترنت TCP/IP التي نستخدمها جميعًا كل يوم الحرف الكبير "I" في المفردة الإنجليزية (Internet). عادةً ما تُسمى العقدة المتصلة بشبكتين أو أكثر موجِّهًا (router) أو بوابةً (gateway)، وهي تلعب دورًا مماثلًا تمامًا للمبدّل (switch)، فهي تعيد توجيه الرسائل من شبكةٍ إلى أخرى. لاحظ أنه يمكن عدُّ شبكة إنترنت في حد ذاتها نوعًا آخر من الشبكات، مما يعني أنه يمكن بناء شبكةٍ متشابكة من مجموعةٍ من الشبكات المتشابكة. وبالتالي، يمكننا بصفة متكرّرة بناء شبكات كبيرة بصورةٍ اعتباطية عن طريق ربط السُّحب لتشكيل سُحبٍ أكبر. نستطيع القول على نحوٍ معقولٍ أن فكرة الربط بين الشبكات المختلفة اختلافًا كبيرًا كانت الابتكار الأساسي للإنترنت وأن النمو الناجح للإنترنت إلى حجمها العالمي والمليارات من العُقَد كان ثمرة بعض قرارات التصميم الجيدة جدًا التي اتخذها مهندسو الإنترنت الأوائل، والتي سنناقشها لاحقًا.

إنّ مجرّد وجود مجموعة من المضيفين متصلين بعضهم ببعضٍ بصورةٍ مباشرة أو غير مباشرة لا يعني بالضّرورة أننا نجحنا في توفير اتصال من مُضيفٍ لمُضيفٍ. فالهدف النهائي هو أن تكون كلّ عقدة قادرةً على تحديد أي عُقَد أخرى على الشبكة تريد التواصل معها، ويتم ذلك عن طريق إسناد عنوانٍ (address) لكل عقدة. العنوان هو سلسلة بايتات تُحدّد عقدةً؛ أي أن الشبكة يمكنها استخدام عنوان العقدة لتمييزها عن العُقَد الأخرى المتصلة بالشبكة. عندما تريد العقدة المصدر تسليم رسالة عبر الشبكة إلى عُقدةٍ وِجهةٍ معينةٍ، فإنها تحدّد عنوان العُقدةِ الوِجهة. إذا لم تكن العُقدتان المرسلة والمستقبلة متصلتين مباشرةً، فإنّ مبدّلات الشبكة والموجهات تستخدم هذا العنوان لتحديد كيفية إعادة توجيه الرسالة نحو الوِجهَة. تسمى عملية تحديد كيفية إعادة توجيه الرسائل نحو العُقدة الوِجهة بصورةٍ منهجيةٍ بناءً على عنوانها عمليةَ التوجيه (routing).

تفترض هذه المقدمة الموجزة عن العنونة والتوجيه أنّ العقدة المصدر تريد إرسال رسالة إلى عقدةٍ وِجهةٍ واحدةٍ (البث الأحادي unicast). ورغم أنّ هذا السيناريو هو الأكثر شيوعًا، فمن الممكن أيضًا أنّ العقدة المصدر ترغب في بث رسالةٍ إلى جميع العُقد على الشبكة، أو قد ترغب العقدة المصدر في إرسال رسالةٍ إلى مجموعة فرعية من العُقَد الأخرى ولكن ليس جميعها، وهي حالة تسمى البث المتعدد (multicast). وبالتالي، بالإضافة إلى العناوين الخاصة بالعقدة، فمن متطلّبات الشبكة كذلك أن تدعم عناوين البث المتعدّد والبثّ العريض (broadcast).

اقتباس

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

مشاركة الموارد ذات التكلفة الفعالة

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

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

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

ومن أجل معرفة كيف يعمل هذا الأمر، نفترض الشبكة البسيطة الموضحة في الشكل التالي، إذ يرسل المضيفون الثلاثة المتواجدون على الجانب الأيسر من الشبكة (المرسلون S3-S1) البيانات إلى المضيفين الثلاثة على اليمين (المستقبلون R3-R1) من خلال تشارك شبكة تبديلٍ تحتوي على رابطٍ فيزيائي واحدٍ فقط. (من أجل التبسيط، نفترض أن المضيف S1 يرسل البيانات إلى المضيف المقابل R1، والأمر نفسه بالنسبة للبقية). في هذه الحالة، سوف يجري تجميع ثلاث تدفقات من البيانات، الموافقة لأزواج المضيفين الثلاثة، على رابطٍ فيزيائي واحدٍ عن طريق المبدّل 1، ومن ثم فكّ الدمج مرة أخرى إلى تدفقات منفصلة عن طريق المبدّل 2. لاحظ أننا نتعمد الغموض لما يحتويه "تدفق البيانات" بالضبط. ولأغراض هذه المناقشة، نفترض أنّ لكلّ مضيف على اليسار مقدارٌ كبير من البيانات التي يريد إرسالها إلى نظيره على اليمين.

هناك طرقٌ عديدة مختلفة لدمج (multiplexing) التدفقات المتعددة على رابطٍ فيزيائي واحد. إحدى الطرق الشائعة هي تعدّد الإرسال بالتقسيم الزمني المتزامن (synchronous time-division multiplexing أو اختصارًا STDM). تتمثّل فكرة STDM في تقسيم الوقت إلى كمّات (quanta) زمنية متساوية، ومنح الفرصة بالدّور لكلّ تدفقٍ كي يُرسِل بياناته عبر الرابط المادي. وبعبارة أخرى، تُنقل البيانات من S1 إلى R1 أثناء الكمّ 1، وخلال الكم الزمني 2، تُرسَل البيانات من S2 إلى R2؛ وفي الكمّ 3، يُرسل S3 البيانات إلى R3. عند هذه النقطة، يبدأ التدفق الأول (S1 إلى R1) مرة أخرى، وتتكرّر العملية. طريقةُ أخرى تستخدم كثيرًا هي تعدّد الإرسال بتقسيم التردد (frequency-division multiplexing أو اختصارًا FDM). وتتجلى فكرة FDM في إرسال كل تدفّق عبر الرابط الفيزيائي بتردّدٍ مختلفٍ، بالطريقة نفسها التي تُرسَل بها الإشارات لمحطّات التلفزيون المختلفة بتردّدات مختلفة عبر موجات الهواء أو على رابط الكابل التلفزيوني المِحوري.

ورغم سهولة فهمهما، إلّا أنّ كلا الطريقتين STDM و FDM تُظهران بعض القصور في نقطتين مهمّتين. أولًا، عندما لا يكون لدى أيّ من التدفقات (أزواج المضيفين) أيّ بيانات لإرسالها، فإنّ نصيبها من الرابط الفيزيائي، أي من الكمّ الزمني أو التردّد، يظلّ خاملًا، حتى لو كان لدى أحد التدفقات الأخرى بيانات لإرسالها. على سبيل المثال، سيكون على المرسل S3 انتظار دوره خلف S1 و S2 في الفقرة السابقة، حتى لو لم يكن لدى S1 و S2 أي شيء لإرساله. وفي معايير الاتصالات الحاسوبية، يمكن أن يكون مقدار الوقت الذي يبقى فيه الرابط خاملًا كبيرًا جدًا. يمكنك أن تأخذ على سبيل المثال مقدار الوقت الذي تقضيه في قراءة صفحة ويب (ترك الرابط خاملًا) وتُقارِنه بالوقت الذي تقضيه في جلب الصفحة. ثانيًا، يقتصر كلّ من STDM و FDM على المواقف التي يكون فيها الحدّ الأقصى لعدد التدفقات ثابتًا ومعروفًا مسبقًا. ولن يكون تغيير حجم الكمّ أو إضافة كمّات إضافية في حالة STDM أو إضافة تردّدات جديدة في حالة FDM، أمرًا عمليًّا.

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

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

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

يمكن اتخاذ القرار بشأن أيّ من الرزم ستُرسَل بعد ذلك على رابطٍ مشتركٍ بعدة طرقٍ مختلفة. على سبيل المثال، في شبكة تتكوّن من مبدّلات متصلة بعضُها ببعضٍ عبر روابط، يُتّخذ القرار على مستوى المبدّل الذي ينقل الرزَم إلى الرابط المشترك. (مثلما سنرى لاحقًا، لا تشتمل جميع شبكات تبديل الرزم في الواقع على مبدّلات، وقد تستخدم آليات أخرى لاتخاذ ذلك القرار). يتخذ كل مبدّل في شبكة تبديل الرزم هذا القرار بشكل مستقلّ، على أساس رزمةٍ بعد رزمةٍ. لكنّ إحدى المشكلات التي تواجه مصمّم الشبكة هي كيفية اتخاذ هذا القرار بطريقة عادلة. على سبيل المثال، يمكن تصميم المبدّل لخدمة رزم البيانات على أساس الداخل أولًا، يخرج أولًا (first-in, first-out أو اختصارًا FIFO). وهناك نهج آخر يتمثّل في إرسال الرزم من كل من التدفقات المختلفة التي ترسل البيانات حاليًا من خلال المبدّل بتخصيصٍ دوريٍ. يمكن القيام بذلك للتأكد من أن تدفقات معينة تتلقى حصّة معينة من حيز النطاق التراسلي (bandwidth) للرابط أو أنّ رزمَها لم تتأخر أبدًا في المبدّل لأكثر من فترة زمنية محدّدة. يقال أحيانًا أن الشبكة التي تحاول تخصيص حيز النطاق التراسلي لتدفقات معينة تدعم جودة الخدمة (quality of service أو اختصارًا QoS).

يمكن أن نلاحظ أيضًا في الشكل السابق أنه نظرًا لأنّ على المبدّل أن يدمج ثلاثة تدفقات رزم واردة على رابطٍ صادرٍ واحد، فمن الممكن أن يتلقى المبدّل الرزم بأسرع مما يمكن للرابط المشترك استيعابه. في هذه الحالة، يضطرّ المبدّل إلى تخزين هذه الرزم مؤقتًا في ذاكرته. وإذا كان المبدّل يتلقى الرزم بأسرع مما يمكنه أن يرسلها لفترة طويلة من الزمن، فهذا سيجعل المبدّل في نهاية المطاف يشتغل فوق طاقته التخزينية المؤقتة، وسيضطرّه ذلك إلى إسقاط بعض الرزم. عندما يشتغل المبدّل في هذا الوضع، نقول إنه مُحتقِن (congested).

اقتباس

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

دعم الخدمات المشتركة

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

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

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

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

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

تحديد أنماط الاتصال المشتركة

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

يعدّ برنامج الوصول إلى الملفات مثل بروتوكول نقل الملفات (File Transfer Protocol أو اختصارًا FTP) أو نظام ملفات الشبكة (Network File System أو اختصارًا NFS) أحد أقدم التطبيقات المدعومة على أي شبكة. ورغم اختلاف العديد من التفاصيل، كطريقة نقل الملفات على سبيل المثال التي تتمّ بالكامل عبر الشبكة أو أن القراءة أو الكتابة تكون لكُتل مفردةٍ فقط من الملف في وقت معين، فإن عنصر الاتصال الخاصّ بالولوج إلى الملف عن بعد يُدرِج زوجًا من العمليات، إحداهما تطلب قراءة الملف أو كتابته والعملية الثانية تلبّي هذا الطلب. العملية التي تطلب الوصول إلى الملف تسمى العميل (client)، والعملية التي تدعم الولوج إلى الملف تسمى الخادوم (server).

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

المكتبة الرقمية هي تطبيق أكثر تعقيدًا من نقل الملفات، ولكنها تتطلب خدمات اتصال مماثلة. على سبيل المثال، تُدير رابطة مكائن الحوسبة (Association for Computing Machinery أو اختصارًا ACM) مكتبة رقمية كبيرة لمؤلّفات علوم الحاسوب على الرابط التالي :

http://portal.acm.org/dl.cfm

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

بالاعتماد على خدمة الولوج إلى الملفات، وعلى المكتبة الرقمية، وكذلك تطبيقي الفيديو المذكورين في المقدمة (المؤتمرات عبر الفيديو والفيديو حسب الطلب) كعيناتٍ نموذجيةٍ، رُبّما نقرّر أن نوفّر نوعين من القنوات: قنوات الطلب/الاستجابة (request/reply) وقنوات تدفّق الرسائل (message stream). سوف يُستخدَم النوع الأول في تطبيقات نقل الملفات والمكتبات الرقمية، وسوف يضمن استلام كلّ رسالةٍ مُرسَلةٍ من أحد الجانبين إلى الجانب الآخر، كما سيضمن تسليم نسخة واحدة فقط من كلّ رسالة. وقد تحمي قناة الطلب/الاستجابة أيضًا خصوصية وتكامل البيانات التي تتدفّق عليها حتى لا تتمكّن الأطراف غير المصرّح لها من قراءة أو تعديل البيانات التي يجري تبادُلها بين عمليات العميل والخادوم. أما قناة تدفق الرسائل فيمكن استخدامها في تطبيقات الفيديو عند الطلب والمؤتمرات عبر الفيديو، شريطة أن تكون مُهيّأة لدعم حركة المرور أحادية الاتجاه وذات الاتجاهين ودعمٍ خصائص التأخير المختلفة. قد لا تحتاج قناة تدفق الرسائل إلى ضمان تسليم جميع الرسائل، إذ يمكن أن يعمل تطبيق الفيديو بصورة مناسبة حتى لو لم يستقبل بعضَ مقاطع الفيديو. ومع ذلك، ينبغي التأكد من وصول تلك الرسائل المُستلَمة بالترتيب نفسِه الذي أُرسِلت به، لتجنب عرض المقاطع خارج تسلسلها السليم. ومثلما هو الأمر بالنسبة لقناة الطلب/الاستجابة، قد ترغب قناة تدفّق الرسائل في ضمان خصوصية بيانات الفيديو وتكاملها. أخيرًا، قد تحتاج قناة تدفق الرسائل إلى دعم البث المتعدّد من أجل تمكين أطراف متعدّدة من المشاركة في المؤتمر عن بعد أو مشاهدة الفيديو. يسعى مصمّمو الشبكة غالبًا للحصول على أقلِّ عدد من أنواع القنوات المجردة التي يمكنها أن تخدم أكبر عدد من التطبيقات، إلا أنّ هناك خطرًا في محاولة الاكتفاء بعدد قليل جدًا من القنوات المجردة. ببساطة، إذا كانت لديك مطرقة، فكل شيء سيبدو لك مثل المسمار. على سبيل المثال، إذا كان كلّ ما لديك من أنواع القنوات هو قنوات تدفق الرسائل وقنوات الطلب/الاستجابة، فسيغريانك باستخدامهما لتطبيقك التالي، حتى لو لم يكن أيّ منهما يوفّر المتطلبات التي يحتاجها التطبيق بالضبط. وهكذا، من الراجح أن يخترع مصممو الشبكات أنواعًا جديدة من القنوات، وأن يضيفوا بعض الخيارات إلى القنوات الحالية، مادام مبرمجو التطبيقات يخترعون تطبيقات جديدة.

لاحظ أيضًا أنه بغض النظر عن الوظيفة التي توفرها قناة معينة بالضبط، سيكون هناك سؤالٌ حول مكان تنفيذ هذه الوظيفة. في كثير من الحالات، يكون من الأسهل النظر للاتصال من مضيف لمضيف في الشبكة الأساسية على أنه مجرد توفير أنبوبٍ للبتات (bit pipe)، مع أية دلالات اتصال عالية المستوى يوفّرها المضيفون النهائيون. وتكمن ميزة هذه المقاربة في حفاظها على المبدّل في منتصف الشبكة بأبسط ما يمكن، إذ إنه ببساطة يُعِيد توجيه الرزم، ولكنها تتطلب من المضيفين النهائيين تحمّل الكثير من العبء لدعم قنوات عمليةٍ لعملية (process-to-process). والحلّ البديل هو إضافة وظائف إضافية إلى المبدّلات، مما يسمح للمضيفين النهائيين بأن يكونوا "أجهزة صامتة" (سماعات الهاتف على سبيل المثال). سوف نرى هذه المسألة المتعلقة بكيفية تقسيم خدمات الشبكة المختلفة بين مبدّلات الرزَم والمضيفين النهائيين (الأجهزة) كمشكلةٍ متكررة في تصميم الشبكات.

التسليم الموثوق للرسائل

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

هناك ثلاثة أصنافٍ عامة من الفشل ينبغي على مصممي الشبكات القلق بشأنها. أولًا، عند إرسال رزمة عبر رابطٍ فيزيائي، يمكن أن تحدث أخطاءُ بِتاتٍ في البيانات؛ أي، أن يتحول البِت 1 إلى 0 أو العكس. في بعض الأحيان يصيب التلف البِتات الفردية، ولكن في أغلب الأحيان يحدث خطأ الرشقة (burst error)، أي أن التلف يلحق بالعديد من البِتات المتتالية. تحدث أخطاء البِت عادةً بفعل القوى الخارجية، مثل ضربات الصواعق، واندفاعات الطاقة، وأفران الميكروويف، إذ تُحدِث تداخلًا مع نقل البيانات. لكن ما يبعث على الارتياح هو أن أخطاء البِتات هذه نادرة إلى حد ما، إذ تؤثر في المتوسط على واحد فقط من كل 106 إلى 107 بِت على كابل نموذجي من النحاس وواحد من كل 1012 إلى 1014 بِت على ألياف بصرية نموذجية. وكما سنرى، هناك تقنياتٌ تكشف عن أخطاء البِتات هذه باحتمالية عالية. وبمجرد اكتشافها، يكون في بعض الأحيان تصحيح هذه الأخطاء ممكنًا، فإذا عرفنا البِتات التالفة، يمكننا ببساطة عكسها، بينما في حالات أخرى يكون الضرر سيئًا لدرجة تستلزم التخلص من الرزمة بأكملها. في مثل هذه الحالة، قد يُتوقع من المُرسِل إعادة إرسال الرزمة. الصنف الثاني من الفشل يكون على مستوى الرزمة وليس في البت، أي عندما تضيع رزمةٌ كاملة في الشبكة. أحد أسباب حدوث ذلك هو أن يكون في الرزمة خطأ بِت غير قابل للتصحيح ويستوجب التخلّص منها. ومع ذلك، فالسبب الراجح هو أن تكون إحدى العُقد التي تتعامل مع الرزمة، كالمبدّل الذي يعيد توجيهها من رابط إلى آخر مثلًا، محملة بشكل زائد فلا يبقى مكانٌ لتخزين الرزمة فتضطر لإسقاطها، وهذه هي مشكلة الاحتقان التي ذكرناها في السّابق. هناك سبب آخر أقل شيوعًا، حينما يحدث خطأ في البرنامج الذي يعمل على إحدى العقد التي تتعامل مع الرزمة. إذ قد يعيد، على سبيل المثال، توجيه رزمة بصورة خاطئة على الرابط الخطأ، فلا تجد الرزمة طريقها إلى الوجهة النهائية. وكما سنرى فيما بعد، فإن إحدى الصعوبات الرئيسية في التعامل مع الرزم المفقودة هي التمييز بين رزمة مفقودة بالفعل وأخرى متأخرة فقط في الوصول إلى الوجهة. يحدث الصنف الثالث من الفشل على مستوى العقدة أو الرابط، كأن ينقطع الرابط الفيزيائي، أو يتعطّل الحاسوب المتصل به. يمكن أن يحدث هذا بسبب عُطلٍ في البرنامج، أو انقطاعٍ في التيار الكهربائي، أو ربّما عمليّة حَفرٍ متهوّرة. كما أن الفشل بسبب الضبط الخاطئ (misconfiguration) لجهازٍ على الشبكة أمر شائع أيضًا. ورغم أنه يمكن تصحيح كلٍّ من هذه الإخفاقات في النهاية، إلا أنّ تأثيرها يمكن أن يكون كبيرًا على الشبكة لفترةٍ طويلةٍ من الزمن. ومع ذلك، فهي لا تستدعي تعطيل الشبكة تمامًا. في شبكة تبديل الحزم، على سبيل المثال، يمكن في بعض الأحيان إعادة التوجيه لتفادي العقدة أو الرابط الفاشل. تتمثل إحدى الصعوبات في التعامل مع هذا الصنف الثالث من الفشل في التمييز بين الحاسوب الفاشل والحاسوب البطيء فقط أو بين الرابط المقطوع والذي يوجد في حالة عدم استقرار فيعطي بذلك عددًا كبيرًا من أخطاء البِت.

اقتباس

إنّ أهمّ ما ينبغي أخذه من هذه المناقشة هو أنّ تحديد القنوات المفيدة يستلزم فهم متطلبات التطبيقات والتعرف على قيود التكنولوجيا الأساسية. يكمن التحدي في سدّ الفجوة بين ما يتوقعه التطبيق وما يمكن أن توفره التكنولوجيا الأساسية. وهذا ما يسمى في بعض الأحيان الفجوة الدلالية (semantic gap).

قابلية الإدارة (Manageability)

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

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

المشكلة: بناء شبكة (Building a Network)

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

إن الهدف الأساسي لهذا الكتاب هو الإجابة على هذا السؤال، وذلك من أجل وصف مواد البناء المتاحة ثم لتوضيح كيف يمكن استخدامها لبناء شبكةٍ من الأساس.

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

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

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

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

بالإضافة إلى فهم كيفية بناء الشبكات، تتزايد أهمّية فهم كيفية تشغيلها أو إدارتها وكيفية تطوير تطبيقات الشبكة. لدى جميعنا تقريبًا الآن شبكات حاسوبية في منازلنا ومكاتبنا، وفي بعض الحالات في سياراتنا، لذلك لم تعد شبكات التشغيل مسألة تهم عددًا قليلًا من المتخصصين فقط. ومع انتشار الهواتف الذكية، يطوّر الكثير من أبناء هذا الجيل تطبيقات شبكية أكثر من الماضي. لذلك نحن بحاجة إلى النظر في الشبكات من هذه المنظورات المتعددة: المنشئون (builders) والمشغلون (operators) ومطورو التطبيقات (application developers).

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

تطبيقات (Applications) شبكة الإنترنت

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

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

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

فئات التطبيقات

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

يقدّم الويب في شكله الأساسي واجهةً بسيطة على نحوٍ بديهيٍّ تمامًا. إذ يستعرض المستخدمون صفحات مليئة بالكائنات النصية والرسوم البيانية وينقرون على الكائنات التي يريدون معرفة المزيد عنها، وتظهر صفحة جديدة مرافقة. يدرك معظم الأشخاص أيضًا أنّه، أسفل الأغلفةِ، يكون كلُّ كائنٍ قابلٍ للتحديد في صفحةٍ مرتبطًا بمُعرِّفٍ للصفحة أو الكائن التالي الذي سيُعرَض. هذا المُعرِّف يسمى مُعرِّف الموارد الموحّد (Uniform Resource Locator أو اختصارًا URL)، ويوفر طريقةً لتحديد جميع الكائنات المحتملة التي يمكن عرضها من متصفح الويب.

فمثلًا:

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

هذا عنوان URL لصفحةٍ تُقدّم معلومات حول أحد مؤلفي هذا الكتاب: تشير السلسلة http إلى أنه يجب استخدام بروتوكول نقل النصوص الترابطية (Hypertext Transfer Protocol أو اختصارًا HTTP) لتحميل الصفحة، www.cs.princeton.edu هو اسم جهاز الخادوم الذي يوفّر الصفحة، ويعرّف الجزء ‎/llp/index.html صفحة لاري الرئيسية بشكل فريد في موقع الويب هذا.

ومع ذلك، فإن ما لا يدركه معظم مستخدمي الويب هو أنه من خلال النقر على عنوان URL واحد فقط، هناك عشرات الرسائل يمكن تبادلها عبر الإنترنت، وأكثر من ذلك بكثير إذا كانت صفحة الويب تتشكّل من الكثير من الكائنات المضمّنة. يشتمل تبادل الرسائل هذا على ما يصل إلى ست رسائلٍ لترجمة اسم الخادوم (www.cs.princeton.edu) إلى عنوان IP أي بروتوكول الإنترنت (128.112.136.35)، وثلاث رسائل لإعداد بروتوكول التحكّم بالإرسال ( Transmission Control Protocol أو اختصارًا TCP) بين المتصفّح وهذا الخادوم، وأربع رسائل للمتصفّح من أجل إرسال طلب HTTP من الفئة GET وكذلك للخادوم من أجل الرد على الطلب مع إرفاق الصفحة المطلوبة (دون نسيان الإفادة باستلام الرسالة من كلا الطرفين)، وأربع رسائل لإنهاء اتصال TCP. وبطبيعة الحال، هذا لا يشمل الملايين من الرسائل التي تتبادلها عُقَد شبكة الإنترنت على مدار اليوم، فقط لكي يُعلِم بعضها بعضًا بوجوده واستعداده لتوفير صفحات الويب، وترجمة الأسماء إلى عناوين، وإعادة توجيه الرسائل نحو وِجهاتها النهائية.

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

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

وهناك فئة من التطبيقات مختلفة اختلافًا دقيقًا، وهي تقنية الصوت والفيديو في الزمن الحقيقي (real-time audio and video). ولهذه التطبيقات قيود أكثر تشددًا من تطبيقات البث فيما يخصّ التوقيت. يجب أن تكون التفاعلات بين المشاركين في الوقت المناسب، عند استخدام الصوت عبر بروتوكول الإنترنت مثل تطبيق سكايب أو تطبيق المؤتمرات عبر الفيديو. عندما يقوم شخص ما بإيماءةٍ، يجب أن يُعرض هذا الإجراء في الجانب الآخر بأسرع ما يمكن. ليس تمامًا "في أقرب وقت ممكن". . . تشير أبحاث العوامل البشرية إلى أن 300 ميلي ثانية هي حدّ أعلى معقولٌ لمقدار التأخير ذهابًا وإيابًا الذي يمكن تحمّله في مكالمة هاتفية دون أن تكون هناك شكوى، ويبدو أن التأخير البالغ 100 مللي ثانية جيد جدًا.

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

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

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

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

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