بروتوكول وقت الشبكة

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

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

يُوصَف البروتوكول عادةً بنموذج العميل والخادم ، لكن يُمكن استخدامه بسهولة في علاقات الند للند حيث يعتبر كل طرف الآخر مصدرًا محتملاً للوقت. [ 1 ] : 20 تُرسِل التطبيقات وتستقبل الطوابع الزمنية باستخدام بروتوكول بيانات المستخدم (UDP)؛ وتعمل الخدمة عادةً على المنفذ رقم 123، وفي بعض الأوضاع يستخدم كلا الطرفين هذا المنفذ. [ 4 ] [ 5 ] : 16 كما يُمكنها استخدام البث أو البث المتعدد ، حيث يستمع العملاء بشكل سلبي إلى تحديثات الوقت بعد تبادل معايرة أولي ذهابًا وإيابًا. [ 3 ] يُصدر بروتوكول NTP تحذيرًا بشأن أي تعديل وشيك للثانية الكبيسة، لكن لا يتم إرسال أي معلومات حول المناطق الزمنية المحلية أو التوقيت الصيفي . [ 2 ] [ 3 ]

البروتوكول الحالي هو الإصدار 4 (NTPv4)، [ 5 ] وهو متوافق مع الإصدارات السابقة من الإصدار 3. [ 6 ]

خوارزمية مزامنة الساعة

زمن التأخير ذهابًا وإيابًا δ

يقوم عميل NTP النموذجي باستطلاع خادم NTP واحد أو أكثر بشكل دوري. يجب على العميل حساب فرق التوقيت وتأخير الرحلة ذهابًا وإيابًا . فرق التوقيت θ هو الفرق الموجب أو السالب (توقيت العميل > توقيت الخادم) في التوقيت المطلق بين الساعتين. ويتم تعريفه بواسطة

θ=(ت1-ت0)+(ت2-ت3)2،{\displaystyle \theta ={\frac {(t_{1}-t_{0})+(t_{2}-t_{3})}{2}},} وتأخير الرحلة ذهابًا وإيابًا δ بواسطة دلتا=(ت3-ت0)-(ت2-ت1)،{\displaystyle \delta ={(t_{3}-t_{0})-(t_{2}-t_{1})},} أين

  • يمثل t 0 الطابع الزمني الخاص بالعميل لإرسال حزمة الطلب،
  • يمثل t 1 الطابع الزمني للخادم لاستلام حزمة الطلب،
  • يمثل t 2 الطابع الزمني للخادم عند إرسال حزمة الاستجابة و
  • يمثل t3 الطابع الزمني لاستلام العميل لحزمة الاستجابة. [ 1 ] : 19

لاستنتاج صيغة الإزاحة، لاحظ أنه بالنسبة لحزمة الطلب، ت0+θ+دلتا/2=ت1{\displaystyle t_{0}+\theta +\delta /2=t_{1}} وبالنسبة لحزمة الرد، ت3+θ-دلتا/2=ت2{\displaystyle t_{3}+\theta -\delta /2=t_{2}} يؤدي حل المعادلة لإيجاد قيمة θ إلى تعريف الإزاحة الزمنية.

تُمرر قيمتا θ و δ عبر مرشحات وتُخضعان لتحليل إحصائي ("التخفيف"). تُستبعد القيم الشاذة ، ويُستخلص تقدير لانحراف التوقيت من أفضل ثلاثة مرشحين متبقين. ثم يُعدّل تردد الساعة لتقليل الانحراف تدريجيًا ("الضبط")، مما يُنشئ حلقة تغذية راجعة . [ 1 ] : 20

يتحقق التزامن الدقيق عندما يكون لكل من المسارين الوارد والصادر بين العميل والخادم تأخير اسمي متناظر. إذا لم يكن للمسارين تأخير اسمي مشترك، فسيوجد انحياز منهجي يعادل نصف الفرق بين زمن الرحلة ذهابًا وإيابًا. وقد اقتُرحت عدة طرق لقياس عدم التناظر، [ 7 ] ولكن من بين التطبيقات العملية، يبدو أن برنامج chrony هو الوحيد الذي يتضمن هذه الطريقة. [ 8 ] [ 9 ]

تاريخ

تم تصميم بروتوكول NTP بواسطة ديفيد إل. ميلز .
تطور RFC لـ NTP
1980  
1985  
1990  
1995  
2000  
2005  
2010  
2015  
2020  
v0، RFC  958 [ 10 ]
الإصدار 1، RFC  1059 [ 11 ]
الإصدار الثاني، RFC  1119 [ 12 ]
الإصدار 3، RFC  1305 [ 6 ]
الإصدار الرابع، RFC  5905 [ 5 ]
الإصدار 3، RFC  1361 [ 13 ]
الإصدار 3، RFC  1769 [ 14 ]
الإصدار الرابع، RFC  2030 [ 15 ]
الإصدار الرابع، RFC  4330 [ 16 ]
خدمة ساعة الإنترنت DCNET [ 17 ]
بروتوكول نقل الملفات البسيط (SNTP)
تم دمج بروتوكول SNTP
الحقول الخارجية [ 18 ]
تغيير MAC [ 19 ]
التوزيع العشوائي للمنافذ [ 20 ]

في عام ١٩٧٩، استُخدمت تقنية مزامنة الوقت الشبكي فيما يُحتمل أنه أول عرضٍ علني لخدمات الإنترنت التي تعمل عبر شبكة أقمار صناعية عابرة للمحيط الأطلسي، وذلك في المؤتمر الوطني للحاسوب في نيويورك. وتم وصف هذه التقنية لاحقًا في مذكرة هندسة الإنترنت (IEN) ١٧٣ لعام ١٩٨١ [ ٢١ ] ، وطُوّر منها بروتوكول عام وُثّق في RFC ٧٧٨. نُشرت التقنية لأول مرة في شبكة محلية كجزء من بروتوكول توجيه Hello، وطُبّقت في جهاز توجيه Fuzzball ، وهو نظام تشغيل تجريبي استُخدم في تصميم نماذج الشبكات، حيث استمر تشغيله لسنوات عديدة. 

كانت هناك أدوات شبكية أخرى ذات صلة متاحة آنذاك والآن. تشمل هذه الأدوات بروتوكولات Daytime و Time لتسجيل وقت الأحداث، بالإضافة إلى رسائل ICMP Timestamp وخيار IP Timestamp ( RFC 781 ). وتشمل أنظمة المزامنة الأكثر اكتمالاً، على الرغم من افتقارها إلى خوارزميات تحليل البيانات وضبط الساعة الخاصة ببروتوكول NTP، برنامج timed الخفي في نظام Unix ، والذي يستخدم خوارزمية انتخاب لتعيين خادم لجميع العملاء؛ [ 22 ] وخدمة مزامنة الوقت الرقمي (DTSS)، التي تستخدم تسلسلاً هرمياً للخوادم مشابهاً لنموذج طبقات NTP. 

في عام 1985، تم تطبيق الإصدار 0 من بروتوكول NTP (NTPv0) في كل من Fuzzball و Unix، وتم توثيق حسابات رأس حزمة NTP وتأخير الرحلة ذهابًا وإيابًا والإزاحة، والتي استمرت في NTPv4، في RFC 958. على الرغم من بطء أجهزة الكمبيوتر والشبكات المتاحة في ذلك الوقت، إلا أنه كان يتم الحصول عادةً على دقة أفضل من 100 مللي ثانية على الروابط التي تغطي المحيط الأطلسي، مع دقة تصل إلى عشرات المللي ثوانٍ على شبكات الإيثرنت . 

في عام 1988، نُشرت مواصفات أكثر شمولاً لبروتوكول NTPv1، مع الخوارزميات المرتبطة به، في RFC 1059. وقد استندت هذه المواصفات إلى النتائج التجريبية وخوارزمية مرشح الساعة الموثقة في RFC 956، وكانت أول نسخة تصف نمطي العميل والخادم والند للند . وفي عام 1991، لفتت بنية بروتوكول NTPv1 وبروتوكوله وخوارزمياته انتباه مجتمع هندسي أوسع مع نشر مقال لديفيد ل. ميلز في مجلة IEEE Transactions on Communications . [ 23 ]  

في عام 1989، نُشرت وثيقة RFC 1119 التي تُعرّف بروتوكول NTPv2 باستخدام آلة الحالة ، مع رمز زائف لوصف آلية عمله. وقدّمت هذه الوثيقة بروتوكول إدارة ونظام مصادقة تشفيرية ، وكلاهما استمرّ في بروتوكول NTPv4، إلى جانب الجزء الأكبر من الخوارزمية. مع ذلك، تعرّض تصميم NTPv2 لانتقادات من مجتمع DTSS لافتقاره إلى الدقة الرسمية ، وتمّ تعديل إجراء اختيار الساعة ليشمل خوارزمية مارزولو بدءًا من NTPv3. [ 24 ] 

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

في السنوات اللاحقة، ومع إضافة ميزات جديدة وتحسين الخوارزميات، بات من الواضح ضرورة إصدار نسخة جديدة من البروتوكول. [ 25 ] في عام 2010، نُشرت RFC 5905 متضمنةً مواصفات مقترحة لبروتوكول NTPv4. [ 26 ] بعد تقاعد ميلز من جامعة ديلاوير ، يُدار التطبيق المرجعي حاليًا كمشروع مفتوح المصدر بقيادة هارلان ستين. [ 27 ] [ 28 ] أما من جانب IANA ، فتتولى مجموعة عمل بروتوكولات وقت الشبكة (ntp ) مسؤولية مراجعة المسودات المقترحة. [ 29 ] 

لقد شهد البروتوكول تطوراً ملحوظاً منذ الإصدار الرابع من بروتوكول NTP. [ 26 ] اعتباراً من عام 2022نُشرت ثلاث وثائق RFC تصف تحديثات البروتوكول، [ 18 ] [ 19 ] [ 20 ] هذا بالإضافة إلى العديد من المعايير الطرفية [ 29 ] مثل معيار أمان وقت الشبكة. [ 30 ] كان ميلز قد ذكر خططًا لإصدار "NTPv5" على صفحته، لكن لم يُنشر أي منها. [ 26 ] بدأ العمل على مسودة منفصلة تحمل اسم "NTPv5" من قِبل م. ليشفار من كروني في عام 2020، وتتضمن تغييرات في الأمان والدقة وقابلية التوسع. [ 31 ]

بروتوكول نقل الملفات البسيط (SNTP)

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

مع استبدال بروتوكول NTP ببروتوكول الوقت القديم ، وجدت بعض حالات الاستخدام أن البروتوكول الكامل معقد للغاية. في عام 1992، تم تعريف بروتوكول وقت الشبكة البسيط ( SNTP ) لسدّ هذه الثغرة. يصف معيار SNTPv3 طريقة استخدام NTPv3 بحيث لا حاجة لتخزين الحالة على مدى فترة طويلة. يصبح تصميم الشبكة مماثلاً تقريبًا لبروتوكول الوقت، حيث يُستخدم خادم واحد فقط. [ 13 ] في عام 1996، تم تحديث SNTP إلى SNTPv4، [ 15 ] مع بعض ميزات NTPv4 الذي كان قيد التطوير آنذاك. تم دمج SNTPv4 في معيار NTPv4 الرئيسي في عام 2010. [ 5 ]

يُعدّ بروتوكول SNTP متوافقًا تمامًا مع بروتوكول NTP لأنه لا يُعرّف بروتوكولًا جديدًا [ 32 ] : §14 ، إذ يستخدم نفس تنسيق الحزم والمنفذ الخاص بـ NTP، مما يضمن التوافق مع خوادم NTP. مع ذلك، سيفتقر نظام العميل/الخادم إلى الخوارزميات المعقدة اللازمة لتصفية اضطراب الشبكة ، وتحليل انحراف الساعة ، أو الربط المرجعي بين مصادر زمنية متعددة. هذا يجعله مناسبًا لأجهزة إنترنت الأشياء والأجهزة الأساسية التي تتطلب توقيتًا دقيقًا دون الحاجة إلى حزمة تطبيقات NTP كاملة. [ 5 ]

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

طبقات الساعة

تعتبر الساعة الرئيسية البديلة للمرصد البحري الأمريكي في قاعدة شريفر الجوية (كولورادو) مصدرًا من الطبقة 0 لـ NTP.
تشير الأسهم الصفراء إلى اتصال مباشر؛ وتشير الأسهم الحمراء إلى اتصال عبر الشبكة.

يستخدم بروتوكول NTP نظامًا هرميًا شبه طبقي لمصادر الوقت. يُطلق على كل مستوى من هذا التسلسل الهرمي اسم " طبقة" ويُخصص له رقم يبدأ من الصفر لساعة المرجع في الأعلى. يعمل الخادم المتزامن مع خادم الطبقة n في الطبقة n + 1. يُمثل الرقم المسافة من ساعة المرجع ويُستخدم لمنع التبعيات الدورية في التسلسل الهرمي. لا تُعد الطبقة دائمًا مؤشرًا على الجودة أو الموثوقية؛ فمن الشائع العثور على مصادر وقت من الطبقة 3 ذات جودة أعلى من بعض مصادر الوقت من الطبقة 2. [ أ ] فيما يلي وصف موجز للطبقات 0 و1 و2 و3.

الطبقة 0
هذه أجهزة ضبط وقت عالية الدقة، مثل الساعات الذرية ، وأنظمة الملاحة عبر الأقمار الصناعية (بما في ذلك نظام تحديد المواقع العالمي GPS )، أو ساعات الراديو الأخرى ، أو الساعات المتزامنة مع بروتوكول PTP . [ 33 ] تُولّد هذه الأجهزة إشارة نبضية دقيقة للغاية في الثانية ، تُفعّل مقاطعة وطابعًا زمنيًا على جهاز كمبيوتر متصل. تُعرف أجهزة الطبقة 0 أيضًا باسم الساعات المرجعية . لا يمكن لخوادم NTP الإعلان عن نفسها كطبقة 0؛ يشير حقل الطبقة المُعيّن إلى 0 في رسالة NTP إلى طبقة غير مُحددة. [ 5 ] : 21
الطبقة 1
هذه حواسيب تتم مزامنة وقت نظامها بدقة تصل إلى بضعة ميكروثوانٍ مع أجهزة الطبقة 0 المتصلة بها. قد تتصل خوادم الطبقة 1 بخوادم أخرى من الطبقة 1 للتحقق من سلامة البيانات وإجراء النسخ الاحتياطي. [ 34 ] ويُشار إليها أيضًا باسم خوادم الوقت الأساسية. [ 2 ] [ 3 ]
الطبقة 2
هذه أجهزة حاسوب تتم مزامنتها عبر الشبكة مع خوادم الطبقة الأولى. غالبًا ما يستعلم جهاز حاسوب من الطبقة الثانية من عدة خوادم من الطبقة الأولى. وقد تتصل أجهزة حاسوب الطبقة الثانية أيضًا بأجهزة حاسوب أخرى من الطبقة الثانية لتوفير توقيت أكثر استقرارًا وموثوقية لجميع الأجهزة في مجموعة النظراء.
الطبقة 3
هذه أجهزة كمبيوتر متزامنة مع خوادم الطبقة الثانية. وهي تستخدم نفس خوارزميات التناظر وأخذ عينات البيانات المستخدمة في الطبقة الثانية، ويمكنها أن تعمل كخوادم لأجهزة كمبيوتر الطبقة الرابعة، وهكذا.

الحد الأعلى للطبقة هو 15؛ وتُستخدم الطبقة 16 للإشارة إلى أن الجهاز غير متزامن. تتفاعل خوارزميات NTP على كل جهاز كمبيوتر لإنشاء شجرة امتداد أقصر مسار من نوع بيلمان-فورد ، وذلك لتقليل زمن التأخير التراكمي ذهابًا وإيابًا إلى خوادم الطبقة 1 لجميع العملاء. [ 1 ] : 20

بالإضافة إلى الطبقة، فإن البروتوكول قادر على تحديد مصدر المزامنة لكل خادم من حيث معرف مرجعي (refid).

رموز المعرفات المرجعية الزمنية الشائعة (refid)
Refid [ 35 ]مصدر الساعة
يذهبقمر صناعي بيئي تشغيلي ثابت بالنسبة للأرض (يوصف بأنه "قمر صناعي بيئي في مدار متزامن مع الأرض" في RFC 5905)
نظام تحديد المواقع العالمي (GPS)نظام تحديد المواقع العالمي (GPS)
غالنظام تحديد المواقع جاليليو
PPSنبضة عامة في الثانية
إيريجمجموعة أجهزة القياس بين النطاقات
WWVBمحطة راديو WWVB ذات التردد المنخفض، فورت كولينز، كولورادو، 60  كيلوهرتز
DCF/PZF [ 36 ]راديو LF DCF77 Mainflingen، DE 77.5  كيلو هرتز
HBGراديو LF HBG Prangins، HB 75  كيلو هرتز (توقف عن التشغيل)
أطباء بلا حدودراديو LF MSF أنثورن، المملكة المتحدة 60  كيلوهرتز
جاي جاي وايراديو LF JJY فوكوشيما، اليابان 40  كيلوهرتز، ساغا، اليابان 60  كيلوهرتز
LORCمحطة راديو لوران-سي متوسطة التردد ، 100  كيلوهرتز
تي دي إفراديو MF ألويس، فرنسا 162 كيلوهرتز
تشوراديو HF، مستشفى جامعة أوتاوا، أونتاريو
WWVمحطة راديو HF WWV، فورت كولينز، كولورادو
WWVHراديو HF WWVH كاواي، هاواي
المعهد الوطني للمعايير والتكنولوجيامودم الهاتف NIST
أفعالمودم الهاتف NIST
البحرية الأمريكيةمودم الهاتف التابع للبحرية الأمريكية
PTBمودم الهاتف الألماني PTB ذو التوقيت القياسي
السّيدةمصادر مرجعية متعددة (غير رسمية)
جوجل(غير رسمي) معرف جوجل المستخدم بواسطة خوادم NTP الخاصة بجوجل كـ time4.google.com [ 37 ]

بالنسبة للخوادم في الطبقة الثانية وما دونها، يُعدّ refid شكلاً مُشفّراً لعنوان IP الخاص بخادم الوقت المصدر. في IPv4، يكون هذا ببساطة هو العنوان المكون من 32 بت؛ أما في IPv6، فيكون أول 32 بت من تجزئة MD5 لعنوان المصدر. تُستخدم refids للكشف عن حلقات التوقيت ومنعها من الدرجة الأولى. [ 5 ]

يُملأ حقل refid بكلمات الحالة في حالة حزم "الموت المبكر" (KoD)، والتي تُخبر العميل بالتوقف عن إرسال الطلبات حتى يتمكن الخادم من الراحة. [ 5 ] ومن الأمثلة على ذلك: INIT (التهيئة)، وSTEP (تغيير خطوة الوقت)، وRATE (طلب العميل بسرعة كبيرة). [ 38 ] قد يستخدم مُخرَج البرنامج أيضًا رموزًا غير مُرسَلة في الحزمة للإشارة إلى وجود خطأ، مثل XFAC للإشارة إلى انقطاع الاتصال بالشبكة. [ 35 ]

تحتفظ هيئة IANA بسجل لأسماء مصادر refid ورموز KoD. ولا يزال من الممكن ظهور تعيينات غير رسمية. [ 39 ]

تطبيقات البرمجيات

تُستخدم أداة إدارة بروتوكول NTP ntpqفي نظام التشغيل Windows 11 للاستعلام عن حالة خوادم الوقت من الطبقة 1 والتحقق من التشغيل السليم للعميل.

التنفيذ المرجعي

تم تطوير تطبيق NTP المرجعي ، إلى جانب البروتوكول نفسه، بشكل مستمر لأكثر من 20 عامًا. وقد حُفظت إمكانية التوافق مع الإصدارات السابقة مع إضافة ميزات جديدة. يحتوي التطبيق على العديد من الخوارزميات الحساسة، خاصةً لضبط الساعة، والتي قد لا تعمل بشكل صحيح عند مزامنتها مع خوادم تستخدم خوارزميات مختلفة. تم نقل البرنامج إلى جميع منصات الحوسبة تقريبًا، بما في ذلك أجهزة الكمبيوتر الشخصية. يعمل كخدمة (daemon) تُسمى ntpd في أنظمة Unix أو كخدمة (service) في أنظمة Windows. يدعم التطبيق الساعات المرجعية، ويتم ترشيح وتحليل انحرافاتها بنفس طريقة الخوادم البعيدة، على الرغم من أنها تُستطلع عادةً بشكل متكرر أكثر. [ 1 ] : 15-19 خضع هذا التطبيق للتدقيق في عام 2017، حيث تم اكتشاف 14 مشكلة أمنية محتملة. [ 40 ]

وقت ويندوز

جميع إصدارات مايكروسوفت ويندوز منذ ويندوز 2000 تتضمن خدمة وقت ويندوز (W32Time)، [ 41 ] والتي لديها القدرة على مزامنة ساعة الكمبيوتر مع خادم NTP.

تم تطبيق W32Time في الأصل لغرض بروتوكول مصادقة Kerberos الإصدار 5، الذي كان يتطلب أن يكون الوقت في حدود 5 دقائق من القيمة الصحيحة لمنع هجمات إعادة الإرسال . لا يُطبّق خادم وقت الشبكة في Windows 2000 Server (وWindows XP) مزامنة NTP المنضبطة، بل يُطبّق فقط المزامنة المحلية المنضبطة مع تصحيح NTP/SNTP. [ 42 ]

ابتداءً من نظامي التشغيل Windows Server 2003 و Windows Vista ، أصبح موفر بروتوكول NTP الخاص بـ W32Time متوافقًا مع مجموعة فرعية كبيرة من بروتوكول NTPv3. [ 43 ] تشير مايكروسوفت إلى أن W32Time لا يمكنه الحفاظ على مزامنة الوقت بدقة ثانية واحدة بشكل موثوق. [ 44 ] إذا رُغِبَ في دقة أعلى، توصي مايكروسوفت باستخدام إصدار أحدث من Windows أو تطبيق مختلف لبروتوكول NTP. [ 45 ]

ابتداءً من نظام التشغيل Windows 10 الإصدار 1607 ونظام التشغيل Windows Server 2016 ، يمكن ضبط برنامج W32Time للوصول إلى دقة زمنية تبلغ ثانية واحدة، أو 50 مللي ثانية، أو  مللي ثانية واحدة في ظل ظروف تشغيل محددة. [ 46 ] [ 44 ] [ 47 ]

OpenNTPD

في عام ٢٠٠٤، قدّم هينينغ براور من OpenBSD برنامج OpenNTPD ، وهو تطبيق لبروتوكول NTPv3/SNTPv4 [ ٤٨ ] يركز على الأمان ويتضمن تصميمًا يفصل بين الصلاحيات. ورغم أنه موجه بشكل أدق لتلبية الاحتياجات العامة البسيطة لمستخدمي OpenBSD، إلا أنه يتضمن أيضًا بعض التحسينات الأمنية للبروتوكول مع الحفاظ على توافقه مع خوادم NTP الحالية. ويُضحي تصميم قاعدة التعليمات البرمجية الأبسط بالدقة، وهو أمر غير ضروري في هذه الحالة. [ ٤٩ ] يتوفر إصدار محمول منه في مستودعات حزم لينكس.

بروتوكول NTPsec

يُعدّ NTPsec نسخةً مُعدّلة من التطبيق المرجعي، وقد خضعت لتعزيزات أمنية مُمنهجة . كانت نقطة التفرع في يونيو 2015، استجابةً لسلسلة من الاختراقات الأمنية في عام 2014. [ 50 ] صدر الإصدار الإنتاجي الأول في أكتوبر 2017. [ 51 ] بفضل إزالة الميزات غير الآمنة، وإلغاء دعم الأجهزة القديمة، وإلغاء دعم إصدارات يونكس القديمة، تمكّن NTPsec من تقليص 75% من قاعدة التعليمات البرمجية الأصلية، مما سهّل تدقيق ما تبقى منها . [ 52 ] أظهر تدقيقٌ للتعليمات البرمجية في عام 2017 وجود ثماني مشكلات أمنية، من بينها اثنتان لم تكونا موجودتين في التطبيق المرجعي الأصلي، إلا أن NTPsec لم يُعانِ من المشكلات الثماني الأخرى التي بقيت في التطبيق المرجعي. [ 53 ]

كروني

يعرض برنامج chronyc مصادر ومعلومات النشاط المتعلقة بأمان وقت الشبكة (NTS).

برنامج chrony هو تطبيق مستقل لبروتوكول NTP، ترعاه شركة Red Hat بشكل أساسي ، وتستخدمه كبرنامج الوقت الافتراضي في توزيعاتها. [ 54 ] بفضل كتابته من الصفر، يتميز chrony بقاعدة بيانات أبسط، مما يسمح بأمان أفضل [ 55 ] واستهلاك أقل للموارد. [ 56 ] ومع ذلك، فهو لا يُضحي بالدقة، بل يُزامن بشكل أسرع وأفضل من برنامج ntpd المرجعي في كثير من الحالات. وهو متعدد الاستخدامات بما يكفي لأجهزة الكمبيوتر العادية، التي قد تكون غير مستقرة، أو تدخل في وضع السكون، أو يكون اتصالها بالإنترنت متقطعًا. كما أنه مصمم أيضًا للأجهزة الافتراضية، وهي بيئة أقل استقرارًا. [ 57 ]

تم تقييم برنامج chrony بأنه "جدير بالثقة"، مع تسجيل عدد قليل من الحوادث. [ 58 ] وهو قادر على تحقيق دقة محسّنة على اتصالات الشبكة المحلية (LAN) باستخدام ختم زمني مادي على محول الشبكة. [ 8 ] تمت إضافة دعم أمان وقت الشبكة (NTS) في الإصدار 4.0. [ 59 ] يتوفر برنامج chrony بموجب رخصة جنو العمومية العامة الإصدار 2 ، وقد أنشأه ريتشارد كورنو عام 1997، ويتولى صيانته حاليًا ميروسلاف ليتشفار . [ 56 ]

ntpd-rs

ntp-ctl (جزء من ntpd-rs)، يعرض معلومات المزامنة ومصادر NTS

ntpd-rs هو تطبيقٌ لبروتوكول NTP يركز على الأمان، وقد أسسه فريق أبحاث أمن الإنترنت كجزء من مبادرة Prossimo لإنشاء بنية تحتية آمنة للذاكرة على الإنترنت. تم تطوير ntpd-rs بلغة البرمجة Rust التي توفر ضمانات أمان الذاكرة بالإضافة إلى إمكانيات الحوسبة في الوقت الحقيقي اللازمة لتطبيق NTP. يُستخدم ntpd-rs في بيئات حساسة أمنيًا مثل هيئة إصدار الشهادات غير الربحية Let's Encrypt . [ 60 ] يتوفر دعم NTS. [ 61 ] يُعد ntpd-rs جزءًا من مشروع "Pendulum" الذي يتضمن أيضًا تطبيقًا لبروتوكول التوقيت الدقيق "statime". كلا المشروعين متاحان بموجب تراخيص برمجيات Apache و MIT .

آحرون

الثواني الكبيسة

في يوم حدوث ثانية كبيسة، يتلقى برنامج ntpd إشعارًا إما من ملف تكوين ، أو ساعة مرجعية متصلة، أو خادم بعيد. على الرغم من أن ساعة NTP تتوقف فعليًا أثناء الحدث، نظرًا لشرط أن يظهر الوقت وكأنه يتزايد بشكل صارم ، فإن أي عملية تستعلم عن وقت النظام تتسبب في زيادته بمقدار ضئيل، مما يحافظ على ترتيب الأحداث. إذا دعت الحاجة إلى ثانية كبيسة سالبة، فسيتم حذفها بالتسلسل 23:59:58، 00:00:00، مع تخطي 23:59:59. [ 67 ]

يتمثل أحد الحلول البديلة، المسمى "توزيع الثواني الكبيسة"، في إضافة الثانية الكبيسة تدريجيًا على مدار 24 ساعة، من الظهر إلى الظهر بتوقيت UTC. يُستخدم هذا الحل من قِبل جوجل (داخليًا وعلى خوادم NTP العامة الخاصة بها)، وأمازون AWS، [ 68 ] وفيسبوك. [ 69 ] يدعم برنامج Chrony توزيع الثواني الكبيسة في وضعَي smoothtime و leapsecmode ، ولكن لا يُنصح باستخدامه مع مجموعة خوادم NTP العامة، لأن توزيع الثواني الكبيسة غير قياسي وسيؤدي إلى خلل في حسابات العميل عند دمجه مع خوادم أخرى. [ 70 ]

مخاوف أمنية

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

تم اكتشاف ثغرة أمنية ناتجة عن تجاوز سعة المخزن المؤقت للمكدس، وتم إصلاحها في عام 2014. [ 74 ] وقد أثارت هذه الثغرة قلق شركة آبل لدرجة أنها استخدمت خاصية التحديث التلقائي لأول مرة. [ 75 ] في الأنظمة التي تستخدم الإصدار المرجعي، والذي يعمل بصلاحيات المستخدم الجذر، قد يسمح ذلك بوصول غير محدود. أما بعض الإصدارات الأخرى، مثل OpenNTPD ، التي تتميز بقاعدة بيانات أصغر حجمًا وتعتمد تدابير وقائية أخرى مثل فصل الصلاحيات، فهي غير عرضة لهذه الثغرة. [ 76 ]

أشارت مراجعة أمنية أجريت عام 2017 لثلاثة تطبيقات لبروتوكول NTP، نيابة عن مبادرة البنية التحتية الأساسية التابعة لمؤسسة لينكس، إلى أن كلاً من NTP [ 77 ] [ 78 ] وNTPsec [ 79 ] كانا أكثر إشكالية من chrony [ 80 ] من وجهة نظر أمنية. [ 81 ]

قد تكون خوادم بروتوكول وقت الشبكة (NTP) عرضةً لهجمات الوسيط (man-in-the-middle) ما لم يتم توقيع الحزم تشفيرياً لأغراض المصادقة. [ 82 ] قد تجعل التكاليف الحسابية الإضافية هذا الأمر غير عملي على الخوادم المشغولة، لا سيما أثناء هجمات حجب الخدمة . [ 83 ] يمكن استخدام انتحال رسائل NTP الناتج عن هجوم الوسيط لتغيير ساعات أجهزة الكمبيوتر العميلة، مما يسمح بتنفيذ عدد من الهجمات القائمة على تجاوز انتهاء صلاحية مفتاح التشفير. [ 84 ] من بين الخدمات المتأثرة برسائل NTP المزيفة التي تم تحديدها: بروتوكول أمان طبقة النقل (TLS) ، وبروتوكول أمان نظام أسماء النطاقات (DNSSEC )، وأنظمة التخزين المؤقت المختلفة (مثل ذاكرة التخزين المؤقت لنظام أسماء النطاقات)، وبروتوكول بوابة الحدود (BGP)، وبيتكوين ، وعدد من أنظمة تسجيل الدخول الدائمة. [ 85 ] [ 86 ]

استُخدم بروتوكول NTP في هجمات الحرمان من الخدمة الموزعة . [ 87 ] [ 88 ] حيث تُرسل استعلامة صغيرة إلى خادم NTP مع تزييف عنوان IP المُسترجع ليُطابق عنوان الهدف. وعلى غرار هجوم تضخيم DNS ، يستجيب الخادم بردٍّ أكبر بكثير، مما يسمح للمهاجم بزيادة كمية البيانات المُرسلة إلى الهدف بشكل كبير. ولتجنب الوقوع ضحيةً لهذا الهجوم، يُمكن ترقية برنامج خادم NTP أو تهيئة الخوادم لتجاهل الاستعلامات الخارجية. [ 89 ]

ملحقات آمنة

يتضمن بروتوكول NTP نفسه دعمًا لمصادقة الخوادم للعملاء. يدعم NTPv3 وضع المفتاح المتناظر ، وهو غير فعال ضد هجمات الوسيط. يوفر نظام المفتاح العام المعروف باسم "autokey" في NTPv4، والمقتبس من IPSec، مصادقة فعالة، [ 82 ] ولكنه غير عملي للخوادم المشغولة. [ 83 ] كما تبين لاحقًا أن Autokey يعاني من عدة عيوب تصميمية، [ 90 ] دون نشر أي تصحيح، باستثناء تغيير في رمز مصادقة الرسائل . [ 19 ] لذا، يُنصح بالتوقف عن استخدام Autokey. [ 91 ]

أمان وقت الشبكة (NTS) هو إصدار آمن من بروتوكول NTPv4 مع TLS و AEAD . [ 92 ] يتمثل التحسين الرئيسي مقارنةً بالمحاولات السابقة في أن خادم "إنشاء المفاتيح" المنفصل يتولى عملية التشفير غير المتماثل المعقدة، والتي لا تتطلب سوى تنفيذ واحد. في حال تعطل الخادم، سيظل بإمكان المستخدمين السابقين الحصول على الوقت دون خوف من هجمات الوسيط. [ 30 ] يدعم NTS العديد من خوادم NTP، بما في ذلك Cloudflare و Netnod . [ 93 ] [ 94 ] ويمكن تفعيله على chrony و NTPsec و ntpd-rs. [ 95 ]

لدى مايكروسوفت أيضًا طريقة لمصادقة حزم NTPv3/SNTPv4 باستخدام هوية نطاق ويندوز ، تُعرف باسم MS-SNTP. [ 96 ] تم تطبيق هذا النظام في برنامجي ntpd و chrony المرجعيين، باستخدام سامبا للاتصال بالنطاق. [ 97 ]

تنسيق رأس حزمة NTP

تنسيق رأس حزمة بروتوكول وقت الشبكة (NTP) [ 5 ] : §7.3
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
00ليVNوضعطبقةاستطلاع رأيدقة
432تأخير الجذر
864انتشار الجذور
1296رقم المرجع
16128الطابع الزمني المرجعي (64 بت)
20160
24192الطابع الزمني للأصل (64 بت)
28224
32256استلام الطابع الزمني (64 بت)
36288
40320طابع زمني للإرسال (64 بت)
44352
48384اختياري: حقل (حقول) الامتداد (ن * 32 بت)
52416اختياري: مُعرِّف المفتاح (في حال وجود رمز مصادقة الرسائل)
56448اختياري: ملخص الرسالة (dgst) (في حال وجود رمز مصادقة الرسائل MAC)
60480
64512
68544
مؤشر القفزة (LI) : 2 بت
تحذير بشأن إدخال أو حذف ثانية كبيسة:
  • 0 = لا يوجد تحذير
  • 1 = الدقيقة الأخيرة تحتوي على 61 ثانية
  • 2 = الدقيقة الأخيرة تحتوي على 59 ثانية
  • 3 = غير معروف (الساعة غير متزامنة)
رقم الإصدار (VN) : 3 بتات
رقم إصدار بروتوكول NTP، عادةً 4.
الوضع : 3 بتات
وضع الارتباط:
  • 0 = محجوز
  • 1 = نشط متناظر
  • 2 = سلبي متناظر
  • 3 = العميل
  • 4 = خادم
  • 5 = بث
  • 6 = التحكم
  • 7 = خاص
الطبقة : 8 بت
يشير إلى المسافة من الساعة المرجعية.
  • 0 = غير صالح
  • 1 = الخادم الرئيسي
  • 2-15 = ثانوي
  • 16 = غير متزامن
استطلاع رأي : 8 بت
الحد الأقصى للفاصل الزمني بين الرسائل المتتالية، بوحدة لوغاريتم 2 (بالثواني). يتراوح النطاق النموذجي بين 6 و 10.
الدقة : 8 بت
log₂(seconds) الموقع لدقة ساعة النظام (على سبيل المثال، –18 ≈ 1 ميكروثانية).
تأخير الجذر : 32 بت
إجمالي زمن التأخير ذهابًا وإيابًا إلى الساعة المرجعية، بتنسيق NTP المختصر.
تشتت الجذر : 32 بت
التشتت الكلي بالنسبة لساعة المرجع، بتنسيق NTP المختصر.
رقم المرجع : 32 بت
يحدد الخادم المحدد أو ساعة المرجع؛ ويعتمد التفسير على الطبقة.
الطابع الزمني المرجعي : 64 بت
الوقت الذي تم فيه ضبط أو تصحيح ساعة النظام آخر مرة، بتنسيق الطابع الزمني NTP.
الطابع الزمني للأصل (org) : 64 بت
الوقت عند العميل عند مغادرة الطلب، بتنسيق الطابع الزمني لبروتوكول NTP.
طابع زمني للاستلام (rec) : 64 بت
التوقيت المحلي، بتنسيق الطابع الزمني، عند وصول آخر رسالة NTP.
طابع زمني للإرسال (xmt) : 64 بت
الوقت على الخادم عندما غادرت الاستجابة، بتنسيق الطابع الزمني لبروتوكول NTP.
حقل الامتداد : متغير
حقل (حقول) اختيارية لامتدادات NTP (انظر [ 5 ] ، القسم 7.5).
معرّف المفتاح : 32 بت
عدد صحيح غير مُوقّع يُشير إلى مفتاح MD5 مشترك بين العميل والخادم.
ملخص الرسالة (MD5) : 128 بت
تجزئة MD5 التي تغطي رأس الحزمة وحقول الامتداد، وتستخدم للمصادقة.

الطوابع الزمنية

تتكون الطوابع الزمنية الثنائية ذات النقطة الثابتة 64 بت المستخدمة في بروتوكول NTP من جزء 32 بت للثواني وجزء 32 بت لأجزاء الثانية، مما يُعطي مقياسًا زمنيًا يتكرر كل 2^ 32 ثانية (136 عامًا) ودقة نظرية تبلغ 2^ -32 ثانية (233 بيكو ثانية). يستخدم بروتوكول NTP بداية حقبة 1 يناير 1900. لذلك، يحدث أول تكرار في 7 فبراير 2036. [ 98 ] [ 99 ]

يُقدّم بروتوكول NTPv4 تنسيقًا للتاريخ مكونًا من 128 بت: 64 بت للثانية و64 بت لجزء الثانية. مع ذلك، لا يُرسل هذا التنسيق أبدًا، إذ ينص المعيار على أن الحقب "لا يُمكن لبروتوكول NTP إنتاجها مباشرةً، ولا حاجة لذلك". [ 100 ] تُمثّل البتات الـ 32 الأكثر أهمية في هذا التنسيق رقم الحقبة ، والذي من شأنه حلّ غموض تجاوز الحدّ في معظم الحالات. [ 101 ] ووفقًا لميلز، "تكفي قيمة الـ 64 بت لجزء الثانية لتحديد المدة الزمنية التي يستغرقها فوتونٌ لعبور إلكترون بسرعة الضوء. وتكفي قيمة الـ 64 بت للثانية لتوفير تمثيل زمني لا لبس فيه حتى يخفت الكون". [ 102 ] [ ب ]

تكوين NTP والمنطقة الزمنية عبر DHCP

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

اكتشاف خادم NTP

RFC 2132 [ 103 ] يحدد خيار DHCPv4 مخصص لتوزيع عناوين خادم NTP على العملاء.

يحتوي خيار خوادم بروتوكول وقت الشبكة على قائمة بعناوين IPv4 التي تحدد خوادم NTP المتاحة للعميل. يجب أن تُدرج الخوادم حسب ترتيب الأفضلية، مما يسمح للعميل باختيار المصدر الأنسب.

خوادم بروتوكول وقت الشبكة
شفرةطولالعنوان 1العنوان 1
42نأ1.أ2.أ3.أ4ب1.ب2.ب3.ب4
  • رمز الخيار: 42
  • الحد الأدنى للطول: 4 أوكتات
  • الطول: يجب أن يكون من مضاعفات العدد 4
  • المحتوى: سلسلة من عناوين IPv4 ذات 32 بت، يمثل كل عنوان خادم NTP واحد
  • أمثلة: 42|2|192.0.2.1|192.0.2.2

ضبط المنطقة الزمنية عبر بروتوكول DHCP

بينما يتولى بروتوكول وقت الشبكة (NTP) مسؤولية مزامنة ساعات النظام مع التوقيت العالمي المنسق (UTC)، فإنه لا يوزع معلومات المنطقة الزمنية المحلية . ويتم ضبط إعدادات المنطقة الزمنية بشكل منفصل على مستوى نظام التشغيل.

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

تم تعريف هذه الخيارات في RFC 4833 [ 104 ] وهي تنطبق على كل من DHCP لـ IPv4 ( DHCPv4 ) و IPv6 ( DHCPv6 ).

خيارات المنطقة الزمنية لبروتوكول DHCPv4

تم تعريف خيارات DHCPv4 التالية:

رمز الخياروصف
100سلسلة المنطقة الزمنية POSIX
101اسم قاعدة بيانات المناطق الزمنية IANA (tzdb)

كلا الخيارين يحتويان على سلسلة نصية متغيرة الطول ولا تنتهي بـ null.

سلسلة المنطقة الزمنية POSIX (الخيار 100)

يحمل هذا الخيار تعريف المنطقة الزمنية باستخدام TZتنسيق متغير بيئة POSIX (كما هو محدد في IEEE 1003.1)، باستثناء أنه يجب ألا تبدأ السلسلة بنقطتين رأسيتين ( :).

المنطقة الزمنية POSIX
شفرةطولمحتوى
100ن(سلسلة المنطقة الزمنية POSIX)

مثال:

EST5EDT4,M3.2.0/02:00,M11.1.0/02:00

هذا يصف:

  • التوقيت القياسي: التوقيت الشرقي (UTC-5)
  • التوقيت الصيفي : التوقيت الشرقي الصيفي (UTC-4)
  • يبدأ التوقيت الصيفي: ثاني أحد من شهر مارس الساعة 02:00
  • ينتهي التوقيت الصيفي: أول أحد من شهر نوفمبر الساعة 02:00
اسم قاعدة بيانات المنطقة الزمنية (الخيار 101)

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

يحتوي هذا الخيار على اسم منطقة من قاعدة بيانات المناطق الزمنية التابعة لهيئة IANA ، مثل:

قاعدة بيانات المناطق الزمنية التابعة لهيئة الأرقام المخصصة للأرقام (IANA)
شفرةطولمحتوى
101ن( سلسلة قاعدة بيانات المناطق الزمنية التابعة لهيئة IANA )
Europe/Oslo

خيارات المنطقة الزمنية لبروتوكول DHCPv6

يحدد RFC 4833 خيارات مكافئة لبروتوكول DHCPv6 برموز خيارات مختلفة:

رمز الخياروصف
41سلسلة المنطقة الزمنية POSIX
42اسم قاعدة بيانات المنطقة الزمنية

تتطابق الدلالات وتنسيقات السلاسل مع تلك المستخدمة في DHCPv4؛ ويختلف الترميز الثنائي فقط بسبب اختلافات البروتوكول بين DHCPv4 وDHCPv6.

العلاقة ببرنامج السموم الوطني

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

في عمليات النشر النموذجية:

  • يوفر بروتوكول DHCP معلومات حول تكوين بروتوكول الإنترنت (IP) والمنطقة الزمنية.
  • يقوم بروتوكول NTP بمزامنة ساعة النظام مع التوقيت العالمي المنسق (UTC).
  • يقوم نظام التشغيل بتطبيق المنطقة الزمنية المُهيأة لعرض التوقيت المحلي للمستخدمين والتطبيقات.

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

انظر أيضاً

ملحوظات

  1. تستخدم أنظمة الاتصالات تعريفًا مختلفًا لطبقات الساعة .
  2. 2 −64 ثانية تساوي حوالي 54 زيبتوسكتون (سيسافر الضوء مسافة 16.26 بيكومتر، أو ما يقرب من 0.31 × نصف قطر بور )، و 2 64 ثانية تساوي حوالي 585 مليار سنة .

مراجع

  1. 1 2 3 4 5 6 ديفيد ل. ميلز (12 ديسمبر 2010). مزامنة وقت شبكة الحاسوب: بروتوكول وقت الشبكة . تايلور وفرانسيس. ص 12 وما بعدها. ISBN  978-0-8493-5805-0أُرشف من المصدر الأصلي بتاريخ 18 يوليو 2014. تم الاطلاع عليه بتاريخ 16 أكتوبر 2016 .
  2. 1 2 3 "ملخص تنفيذي: مزامنة الوقت في شبكة الحاسوب" . مؤرشف من الأصل في 2 نوفمبر 2011. تم الاطلاع عليه في 21 نوفمبر 2011 .
  3. ١ ٢ ٣ ٤ "أسئلة وأجوبة حول برنامج مكافحة السموم الوطني" . مشروع برنامج مكافحة السموم الوطني. مؤرشف من الأصل بتاريخ ٦ سبتمبر ٢٠١١. تم الاطلاع عليه بتاريخ ٢٧ أغسطس ٢٠١١ .
  4. "أرقام المنافذ" . هيئة أرقام الإنترنت المخصصة (IANA). مؤرشف من الأصل في 4 يونيو 2001. تم الاطلاع عليه في 19 يناير 2011 .
  5. ١ ٢ ٣ ٤ ٥ ٦ ٧ ٨ ٩ ١٠ ١١ د. ميلز ؛ ج. بوربانك؛ و. كاش (أغسطس ٢٠١٠). ج. مارتن (محرر). بروتوكول وقت الشبكة الإصدار ٤: مواصفات البروتوكول والخوارزميات . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC5905 . ISSN 2070-1721 . RFC 5905 . معيار مقترح. يلغي RFC 1305 و 4330 . تم تحديثه بواسطة RFC 7822 و 8573 و 9109 .  
  6. 1 2 ديفيد ل. ميلز (مارس 1992). بروتوكول وقت الشبكة (الإصدار 3) - المواصفات والتنفيذ والتحليل . مجموعة عمل الشبكة. doi : 10.17487/RFC1305 . RFC 1305 .مُلغى. تم إلغاؤه بموجب RFC 5905. يُلغي RFC 958 و 1059 و 1119 .  
  7. غوتوه، ت.؛ إمامورا، ك.؛ كانيكو، أ. (2002). "تحسين إزاحة وقت NTP في ظل الشبكة غير المتناظرة باستخدام طريقة الحزم المزدوجة". ملخص مؤتمر القياسات الكهرومغناطيسية الدقيقة . مؤتمر القياسات الكهرومغناطيسية الدقيقة. الصفحات 448-449 . doi : 10.1109/CPEM.2002.1034915 . ISBN  0-7803-7242-5.
  8. 1 2 ليتشفار، ميروسلاف (18 سبتمبر 2018). "chrony – chrony.conf(5)" . مشروع Chrony . تم الاطلاع عليه في 2 أغسطس 2020. يُمكّن هذا التوجيه من إضافة طابع زمني للأجهزة لحزم NTP المُرسلة إلى واجهة الشبكة المُحددة والمُستلمة منها .
  9. "sourcestats.c، الدالة estimate_asymmetry()" . git.tuxfamily.org (chrony) .
  10. د. ميلز (سبتمبر 1985). بروتوكول وقت الشبكة (NTP) . مجموعة عمل الشبكة. doi : 10.17487/RFC0958 . RFC 958 .قديم. تم إلغاؤه بموجب RFC 1059 و 1119 و 1305 . 
  11. د. ميلز (يوليو 1988). بروتوكول وقت الشبكة (الإصدار 1): المواصفات والتنفيذ . مجموعة عمل الشبكة. doi : 10.17487/RFC1059 . RFC 1059 .قديم. تم إلغاؤه بموجب RFC 1119 و 1305 . 
  12. د. ميلز (سبتمبر 1989). مواصفات وتنفيذ بروتوكول وقت الشبكة (الإصدار 2) . مجموعة عمل الشبكة. doi : 10.17487/RFC1119 . RFC 1119 .مُلغى. تم إلغاؤه بموجب RFC 1305. يُلغي RFC 958 و 1059 .  
  13. 1 2 د. ميلز (أغسطس 1992). نوع الخدمة في مجموعة بروتوكولات الإنترنت . مجموعة عمل الشبكة. doi : 10.17487/RFC1361 . RFC 1361 .قديم. تم إلغاؤه بموجب RFC 1769 . 
  14. د. ميلز (مارس 1995). بروتوكول وقت الشبكة البسيط (SNTP) . مجموعة عمل الشبكة. doi : 10.17487/RFC1769 . RFC 1769 .مُلغى. تم إلغاؤه بموجب RFC 2030. يُلغي RFC 1361 .  
  15. 1 2 د. ميلز (أكتوبر 1996). بروتوكول وقت الشبكة البسيط (SNTP) الإصدار 4 لـ IPv4 و IPv6 و OSI . مجموعة عمل الشبكة. doi : 10.17487/RFC2030 . RFC 2030 .مُلغى. تم إلغاؤه بموجب RFC 4330. يُلغي RFC 1769 .  
  16. د. ميلز (يناير 2006). بروتوكول وقت الشبكة البسيط (SNTP) الإصدار 4 لبروتوكولات IPv4 وIPv6 ونموذج OSI . مجموعة عمل الشبكة. doi : 10.17487/RFC4330 . RFC 4330 .مُلغى. يُلغي RFC 2030 و 1769 . تم إلغاؤه بواسطة RFC 5905 .  
  17. دي إل ميلز (أبريل 1981). خدمة ساعة الإنترنت DCNET . IETF . doi : 10.17487/RFC0778 . RFC 778 .تاريخي.
  18. 1 2 ت. مزراحي؛ د. ماير (مارس 2016). حقول امتداد بروتوكول وقت الشبكة الإصدار 4 (NTPv4) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7822 . ISSN 2070-1721 . RFC 7822 . معلومات. تحديثات RFC 5905 . 
  19. 1 2 3 أ. مالهوترا؛ س. غولدبيرغ (يونيو 2019). رمز مصادقة الرسائل لبروتوكول وقت الشبكة . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC8573 . ISSN 2070-1721 . RFC 8573 . المعيار المقترح. تحديثات RFC 5905 . 
  20. 1 2 ف. غونت؛ ج. غونت؛ م. ليشفار (أغسطس 2021). بروتوكول وقت الشبكة الإصدار 4: عشوائية المنافذ . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9109 . ISSN 2070-1721 . RFC 9109 . المعيار المقترح. تحديثات RFC 5905 . 
  21. دي إل ميلز (25 فبراير 1981)، مزامنة الوقت في مضيفي DCNET ، مؤرشف من الأصل في 30 ديسمبر 1996
  22. "TIMED(8)" ، دليل مدير نظام يونكس ، مؤرشف من الأصل في 22 يوليو 2011 ، تم استرجاعه في 12 سبتمبر 2017
  23. ديفيد ل. ميلز (أكتوبر 1991). "مزامنة الوقت عبر الإنترنت: بروتوكول وقت الشبكة" (ملف PDF) . مجلة IEEE للمعاملات في الاتصالات . 39 (10): 1482-1493 . رمز Bibcode : 1991ITCom..39.1482M . doi : 10.1109/26.103043 . مؤرشف (ملف PDF) من الأصل في 10 يونيو 2016. تم الاطلاع عليه في 6 نوفمبر 2017 .
  24. ديفيد ل. ميلز (مارس 1992). بروتوكول وقت الشبكة (الإصدار 3) - المواصفات والتنفيذ والتحليل . مجموعة عمل الشبكة. doi : 10.17487/RFC1305 . RFC 1305 .تم تعديل إجراء اختيار الساعة لإزالة الخطوة الأولى من خطوتي الفرز/الاستبعاد واستبدالها بخوارزمية اقترحها مارزولو أولاً، ثم أُدرجت لاحقاً في خدمة التوقيت الرقمي. لا تؤثر هذه التغييرات بشكل كبير على التشغيل العادي أو التوافق مع مختلف إصدارات بروتوكول NTP، لكنها توفر الأساس لبيانات رسمية تُثبت صحتها .
  25. ديفيد ل. ميلز (15 نوفمبر 2010). مزامنة وقت شبكة الحاسوب: بروتوكول وقت الشبكة على الأرض وفي الفضاء، الطبعة الثانية . مطبعة سي آر سي. ص 377. ISBN  978-1-4398-1464-2.
  26. 1 2 3 "الخطط المستقبلية"، مشروع بحث مزامنة وقت الشبكة ، مؤرشف من الأصل في 23 ديسمبر 2014 ، تم استرجاعه في 24 ديسمبر 2014
  27. "برنامج مكافحة السموم الوطني بحاجة إلى تمويل: هل المؤسسة هي الحل؟" . InformationWeek . 23 مارس 2015. مؤرشف من الأصل في 10 أبريل 2015. تم الاطلاع عليه في 4 أبريل 2015 .
  28. "مصير NTP يتوقف على 'الأب الزمن'"" . InformationWeek . 11 مارس 2015. مؤرشف من الأصل في 10 أبريل 2015. تم الاطلاع عليه في 4 أبريل 2015. "
  29. 1 2 "بروتوكولات وقت الشبكة (ntp): وثائق" . datatracker.ietf.org . تم الاطلاع عليه بتاريخ 27 ديسمبر 2022 .
  30. 1 2 د. فرانك؛ د. سيبولد؛ ك. تيشيل؛ م. دانساري؛ ر. سوندبلاد (سبتمبر 2020). أمن وقت الشبكة لبروتوكول وقت الشبكة . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC8915 . ISSN 2070-1721 . RFC 8915 . المعيار المقترح.
  31. ليتشفار، ميروسلاف (2 يوليو 2025). "بروتوكول وقت الشبكة الإصدار 5" . www.ietf.org .
  32. د. ميلز ؛ ج. بوربانك؛ و. كاش (أغسطس 2010). ج. مارتن (محرر). بروتوكول وقت الشبكة الإصدار 4: مواصفات البروتوكول والخوارزميات . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC5905 . ISSN 2070-1721 . RFC 5905 . لا تحتاج الخوادم والعملاء الأساسيون المتوافقون مع مجموعة فرعية من بروتوكول وقت الشبكة (NTP)، تُسمى بروتوكول وقت الشبكة البسيط (SNTPv4)، إلى تطبيق خوارزميات التخفيف. صُمم تطبيق NTPv4 المطوّر بالكامل للخوادم التي تحتوي على عدة خوادم مصدرية وعدة خوادم وجهة. وبغض النظر عن هذه الاعتبارات، فإن خوادم وعملاء NTP وSNTP متوافقون تمامًا ويمكن دمجهم معًا.
  33. "دمج بروتوكول PTP مع بروتوكول NTP للحصول على أفضل ما في كلا البروتوكولين" . www.redhat.com . يمكن استخدام برامج حزمة linuxptp مع خادم NTP. تتم مزامنة ساعة PTP على بطاقة الشبكة بواسطة ptp4l، وتُستخدم كساعة مرجعية بواسطة chronyd أو ntpd لمزامنة ساعة النظام.
  34. "بروتوكول وقت الشبكة: ورقة بيضاء لأفضل الممارسات" . مؤرشف من الأصل في 1 أكتوبر 2013. تم الاطلاع عليه في 15 أكتوبر 2013 .
  35. 1 2 "مخرجات الأمر 'ntpq -p' . NLUG.ML1.co.uk. مؤرشف من الأصل بتاريخ ١٢ نوفمبر ٢٠١٨. تم الاطلاع عليه بتاريخ ١٢ نوفمبر ٢٠١٨ .
  36. ^ "IMS-PZF: مستقبل الارتباط PZF (DCF77) (Eurocard)" . Meinberg Funkuhren GmbH & Co KG . تم الاسترجاع 19 يونيو 2025 .
  37. "هل توجد أي إشارة في استجابة NTP تدل على تفعيل خاصية التلاعب بالثواني الكبيسة من جوجل؟" . Groups.google.com . تم الاطلاع عليه بتاريخ 22 يونيو 2026 .
  38. "رسائل الأحداث وكلمات الحالة" . docs.ntpsec.org . تُستخدم رموز Refid في حزم kiss-o'-death (KoD)، وحقل مُعرّف المرجع في شاشات عرض ntpq وntpmon ورسائل السجل.
  39. "معلمات بروتوكول وقت الشبكة (NTP)" . www.iana.org .
  40. "تقرير اختبار الاختراق NTP 01.2017" (ملف PDF) . Cure53. 2017. مؤرشف (ملف PDF) من الأصل في 1 ديسمبر 2018. تم الاطلاع عليه في 3 يوليو 2019 .
  41. "المرجع التقني لخدمة وقت ويندوز" . technet.microsoft.com. ١٧ أغسطس ٢٠١١. مؤرشف من الأصل في ٦ سبتمبر ٢٠١١. تم الاطلاع عليه في ١٩ سبتمبر ٢٠١١ .
  42. "صفحة خدمة وقت ويندوز على موقع NTP.org" . Support.NTP.org . 25 فبراير 2008. مؤرشفة من الأصل في 14 مايو 2017. تم الاطلاع عليها في 1 مايو 2017 .
  43. "كيف تعمل خدمة الوقت في ويندوز" . technet.microsoft.com. ١٢ مارس ٢٠١٠. مؤرشف من الأصل في ٢٤ سبتمبر ٢٠١١. تم الاطلاع عليه في ١٩ سبتمبر ٢٠١١ .
  44. 1 2 "دعم حدود تهيئة خدمة وقت ويندوز للبيئات عالية الدقة" . مايكروسوفت . 19 أكتوبر 2011. مؤرشف من الأصل في 12 يناير 2009. تم الاطلاع عليه في 10 ديسمبر 2008 .
  45. نيد بايل (23 أكتوبر 2007). "متطلبات W32time عالية الدقة" . مايكروسوفت . مؤرشف من الأصل في 17 أكتوبر 2012. تم الاطلاع عليه في 26 أغسطس 2012 .
  46. "التوقيت الدقيق في ويندوز سيرفر 2016" . technet.microsoft.com . مؤرشف من الأصل بتاريخ 2 ديسمبر 2016. تم الاطلاع عليه بتاريخ 7 ديسمبر 2016 .
  47. داهافي. "حدود الدعم للوقت عالي الدقة" . docs.microsoft.com . مؤرشف من الأصل في 2 مايو 2021. تم الاطلاع عليه في 24 يوليو 2021 .
  48. "ntpd(8) - صفحات دليل OpenBSD" . man.openbsd.org . يُنفذ بروتوكول وقت الشبكة البسيط الإصدار 4، كما هو موضح في RFC 5905، وبروتوكول وقت الشبكة الإصدار 3، كما هو موضح في RFC 1305.
  49. مشروع OpenBSD (21 أغسطس 2006). "الأسئلة الشائعة 6.12.1: 'لكن OpenNTPD ليس دقيقًا مثل برنامج ntp.org!'"مشروع OpenBSD . مؤرشف من الأصل في 5 فبراير 2016. تم الاطلاع عليه في 14 مايو 2020 .
  50. ريموند، إريك س. (30 مارس 2017). "NTPsec: تطبيق آمن ومُحسَّن لبروتوكول NTP | مجلة لينكس" . مجلة لينكس . تم الاطلاع عليه بتاريخ 26 يناير 2024 .{{cite web}}: CS1 maint: deprecated archiveal service ( link )
  51. "توزيع بروتوكول وقت الشبكة الآمن (NTPsec)" . مؤرشف من الأصل في 13 يناير 2019. تم الاطلاع عليه في 12 يناير 2019 .
  52. ^ ليسكا ، آلان (10 ديسمبر 2016). أمان NTP: دليل البدء السريع . Apress. ص 80–. رقم ISBN  978-1-4842-2412-0.
  53. "تقرير اختبار الاختراق NTPsec 01.2017" (ملف PDF) . Cure53. 2017. مؤرشف (ملف PDF) من الأصل في 4 يوليو 2019. تم الاطلاع عليه في 3 يوليو 2019 .
  54. ليتشفار، ميروسلاف (20 يوليو 2016). "دمج بروتوكول PTP مع بروتوكول NTP للحصول على أفضل ما في كلا البروتوكولين" . مدونة Red Hat Enterprise Linux . Red Hat . مؤرشف من الأصل في 30 يوليو 2016. تم الاطلاع عليه في 19 نوفمبر 2017. بدءًا من Red Hat Enterprise Linux 7.0 (والآن في Red Hat Enterprise Linux 6.8) ، يتم توفير تطبيق NTP أكثر تنوعًا عبر حزمة chrony.
  55. "تأمين وقت الشبكة" . مبادرة البنية التحتية الأساسية، مشروع تعاوني لمؤسسة لينكس . مبادرة البنية التحتية الأساسية. 27 سبتمبر 2017. مؤرشف من الأصل في 28 أكتوبر 2017. تم الاطلاع عليه في 19 نوفمبر 2017. باختصار، برنامج Chrony NTP قوي ويمكن اعتباره جديرًا بالثقة .
  56. ١ ٢ "مقدمة عن برنامج كروني" . TuxFamily، منظمة غير ربحية . كروني. مؤرشف من الأصل في ٩ ديسمبر ٢٠٠٩. تم الاطلاع عليه في ١٩ نوفمبر ٢٠١٧. يدعم البرنامج أنظمة لينكس، وفري بي إس دي، ونت بي إس دي، وماك أو إس، وسولاريس.
  57. بوث، ديفيد. "إدارة بروتوكول NTP باستخدام كروني" . Opensource.com . مؤرشف من الأصل في 29 يونيو 2019. تم الاطلاع عليه في 29 يونيو 2019 .
  58. هايدريش، ماريو (أغسطس 2017). "تقرير اختبار الاختراق Chrony 08.2017" (ملف PDF) . فريق Cure53.de . wiki.mozilla.org، المعروف أيضًا باسم MozillaWiki أو WikiMO. مؤرشف من الأصل (ملف PDF) في 5 أكتوبر 2017. تم الاطلاع عليه في 19 نوفمبر 2017. إن صمود Chrony أمام أحد عشر يومًا كاملة من الاختبارات عن بُعد في أغسطس 2017 يعني أنه برنامج قوي ومتين، وقد طُوّر مع مراعاة الأمن.
  59. "chrony/chrony.git - مستودع Git الرسمي لمشروع Chrony" . git.tuxfamily.org . تم الاطلاع عليه بتاريخ 31 يوليو 2021 .
  60. آس، جوش. "مزيد من أمان الذاكرة لـ Let's Encrypt: نشر ntpd-rs" . Let's Encrypt . Let's Encrypt . تم الاطلاع عليه بتاريخ 18 ديسمبر 2024 .
  61. "أمان وقت الشبكة - وثائق ntpd-rs" . docs.ntpd-rs.pendulum-project.org . تم الاطلاع عليه بتاريخ 13 يناير 2025 .
  62. بول-هينينغ، كامب. "20140926 - اللعب بالزمن مجدداً" . مستودع دراجات PHK . مؤرشف من الأصل في 20 ديسمبر 2019. تم الاطلاع عليه في 4 يونيو 2015 .
  63. بول-هينينغ، كامب. "برنامج مزامنة وقت الشبكة، بديل لـ NTPD" . ملف README لمستودع ntimed على GitHub. مؤرشف من الأصل في 2 أغسطس 2015. تم الاطلاع عليه في 4 يونيو 2015 .
  64. "التحويل من OpenNTPd إلى Chrony - anarcat" . anarc.at . وبالتالي، أصبح systemd-timesyncd هو برنامج NTP الافتراضي في Debian في bookworm، وهو أمر أعتبره مفاجئًا إلى حد ما.
  65. "ntpdate(8): ضبط التاريخ/الوقت عبر NTP - صفحة دليل لينكس" . linux.die.net . تم الاطلاع عليه بتاريخ 12 أبريل 2020 .
  66. هارلان ستين (2 سبتمبر 2012). "NTP.Org - إيقاف ntpdate" . تم الاطلاع عليه في 30 أكتوبر 2012. يُنفذ الآن برنامجا ntpd و sntp وظائف ntpdate . وبمجرد حل بعض المشكلات المتبقية في sntp ، سيتم إيقاف برنامج ntpdate.
  67. ديفيد ميلز. "المقياس الزمني للجدول الزمني الوطني والثواني الكبيسة" . مؤرشف من الأصل في 7 سبتمبر 2013. تم الاطلاع عليه في 15 أكتوبر 2013 .
  68. "حملة تشويه سمعة مطوري جوجل" . مؤرشف من الأصل في 4 أبريل 2019. تم الاطلاع عليه في 4 أبريل 2019 .
  69. أوبليخوف، أوليغ (18 مارس 2020). "بناء خدمة توقيت أكثر دقة على نطاق فيسبوك" . الهندسة في ميتا .
  70. "chrony – الأسئلة الشائعة" . chrony.tuxfamily.org .
  71. "إشعار أمني" . Support.NTP.org . 10 ديسمبر 2009. تم الاطلاع عليه في 12 يناير 2011 .
  72. "ثغرة أمنية في بروتوكول وقت الشبكة لبرمجيات Cisco IOS" . شركة Cisco Systems . 23 سبتمبر 2009. مؤرشف من الأصل في 11 يونيو 2020. تم الاطلاع عليه في 11 يونيو 2020 .
  73. "تدقيق الكود" . Support.NTP.org . 13 يونيو 2009. تم الاطلاع عليه في 12 يناير 2011 .
  74. "ثغرات بروتوكول وقت الشبكة (التحديث ج) | ICS-CERT" . Ics-cert.us-cert.gov. مؤرشف من الأصل بتاريخ 20 ديسمبر 2014. تم الاطلاع عليه بتاريخ 15 أبريل 2015 .
  75. كونينغهام، أندرو (23 ديسمبر 2014). "أبل تُصدر تحديثات تلقائية لأجهزة ماك لإصلاح ثغرة أمنية خطيرة في بروتوكول NTP" . arstechnica. مؤرشف من الأصل في 15 أبريل 2015. تم الاطلاع عليه في 29 أبريل 2015 .
  76. فيرهيد، هاري (23 ديسمبر 2014). "بروتوكول NTP: أحدث مشكلة أمنية في البرمجيات مفتوحة المصدر" . مجلة I Programmer. مؤرشف من الأصل في 24 ديسمبر 2014. تم الاطلاع عليه في 24 ديسمبر 2014 .
  77. صفحة إشعار أمان بروتوكول وقت الشبكة (NTP) مؤرشفة بتاريخ 19 فبراير 2014 على موقع Wayback Machine
  78. بحث منتجات NVD NIST NTP
  79. بحث منتجات NVD NIST NTPsec مؤرشف بتاريخ 26-06-2020 في Wayback Machine
  80. بحث منتجات NVD NIST، كروني، مؤرشف بتاريخ 26-06-2020 في أرشيف الإنترنت
  81. "تدقيق معهد المعلومات الأمنية يحدد أكثر تطبيقات بروتوكول NTP أمانًا" . مؤسسة لينكس. 28 سبتمبر 2017. مؤرشف من الأصل في 3 فبراير 2018. تم الاطلاع عليه في 3 يوليو 2019 .
  82. 1 2 بروتوكول وقت الشبكة الإصدار 4: مواصفات المفتاح التلقائي . IETF. يونيو 2010. doi : 10.17487/RFC5906 . RFC 5906 .
  83. 1 2 "تحليل أمان بروتوكول NTP" . مؤرشف من الأصل في 7 سبتمبر 2013. تم الاطلاع عليه في 11 أكتوبر 2013 .
  84. خوسيه سيلفي (16 أكتوبر 2014). "تجاوز أمان النقل الصارم لبروتوكول HTTP" (ملف PDF) . مؤرشف من الأصل (ملف PDF) في 18 أكتوبر 2014. تم الاطلاع عليه في 16 أكتوبر 2014 .
  85. أنشال مالهوترا؛ إسحاق إي. كوهين؛ إريك براك؛ وشارون غولدبيرغ (20 أكتوبر 2015). "مهاجمة بروتوكول وقت الشبكة" (ملف PDF) . NDSS . مؤرشف من الأصل (ملف PDF) بتاريخ 22 أكتوبر 2015. تم الاطلاع عليه بتاريخ 27 أكتوبر 2015 .
  86. "مهاجمة بروتوكول وقت الشبكة" . www.cs.bu.edu . مؤرشف من الأصل بتاريخ 24 أكتوبر 2015. تم الاطلاع عليه بتاريخ 27 أكتوبر 2015 .
  87. غودين، دان (13 يناير 2014). "هجمات حجب الخدمة الجديدة التي تُعطّل مواقع الألعاب تُسبّب فيضانات مُدمّرة بسرعة 100 جيجابت في الثانية" . آرس تكنيكا . مؤرشف من الأصل في 24 يناير 2014. تم الاطلاع عليه في 25 يناير 2014 .
  88. لي، ديف (11 فبراير 2014). "اختراق ضخم 'علامة قبيحة على مستقبل التهديدات الإلكترونية'" . بي بي سي. مؤرشف من الأصل في 11 فبراير 2014. تم الاطلاع عليه في 12 فبراير 2014 .
  89. "هجوم DRDoS / هجوم التضخيم باستخدام أمر ntpdc monlist" . support.NTP.org . 24 أبريل 2010. مؤرشف من الأصل في 30 مارس 2014. تم الاطلاع عليه في 13 أبريل 2014 .
  90. ^ ديتر سيبولد. ستيفن روتجر (2012). تحليل بروتوكول Autokey الخاص بـ NTP (PDF) . فريق عمل الإنترنت 83.
  91. هـ. ستين؛ د. سيبولد (يوليو 2019). د. رايلي (محرر). أفضل الممارسات الحالية لبروتوكول وقت الشبكة . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC8633 . ISSN 2070-1721 . BCP 223. RFC 8633 . أفضل الممارسات الحالية 223. القسم 4.2.
  92. "الصفحة الرئيسية لموقع nts.time.nl" . nts.time.nl. تم الاطلاع عليه بتاريخ 19 أغسطس 2021 .
  93. لانجر، مارتن (5 ديسمبر 2019). "إعداد بروتوكول NTP المحمي بواسطة NTS باستخدام NTPsec" . Weberblog.net . تم الاطلاع عليه بتاريخ 19 أغسطس 2021 .
  94. "كيفية استخدام NTS | Netnod" . Netnod . تم الاطلاع عليه بتاريخ 19 أغسطس 2021 .
  95. "أمان وقت الشبكة · وثائق خدمات وقت Cloudflare" . developers.cloudflare.com . 13 أغسطس 2024. تم الاطلاع عليه في 12 يناير 2025 .
  96. " [ MS-SNTP ] : ملحقات مصادقة بروتوكول وقت الشبكة (NTP)" . 24 يونيو 2021.
  97. "مقارنة تطبيقات بروتوكول NTP" . chrony.tuxfamily.org . تم الاطلاع عليه بتاريخ 8 أكتوبر 2019 .
  98. ديفيد ل. ميلز (12 مايو 2012). "عصر NTP وترقيم العصر" . مؤرشف من الأصل في 26 أكتوبر 2016. تم الاطلاع عليه في 24 سبتمبر 2016 .
  99. دبليو. ريتشارد ستيفنز؛ بيل فينير؛ أندرو إم. رودوف (2004). برمجة شبكات يونكس . أديسون-ويسلي بروفيشنال. ص 582–. ISBN  978-0-13-141155-5أُرشف من المصدر الأصلي في 30 مارس 2019. تم الاطلاع عليه في 16 أكتوبر 2016 .
  100. مارتن، جيم؛ بوربانك، جاك؛ كاش، ويليام؛ ميلز، البروفيسور ديفيد ل. (يونيو 2010). بروتوكول وقت الشبكة الإصدار 4: مواصفات البروتوكول والخوارزميات (تقرير). فريق عمل هندسة الإنترنت. ص 12. 
  101. "نظرة على مشاكل عامي 2036/2038 ومدى ثباتها الزمني في مختلف الأنظمة" . 14 مارس 2017. مؤرشف من الأصل في 21 يوليو 2018. تم الاطلاع عليه في 20 يوليو 2018 .
  102. عرض تقديمي لندوة الأنظمة الرقمية بجامعة ديلاوير ، قدمه ديفيد ميلز، 26 أبريل 2006
  103. ألكسندر، ستيف (1 مارس 1997). "خيارات DHCP وامتدادات BOOTP الخاصة بالبائعين" . متتبع بيانات IETF . القسم 8.3 . تم الاطلاع عليه في 25 يناير 2026 .
  104. لير، إليوت؛ إيغرت، بول (1 أبريل 2007). خيارات المنطقة الزمنية لبروتوكول DHCP (تقرير). فريق عمل هندسة الإنترنت . تم الاطلاع عليه بتاريخ 26 يناير 2026 .{{cite report}}: CS1 maint: url-status ( link )

للمزيد من القراءة