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

عنوان خروج جديد يغيّر وجهة الاختبار

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

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

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

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

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

البداية البطيئة تنتهي بعد انتهاء معظم الاختبارات القصيرة

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

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

انظر إلى مراحل الاتصال بدلًا من الثقة برقم واحد. يبلّغ Curl عن كل مرحلة على حدة، فترى هل يذهب الوقت في المصافحة أم في التصاعد أم في النقل:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

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

تدفق واحد وستة تدفقات تقيس أشياء مختلفة

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

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

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

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

التشفير يكلّف وقت معالج، والتغليف يكلّف بايتات

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

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

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

ObservationLikely mechanismWhat to measure
Throughput flat as streams increaseCPU per packet on one corePer-core utilisation during the test
Fast small transfers, stalled large onesMTU and fragmentationPayload size at which it breaks
Good average, unusable callsQueueing delay behind a full bufferLatency under load

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

ضع الطريقة في السجل

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

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

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

مقالات ذات صلة