اختبار السرعة لديك يكذب.
قِس responsiveness بدلًا من ذلك.

كذبة الرقم الكبير

كل موقع لاختبار السرعة يفتح بعدّاد. يدور، يتوقف عند رقم لافت (480 للتنزيل، 510، 940 إن كنت على ألياف ضوئية)، ويصبح هذا الرقم هو الحكاية. الحكاية تكون شبه دائمًا خاطئة. ليست غير صادقة بالضبط، فقط سؤال خاطئ تمت الإجابة عليه بدقة.

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

هذا السؤال الثاني هو responsiveness، ولعشرين عامًا لم تكن لدينا في المتصفح وسيلة لقياسه تقريبًا. الآن لدينا. إنه مدمج في macOS. لم يخبرك أحد فحسب.

ما هو bufferbloat، في فقرة واحدة

كل راوتر ومودم بين حاسوبك المحمول والإنترنت يحتوي على بافر: قطعة صغيرة من الذاكرة تنتظر فيها الحزم دورها. عندما يكون الرابط الأمامي للبافر أبطأ من الرابط الخلفي (مثلًا 40 ميغابت/ث للرفع خلف شبكة محلية بسرعة جيغابت)، يبدأ البافر بالامتلاء. جعلت الشركات هذه البافرات كبيرة بشكل سخيف لأن إسقاط الحزم يبدو كأنه عطل. لكن البافر الكبير جدًا يُبقي حزمة Zoom الصوتية لديك خلف كل حزمة أخرى وصلت قبلها بميلي ثانية. الأنبوب ينقل بايتات كثيرة. البايتات المهمة فقط تنتظر في الصف. هذا التأخير (الذي يقاس بمئات الميلي ثوانٍ تحت الحمل) هو bufferbloat. لذلك يمر اختبار السرعة لديك وتنهار مكالمتك.

تعرّف على RPM وRound-trips Per Minute

في عام 2021 اقترح فريق الشبكات في Apple مقياسًا بلغة واضحة: RPM، أي Round-trips Per Minute. الفكرة بسيطة بشكل يكاد يكون محرجًا. بينما يكون الأنبوب مشبعًا (تنزّل وترفع بكامل القوة)، عُدّ كم من جولات الطلب/الرد الكاملة يمكنك إنهاؤها في دقيقة. الشبكة المتجاوبة تنجز الآلاف. الشبكة المنتفخة تنخفض إلى المئات. نفس الأنبوب 500 ميغابت/ث في الحالتين.

أصدرت Apple أداة لذلك في macOS Monterey. اسمها networkQuality، تقع في /usr/bin/networkQuality، وإذا فتحت Terminal وشغّلتها سترى شيئًا كهذا:

$ networkQuality
==== SUMMARY ====
Uplink capacity:   38.412 Mbps
Downlink capacity: 476.185 Mbps
Responsiveness:    Medium (540 RPM)
Idle Latency:      18 ms

اقرأ هذا الإخراج بعناية. الأنبوب واسع، قرابة نصف جيغابت تنزيلًا. الـ responsiveness medium. 540 جولة في الدقيقة تساوي نحو تسع جولات في الثانية: تنتظر حزمتك الصوتية حوالي 111 ميلي ثانية على شبكة محمّلة، مقابل 18 ميلي ثانية في حالة الخمول. هذه الفجوة هي السبب الكامل لكون مكالمتك تبدو نظيفة حين لا يكون أحد آخر في المنزل، ومحطّمة حين تكون العائلة كلها تشاهد البث.

High وMedium وLow، ماذا تعني؟

تُصنّف Apple RPM في ثلاث فئات قابلة للقراءة:

• High: 2,000 RPM فأكثر. الشبكة متجاوبة. ستشعر بالعمل اللحظي (المكالمات، الألعاب، التحرير المشترك) بنشاط بصرف النظر عن أي شيء آخر يعمل.
• Medium: تقريبًا 600–2,000 RPM. الشبكة لا تزال صالحة للاستخدام، لكن التطبيقات التفاعلية ستشعر بالبطء تحت الحمل. هنا تجلس معظم الشبكات المنزلية في وقت الذروة، ومن هنا تأتي الشكاوى.
• Low: أقل من 600 RPM. البافرات ممتلئة. ستنقطع المكالمات الصوتية، يتجمد الفيديو، تصل ضربات المفاتيح في SSH على دفعات. لن يصلح أي قدر إضافي من النطاق الترددي ذلك حتى تفرغ البافرات.

لماذا لا يرى اختبار السرعة هذا

اختبار السرعة يقيس فقط النصف السهل من المشكلة: idle throughput، عادة في دفقة قصيرة، عادة على اتصال تعلّم مزود الخدمة لديك أن يعطيه الأولوية. يخبرك بما يستطيع أنبوبك فعله حين يكون الحمل خفيفًا، ولا يطرح أبدًا السؤال التالي عن الكمون تحت الحمل. Bufferbloat بحكم تعريفه غير مرئي لهذا الاختبار، لأن الاختبار هو الحمل، ولا يوجد ترافيك آخر يقف خلفه في الصف.

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

اختبار RPM عملياً

إن networkQuality من Apple أنيق وقاسٍ في آن. يفتح عدة اتصالات متوازية إلى نقاط نهاية CDN، يشبعها في الاتجاهين، ثم يقيس كم تستغرق زوجية صغيرة من الطلب والرد بـ HTTP/2 لإكمال الدورة أثناء هذا الإشباع. هذه هي قيمة RPM. تأتي قياسات السعة بصحبة هذا، ولذلك تعيد الأداة الأرقام الثلاثة من تشغيل واحد.

الاختبار يستغرق نحو خمس عشرة ثانية. يطرق رابطك بقوة، فلا تشغّله أثناء مكالمة. كما يكشف أمورًا قد لا يحب مزود الخدمة أن تراها: قنوات Wi-Fi تتداخل مع الجيران، راوتر فيه عيب في البرنامج الثابت يضاعف عمق الطابور، VPN يضيف 200 ميلي ثانية من الكمون لكل جولة. كثيرًا ما تكتشف أن الحلقة الأضعف ليست مزود الخدمة، بل شيء داخل بيتك.

ماذا تفعل عندما يكون RPM منخفضًا (Low)

لا توجد رصاصة سحرية، لكن قائمة التحقق محدودة:

1. اختبر السلكي أولًا. أوصل كابل Ethernet بالـ Mac وأعد تشغيل networkQuality. إذا قفز RPM إلى High، فمشكلتك في الـ Wi-Fi (الازدحام، تداخل القنوات، أو المسافة)، لا في مزود الخدمة.
2. فعِّل Smart Queue Management. الراوترات التي تدعم SQM أو CAKE أو fq_codel تسوّي bufferbloat بشكل دراماتيكي. راوتر بـ 100$ مع fq_codel مفعّل يهزم راوتر بـ 600$ بدونه.
3. قيِّد الرفع. إذا لم يتوفر SQM، حُدّ من رفع الـ Mac إلى نحو 90 % من سعة الرفع التي قست. هذا التغيير وحده يمنع ملفات الرفع الخاصة بك من ملء البافر وتجويع تنزيلاتك من رسائل ACK المرتدة.
4. استبدل وحدة المودم/الراوتر المدمجة من مزود الخدمة. كثير من الأجهزة التي يصدرها مزودو الخدمة مضبوطة لمعايير الإنتاجية، لا للاستجابة. وضع جهاز مزود الخدمة في وضع bridge وتشغيل راوتر خاص بك أمامه هو أكبر تحسّن منفرد في RPM يراه معظم الناس.

ثلاث خرافات راسخة

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

«ping لدي 12 ms، إذًا أنا بخير.» الـ ping يقيس كمونًا في الخمول: كم تستغرق حزمة عندما لا يقف شيء في الطريق. Bufferbloat يظهر فقط تحت الحمل. ping خمول 12 ms على رابط منتفخ يصبح بسهولة 350 ms تحت الحمل. شغّل ping في طرفية، ورفعًا كبيرًا في طرفية أخرى، وسترى ذلك يحدث في الزمن الحقيقي.

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

أين يندرج WiFi & IP Info

وضعنا محرك networkQuality على بُعد نقرة في شريط القوائم. لوحة Network Quality في طبقة Pro تشغّل الاختبار نفسه من Apple، وتُظهر سعة الرفع/التنزيل، وتُبلّغ عن فئة RPM وخط الأساس لـ RTT، والأهم أنها تحتفظ بسجل. يمكنك ضغط «شغّل من جديد» مرة كل ساعة طوال أسبوع لرؤية النمط: High صباح السبت، Medium وقت العشاء، Low عند عودة الأطفال من المدرسة. هذا الرسم هو ما يجعل مزود الخدمة يفعل شيئًا فعلًا، لأن قابلية إعادة الإنتاج هي ما يُحوّل الشكوى إلى تذكرة.

اقرنه برسم Latency History وسجل الاتصالات في التطبيق، فترسل لمزود الخدمة تذكرة تكتبها في ثلاثين ثانية: «RPM ينخفض من 2,400 إلى 410 بين 18:00 و21:00 بالتوقيت المحلي، مرتبطًا بمتوسط RTT أعلى ثلاث مرات إلى بوابتكم. ملف CSV مرفق.» هذه محادثة مختلفة تمامًا عن «الإنترنت لدي بطيء.»

النسخة القصيرة

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

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