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