معيار الانترنت

الموسوعة الحرة

في هندسة شبكات الكمبيوتر ، معيار الإنترنت هو مواصفة معيارية لتقنية أو منهجية قابلة للتطبيق على الإنترنت . يتم إنشاء معايير الإنترنت ونشرها بواسطة فريق عمل هندسة الإنترنت (IETF). وهي تسمح بالتشغيل المتبادل للأجهزة والبرامج من مصادر مختلفة مما يسمح للإنترنت بالعمل. [1] ومع تزايد انتشار الإنترنت على مستوى العالم، أصبحت معايير الإنترنت لغة مشتركة للاتصالات العالمية. [2]

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

يتميز معيار الإنترنت بالنضج التقني والفائدة. كما يعرّف IETF المعيار المقترح بأنه مواصفة أقل نضجًا ولكنها مستقرة وخضعت لمراجعة جيدة. كان المعيار المسودة مستوى متوسطًا، وتوقف العمل به في عام 2011. [3] كان المعيار المسودة خطوة وسيطة حدثت بعد المعيار المقترح ولكن قبل معيار الإنترنت.

كما هو موضح في RFC 2026:

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

ملخص

يتم توثيق معيار الإنترنت من خلال [4] طلب التعليقات (RFC) أو مجموعة من RFCs. تبدأ المواصفات التي ستصبح معيارًا أو جزءًا من معيار كمسودة إنترنت ، ويتم قبولها لاحقًا، عادةً بعد عدة مراجعات، ونشرها بواسطة محرر RFC كـ RFC وتسمية معيار مقترح . لاحقًا، يتم رفع RFC إلى مستوى معيار الإنترنت ، مع رقم تسلسل إضافي، عندما يصل النضج إلى مستوى مقبول. تُعرف هذه المراحل مجتمعة باسم مسار المعايير ، ويتم تعريفها في RFC 2026 وRFC 6410. يتم تطبيق العلامة التاريخية على مستندات مسار المعايير القديمة أو RFCs القديمة التي تم نشرها قبل إنشاء مسار المعايير.

لا يمكن إلا لـ IETF ، الممثلة بواسطة مجموعة توجيه هندسة الإنترنت (IESG)، الموافقة على طلبات RFCs الخاصة بمسار المعايير. يتم الاحتفاظ بالقائمة النهائية لمعايير الإنترنت في معايير بروتوكول الإنترنت الرسمية. في السابق، كانت المعايير 1 تستخدم للحفاظ على لقطة من القائمة. [5]

تاريخ وهدف معايير الإنترنت

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

بروتوكول التحكم في الإرسال/بروتوكول الإنترنت

التاريخ الرسمي لبدء تشغيل الإنترنت لأول مرة هو 1 يناير 1983. [6] دخل بروتوكول التحكم في الإرسال/بروتوكول الإنترنت (TCP/IP) حيز التنفيذ. وكانت شبكة ARPANET (شبكة وكالة مشاريع الأبحاث المتقدمة) وشبكة بيانات الدفاع هي الشبكات التي نفذت البروتوكولات. تعتبر هذه البروتوكولات جزءًا أساسيًا من كيفية عمل الإنترنت لأنها تحدد القواعد التي تعمل بها الاتصالات بين الخوادم. لا تزال تُستخدم اليوم من خلال تنفيذ طرق مختلفة لإرسال البيانات عبر الشبكات العالمية.

بروتوكول الإنترنت الآمن

أمان بروتوكول الإنترنت هو مجموعة من البروتوكولات التي تضمن سلامة التشفير في الاتصال بين أجهزة متعددة. الغرض من هذا البروتوكول هو حماية الشبكات العامة. وفقًا لـ IETF Datatracker، تم اقتراح المجموعة المخصصة لإنشائه في 25 نوفمبر 1992. [7] بعد نصف عام تم إنشاء المجموعة ولم يمض وقت طويل حتى تم نشر المسودة الأولى في منتصف عام 1993.

HTTP

بروتوكول نقل النص التشعبي هو أحد أكثر البروتوكولات استخدامًا اليوم في سياق شبكة الويب العالمية. HTTP هو بروتوكول بسيط للتحكم في كيفية تبادل المستندات المكتوبة بلغة علامات النص التشعبي (HTML) عبر الشبكات. هذا البروتوكول هو العمود الفقري للويب مما يسمح بوجود نظام النص التشعبي بأكمله عمليًا. تم إنشاؤه بواسطة فريق من المطورين بقيادة تيم بيرنرز لي . بيرنرز لي مسؤول عن اقتراح إنشائه، والذي فعله في عام 1989. 6 أغسطس 1991 هو التاريخ الذي نشر فيه أول نسخة كاملة من HTTP على منتدى عام. [8] يعتبر هذا التاريخ لاحقًا من قبل البعض بمثابة الميلاد الرسمي لشبكة الويب العالمية. كان HTTP يتطور باستمرار منذ إنشائه، وأصبح أكثر تعقيدًا بمرور الوقت وتقدم تكنولوجيا الشبكات. بشكل افتراضي، لا يتم تشفير HTTP، لذلك يتم استخدام HTTPS عمليًا ، وهو ما يرمز إلى HTTP Secure.

TLS/SSL

TLS تعني Transport Layer Security (أمان طبقة النقل ) وهو معيار يمكّن نقطتي نهاية مختلفتين من الاتصال ببعضهما البعض بشكل متين وخاص. جاء TLS كبديل لـ SSL. تم تقديم Secure Sockets Layers لأول مرة قبل إنشاء HTTPS وتم إنشاؤه بواسطة Netscape. في الواقع، كان HTTPS يعتمد على SSL عندما ظهر لأول مرة. كان من الواضح أن هناك حاجة إلى طريقة واحدة شائعة لتشفير البيانات، لذلك حددت IETF TLS 1.0 في RFC 2246 في يناير 1999. [9] وقد تمت ترقيته منذ ذلك الحين. الإصدار الأخير من TLS هو 1.3 من RFC 8446 في أغسطس 2018.

نموذج OSI

بدأ تطوير نموذج الربط بين الأنظمة المفتوحة في عام 1977. [ 10 ] وقد أنشأته المنظمة الدولية للمعايير . وتم نشره رسميًا واعتماده كمعيار للاستخدام في عام 1979. ثم تم تحديثه عدة مرات والنسخة النهائية. استغرق الأمر بضع سنوات حتى يتم تقديم البروتوكول في شكله النهائي. تم نشر ISO 7498 في عام 1984. وأخيرًا في عام 1995 تمت مراجعة نموذج OSI مرة أخرى لتلبية الاحتياجات العاجلة للتطور المتزايد في مجال الشبكات الحاسوبية.

بروتوكول بيانات المستخدم

كان هدف بروتوكول مخطط بيانات المستخدم هو إيجاد طريقة للتواصل بين جهازين كمبيوتر بأسرع ما يمكن وبكفاءة. تم تصور وتنفيذ بروتوكول UDP بواسطة ديفيد ب. ريد في عام 1980. [11] في الأساس، تعتمد طريقة عمله على استخدام الضغط لإرسال المعلومات. يتم ضغط البيانات في مخطط بيانات وإرسالها من نقطة إلى نقطة. ثبت أن هذه طريقة آمنة لنقل المعلومات وعلى الرغم من عيب فقدان جودة البيانات، لا يزال بروتوكول UDP قيد الاستخدام.

عملية التوحيد القياسي

إن التحول إلى معيار هو عملية تتكون من خطوتين ضمن عملية معايير الإنترنت: المعيار المقترح ومعيار الإنترنت . وتسمى هذه مستويات النضج وتسمى العملية مسار المعايير .

إذا كان RFC جزءًا من اقتراح يقع على مسار المعايير، ففي المرحلة الأولى، يتم اقتراح المعيار ثم تقرر المنظمات بعد ذلك ما إذا كانت ستنفذ هذا المعيار المقترح أم لا. بعد استيفاء المعايير الواردة في RFC 6410 (تنفيذان منفصلان، واستخدام واسع النطاق، وعدم وجود أخطاء، وما إلى ذلك)، [12] يمكن أن يتقدم RFC إلى معيار الإنترنت.

تم تعريف عملية معايير الإنترنت في العديد من مستندات "أفضل الممارسات الحالية"، ولا سيما BCP 9 (حاليًا RFC 2026 وRFC 6410). كانت هناك في السابق ثلاثة مستويات لنضج المعايير: المعيار المقترح ، والمعيار المسودة ، ومعيار الإنترنت . قلص RFC 6410 هذا إلى مستويين من النضج.

المعيار المقترح

وصفت RFC 2026 في الأصل المعايير المقترحة بأنها مواصفات غير ناضجة، ولكن تم إلغاء هذا الموقف بموجب RFC 7127. [13]

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

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

في الواقع، يتم نشر العديد من المعايير المقترحة على الإنترنت واستخدامها على نطاق واسع، باعتبارها بروتوكولات مستقرة. كانت الممارسة الفعلية أن التقدم الكامل عبر تسلسل مستويات المعايير نادر جدًا، وتظل معظم بروتوكولات IETF الشائعة في المعيار المقترح. [14]

مسودة المعيار

في أكتوبر 2011، دمجت RFC 6410 مستويات النضج الثانية والثالثة في معيار إنترنت واحد. تحتفظ مسودة المعايير القديمة الحالية بهذا التصنيف، في غياب إجراءات صريحة. بالنسبة لمسودة المعايير القديمة، هناك إجراءان محتملان [15] متاحان، ويجب الموافقة عليهما من قبل IESG: يمكن إعادة تصنيف مسودة المعيار كمعيار إنترنت بمجرد استيفاء المعايير في RFC 6410 [12] ؛ أو بعد عامين منذ الموافقة على RFC 6410 كمعيار BCP (أكتوبر 2013)، يمكن لـ IESG اختيار إعادة تصنيف مسودة معيار قديمة كمعيار مقترح . [16]

معيار الانترنت

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

يتم إعطاء جميع معايير الإنترنت رقمًا في سلسلة STD. تم تلخيص السلسلة في أول وثيقة لها، STD 1 (RFC 5000)، حتى عام 2013، ولكن تم إيقاف هذه الممارسة في RFC 7100. يتم الآن صيانة القائمة النهائية لمعايير الإنترنت بواسطة محرر RFC. [17]

لا تتم مراجعة المستندات المرسلة إلى محرر IETF والمقبولة باعتبارها RFC؛ إذا كان من الضروري تغيير المستند، يتم إرساله مرة أخرى وتعيين رقم RFC جديد له. عندما يصبح RFC معيارًا للإنترنت (STD)، يتم تعيين رقم STD له ولكنه يحتفظ برقم RFC الخاص به. عند تحديث معيار للإنترنت، يظل رقمه دون تغيير ولكنه يشير إلى RFC مختلف أو مجموعة من RFCs. على سبيل المثال، في عام 2007 كان RFC 3700 معيارًا للإنترنت (STD 1) وفي مايو 2008 تم استبداله بـ RFC 5000. حصل RFC 3700 على حالة تاريخية ، وأصبح RFC 5000 هو STD 1.

تم نشر قائمة معايير الإنترنت في الأصل باعتبارها STD 1 ولكن تم التخلي عن هذه الممارسة لصالح قائمة عبر الإنترنت يحتفظ بها محرر RFC. [18]

منظمات معايير الإنترنت

تنقسم عملية التوحيد إلى ثلاث خطوات:

  1. المعايير المقترحة هي معايير يجب تنفيذها ويمكن تغييرها في أي وقت
  2. تم اختبار مسودة المعيار بعناية استعدادًا لتشكيل معيار الإنترنت المستقبلي
  3. معايير الإنترنت هي معايير ناضجة.

هناك خمس منظمات لمعايير الإنترنت: فريق هندسة الإنترنت (IETF)، وجمعية الإنترنت (ISOC)، ومجلس هندسة الإنترنت (IAB)، وفريق أبحاث الإنترنت (IRTF)، واتحاد شبكة الويب العالمية (W3C). ويتعين على جميع المنظمات استخدام لغة الإنترنت والتعبير عنها من أجل الحفاظ على القدرة التنافسية في مرحلة الإنترنت الحالية. ومن بين الأهداف الأساسية لعملية معايير الإنترنت: ضمان التميز الفني؛ والتنفيذ والاختبار في وقت مبكر؛ والسجلات المثالية والمختصرة وسهلة الفهم.

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

حتى عام 1993، كانت الحكومة الفيدرالية للولايات المتحدة تدعم IETF. والآن، تشرف عليها هيئة هندسة الإنترنت التابعة لجمعية الإنترنت (IAB). وهي منظمة من أسفل إلى أعلى ليس لديها متطلبات رسمية للانتماء ولا يوجد لديها أيضًا إجراء رسمي للعضوية. وهي تعمل بحذر مع اتحاد شبكة الويب العالمية (W3C) ومنظمات تطوير المعايير الأخرى. علاوة على ذلك، تعتمد بشكل كبير على مجموعات العمل التي يتم تشكيلها واقتراحها على مدير المنطقة. تعتمد IETF على مجموعات العمل الخاصة بها لتوسيع شروط واستراتيجيات IETF بهدف جعل عمل الإنترنت أفضل. [19] تعمل مجموعة العمل بعد ذلك تحت إشراف مدير المنطقة وتقدم اتفاقية. بعد توزيع الميثاق المقترح على قوائم البريد الخاصة بـ IESG وIAB والموافقة عليه، يتم إرساله بعد ذلك إلى IETF العامة. ليس من الضروري الحصول على موافقة كاملة من جميع مجموعات العمل وتبني الاقتراح. مجموعات عمل IETF مطلوبة فقط للتحقق مما إذا كانت الاتفاقية قوية.

وعلى نحو مماثل، تنتج مجموعة العمل وثائق في شكل طلبات التعليقات (RFCs) وهي عبارة عن مذكرات تحتوي على مناهج وأفعال وفحوصات فضلاً عن ابتكارات مناسبة لعمل الإنترنت والترتيبات المرتبطة بالإنترنت. وبعبارة أخرى، تُستخدم طلبات التعليقات (RFCs) في المقام الأول لتطوير بروتوكول شبكة قياسي مرتبط ببيانات الشبكة. وتهدف بعض طلبات التعليقات (RFCs) إلى إنتاج المعلومات بينما يُطلب من البعض الآخر نشر معايير الإنترنت. يتحول الشكل النهائي لطلب التعليقات (RFCs) إلى المعيار ويتم إصداره برقم. بعد ذلك، لا يُسمح بمزيد من التعليقات أو الاختلافات للشكل الختامي. [20] يتم اتباع هذه العملية في كل منطقة لتوليد آراء إجماعية حول مشكلة تتعلق بالإنترنت وتطوير معايير الإنترنت كحل لمشاكل مختلفة. هناك ثمانية مجالات مشتركة تركز عليها IETF وتستخدم مجموعات عمل مختلفة جنبًا إلى جنب مع مدير المنطقة. في المجال "العام"، تعمل على تطوير معايير الإنترنت. في مجال "التطبيق"، تركز على تطبيقات الإنترنت مثل البروتوكولات المتعلقة بالويب. علاوة على ذلك، تعمل أيضًا على تطوير البنية الأساسية للإنترنت في شكل امتدادات PPP. كما تضع IETF أيضًا المبادئ ومعايير الوصف التي تشمل مجموعة بروتوكولات الإنترنت (TCP/IP). يتعاون مجلس هندسة الإنترنت (IAB) مع فريق عمل أبحاث الإنترنت (IRTF) مع IETF في جهودهم باستخدام التقنيات المبتكرة.

إن IETF هي منظمة وضع المعايير التي تركز على توليد الشروط "المعيارية" للخبرة واستخدامها المتوقع. تركز IETF على الأمور المرتبطة بتقدم تكنولوجيا الإنترنت وTCP/IP الحالية. وهي مقسمة إلى مجموعات عمل عديدة، وكل منها مسؤولة عن تطوير المعايير والمهارات في مجال معين، على سبيل المثال التوجيه أو الأمان. والأفراد في مجموعات العمل هم متطوعون ويعملون في مجالات مثل بائعي المعدات ومشغلي الشبكات ومؤسسات البحث المختلفة. أولاً، تعمل على الحصول على الاهتمام المشترك بالمتطلبات التي يجب أن يتناولها الجهد. ثم يتم تشكيل مجموعة عمل IETF ويتم مناقشة المتطلبات في جمعيات Birds of a Feather (BoF) المؤثرة في مؤتمرات IETF.

فريق عمل هندسة الإنترنت

إن فريق عمل هندسة الإنترنت (IETF) هو المنظمة الرائدة في مجال معايير الإنترنت. وهو يتبع عمليات مفتوحة وموثقة جيدًا لوضع معايير الإنترنت. وتتضمن الموارد التي يقدمها فريق عمل هندسة الإنترنت طلبات التعليقات (RFCs)، ومسودات الإنترنت، ووظائف IANA، وحقوق الملكية الفكرية، وعملية المعايير، ونشر طلبات التعليقات (RFCs) والوصول إليها. [21]

طلبات التعليقات

  • المستندات التي تحتوي على المواصفات الفنية والملاحظات الخاصة بالإنترنت.
  • جاء اختصار RFC من عبارة "طلب التعليقات" - لم يعد هذا يُستخدم اليوم ويُشار إليه الآن ببساطة باسم RFCs. [22]
  • موقع RFC Editor هو أرشيف رسمي لمعايير الإنترنت، ومسودات المعايير، والمعايير المقترحة. [23]

مسودات الإنترنت

  • وثائق عمل IETF ومجموعات العمل التابعة لها. [24]
  • يجوز لمجموعات أخرى توزيع وثائق العمل كمسودات على الإنترنت

حقوق الملكية الفكرية

  • جميع معايير IETF متاحة مجانًا للعرض والقراءة، ويمكن لأي شخص تنفيذها مجانًا دون إذن أو دفع. [25]

عملية المعايير

  • إن عملية إنشاء معيار ما هي عملية مباشرة - حيث تخضع المواصفات لعملية مراجعة مكثفة من قبل مجتمع الإنترنت ويتم مراجعتها من خلال الخبرة. [26]

نشر RFCs والوصول إليها

  • مسودات الإنترنت التي استكملت عملية المراجعة بنجاح.
  • تم تقديمه إلى محرر RFC للنشر.

أنواع معايير الإنترنت

هناك طريقتان لتشكيل معيار الإنترنت ويمكن تصنيفهما كواحدة مما يلي: معايير "قانونية" ومعايير "فعلية". [27] يصبح المعيار الواقعي معيارًا من خلال الاستخدام الواسع النطاق داخل مجتمع التكنولوجيا. يتم إنشاء المعيار القانوني رسميًا من قبل منظمات تطوير المعايير الرسمية. [27] تخضع هذه المعايير لعملية معايير الإنترنت. تشمل المعايير القانونية الشائعة ASCII و SCSI ومجموعة بروتوكولات الإنترنت . [23]

المواصفات القياسية للإنترنت

يمكن تصنيف المواصفات الخاضعة لعملية معايير الإنترنت إلى أحد التصنيفات التالية: المواصفات الفنية (TS) وبيان التطبيق (AS). [28] المواصفات الفنية عبارة عن بيان يصف جميع الجوانب ذات الصلة ببروتوكول أو خدمة أو إجراء أو اتفاقية أو تنسيق. [28] وهذا يشمل نطاقها ونيتها للاستخدام، أو "مجال التطبيق". ومع ذلك، يتم تعريف استخدام المواصفات الفنية داخل الإنترنت من خلال بيان التطبيق. يحدد AS كيف، وفي أي ظروف، يمكن تطبيق المواصفات الفنية لدعم قدرة إنترنت معينة. يحدد AS الطرق التي يتم بها دمج المواصفات الفنية ذات الصلة ويحدد المعلمات أو الوظائف الفرعية لبروتوكولات المواصفات الفنية. يصف AS أيضًا مجالات تطبيق المواصفات الفنية، مثل أجهزة توجيه الإنترنت أو خادم المحطة الطرفية أو خوادم قواعد البيانات القائمة على البيانات. [28] يطبق AS أيضًا أحد "مستويات المتطلبات" التالية على كل من المواصفات الفنية التي يشير إليها:

  • المطلوب: يلزم تنفيذ TS المشار إليه لتحقيق التوافق. على سبيل المثال، يلزم أنظمة الإنترنت التي تستخدم مجموعة بروتوكولات الإنترنت بتنفيذ IP و ICMP . [28]
  • موصى به: ليس من الضروري تنفيذ المواصفات الفنية المشار إليها، ولكن من المستحسن أن يتم ذلك في نطاق قابلية تطبيق نظام AS. كما يتم تشجيع تضمين وظائف وميزات وبروتوكولات المواصفات الفنية الموصى بها في تطوير الأنظمة. على سبيل المثال، يجب تنفيذ بروتوكول TELNET بواسطة جميع الأنظمة التي تنوي استخدام الوصول عن بعد. [28]
  • اختياري: تنفيذ TS المشار إليه اختياري. TS ضروري فقط في بيئة محددة. على سبيل المثال، يمكن اعتبار DECNET MIB ذات قيمة في بيئة يتم فيها استخدام بروتوكول DECNET . [28]

المعايير المشتركة

معايير الويب

نموذج TCP/IP ومعايير الإنترنت المرتبطة به معايير الويب هي نوع من معايير الإنترنت التي تحدد جوانب شبكة الويب العالمية . وهي تسمح ببناء وعرض مواقع الويب. المعايير الثلاثة الرئيسية التي تستخدمها شبكة الويب العالمية هي بروتوكول نقل النص التشعبي و HTML و URL . [29] وهي تحدد على التوالي نقل البيانات بين المتصفح وخادم الويب ومحتوى وتخطيط صفحة الويب وما تعنيه معرفات صفحة الويب.

معايير الشبكة

معايير الشبكة هي نوع من معايير الإنترنت التي تحدد قواعد الاتصال بالبيانات في تقنيات وعمليات الشبكات. تسمح معايير الإنترنت بإجراءات الاتصال بين جهاز وأجهزة أخرى أو بينها.

فيما يتعلق بنموذج TCP/IP، فإن المعايير والبروتوكولات المشتركة في كل طبقة هي كما يلي: [ بحاجة لمصدر ]

  • طبقة النقل: TCP و SPX
  • طبقة الشبكة: IP و IPX
  • طبقة ارتباط البيانات: IEEE 802.3 لشبكة LAN و Frame Relay لشبكة WAN
  • الطبقة المادية: 8P8C و V.92

مستقبل معايير الإنترنت

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

توجد بالفعل طرق لجعل BGP وDNS أكثر أمانًا ولكنها ليست منتشرة على نطاق واسع. على سبيل المثال، هناك حماية BGP الحالية تسمى البنية التحتية للمفتاح العام للتوجيه (RPKI). إنها قاعدة بيانات للطرق المعروفة بأنها آمنة وتم توقيعها تشفيريًا. [31] يقدم المستخدمون والشركات الطرق ويتحققون من طرق المستخدمين الآخرين بحثًا عن الأمان. إذا تم اعتمادها على نطاق أوسع، فيمكن إضافة المزيد من الطرق وتأكيدها. ومع ذلك، فإن RPKI تكتسب زخمًا. اعتبارًا من ديسمبر 2020، سجلت شركة التكنولوجيا العملاقة Google 99٪ من طرقها مع RPKI. [31] إنهم يسهلون على الشركات تبني ضمانات BGP. يحتوي DNS أيضًا على بروتوكول أمان بمعدل تبني منخفض: ملحقات أمان DNS (DNSSEC). في الأساس، في كل مرحلة من مراحل عملية البحث عن DNS، يضيف DNSSEC توقيعًا إلى البيانات لإظهار أنه لم يتم العبث بها. [32]

لقد أخذت بعض الشركات زمام المبادرة لتأمين بروتوكولات الإنترنت. ويتعين على الشركات الأخرى أن تجعل هذه المبادرة أكثر انتشارا.

انظر أيضا

مراجع

  1. ^ ليبا، باري (يناير 2008). "مقدمة لمعايير الإنترنت". IEEE Internet Computing . 12 (1): 71–74. doi :10.1109/MIC.2008.2. ISSN  1089-7801. S2CID  26168365. مؤرشف من الأصل في 2022-02-09 . تم الاسترجاع في 2022-02-04 .
  2. ^ كاث، كورين؛ فلوريدي، لوتشيانو (أبريل 2017). "تصميم بنية الإنترنت من قبل فريق هندسة الإنترنت وحقوق الإنسان". أخلاقيات العلوم والهندسة . 23 (2): 449-468. doi :10.1007/s11948-016-9793-y. ISSN  1353-3452. PMID  27255607. S2CID  3613408.
  3. ^ راسل هاوسلي؛ ديف كروكر؛ إريك دبليو برجر (11 أكتوبر 2011). تقليص مسار المعايير إلى مستويين من النضج. IETF . doi : 10.17487/RFC6410 . RFC 6410.
  4. ^ Huitema, C.; Postel, J.; Crocker, S. (1995). "Not All RFCs are Standards". IETF Request for Comments (RFC) Pages - Test . ISSN  2070-1721. مؤرشف من الأصل في 2018-03-20 . تم الاسترجاع في 2018-03-20 .
  5. ^ وثيقة ملخص "معايير بروتوكول الإنترنت الرسمية" RFC 7100
  6. ^ "تاريخ موجز للإنترنت". www.usg.edu . مؤرشف من الأصل في 2002-02-18 . تم الاسترجاع في 2021-12-08 .
  7. ^ "بروتوكول أمان IP (ipsec) -". datatracker.ietf.org . مؤرشف من الأصل في 2019-09-13 . تم الاسترجاع 2021-12-08 .
  8. ^ "تطور HTTP - HTTP | MDN". developer.mozilla.org . مؤرشف من الأصل في 2023-03-27 . تم الاسترجاع 2021-12-08 .
  9. ^ "Transport Layer Security (TLS) - MDN Web Docs Glossary: ​​Definitions of Web-related terms | MDN". developer.mozilla.org . مؤرشف من الأصل في 2021-12-08 . تم الاسترجاع في 2021-12-08 .
  10. ^ علاني، محمد م. (2014)، "نموذج OSI"، دليل نماذج OSI وTCP/IP ، SpringerBriefs in Computer Science، شام: Springer International Publishing، ص. 5-17، doi :10.1007/978-3-319-05152-9_2، ISBN 978-3-319-05151-2تم الاسترجاع بتاريخ 2021-12-08
  11. ^ "ما هو UDP | DiverseNet Inc". مؤرشف من الأصل في 2021-12-08 . تم الاسترجاع 2021-12-08 .
  12. ^ ab Russell Housley; Dave Crocker; Eric W. Burger (11 أكتوبر 2011). "مستوى النضج الثاني: معيار الإنترنت". تقليص مسار المعايير إلى مستويين من النضج. IETF . القسم 2.2. doi : 10.17487/RFC6410 . RFC 6410. يتم إرسال طلب إعادة التصنيف إلى IESG مع شرح لكيفية استيفاء المعايير. المعايير هي:...
  13. ^ "توصيف المواصفات". توصيف المعايير المقترحة. IETF . يناير 2014. القسم 3. doi : 10.17487/RFC7127 . RFC 7127. تم الاسترجاع في 11 مارس 2016 .
  14. ^ "مراجعة IETF للمعايير المقترحة". توصيف المعايير المقترحة. IETF . يناير 2014. القسم 2. doi : 10.17487/RFC7127 . RFC 7127. تم الاسترجاع في 11 مارس 2016 .
  15. ^ Bradner, S. (أكتوبر 1996). "Standards Actions". The Internet Standards Process -- Revision 3. sec. 6.1. doi : 10.17487/rfc2026 . RFC 2026.
  16. ^ راسل هاوسلي؛ ديف كروكر؛ إريك دبليو برجر (11 أكتوبر 2011). "الانتقال إلى مسار المعايير بمستويين من النضج". تقليص مسار المعايير إلى مستويين من النضج. IETF . القسم 2.3. doi : 10.17487/RFC6410 . RFC 6410.
  17. ^ "المعايير الرسمية لبروتوكول الإنترنت". مؤرشف من الأصل في 2018-03-15 . تم الاسترجاع 2018-03-19 .
  18. ^ RFC  7100
  19. ^ ما، د.؛ ماندلبرج، د.؛ بروينزلز، ت. (أغسطس 2018). إدارة موارد أرقام الإنترنت المحلية المبسطة باستخدام RPKI (SLURM). doi : 10.17487/rfc8416 . RFC 8416.
  20. ^ Knieps, Günter (سبتمبر 2015). "إدارة حركة المرور الريادية وفريق عمل هندسة الإنترنت". مجلة قانون المنافسة والاقتصاد . 11 (3): 727-745. doi :10.1093/joclec/nhv018. ISSN  1744-6414.
  21. ^ جمعية هندسة الإنترنت، فريق عمل هندسة الإنترنت (2005). مجلة IETF . جمعية الإنترنت. OCLC  746928702.
  22. ^ "RFCs". IETF . مؤرشف من الأصل في 2021-12-06 . تم الاسترجاع 2021-12-08 .
  23. ^ معايير بروتوكول الإنترنت الرسمية. مايو 2008. doi : 10.17487/rfc5000 . RFC 5000.
  24. ^ Farrel, A. (أبريل 2014). التعامل مع مسودات الإنترنت بواسطة مجموعات عمل IETF. doi : 10.17487/rfc7221 . RFC 7221.
  25. ^ حقوق الملكية الفكرية في تكنولوجيا IETF. مارس 2005. doi : 10.17487/rfc3979 . RFC 3979.
  26. ^ Hovey, R.; Bradner, S. (أكتوبر 1996). المنظمات المشاركة في عملية معايير IETF. doi : 10.17487/rfc2028 . RFC 2028.
  27. ^ ab Nickerson; Muehlen (2006). "علم البيئة لعمليات المعايير: رؤى من صنع المعايير على الإنترنت". MIS Quarterly . 30 : 467–488. doi :10.2307/25148769. JSTOR  25148769.
  28. ^ abcdef Bradner, S. (أكتوبر 1996). عملية معايير الإنترنت -- المراجعة 3. doi : 10.17487/rfc2026 . RFC 2026.
  29. ^ كومر، دوغلاس (2015). شبكات الكمبيوتر والإنترنت (الطبعة السادسة). بوسطن، ماساتشوستس. ISBN 978-0-13-358793-7. OCLC  870649960.{{cite book}}: CS1 maint: location missing publisher (link)
  30. ^ ab Sherman, Justin (1 October 2020). "رسم خريطة تأثير القطاع الخاص على الإنترنت: البدء ببروتوكولات الإنترنت". سياسات أمن الإنترنت: الصناعة الخاصة ومستقبل الويب (تقرير). المجلس الأطلسي. ص. 4-7. JSTOR resrep26661.5 . 
  31. ^ ab Newman, Lily Hay. "A Broken Piece of Internet Backbone Might Finally Get Repaired". Wired . ISSN  1059-1028 . تم الاسترجاع في 2021-12-08 .
  32. ^ "DNSSEC: مقدمة". مدونة Cloudflare . 2014-10-07. مؤرشف من الأصل في 2021-12-06 . تم الاسترجاع في 2021-12-08 .
  • محرر RFC
Retrieved from "https://en.wikipedia.org/w/index.php?title=Internet_Standard&oldid=1257389936"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate