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

📅 آخر تحديث: ٢٧ يوليو ٢٠٢٦
✍️ نُشر في: ٢٧ يوليو ٢٠٢٦
الموسوعة الحرة

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

تُعرَّف عملية وضع معايير الإنترنت في سلسلة من وثائق أفضل الممارسات الحالية الصادرة عن فريق عمل هندسة الإنترنت (IETF) ، بما في ذلك RFC 2026 وRFC 6410. [ 3 ] [ 4 ] ليست جميع وثائق RFC معايير إنترنت؛ فقد تكون وثائق RFC إعلامية أو تجريبية أو خارجة عن مسار المعايير. [ 5 ]

ملخص

يبدأ العمل الهندسي عادةً كمسودة إنترنت، وقد يُنشر لاحقًا كطلب تعليقات (RFC). تُنشر طلبات التعليقات (RFC) الخاصة بمسار المعايير مبدئيًا كمعايير مقترحة ، وقد تُصبح لاحقًا معيارًا للإنترنت عند استيفاء متطلبات التنفيذ والخبرة التشغيلية، وفقًا لما هو محدد في عملية معايير الإنترنت. [ 6 ] [ 4 ]

يتولى محرر RFC مسؤولية الاحتفاظ بالقائمة النهائية لمعايير الإنترنت (وأرقام STD وRFC المرتبطة بها). [ 1 ]

تاريخ معايير الإنترنت والغرض منها

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

بروتوكول الإنترنت TCP/IP

يُعدّ انتقال شبكة أربانت من برنامج التحكم بالشبكة (NCP) إلى مجموعة بروتوكولات TCP/IP في 1 يناير 1983 (وهو انتقال مُخطط له في يوم "العلم" ) علامة فارقة في تطور الإنترنت الحديث. [ 10 ] ويشير لينر وآخرون إلى أن بروتوكول TCP/IP كان قد اعتُمد بالفعل كمعيار دفاعي أمريكي في عام 1980، وأن انتقال أربانت إلى TCP/IP مكّن من فصل الشبكة إلى شبكة عسكرية (MILNET) لتلبية المتطلبات العسكرية التشغيلية، وجزء من أربانت لدعم الأبحاث. [ 10 ] ويُعتبر بروتوكول TCP/IP أساسيًا لأنه يُحدد آليات اتصال وربط شبكي قابلة للتشغيل البيني من طرف إلى طرف - مثل تسليم الحزم، والعنونة، والموثوقية - مما يسمح للشبكات المستقلة بالترابط وتبادل البيانات، ولا يزال مجموعة البروتوكولات الأساسية المستخدمة في اتصالات الإنترنت. [ 11 ]

بروتوكول أمان الإنترنت (IPsec)

يُعدّ بروتوكول أمان الإنترنت (IPS) مجموعة من البروتوكولات التي تضمن سلامة التشفير في الاتصال بين الأجهزة المتعددة. يهدف هذا البروتوكول إلى حماية الشبكات العامة. وفقًا لبيانات IETF Datatracker، تم اقتراح إنشاء المجموعة المُخصصة لوضع هذا البروتوكول في 25 نوفمبر 1992. [ 12 ] وبعد ستة أشهر، تم إنشاء المجموعة، وبعد فترة وجيزة، في منتصف عام 1993، نُشرت المسودة الأولى.

HTTP

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

TLS/SSL

يرمز TLS إلى أمان طبقة النقل، وهو معيار يُمكّن نقطتي نهاية مختلفتين من الاتصال بشكل آمن وسري. جاء TLS كبديل لبروتوكول SSL. تم تقديم طبقة المقابس الآمنة ( SSL ) لأول مرة قبل إنشاء HTTPS، وقد طورتها شركة نتسكيب . في الواقع، كان HTTPS يعتمد على SSL عند ظهوره. كان من الواضح الحاجة إلى طريقة موحدة لتشفير البيانات، لذا حددت فرقة عمل هندسة الإنترنت (IETF) بروتوكول TLS 1.0 في RFC 2246 في يناير 1999. [ 14 ] وقد تم تحديثه منذ ذلك الحين. آخر إصدار من TLS هو 1.3 من RFC 8446 في أغسطس 2018.

نموذج OSI

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

بروتوكول UDP

كان الهدف من بروتوكول بيانات المستخدم (UDP) هو إيجاد طريقة للتواصل بين جهازَي كمبيوتر بأسرع وأكثر كفاءة ممكنة. وقد طُوِّر هذا البروتوكول ونُفِّذ على يد ديفيد ب. ريد عام ١٩٨٠. [ ١٦ ] ويعتمد أساسًا على استخدام الضغط لنقل المعلومات، حيث تُضغط البيانات في حزمة بيانات وتُرسَل من نقطة إلى أخرى. وقد أثبتت هذه الطريقة أنها آمنة لنقل المعلومات، وعلى الرغم من عيب فقدان جودة البيانات، لا يزال بروتوكول UDP مستخدمًا حتى اليوم.

عملية التقييس

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

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

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

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

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

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

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

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

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

في أكتوبر 2011، دمجت RFC 6410 مستويي النضج الثاني والثالث في معيار إنترنت واحد. وتحتفظ مسودات المعايير القديمة الحالية بهذا التصنيف، ما لم تُتخذ إجراءات صريحة. بالنسبة لمسودات المعايير القديمة ، يتوفر إجراءان محتملان [ 20 ] ، يجب أن يوافق عليهما فريق هندسة الإنترنت (IESG): يمكن إعادة تصنيف مسودة المعيار كمعيار إنترنت بمجرد استيفاء المعايير الواردة في RFC 6410 [ 17 ] ؛ أو، بعد عامين من اعتماد RFC 6410 كمعيار أساسي (أكتوبر 2013)، يمكن لفريق هندسة الإنترنت (IESG) اختيار إعادة تصنيف مسودة المعيار القديمة كمعيار مقترح . [ 21 ]

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

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

تُمنح جميع معايير الإنترنت رقمًا ضمن سلسلة STD. وقد لُخِّصت هذه السلسلة في وثيقتها الأولى، STD 1 (RFC 5000)، حتى عام 2013، ولكن تم التخلي عن هذه الممارسة في RFC 7100. ويتولى محرر RFC الآن مسؤولية تحديث القائمة النهائية لمعايير الإنترنت. [ 22 ]

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

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

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

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

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

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

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

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

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

تُعنى فرقة عمل هندسة الإنترنت (IETF) بوضع معايير تقنية موحدة وتطبيقاتها المتوقعة. وتركز IETF على المسائل المتعلقة بتطوير تقنيات الإنترنت وبروتوكول TCP/IP الحديثة. وهي مُقسّمة إلى عدة فرق عمل، كل منها مسؤول عن تطوير المعايير والمهارات في مجال مُحدد، مثل التوجيه أو الأمن السيبراني. أعضاء فرق العمل متطوعون، ويعملون في مجالات متنوعة، مثل موردي المعدات، ومشغلي الشبكات، ومؤسسات بحثية مختلفة. تبدأ IETF عملها بجمع الآراء حول المتطلبات التي ينبغي مناقشتها. ثم يتم تشكيل فريق عمل IETF، وتُطرح هذه المتطلبات في اجتماعات "الطيور على أشكالها تقع" (BoF) المؤثرة خلال مؤتمرات IETF.

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

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

RFCs

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

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

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

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

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

عملية وضع المعايير

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

نشر وثائق طلب التعليقات (RFCs) والوصول إليها

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

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

تُصاغ معايير الإنترنت بطريقتين، ويمكن تصنيفها إلى نوعين: المعايير "الرسمية" والمعايير "الفعلي". [ 32 ] يصبح المعيار الفعلي معيارًا من خلال استخدامه على نطاق واسع في أوساط مجتمع التقنية. أما المعيار الرسمي، فيُصاغ رسميًا من قِبل منظمات تطوير المعايير الرسمية. [ 32 ] وتخضع هذه المعايير لعملية معايير الإنترنت . ومن المعايير الرسمية الشائعة: ASCII و SCSI ومجموعة بروتوكولات الإنترنت . [ 28 ]

مواصفات معيار الإنترنت

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

  • مطلوب: يتطلب تحقيق قابلية التشغيل البيني تطبيق المواصفات الفنية المشار إليها. على سبيل المثال، يتعين على أنظمة الإنترنت التي تستخدم مجموعة بروتوكولات الإنترنت تطبيق بروتوكول الإنترنت (IP) وبروتوكول رسائل التحكم في الإنترنت (ICMP) . [ 33 ]
  • التوصية: لا يُشترط تطبيق المواصفات الفنية المرجعية، ولكن يُستحسن ذلك في نطاق تطبيق نظام التطبيقات. ويُشجع على تضمين وظائف وميزات وبروتوكولات المواصفات الفنية الموصى بها في تطوير الأنظمة. على سبيل المثال، يجب تطبيق بروتوكول TELNET في جميع الأنظمة التي تعتزم استخدام الوصول عن بُعد. [ 33 ]
  • اختياري: يُعدّ تطبيق المواصفات الفنية المشار إليها اختيارياً. ولا تكون هذه المواصفات ضرورية إلا في بيئة محددة. على سبيل المثال، يمكن اعتبار قاعدة معلومات إدارة DECNET ذات قيمة في بيئة تُستخدم فيها بروتوكول DECNET . [ 33 ]

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

معايير الويب

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

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

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

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

انظر أيضاً

مراجع

  1. 1 2 "معايير بروتوكول الإنترنت الرسمية" . محرر RFC . تم الاطلاع عليه بتاريخ 25 ديسمبر 2025 .
  2. ↑ "مقدمة إلى ملاحظات STD" . محرر RFC . تم الاطلاع عليه بتاريخ 25 ديسمبر 2025 .
  3. ↑ "عملية معايير الإنترنت - المراجعة 3" . محرر RFC . تم الاطلاع عليه بتاريخ 25 ديسمبر 2025 .
  4. 1 2 "تقليص مسار المعايير إلى مستويين من النضج" . محرر RFC . تم الاطلاع عليه بتاريخ 25 ديسمبر 2025 .
  5. ↑ "ليست كل طلبات التعليقات (RFCs) معايير" . متتبع بيانات IETF . تم الاطلاع عليه بتاريخ 25 ديسمبر 2025 .
  6. ↑ ليبا، باري (يناير 2008). "مقدمة في معايير الإنترنت". مجلة IEEE للحوسبة عبر الإنترنت . 12 (1): 71-74 . doi : 10.1109/MIC.2008.2 .
  7. 1 2 ليبا، باري (يناير 2008). "مقدمة في معايير الإنترنت". مجلة IEEE للحوسبة عبر الإنترنت . 12 (1): 71-74 . doi : 10.1109/MIC.2008.2 . ISSN 1089-7801 . 
  8. ↑ أبّاتي، جانيت (1999). اختراع الإنترنت . مطبعة معهد ماساتشوستس للتكنولوجيا. رقم ISBN 978-0-262-01172-3.
  9. ↑ سيرف، فينتون ج.؛ كان، روبرت إي. (مايو 1974). "بروتوكول للاتصال بين شبكات الحزم". معاملات IEEE في الاتصالات . 22 (5): 637-648 . doi : 10.1109/TCOM.1974.1092259 .
  10. 1 2 لينر، باري م.؛ سيرف، فينتون ج.؛ كلارك، ديفيد د.؛ كان، روبرت إ.؛ كلاينروك، ليونارد؛ لينش، دانيال س.؛ بوستل، جون؛ روبرتس، لورانس ج.؛ وولف، ستيفن (أكتوبر 2009). "تاريخ موجز للإنترنت" (ملف PDF) . مجلة ACM SIGCOMM لمراجعة اتصالات الحاسوب . 39 (5): 22-31 . doi : 10.1145/1629607.1629613 .
  11. ↑ سيرف، فينتون ج.؛ كان، روبرت إي. (مايو 1974). "بروتوكول للاتصال بين شبكات الحزم" (ملف PDF) . معاملات IEEE في الاتصالات . 22 (5): 637-648 . doi : 10.1109/TCOM.1974.1092259 .
  12. ↑ "بروتوكول أمان بروتوكول الإنترنت (ipsec) -" . datatracker.ietf.org . مؤرشف من الأصل بتاريخ 13-09-2019 . تم الاطلاع عليه بتاريخ 08-12-2021 .
  13. ↑ "تطور بروتوكول HTTP - HTTP | MDN" . developer.mozilla.org . مؤرشف من الأصل بتاريخ 27-03-2023 . تم الاطلاع عليه بتاريخ 08-12-2021 .
  14. ↑ "بروتوكول أمان طبقة النقل (TLS) - مسرد مصطلحات MDN Web Docs: تعريفات المصطلحات المتعلقة بالويب | MDN" . developer.mozilla.org . مؤرشف من الأصل بتاريخ 2021-12-08 . تم الاطلاع عليه بتاريخ 2021-12-08 .
  15. ↑ علاني، محمد م. (2014)، "نموذج OSI" ، دليل نماذج OSI وTCP/IP ، سلسلة SpringerBriefs في علوم الحاسوب، تشام: Springer International Publishing، ص 5-17 ، doi : 10.1007/978-3-319-05152-9_2 ، ISBN  978-3-319-05151-2تم الاطلاع عليه بتاريخ 2021-12-08
  16. ↑ "ما هو بروتوكول UDP | شركة DiverseNet" . مؤرشف من الأصل بتاريخ 2021-12-08 . تم الاطلاع عليه بتاريخ 2021-12-08 .
  17. 1 2 راسل هاوسلي؛ ديف كروكر؛ إريك دبليو. برجر (11 أكتوبر 2011). "مستوى النضج الثاني: معيار الإنترنت" . تقليص مسار المعايير إلى مستويين من النضج . IETF . القسم 2.2. doi : 10.17487/RFC6410 . RFC 6410. يُرسل طلب إعادة التصنيف إلى IESG مع شرح لكيفية استيفاء المعايير. المعايير هي:... 
  18. ↑ "توصيف المواصفات" . توصيف المعايير المقترحة . IETF . يناير 2014. القسم 3. doi : 10.17487/RFC7127 . RFC 7127. تم الاطلاع عليه في 11 مارس 2016 . 
  19. ↑ "مراجعة IETF للمعايير المقترحة" . توصيف المعايير المقترحة . IETF . يناير 2014. القسم 2. doi : 10.17487/RFC7127 . RFC 7127. تم الاطلاع عليه في 11 مارس 2016 . 
  20. ↑ برادنر، س. (أكتوبر 1996). "إجراءات المعايير" . عملية معايير الإنترنت - المراجعة 3. IETF . القسم 6.1. doi : 10.17487/rfc2026 . RFC 2026 . 
  21. ↑ راسل هاوسلي؛ ديف كروكر؛ إريك دبليو. برجر (11 أكتوبر 2011). "الانتقال إلى مسار معايير بمستويين من النضج" . تقليص مسار المعايير إلى مستويين من النضج . IETF . القسم 2.3. doi : 10.17487/RFC6410 . RFC 6410 . 
  22. ↑ "معايير بروتوكول الإنترنت الرسمية" . مؤرشف من الأصل بتاريخ 15-03-2018 . تم الاطلاع عليه بتاريخ 19-03-2018 .
  23. ↑ RFC 7100 
  24. ↑ ما، د.؛ ماندلبرغ، د.؛ بروينزيلز، ت. (أغسطس 2018). إدارة مبسطة لموارد أرقام الإنترنت المحلية باستخدام RPKI (SLURM) . IETF . doi : 10.17487/rfc8416 . RFC 8416 .
  25. ↑ كنيبس، غونتر (سبتمبر 2015). "إدارة حركة المرور الريادية وفريق عمل هندسة الإنترنت" . مجلة قانون المنافسة والاقتصاد . 11 (3): 727-745 . doi : 10.1093/joclec/nhv018 . ISSN 1744-6414 . 
  26. ↑ جمعية الإنترنت، فريق عمل هندسة الإنترنت. الإنترنت (2005). مجلة فريق عمل هندسة الإنترنت . جمعية الإنترنت. OCLC 746928702 . 
  27. ↑ "RFCs" . IETF . مؤرشف من الأصل بتاريخ 2021-12-06 . تم الاطلاع عليه بتاريخ 2021-12-08 .
  28. 1 2 معايير بروتوكول الإنترنت الرسمية . IETF . مايو 2008. doi : 10.17487/rfc5000 . RFC 5000 .
  29. ↑ فاريل، أ. (أبريل 2014). معالجة مسودات الإنترنت من قبل مجموعات عمل IETF . IETF . doi : 10.17487/rfc7221 . RFC 7221 .
  30. ↑ حقوق الملكية الفكرية في تقنية IETF . IETF . مارس 2005. doi : 10.17487/rfc3979 . RFC 3979 .
  31. ↑ هوفي، ر.؛ برادنر، س. (أكتوبر 1996). المنظمات المشاركة في عملية معايير IETF . IETF . doi : 10.17487/rfc2028 . RFC 2028 .
  32. 1 2 نيكرسون؛ موهلين (2006). "بيئة عمليات وضع المعايير: رؤى من وضع معايير الإنترنت". مجلة نظم المعلومات الإدارية الفصلية . 30 : 467-488 . doi : 10.2307/25148769 . JSTOR 25148769 . 
  33. 1 2 3 4 5 6 برادنر، س. (أكتوبر 1996). عملية معايير الإنترنت - المراجعة 3. IETF . doi : 10.17487 /rfc2026 . RFC 2026 .
  34. ↑ كومر، دوغلاس (2015). شبكات الحاسوب والإنترنت ( الطبعة السادسة). بوسطن، ماساتشوستس. ISBN  978-0-13-358793-7. OCLC 870649960 . {{cite book}}: CS1 maint: موقع الناشر مفقود ( رابط )