كيفية قياس الكمون عبر كل طبقة من الشبكة

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

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

التكلفة الحقيقية لطلب بطيء

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

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

قاعدة عملية: تعامل مع الكمون كمجموعة عينات، وليس قراءة واحدة. السؤال الأول ليس "ما هو المتوسط؟" بل "كيف يبدو الذيل، وما الذي تغير هناك؟"

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

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

أساسيات الكمون التي تحتاجها قبل الاختبار

ابدأ بالمصطلحات التي تهم

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

تقدم النسب المئوية لك نظرة عملية. p50 هو منتصف التوزيع، p95 يظهر المستوى الذي تبقى تحته 95% من الطلبات، وp99 يتعمق أكثر في الذيل حيث تعيش الطلبات البطيئة النادرة. إذا كان الوسيط جيدًا لكن p95 وp99 تمتد، فإن مستخدميك سيشعرون بذلك.

فكر في الطبقات، وليس في قفزة واحدة

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

نموذج ذهني مفيد بسيط. تؤثر جودة المسار الفيزيائي على RTT، وسلوك النقل يؤثر على إعادة الإرسال وإعداد الاتصال، وعمل التطبيق يؤثر على مدى طول انتظار الطلب قبل أن يعود البايت الأول. لهذا السبب ستنتهي بقياس عدة طبقات إذا كنت تريد إجابة موثوقة.

إذا أظهر الاختبار رقمًا واحدًا فقط، افترض أنه غير مكتمل حتى يتم إثبات خلاف ذلك.

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

قياس الكمون من سطر الأوامر

يخبرك Ping بأول RTT

استخدم ping عندما تريد قراءة سريعة عن جودة المسار. أمر بسيط مثل ping -c 20 target يعطيك مجموعة صغيرة من العينات، وعادة ما ينتهي الإخراج بـ min/avg/max بالإضافة إلى قيمة الانتشار. الحقل الذي يجب قراءته هو خط RTT، وليس تسلسل الحزم.

نمط الإخراج المثال:

20 packets transmitted, 20 received, 0% packet loss rtt min/avg/max/mdev = 12.4/18.7/41.3/6.2 ms

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

Traceroute يظهر أين يتباطأ المسار

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

نمط الإخراج المثال:

1 1.1 ms 1.0 ms 1.2 ms 2 4.8 ms 5.1 ms 4.9 ms 3 19.6 ms 20.1 ms 21.0 ms

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

MTR يجمع بين الرؤيتين

mtr target مفيد عندما تريد تقريرًا مباشرًا عن كل من المسار والفقد. الأعمدة التي يجب قراءتها هي Loss% وAvg. قفزة مع فقد متزايد ومتوسط RTT متزايد تكون أكثر إثارة للقلق من واحدة مع قمة غريبة واحدة.

نمط الإخراج المثال:

Host Loss% Avg Best Wrst 1 0.0% 1.1 1.0 1.5 2 0.0% 5.0 4.8 5.4 3 2.0% 20.4 19.7 41.2

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

Iperf3 يخبرك كيف يتصرف الرابط تحت الحمل

استخدم iperf3 عندما تهتم بالسعة وحساسية الحمل. أمر أساسي مثل iperf3 -c target يتحقق من كيفية تصرف المسار عندما تتدفق البيانات، وليس فقط عندما يرتد الاستطلاع. الحقل الذي يجب مراقبته هو معدل النقل، لأن الكمون غالبًا ما يزداد سوءًا بمجرد أن يصبح الرابط مشغولًا.

نمط الإخراج المثال:

[ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 120 MBytes 101 Mbits/sec

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

Tcpdump و tshark تكشف توقيتات مستوى الحزمة

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

نمط الالتقاط المثال:

tcpdump -i any host target إحصائيات ICMP: الحد الأدنى 12 مللي ثانية، الحد الأقصى 71 مللي ثانية، المتوسط 19 مللي ثانية، الوسيط 16 مللي ثانية، الانحراف المعياري 8 مللي ثانية

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

تأخير التطبيق والمتصفح الذي يمكنك رؤيته فعلاً

يمكن أن يبدو الطلب سريعًا على مستوى الشبكة ومع ذلك يشعر بالبطء في المتصفح. لهذا السبب أُفصّل دائمًا الأمر باستخدام curl قبل أن أثق في أي شيء آخر. الحقول المفيدة هي وقت DNS، وقت الاتصال TCP، وقت TLS، TTFB لوقت أول بايت، و الوقت الكلي.

يبدو الأمر العملي هكذا:

curl -o /dev/null -s -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

نموذج الناتج:

dns:0.012 tcp:0.045 tls:0.089 ttfb:0.150 total:0.320

تلك السطر الواحد يخبرك أين يحدث الانتظار. إذا كان DNS رخيصًا ولكن TTFB بطيئًا، فإن المشكلة تكمن في الخادم أو مسار الوكيل. إذا كانت TCP و TLS هما العقبة، فأنت تنظر إلى إعداد الاتصال، وليس تسليم المحتوى.

استخدم شلال المتصفح لتوقيتات الواجهة الأمامية للمستخدم

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

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

عادة مفيدة: قارن شلال المتصفح مع خط توقيت curl من نفس الهدف. إذا كانا مختلفين، فإن مسار المتصفح لديه تكاليف إضافية لا تراها في اختبار CLI الخاص بك.

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

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

قراءة الأرقام دون خداع نفسك

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

اقرأ النسب المئوية كشكل

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

هذا هو أول مكان أنظر إليه في معيار الإنتاج. إذا كان p99 قبيحًا، أتوقف عن اعتبار المتوسط كمعيار قرار وأبدأ في اعتباره مصدراً للضوضاء.

افصل مشاكل القفز عن مشاكل الخدمة

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

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

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

قياس التأخير من خلال الوكلاء المتنقلين و 4G

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

لهذا السبب يجب أن يبقى المعيار مثبتًا على مسار واحد. إذا قمت بتدوير عنوان IP للوكيل أثناء جمع العينات، فإنك تتوقف عن قياس اتصال واحد وتبدأ في دمج عدة مسارات في مجموعة واحدة من النسب المئوية. احتفظ بـ نفس الجلسة الثابتة طوال التشغيل الكامل، ثم كرر الاختبار بعد التدوير إذا كنت تريد أن ترى مدى تغير المسار نفسه. لملاحظة إعداد أعمق حول توجيه الهاتف المحمول، هذا الدليل لوكيل 4G LTE هو أوضح مكان للتحقق من سلوك الجلسة الذي تحتاجه للحفاظ على استقراره.

ما يجب الاحتفاظ به ثابتًا أثناء الاختبار

• احتفظ بالجلسة مستقرة: لا تقم بتدوير عنوان IP أثناء جمع عينات التأخير. يمكن أن يؤدي تغيير واحد في المسار إلى تغيير التوزيع بما يكفي لجعل المعيار صعب القراءة.
• تحقق من ASN أولاً: تأكد مما إذا كان المسار يقع في شبكة هاتف محمول، مسار سكني، أو مسار مركز بيانات قبل أن تقارن النتائج.
• استخدم نفس نقطة النهاية ونفس نافذة التوقيت: خلاف ذلك، ستخلط تغييرات الشبكة مع تغييرات الحمل، ويتوقف الناتج عن كونه مفيدًا.
• قارن مثل مع مثل: قم بتشغيل نفس الطلب من الأصل، ثم من خلال وكيل سكني، ثم من خلال وكيل 4G متنقل.

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

لماذا يمكن أن يبدو traceroute غريبًا على 4G

نادراً ما يبدو مسار 4G كمسار مؤسسي نظيف. بعض القفزات لا تجيب أبدًا، بعض الردود محدودة السرعة، وقد يجلس عنوان IP العام خلف حافة الناقل بدلاً من آلة واحدة. لا يزال traceroute يساعد، لكن اعتبره وسيلة لقراءة شكل المسار، وليس كخريطة مثالية لكل قفزة.

عادة التشغيل التي تثبت فعاليتها بسيطة. قم بمعيار ثلاثة مسارات جنبًا إلى جنب، شبكتك الأصلية، نفس الطلب من خلال وكيل سكني، ثم نفس الطلب من خلال وكيل 4G متنقل. احتفظ بالجلسة ثابتة في كل حالة، ثم قارن p50، p95، p99، والحد الأقصى. يمنحك ذلك قراءة عملية للتأخير قبل أن تفعل حركة الإنتاج.

المزالق الشائعة وقائمة التحقق التي يمكنك إعادة استخدامها

• الاختبار فقط على الشبكات الخاملة. قد تبدو الأرقام نظيفة على مسار هادئ وتنهار بمجرد أن يشارك حركة المرور الحقيقية الرابط. المشكلة ليست في الاختبار نفسه، بل في حالة الشبكة أثناء الاختبار. الإصلاح: كرر التشغيل خلال الفترات المزدحمة وقارن التغير في التوزيع.
• أخذ عينة واحدة فقط. يمكن أن يبدو التشغيل القصير حاسماً بينما لا يزال من الصعب تكراره. المشكلة هي ضوضاء التوقيت ومسار تغير تحتك. الإصلاح: اجمع عدة نوافذ وقارن الانتشار، وليس فقط الرقم الرئيسي.
• تجاهل زمن الانتظار النهائي. يمكن أن يخفي المتوسط الصحي الطلبات البطيئة التي يشعر بها المستخدمون. تظهر المشكلة في الطرف البعيد من التوزيع، وليس في المنتصف. الإصلاح: اقرأ p95 و p99 و max معاً، ثم قرر ما إذا كان الذيل مقبولاً.
• تدوير البروكسي أثناء الاختبار. إذا تغيرت الجلسة في منتصف الطريق، فإن المسار يتغير معها وتتوقف النسب المئوية عن أن تعني الكثير. هذا شائع في المسارات المحمولة مع NAT من الدرجة الناقلة وسلوك الجلسة الثابتة، حيث قد يبقى تشغيل واحد على مخرج واحد وقد لا يفعل الآخر. الإصلاح: احتفظ بجلسة ثابتة واحدة طوال فترة التشغيل.
• قياس الخادم فقط. يمكن أن يتم إلقاء اللوم على بحث DNS البطيء أو مصافحة TLS المتأخرة على الواجهة الخلفية حتى عندما لا يكون التطبيق هو عنق الزجاجة. يجب أن يفصل المؤقت بين إعداد الاتصال، ووقت المصافحة، ووقت الاستجابة. الإصلاح: قم بتقسيم الطلب إلى تلك المراحل وسجل كل واحدة.
• استخدام المتوسطات للتقارير. يمكن أن يflatten المتوسط تجربة المستخدم السيئة إلى رقم يبدو غير ضار. ذلك يخفي الطلبات التي تفشل في عملية السحب، أو فحص التحقق من الإعلان، أو تدفق QA المحمول. الإصلاح: أبلغ عن النسب المئوية التي تتطابق مع الطلبات الحقيقية واحتفظ بالحد الأقصى الخام في العرض.
• إيقاف التشغيل قبل انتهاء الطلبات الجارية. يمكن أن يفوت التشغيل الذي ينتهي مبكراً أبطأ الطلبات ويجعل المعيار يبدو أفضل مما هو عليه. نافذة الجمع غير مكتملة، لذا فإن الحد الأقصى يكون أقل من قيمته. الإصلاح: دع المعيار ينفد قبل أن توقفه.

بالنسبة لعمليات البروكسي المحمولة و4G، فإن قائمة التحقق بسيطة. تأكد من ASN وسلوك الجلسة قبل مقارنة النتائج، حافظ على نقطة النهاية ونافذة التوقيت ثابتة، اجمع عينات كافية لرؤية الذيل، وتحقق من أن غرائب traceroute متوقعة لمسار الناقل الذي تستخدمه. إذا كنت بحاجة إلى مرجع لسلوك بروكسي 4G وLTE، استخدم صفحة الويكي التي تحتفظ بها بالفعل لذلك الإعداد، ثم اختبر ضد خط الأساس الخاص بك بدلاً من افتراض أن مساراً واحداً سيتصرف مثل آخر.