سؤال ما مقدار كمون الشبكة "المعتاد" بالنسبة إلى الساحل الشرقي الغربي للولايات المتحدة الأمريكية؟


في الوقت الحالي ، نحاول أن نقرر نقل مركز البيانات من الساحل الغربي إلى الساحل الشرقي.

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

  • الساحل الغربي إلى الساحل الشرقي:
    215 مللي ثانية ، زمن الانتقال 46 مللي ثانية ، مجموع ms 261
  • الساحل الغربي إلى الساحل الغربي:
    زمن انتقال 114 ms ، وقت نقل 41 مللي ثانية ، إجمالي ms 155

من المنطقي أن تكون Corvallis، OR قريبة جغرافيًا من موقعي في Berkeley ، CA لذلك أتوقع أن يكون الاتصال أسرع قليلاً .. ولكني أرى زيادة في زمن الاستجابة لـ + 100 مللي ثانية عندما أقوم بإجراء الاختبار نفسه على NYC الخادم. هذا يبدو .. مفرط بالنسبة لي. لا سيما منذ ذلك الحين زاد الوقت الذي يقضيه نقل البيانات الفعلية 10 ٪ فقط ، ولكن زاد الكمون 100 ٪!

هذا يشعر ... خطأ ... بالنسبة لي.

وجدت بعض الروابط هنا التي كانت مفيدة (من خلال Google لا أقل!) ...

... لكن لا شيء موثوق.

هل هذا طبيعي؟ إنه لا يشعر بالطبيعية. ما هو الكمون "النموذجي" الذي ينبغي توقعه عند نقل حزم الشبكة من الساحل الشرقي <-> الساحل الغربي للولايات المتحدة الأمريكية؟


99
2018-04-30 11:26


الأصل


يبدو أي قياس عبر الشبكات التي لا تتحكم فيها بلا جدوى. في كثير من الأحيان في هذه الأنواع من مناقشات الشبكة يبدو أننا ننسى وجود مكون زمني مرتبط بكل حزمة. إذا قمت بإجراء الاختبار مراراً وتكراراً 24 × 7 ووصلت إلى نتيجة ما ، فهذا شيء واحد. إذا قمت بإجراء الاختبار مرتين فأقترح عليك تشغيله أكثر. ولأولئك الذين يدعون استخدام بينغ كمقياس للأداء ، لا تفعل ذلك. في كل شبكة رئيسية عملت بها على أي حال ، قمنا بتعيين حركة ICMP على أقل أولوية. Ping تعني شيئًا واحدًا فقط ، وهو ليس كذلك ؛) حول الأداء. - dbasnett
من حيث أعيش ، جيفرسون سيتي ، MO ، الأوقات متشابهة. - dbasnett
كملاحظة جانبية: الضوء نفسه يأخذ ~ 14ms للسفر من نيويورك إلى SF في خط مستقيم (النظر في الألياف على طول الطريق). - Shadok
الضوء في رحلات الألياف مع عامل سرعة قدره 0.67 (أي ما يعادل مؤشر الانكسار) ~ 201،000 كم / ثانية ، لذلك لا يقل عن 20 مللي ثانية. - Zac67


الأجوبة:


سرعة الضوء:
  أنت لا تفوز بسرعة الضوء كنقطة أكاديمية مثيرة للاهتمام. هذا الرابط يعمل خارج ستانفورد إلى بوسطن في ~ 40ms أفضل وقت ممكن. عندما قام هذا الشخص بحسابه قرر أن الإنترنت يعمل على نحو "ضمن عامل من اثنين من سرعة الضوء" ، لذلك هناك حوالي 85ms وقت نقل.

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

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

أولا ، على الرغم من أن معظم العملاء   خدم من قبل CDN المجاورة جغرافيا   العقدة ، وهي جزء كبير من العملاء   تجربة latencies عدة عشرات من   ميلي ثانية أعلى من العملاء الآخرين   في نفس المنطقة. ثانيا ، نجد   أن تأخير التأخير في كثير من الأحيان يتجاوز   فوائد تفاعل العميل   مع خادم قريب.

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

whois -h v4-peer.whois.cymru.com "69.59.196.212"
PEER_AS | IP               | AS Name
25899   | 69.59.196.212    | LSNET - LS Networks
32869   | 69.59.196.212    | SILVERSTAR-NET - Silver Star Telecom, LLC

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


108
2018-04-30 12:03



توافق ، سرعة الضوء حيث أن الذباب هو أفضل ما يمكنك فعله. إجابة ممتازة حقا من جانب الطريق ، وهذا هو بالضبط ما كنت أبحث عنه. شكرا لكم. - Jeff Atwood
للفضول الرياضيات الفعلية هي: 3000 ميل / ج = 16.1ms - tylerl
في الفراغ ، يمكن للفوتون أن يسافر في خط الاستواء في حوالي 134 مللي ثانية. نفس الفوتون في الزجاج قد يستغرق حوالي 200 مللي ثانية. إن قطعة 3000 ميل من الألياف لديها 24 مللي ثانية. من التأخير دون أي أجهزة. - dbasnett
وهذا يذكرني حالة 500 ميل البريد الإلكتروني. - bahamat


هذا الموقع يقترح حوالي 70-80ms الكمون بين الساحل الشرقي / الغربي للولايات المتحدة هو نموذجي (سان فرانسيسكو إلى نيويورك على سبيل المثال).

طريق عبر المحيط الأطلسي
نيويورك 78 لندن
اغسل 87 فرانكفورت
طريق عبر المحيط الهادئ
SF 147 هونج كونج
مسار عبر الولايات المتحدة الأمريكية
SF 72 NY

network latency by world city pairs

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

NY - 108ms latency, 61ms transfer, 169 total
OR - 182ms latency, 71ms transfer, 253 total

تم قياس هذه باستخدام أدوات Google Chrome dev.


41
2018-04-30 11:45



مخطط بارد! NY إلى SF هو حاليا 71 ms على ذلك ، فأنت على حق - لا يمكننا أن نتوقع أن نفعل أفضل من ذلك. - Jeff Atwood
شكر. لقد ساعدتني كثيرا. هذا هو مصدر آخر للبحث عن الكمون الشبكة بين أماكن مختلفة من العالم - dotcom-monitor.com/WebTools/network_latency.aspx - Sajib Mahmood


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

الذهاب من قبل إجابة ريتش آدامز واستخدام الموقع التي أوصى بها ، يمكنك أن ترى أنه على العمود الفقري لشركة AT & T ، يستغرق الأمر 72 مللي ثانية لحركة مرور ICMP للتنقل بين نهايتيها SF و NY. هذا رقم صالح ، ولكن يجب أن تضع في اعتبارك أن هذا موجود على شبكة يتم التحكم فيها بالكامل بواسطة AT & T. لا يأخذ في الاعتبار الانتقال إلى شبكة منزلك أو مكتبك.

إذا قمت بإجراء ping ضد careers.stackoverflow.com من شبكة المصدر الخاصة بك ، يجب أن تشاهد شيء ليس بعيدًا عن 72 مللي ثانية (ربما +/- 20 مللي ثانية). إذا كانت هذه هي الحالة ، فمن المحتمل أن تفترض أن مسار الشبكة بينكما على ما يرام ويعمل ضمن النطاقات العادية. إذا لم يكن كذلك ، فلا داعي للذعر وقياس من بضعة أماكن أخرى. يمكن أن يكون مزود خدمة الإنترنت الخاص بك.

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

إذا كانت فترات HTTP تلك ذات تباين واسع ، فلن أكون مندهشًا إذا كانت هناك مشكلة في التهيئة على موقع الأداء البطيء.

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


10
2018-04-30 17:34





تستخدم العديد من الإجابات هنا استخدام ping و traceroute لتفسيراتهم. هذه الأدوات لها مكانها ، لكنها غير موثوقة لقياس أداء الشبكة.

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

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

ونتيجة لذلك ، فإن ping / traceroute يمنحك قدرًا معقولاً الحدود العليا - الأمور تسير على الأقل بسرعة - ولكنهم لا يخبرونك بالفعل عن سرعة حركة المرور الحقيقية.

في أي مناسبة -

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

% traceroute -w 2 www.stanford.edu
traceroute to www-v6.stanford.edu (171.67.215.200), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  v-vfw-cc-clusta-l3-outside.r-seb.umnet.umich.edu (141.211.81.130)  3.808 ms  4.225 ms  2.223 ms
 4  l3-bseb-rseb.r-bin-seb.umnet.umich.edu (192.12.80.131)  1.372 ms  1.281 ms  1.485 ms
 5  l3-barb-bseb-1.r-bin-arbl.umnet.umich.edu (192.12.80.8)  1.784 ms  0.874 ms  0.900 ms
 6  v-bin-arbl-i2-wsu5.wsu5.mich.net (192.12.80.69)  2.443 ms  2.412 ms  2.957 ms
 7  v0x1004.rtr.wash.net.internet2.edu (192.122.183.10)  107.269 ms  61.849 ms  47.859 ms
 8  ae-8.10.rtr.atla.net.internet2.edu (64.57.28.6)  28.267 ms  28.756 ms  28.938 ms
 9  xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112)  52.075 ms  52.156 ms  88.596 ms
10  * * ge-6-1-0.0.rtr.losa.net.internet2.edu (64.57.28.96)  496.838 ms
11  hpr-lax-hpr--i2-newnet.cenic.net (137.164.26.133)  76.537 ms  78.948 ms  75.010 ms
12  svl-hpr2--lax-hpr2-10g.cenic.net (137.164.25.38)  82.151 ms  82.304 ms  82.208 ms
13  hpr-stanford--svl-hpr2-10ge.cenic.net (137.164.27.62)  82.504 ms  82.295 ms  82.884 ms
14  boundarya-rtr.stanford.edu (171.66.0.34)  82.859 ms  82.888 ms  82.930 ms
15  * * *
16  * * *
17  www-v6.stanford.edu (171.67.215.200)  83.136 ms  83.288 ms  83.089 ms

على وجه الخصوص ، لاحظ الفارق الزمني بين نتائج traceroute من غسل جهاز التوجيه و ATLA جهاز التوجيه (القفزات 7 و 8). يذهب مسار الشبكة أولا لغسل ثم إلى ATLA. يأخذ غسل 50-100ms للرد ، يأخذ ATla حوالي 28ms. من الواضح أن الأطلال بعيدًا عن ذلك ، لكن نتائج المتتبعات تشير إلى أنه أقرب.

نرى http://www.internet2.edu/performance/ للحصول على الكثير من المعلومات حول قياس الشبكة. (إخلاء المسؤولية ، اعتدت على العمل ل internet2). انظر أيضا: https://fasterdata.es.net/

لإضافة بعض الصلة الوثيقة بالسؤال الأصلي ... كما ترى ، كان لدي وقت بينغ 83 دقيقة ذهابًا وإيابًا إلى stanford ، لذلك نعرف أن الشبكة يمكن أن تسير على الأقل هذا الصيام.

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

ميشيغان-> واشنطن ، العاصمة-> أتلانتا-> هيوستن-> لوس أنجلوس-> ستانفورد


7
2017-08-15 15:46





أرى اختلافات ثابتة ، وأنا أجلس في النرويج:

serverfault       careers
  509ms            282ms
  511ms            304ms
  488ms            295ms
  480ms            274ms
  498ms            278ms

تم قياس ذلك باستخدام الطريقة العلمية والدقيقة المثبتة لاستخدام طريقة عرض الموارد في Google Chrome ومجرد تحديث كل رابط بشكل متكرر.

تلاحق على خادم serverfault

Tracing route to serverfault.com [69.59.196.212]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  81.27.47.1
  2     2 ms     1 ms     1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     2 ms     1 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    14 ms    14 ms    14 ms  193.28.236.253
  6    13 ms    13 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    22 ms    21 ms    21 ms  te7-1-10G.ar3.cph1.gblx.net [67.16.161.93]
  8    21 ms    20 ms    20 ms  sprint-1.ar3.CPH1.gblx.net [64.212.107.18]
  9    21 ms    21 ms    20 ms  sl-bb20-cop-15-0-0.sprintlink.net [80.77.64.33]
 10   107 ms   107 ms   107 ms  144.232.24.12
 11   107 ms   106 ms   105 ms  sl-bb20-msq-15-0-0.sprintlink.net [144.232.9.109]
 12   106 ms   106 ms   107 ms  sl-crs2-nyc-0-2-5-0.sprintlink.net [144.232.20.75]
 13   129 ms   135 ms   134 ms  sl-crs2-chi-0-15-0-0.sprintlink.net [144.232.24.208]
 14   183 ms   183 ms   184 ms  sl-crs2-chi-0-10-3-0.sprintlink.net [144.232.20.85]
 15   189 ms   189 ms   189 ms  sl-gw12-sea-2-0-0.sprintlink.net [144.232.6.120]
 16   193 ms   189 ms   189 ms  204.181.35.194
 17   181 ms   181 ms   180 ms  core2-gi61-to-core1-gi63.silverstartelecom.com [74.85.240.14]
 18   182 ms   182 ms   182 ms  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com [74.85.242.6]
 19   195 ms   195 ms   194 ms  sst-6509-peak-p2p-gi13.silverstartelecom.com [12.111.189.106]
 20   197 ms   197 ms   197 ms  ge-0-0-2-cvo-br1.peak.org [69.59.218.2]
 21   188 ms   187 ms   189 ms  ge-1-0-0-cvo-core2.peak.org [69.59.218.193]
 22   198 ms   198 ms   198 ms  vlan5-cvo-colo2.peak.org [69.59.218.226]
 23   198 ms   197 ms   197 ms  stackoverflow.com [69.59.196.212]

Trace complete.

تلاحق على وظائف

Tracing route to careers.stackoverflow.com [64.34.80.176]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  81.27.47.1
  2     2 ms     1 ms    <1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     1 ms     2 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    12 ms    13 ms    13 ms  193.28.236.253
  6    13 ms    14 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    21 ms    21 ms    21 ms  ge7-1-10G.ar1.ARN3.gblx.net [67.17.109.89]
  8    21 ms    20 ms    20 ms  tiscali-1.ar1.ARN3.gblx.net [64.208.110.130]
  9   116 ms   117 ms   122 ms  xe-4-2-0.nyc20.ip4.tinet.net [89.149.184.142]
 10   121 ms   122 ms   121 ms  peer1-gw.ip4.tinet.net [77.67.70.194]
 11     *        *        *     Request timed out.

لسوء الحظ ، يبدأ الآن الدخول في حلقة أو ما شابه ويستمر في منح النجوم والمهلة حتى 30 قفزة ثم ينتهي.

لاحظ ، أن traceroutes من مضيف مختلف عن التوقيت في البداية ، اضطررت إلى RDP إلى الخادم المستضاف لتنفيذه


6
2018-04-30 11:43



الحق، ومن المتوقع أن مراكز البيانات الساحل الشرقي ستكون أكثر ودية للجمهور الأوروبي لدينا - ترونه حول + 200MS الوقت اللازم لاجتياز العرض من الولايات المتحدة الأمريكية. يجب أن يكون ~ 80ms فقط للإجابات الأخرى رغم ذلك؟ - Jeff Atwood
يبدو أنها تتفق في جميع أنحاء 200MS، لقد ضرب التحديث حوالي 20-30 مرات حتى الآن على حد سواء (وليس في نفس الوقت على الرغم من)، ويبدو الموقع serverfault مثل ذلك تحوم حول 200MS +/- أكثر من الآخر . لقد جربت متتبعًا ، لكنه يأتي مع النجوم على كل شيء ، لذا ربما قام مسؤولو تكنولوجيا المعلومات لدينا بحجب أي شيء. - Lasse Vågsæther Karlsen


أرى تراكم 80-90ms تقريبًا على الروابط الممتدة بشكل جيد والمقيسة بين السواحل الشرقية والغربية.

سيكون من المثير للاهتمام معرفة المكان الذي تكتسب فيه الكمون - جرّب أداة مثل traceroute layer-four (lft). هناك الكثير من الفرص التي يتم اكتسابها من "الميل الأخير" (أي في مزود النطاق العريض المحلي).

ومن المتوقع أن يكون وقت التحويل متأثراً قليلاً - ففقدان الحزمة والارتعاش هما قياسات أكثر فائدةً للنظر عند التحقيق في فروق الوقت المنقولة بين موقعين.


2
2018-04-30 11:42





فقط للمتعة ، عندما لعبت لعبة على الإنترنت Lineage 2 NA من داخل أوروبا:

Response time to east coast servers: ~110-120ms
Response time to west coast servers: ~190-220ms

يبدو أن الفرق يدعم أن ما يصل إلى 100 مللي ثانية في حدود المعقول ، بالنظر إلى الطبيعة غير المتوقعة للإنترنت.

باستخدام اختبار تحديث Chrome المشهود ، أحصل على وقت تحميل المستند الذي يختلف عن 130 مللي ثانية تقريبًا.


2
2018-04-30 12:52





الجميع هنا لديه بعض النقاط الجيدة وصحيح في بوفهم الخاصة.

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

مثل 72ms NY إلى SF latency هو الكمون من PoP إلى PoP من ناقل الحزمة. هذا لا يأخذ بعين الاعتبار أي من النقاط العظيمة الأخرى التي أشار إليها البعض هنا حول الازدحام ، فقدان الحزم ، جودة الخدمة ، الحزم خارج الترتيب ، أو حجم الرزمة ، أو إعادة توجيه الشبكة فقط بين عالم مثالي من PoP إلى PoP .

ثم عندما تضيف في الميل الأخير (بشكل عام العديد من الأميال) من PoP إلى موقعك الفعلي داخل المدينتين حيث يصبح كل من هذه المتغيرات أكثر مرونة من أي شيء يبدأ بالتصعيد بشكل كبير من قدرة التخمين المعقولة!

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

في نفس الوقت ، راقبت أرقام مزودي الدوائر على الويب.

كانت النتائج أرقام زمن الانتقال بين 88 و 100 مللي ثانية من باب إلى باب مواقع العمل. هذا لم يتضمن أي أرقام زمن الانتقال بين المكتب.

تراوحت أوقات استجابة شبكات موفر الخدمة بين 70 و 80 مللي ثانية. المعنى الذي من الممكن أن يتراوح طول آخر زمن انتقال بين 18 و 30 مللي ثانية. لم أقم بربط القمم والقيعان الدقيقتين بين البيئتين.


2
2017-09-09 15:43