02 · المشكلة
يفقد المستجيبون الاتصال حين يحتاجونه أكثر
لماذا يحتاج المستجيبون إلى الاتصال
يعتمد المستجيبون الأوائل بشكل متزايد على أدوات تعمل عبر الإنترنت في الميدان. تستخدم فرق كثيرة تطبيق ATAK الذي يعرض مواقع أفراد الفريق وبيانات الحادث على خريطة مشتركة في هواتفهم، وقد اعتمد تقليديًا على الشبكة الخلوية. وتخطط فرق البحث والإنقاذ تحركاتها وتتنقّل بأدوات خرائط مثل CalTopo، وتتيح المكالمات الصوتية عبر الإنترنت للفرق أن تتواصل أينما توفّرت تغطية البيانات.
لكن في عمليات البحث والإنقاذ في الصحراء أو أثناء عاصفة رملية تكون التغطية متقطعة، وينتقل هاتف المستجيب باستمرار بين أبراج خلوية مختلفة والأقمار الصناعية. ولا تكون هذه الأدوات أفضل من الاتصال الذي تعمل فوقه.
لماذا يعطّل التنقّل بين الشبكات كل شيء
كل انتقال إلى شبكة جديدة يمنح الهاتف عنوان IP جديدًا. واتصالات التطبيقات العادية مرتبطة بذلك العنوان، فيُجبر كل انتقال التطبيقات على البدء من جديد بمصافحة TCP جديدة. والنتيجة أن الخرائط تتوقف، والصفحات لا تُحمَّل، والمكالمات الصوتية تنقطع.
هكذا يبدو انتقال واحد من وجهة نظر التطبيق:
- ينضم الهاتف إلى شبكة جديدة ويحصل على عنوان IP جديد.
- كل اتصال TCP مفتوح كان مرتبطًا بالعنوان القديم، فأصبح ميتًا، وكثيرًا ما لا يلاحظ التطبيق ذلك إلا بعد انتهاء مهلة الانتظار.
- يفتح التطبيق اتصالًا جديدًا: مصافحة TCP ثم مصافحة TLS، قبل أن تتدفق أي بيانات.
- ما كان في الطريق، صفحة أو جزء من خريطة أو رسالة، يضيع أو يجب إرساله من جديد.
قد تبدو كل فجوة قصيرة، لكن الانتقالات تتكرر مرة بعد مرة أثناء تحرّك الفريق، وكل واحد منها يقطع كل تطبيقات الهاتف في اللحظة نفسها.
كلفة إعادة الاتصال
من الوقت الضائع بعد كل انتقال على رابط قمر صناعي ثابت بالنسبة للأرض، قبل أن تتدفق أي بيانات من جديد.
يحتاج كل اتصال آمن جديد إلى مصافحة TCP ثم مصافحة TLS، وتستغرق كل منهما رحلة ذهاب وإياب كاملة على الأقل. وعلى رابط قمر صناعي ثابت تستغرق الرحلة الواحدة نحو 600 ملّي ثانية، فتزداد كلفة إعادة الاتصال كلما زاد زمن الاستجابة في الرابط.
| الرابط | ذهاب وإياب | مصافحتان |
|---|---|---|
| واي فاي | 8 ملّي ثانية | 16 ملّي ثانية |
| 5G | 24 ملّي ثانية | 48 ملّي ثانية |
| قمر صناعي منخفض المدار | 40 ملّي ثانية | 80 ملّي ثانية |
| قمر صناعي ثابت | 600 ملّي ثانية | 1.2 ثانية |
أزمنة الذهاب والإياب للروابط التي نحاكيها. ويُضاف إليها الوقت اللازم لاكتشاف أن الرابط القديم انقطع.
مع ترحيل الاتصال في QUIC، لا حاجة إلى أي مصافحة جديدة.
03 · الحلول الحالية
ما هو موجود، وأين يقصُر
ترحيل الاتصال في QUIC
QUIC بروتوكول نقل حديث يعرّف الاتصال بمعرّف لا بعنوان IP، فيستطيع مبدئيًا الانتقال إلى شبكة جديدة من دون إعادة الاتصال. وهو مدمج بالفعل في بعض متصفحات الويب، حيث يسرّع تحميل الصفحات بدمج مصافحة النقل ومصافحة التشفير في واحدة.
+ نقطة القوة: مصمَّم ليصمد أمام تغيّر الشبكة، مع مصافحات سريعة ومشفّرة.
− القيد: نادرًا ما يُستخدم الترحيل عمليًا، ومعظم التطبيقات والمكالمات الصوتية ما زالت تعمل عبر TCP الذي لا يستطيع الترحيل أصلًا.
Mosh، الطرفية المتنقّلة
Mosh أداة طرفية عن بُعد تُبقي الجلسة قائمة بينما يغيّر الجهاز عنوان IP، حتى عند التنقّل بين الواي فاي والبيانات الخلوية والإيثرنت السلكي. وتتنبأ أيضًا بكيفية تغيّر الشاشة مع كل ضغطة مفتاح، فتُخفي التأخير عن المستخدم.
+ نقطة القوة: تنقّل مجرَّب بين الشبكات، مع تنبؤ يُخفي التأخير.
− القيد: تعمل لجلسات الطرفية فقط، فلا تساعد مستجيبًا يحمّل خريطة أو يفتح موقعًا أو يجري مكالمة.
Multipath TCP
يتيح Multipath TCP لاتصال واحد أن يستخدم عدة مسارات شبكية في آن واحد، مثل الواي فاي والشبكة الخلوية. فإذا تعطّل مسار استمرت البيانات عبر المسارات الأخرى. وتستخدمه Apple في أجهزة iPhone لخدمات مثل Siri، حتى تصمد الطلبات أمام إشارة واي فاي ضعيفة.
+ نقطة القوة: يُبقي الاتصال قائمًا عندما ينقطع أحد الروابط، ويمكنه جمع سعة عدة روابط.
− القيد: يجب أن يدعمه الجهاز والخادم كلاهما، ومعظم المواقع لا تدعمه، ولا يقلّل البيانات المرسلة عبر الروابط البطيئة.
مقارنة جنبًا إلى جنب
| يصمد أمام تغيّر عنوان IP | يساعد حركة الويب والتطبيقات | يتطلب تغيير كل موقع | يرسل بيانات أقل على الروابط البطيئة | |
|---|---|---|---|---|
| ترحيل QUIC | نعم، إذا دعمه الطرفان | فقط التطبيقات المبنية على QUIC | نعم | لا |
| Mosh | نعم | لا، جلسات الطرفية فقط | يتطلب Mosh على الجهاز البعيد | لشاشات الطرفية فقط |
| Multipath TCP | نعم، إذا توفّر مسار آخر | حيث يدعمه الطرفان | نعم | لا |
| شجرة | نعم | التطبيقات التي تستخدم إعداد الوكيل في الهاتف | لا، خادمنا فقط | نعم: الضغط والجلب المسبق |
04 · فكرتنا
وكيل مزدوج بين الهاتف والسحابة
تضع شجرة وكيلَين بين تطبيقات المستخدم والإنترنت: وكيل عميل على جهاز المستخدم، ووكيل خادم في السحابة. وتمرّ كل البيانات بينهما عبر نفق QUIC واحد يبقى مفتوحًا عندما يغيّر الجهاز شبكته، بينما يتولى وكيل الخادم العمل الثقيل نيابةً عن الجهاز. وعلى خلاف الحلول الحالية، تصمد شجرة أمام التنقّل بين الشبكات وتقلّل أيضًا البيانات التي يجب أن تعبر الرابط البطيء.
تصمد أمام تغيّر IP
يأخذ وكيل العميل حركة كل تطبيق يستخدم إعداد الوكيل في الهاتف، وينقلها داخل نفق QUIC واحد. وعندما ينتقل الهاتف إلى شبكة أخرى، ينتقل النفق معه بدلًا من أن ينقطع.
ترسل بيانات أقل
يجلب وكيل الخادم صفحات الويب نيابةً عن الهاتف ويضغطها قبل إرسالها، فتعبر الرابط البطيء بيانات أقل بكثير. ويوفّر هذا عرض النطاق على كل اتصال لا على روابط الأقمار الصناعية وحدها، فتنخفض كلفة البيانات وتبقى سعة أكبر للحركة الحساسة للوقت مثل المكالمات الصوتية.
تُحمَّل قبل أن تنقر
يستخدم الخادم Jev، وهو نموذج ذكاء اصطناعي خفيف يُستدعى عبر واجهة برمجية، ليتنبأ بالروابط التي سيفتحها المستجيب بعد ذلك. ثم يرسل تلك الصفحات إلى الهاتف مسبقًا، فتُفتح فورًا حتى أثناء انقطاع قصير للإشارة.
لماذا وكيلان؟
لا تحتاج التطبيقات ولا المواقع إلى أي تغيير. تتحدث التطبيقات إلى وكيل العميل كما تتحدث إلى أي وكيل، وترى المواقع زائرًا عاديًا هو وكيل الخادم. والجزء الواقع بينهما وحده، وهو الجزء الذي نتحكم في طرفيه، يحتاج إلى التعامل مع تغيّر الشبكة.
إبقاء الرابط غير الموثوق قصيرًا
يتولى الخادم المصافحات مع المواقع وأي حزم تضيع في الطريق إليها، عبر اتصاله السريع والمستقر. ولا يُترك لنفق QUIC إلا رابط الهاتف نفسه، وهو الرابط الذي يتغيّر باستمرار.
05 · النموذج
كيف تترابط أجزاء شجرة
طلب واحد، خطوة بخطوة
- يطلب تطبيق صفحة من وكيل العميل.
- إذا كانت في ذاكرة الهاتف نسخة حديثة قُدّمت فورًا. وإذا كانت هناك نسخة أقدم، يسأل الوكيل الخادم هل تغيّرت (ETag)، فلا يعبر الرابط إلا الجواب إن لم تتغيّر.
- وإلا يمرّ الطلب عبر النفق؛ فيجلب الخادم الصفحة ويضغطها ويعيدها.
- وفي الخلفية يسأل الخادم Jev عن الروابط التالية ويدفع الصفحات المرجّحة إلى الذاكرة المؤقتة.
عندما تتغيّر الشبكة
- يفحص وكيل العميل النفق خمس مرات في الثانية.
- إذا توقف الرابط الحالي عن الاستجابة لمدة ثانية، ينقل النفق إلى شبكة أخرى تعمل.
- يواصل اتصال QUIC نفسه من عنوان IP الجديد: لا مصافحة جديدة، وتكتمل الطلبات التي كانت في الطريق.
- إذا عاد الرابط بعد صمت طويل، يُعاد ضبط مؤقّت إعادة المحاولة في QUIC فورًا، فتتدفق البيانات من جديد خلال ثانية.
عندما تضعف الإشارة
- يراقب الهاتف قوة الإشارة ويرسم اتجاهها خلال الثواني الخمس الأخيرة.
- إذا كانت الإشارة ستصبح غير صالحة خلال ثماني ثوانٍ ولا توجد شبكة أخرى، ينبّه الخادم.
- يجلب الخادم مسبقًا صفحات أكثر بكثير، وعلى عمق نقرتين في الانقطاعات الطويلة، ليبقى ما يُقرأ من دون اتصال.
- ويتوقف عن الإرسال قبيل الانقطاع المتوقع مباشرة، لأن البيانات المرسلة إلى رابط ميت لا تفعل سوى إعاقة الاتصال عند عودته.
06 · النموذج الأولي
كيف يعمل نموذجنا الأولي
لماذا حاسوبان؟ لم نلتزم بعد بالدفع مقابل استضافة خادم، لذلك يحلّ الحاسوب 2 محل الخادم السحابي. أما في النظام الفعلي فيعمل وكيل العميل على جهاز iPhone نفسه ويتصل مباشرة بخادم بعيد.
تشغيل العرض
يشغّل الحاسوب 2 وكيل الخادم وينشئ شهادة، ننسخها إلى الحاسوب 1 حتى يثق الجهازان ببعضهما. ويشغّل الحاسوب 1 وكيل العميل ويقبل الاتصالات من الأجهزة الأخرى على شبكة الواي فاي. وعلى iPhone نضبط وكيلًا يدويًا في إعدادات الواي فاي يشير إلى الحاسوب 1، ثم نتصفح في Safari كالمعتاد. الخطوات الكاملة في ملف README على GitHub.
نوعان من الحركة
تمرّ مواقع HTTPS الآمنة عبر النفق وهي ما زالت مشفّرة، فلا يستطيع أي من الوكيلين قراءة محتواها. أما مواقع HTTP العادية فتمرّ عبر الوكيل الكامل، حيث يضغط الخادم الصفحات وتحفظها جهة الهاتف في ذاكرتها المؤقتة. ويتشارك النوعان نفق QUIC نفسه بين الحاسوبين.
عرض الانتقال بين الشبكات
لا يعمل إعداد الوكيل في iPhone إلا على الواي فاي، لذلك يحدث الانتقال على الحاسوب 1: يُبقي الواي فاي لجهاز iPhone وينقل النفق بين الإيثرنت وبيانات الجوال بينما يواصل Safari التحميل. وعلى الحاسوب 2 يسجّل سجل الخادم كل موقع يُفتح، ويُظهر Wireshark اتصال QUIC واحدًا يحمل كل الحركة. أما الانتقال نفسه فهو ما تقيسه اختباراتنا في الشبكة المحاكاة؛ انظر النتائج.
ما أظهره العرض الحي
اتصالًا آمنًا بـ44 موقعًا مختلفًا خلال نصف ساعة من التصفح على iPhone، كلها عبر نفق QUIC واحد
اتصالًا فتحه بحث واحد في Google في أقل من أربع ثوانٍ، كلها داخل النفق نفسه
لتحميل صفحة ويكيبيديا حجمها 922 كيلوبايت عبر HTTPS من خلال الوكيلين
عمل تطبيق Instagram عبر النفق من دون أي تعديل، إذ يلتقط إعداد الوكيل في iPhone تلقائيًا. وكل اتصال فشل كان بخادم إعلانات أو تتبّع أو قياس استخدام، ويبدو أن الشبكة التي اختبرنا عليها تحجبها.
07 · عملية الاختبار
كيف اختبرنا شجرة
لنختبر النظام بإنصاف وبشكل قابل للتكرار، بنينا شبكة محاكاة على حاسوب Linux واحد. تُنشئ مساحات أسماء الشبكة أربعة أجهزة منفصلة: هاتفًا وموجّهًا وخادمًا سحابيًا وموقعًا. وتمنح أداة tc netem، وهي أداة Linux مجانية ومفتوحة المصدر، كل رابط تأخيرًا وتذبذبًا وفقدانًا للحزم وعرض نطاق واقعية. وأجرينا سيناريوهين: انقطاع 5G تضعف فيه الإشارة ويبقى الرابط ميتًا نحو 45 ثانية قبل أن يعود، ونزهة تضعف فيها إشارة الواي فاي حتى تختفي فينتقل الهاتف إلى 5G.
تضعف الإشارة ابتداءً من الثانية 30، ويبقى الرابط ميتًا من الثانية 38 إلى 84، ثم تعود 5G. والواي فاي والقمر الصناعي غير متاحين طوال الوقت، فلا توجد شبكة يُنتقل إليها.
بدلًا من اختلاق سلوك تصفح، استخدمنا سجلات النقر العامة في ويكيبيديا، التي تحصي عدد المرات التي تتبّع فيها قرّاء حقيقيون كل رابط من مقالة إلى أخرى. كل تشغيل قارئ افتراضي واحد يتبع نقرات حقيقية من أغسطس 2026. وأجرينا 20 تشغيلًا لكل واحد من أربعة إعدادات، من TCP العادي حتى النظام الكامل، ونقارن القيم الوسيطة حتى لا يؤثر تشغيل واحد سريع أو بطيء على غير العادة في النتيجة.
يُستخدم Jev كما هو عبر واجهته البرمجية، فلا يحتاج إلى بيانات تدريب. قيّمناه على 1,002 صفحة من ويكيبيديا مقابل 109.1 مليون نقرة حقيقية من يوليو 2026، وقارنّاه بثلاثة خطوط أساس: اختيار عشوائي بين الروابط الأربعين نفسها التي يراها Jev، وترتيب الروابط في الصفحة، والرابط الأكثر نقرًا في يونيو. وفصل الأشهر الثلاثة يعني ألا يُقيَّم أي متنبئ على نقرات تعلّم منها.
ما قسناه
- زمن تحميل الصفحة: الوقت من طلب الصفحة حتى استلامها كاملة.
- زمن التعافي: المدة بين عودة الشبكة ومرور أول حزمة جديدة عبر النفق.
- البيانات المنقولة: البايتات المرسلة عبر رابط الهاتف، قبل الضغط وبعده.
- معدل الإصابة: نسبة النقرات الحقيقية التي ذهبت إلى الرابط الأول أو الروابط الثلاثة الأولى في ترتيب المتنبئ.
- الجلب المسبق المهدور: البيانات التي أُنفقت على صفحات مجلوبة مسبقًا لم تُفتح أبدًا.
إعدادات الروابط (في اتجاه واحد)
| الرابط | التأخير | التذبذب | الفقدان | عرض النطاق |
|---|---|---|---|---|
| واي فاي | 4 ms | 2 ms | 0.1% | 100 Mbit/s |
| 5G | 12 ms | 4 ms | 0.2% | 150 Mbit/s |
| LTE | 25 ms | 8 ms | 0.5% | 30 Mbit/s |
| قمر صناعي منخفض المدار | 20 ms | 6 ms | 0.5% | 100 Mbit/s |
| قمر صناعي ثابت | 300 ms | 10 ms | 0.3% | 20 Mbit/s |
تُطبَّق على طرفي كل رابط، فتكون رحلة الذهاب والإياب نحو ضعف التأخير. الصفوف الرمادية جاهزة في بيئة الاختبار لكنها لم تُستخدم بعد في اختبار.
الإعدادات الأربعة
| الإعداد | النفق | الضغط | الجلب المسبق | التشغيلات | الصفحات المفتوحة |
|---|---|---|---|---|---|
| TCP+TLS | TCP+TLS، يعيد الاتصال بعد الانقطاع | نعم | لا | 20 | 78 |
| QUIC | QUIC، يحافظ على الاتصال | نعم | لا | 20 | 90 |
| QUIC مع جلب مسبق ثابت | QUIC | نعم | Jev، مع تجاهل تنبيهات الانقطاع | 20 | 92 |
| شجرة | QUIC | نعم | Jev، وأكثر قبل الانقطاع | 20 | 95 |
ثلاثة أشهر من بيانات النقر، منفصلة
| الشهر | استُخدم في |
|---|---|
| يونيو 2026 | خط أساس الرابط الأكثر نقرًا فقط |
| يوليو 2026 | مفتاح الإجابة: تقييم Jev وخطوط الأساس (109.1 مليون نقرة على 1,002 صفحة) |
| أغسطس 2026 | جلسات التصفح التي يتبعها القرّاء الافتراضيون |
08 · نتائج الاختبار
ما أظهرته الاختبارات
زمن تعافي QUIC بعد انقطاع 5G، مقابل 13.1 ثانية لاتصال TCP+TLS المرجعي لدينا (القيمة الوسيطة لـ20 تشغيلًا)
القيمة الوسيطة لتصغير حجم الصفحة بخوارزمية deflate، على 2,147 صفحة من ويكيبيديا
معدل إصابة Jev في الروابط الثلاثة الأولى، أكثر من ثلاثة أضعاف الاختيار العشوائي بين الروابط نفسها (5.1%)
زمن التعافي، القيمة الوسيطة
بعد انقطاع 5G، 20 تشغيلًا لكل إعداد
اعرضه جدولًا
| القيمة الوسيطة | النصف الأوسط من التشغيلات | |
|---|---|---|
| TCP+TLS | 13.1 ثانية | 13.0–13.2 ثانية |
| QUIC | 0.96 ثانية | 0.92–1.03 ثانية |
زمن تحميل الصفحة، القيمة الوسيطة
بعيدًا عن أي انقطاع
اعرضه جدولًا
| TCP+TLS | QUIC | |
|---|---|---|
| واي فاي | 224 ملّي ثانية (10 صفحات) | 216 ملّي ثانية (10 صفحات) |
| 5G | 265 ملّي ثانية (54 صفحة) | 229 ملّي ثانية (61 صفحة) |
التعافي
عندما عادت 5G بعد انقطاع دام نحو 45 ثانية، عاد QUIC إلى نقل البيانات خلال ثانية، بينما استغرق اتصال TCP+TLS المرجعي لدينا 13 ثانية ليعيد الاتصال. ويشمل ذلك تعديلنا الخاص على QUIC، الذي يعيد ضبط مؤقّت إعادة المحاولة فور سماع الخادم من جديد؛ ومن دونه استغرق QUIC أيضًا عشرات الثواني. وبعيدًا عن أي انقطاع، استغرق تحميل الصفحات الوقت نفسه تقريبًا في الحالتين.
التنبؤ
يتفوّق معدل إصابة Jev في الروابط الثلاثة الأولى، 16.1%، على خطَّي الأساس اللذين لا يحتاجان إلى بيانات: الاختيار العشوائي (5.1%) وترتيب الروابط في الصفحة (9.4%)، من دون الحاجة إلى أي بيانات نقر. ويسجّل ترتيب الروابط الأكثر نقرًا نتيجة أعلى (38.1%)، لكنه يعتمد على سجلات النقر الخاصة بالموقع، وهي سجلات لا يملكها الوكيل.
توفير البيانات
في تشغيلات الانقطاع العشرين، أرسل QUIC العادي 4.7 ميغابايت حيث كانت الصفحات غير المضغوطة ستستهلك 25.2 ميغابايت، أي أقل بـ5.4 مرة. وعلى لقطة ويكيبيديا الكاملة المستخدمة في الاختبار، تُضغط صفحات حجمها 847 ميغابايت إلى 133 ميغابايت، أي توفير بمقدار 6.4 مرة على كل رابط، لا على الروابط البطيئة وحدها.
انتظار الصفحات أثناء الانقطاع
إجمالي الوقت الذي قضاه كل قارئ في انتظار الصفحات خلال التشغيل الذي يمتد دقيقتين، 20 قارئًا لكل إعداد. والصفحات التي فُتحت من الهاتف أثناء الانقطاع هي التي جلبتها شجرة مسبقًا أو حفظتها.
| الإعداد | متوسط الانتظار | الانتظار الوسيط | نقرات الانقطاع المفتوحة من الهاتف | المجلوب مسبقًا لكل تشغيل |
|---|---|---|---|---|
| TCP+TLS | 31.7 ثانية | 28.5 ثانية | 3 من 20 | – |
| QUIC | 21.6 ثانية | 17.0 ثانية | 3 من 22 | – |
| QUIC مع جلب مسبق ثابت | 20.1 ثانية | 12.6 ثانية | 5 من 23 | 0.24 ميغابايت |
| شجرة | 14.0 ثانية | 3.4 ثانية | 14 من 26 | 2.9 ميغابايت |
مقارنةً بـQUIC العادي، كانت شجرة أسرع لدى 8 من القرّاء العشرين ولم تكن أبطأ لدى أي منهم؛ أما الباقون فنقروا صفحة لم يُتنبأ بها، فانتظروا الشبكة مثل الجميع.
التنبؤ بالتفصيل
| المتنبئ | الأول | الثلاثة الأولى | يحتاج إلى |
|---|---|---|---|
| Jev | 6.2% | 16.1% | الصفحة وحدها |
| اختيار عشوائي بين الروابط الأربعين نفسها | 1.7% | 5.1% | لا شيء |
| ترتيب الروابط في الصفحة | 2.7% | 9.4% | لا شيء |
| الرابط الأكثر نقرًا في الشهر السابق | 19.2% | 38.1% | سجلات النقر الخاصة بالموقع |
نسبة نقرات يوليو الحقيقية على كل صفحة التي ذهبت إلى الروابط الأولى في ترتيب المتنبئ، في المتوسط على 1,002 صفحة. يرى Jev أول 40 رابطًا في محتوى الصفحة، وهي تحمل 66% من النقرات؛ أما خط أساس الرابط الأكثر نقرًا فيرتّب كل الروابط.
البيانات بالتفصيل
| غير مضغوطة | المرسَلة | التوفير | |
|---|---|---|---|
| لقطة ويكيبيديا، 2,147 صفحة | 847 ميغابايت | 133 ميغابايت | 6.4× |
| QUIC، 20 تشغيل انقطاع | 25.2 ميغابايت | 4.7 ميغابايت | 5.4× |
| شجرة، 20 تشغيل انقطاع، مع الجلب المسبق | 384 ميغابايت | 62.1 ميغابايت | 6.2× |
يتراوح التوفير لكل صفحة بين 2.7× و19×؛ ويصغر النصف الأوسط من الصفحات بين 5.1× و6.2×.
كلفة الجلب المسبق
أرسلت شجرة 2.9 ميغابايت من الصفحات المجلوبة مسبقًا في كل تشغيل، ولم يُفتح 99.2% منها قط: فمعظم التنبؤات تخطئ، ولا يُجدي الجلب المسبق إلا عندما يجعل الانقطاعُ إصابةً واحدة تستحق تلك البيانات. ولهذا لا يكون الجلب المسبق كثيفًا إلا عند توقّع انقطاع.
ما الذي حدث على نحو خاطئ في الطريق
- الدفع إلى رابط ميت. في التشغيلات الأولى استمر الجلب المسبق خلال الانقطاع. ثم أعاقت البيانات غير المؤكَّد استلامها تعافي QUIC، فانتظر بعض القرّاء أكثر مما مع QUIC العادي. والآن يتوقف الخادم قبيل الانقطاع المتوقع، ولا تتجاوز البيانات المجلوبة مسبقًا غير المؤكَّد استلامها 256 كيلوبايت.
- مؤقّت إعادة محاولة ظل يطول. بعد 45 ثانية من الصمت، كان QUIC ينتظر نحو 30 ثانية قبل أن يحاول من جديد. والآن يعيد الطرفان ضبط هذا المؤقّت فور أن يسمع كل منهما الآخر.
- صفحات لم تتطابق أبدًا. فاتت صفحات مجلوبة مسبقًا لأن العنوان نفسه كُتب بطريقتين. والآن يُوحَّد شكل العناوين في الطرفين.
09 · التحسينات
ما يمكننا تحسينه
- نفق QUICاتصال واحد يصمد أمام تغيّر عنوان IP.
- تمرير HTTPSتعبر المواقع الآمنة النفق وهي ما زالت مشفّرة.
- القمر الصناعي والخلوية معًاالإرسال عبر الرابطين واستخدام الأسرع منهما.
- انتقال مبكر تنبؤيالانتقال إلى شبكة أخرى قبل أن تنقطع الإشارة.
- مصادقة الوكيللا تستخدم وكيل العميل إلا الأجهزة المعتمدة.
- تنبؤ Jev بالروابطيرتّب الروابط التي يُرجَّح أن يفتحها المستخدم بعد ذلك.
- ذاكرة الصفحات المؤقتةتلبّي الطلبات المتكررة من دون إعادة جلبها.
- الطلبات المشروطة (ETag)تتحقق هل تغيّرت الصفحة من دون تنزيلها من جديد.
- Jev محلي عبر Layaيُبقي بيانات التصفح على خوادم نتحكم فيها.
- جلب مسبق يراعي البطاريةيجلب أقل عندما تنخفض البطارية.
- ضغط deflateتعبر الصفحات النفق أصغر بنحو 5.7 مرة.
- ضغط Brotliخوارزمية أقوى تصغّر الصفحات أكثر.
- النص أولًايُرسل نص الصفحة قبل صورها.
- حذف HTML وCSS غير اللازمَينيزيل شيفرة لا تحمل معلومات مفيدة.
- تصغير الصور والفيديويصغّر الصور ويخفض جودة الفيديو على الروابط البطيئة.
- بيئة اختبار بالمحاكاةتعيد إنشاء روابط الواي فاي و5G والانقطاعات والانتقالات.
- خادم مستضاف ذاتيًاتتحكم خدمات الطوارئ في بنيتها التحتية.
- أولوية المستجيبين (eMLPP)يخدم المستجيبين أولًا، كما تفعل شبكات GSM مع مكالمات الإنقاذ.
- مكالمات Opus صامدةتحوّل تصحيحُ الأخطاء فقدانَ الحزم إلى تشويش قصير.
- رسائل التخزين وإعادة التوجيهتصل الرسائل المرسلة أثناء الانقطاع عند عودة الاتصال.
10 · الاستخدام الفعلي
من النموذج الأولي إلى الميدان
المرحلة 1 · مُنجَزة
نموذج أولي في المختبر
بيئة الاختبار بالمحاكاة وعرض iPhone المقدَّمان هنا.
المرحلة 2
تسجيلات ميدانية
استخدام هوائي لتسجيل انقطاعات الإشارة الحقيقية في الميدان، ثم إعادة تشغيلها في شبكتنا المحاكاة.
المرحلة 3
خادم سحابي
إعداد خادم على AWS لاستضافة وكيل الخادم، حتى يعمل النفق عبر الإنترنت الحقيقي.
المرحلة 4
تطبيق سهل الاستخدام
بناء تطبيق سهل الاستخدام للحاسوب المحمول أو Android يُعدّ وكيل العميل للمستخدم.
من يمكنه استخدامها
بُنيت شجرة حول المستجيبين الأوائل، مثل فرق البحث والإنقاذ وطواقم الإسعاف العاملة في المناطق النائية، لكن المشكلة نفسها تصيب المستخدمين العاديين. فركّاب القطارات والحافلات، والسائقون المارّون بين الأبراج الخلوية، والمسافرون على اتصالات متقطعة، كلهم يفقدون صفحات ومكالمات عندما يغيّر الهاتف شبكته، فتستطيع شجرة أن تجعل التصفح العادي سلسًا أيضًا. أما لفرق الطوارئ، فسيُسجَّل كل جهاز بمستوى أولوية، ليعرف الخادم من يخدم أولًا عندما يشحّ عرض النطاق.
المخاطر والضمانات
لأن وكيل الخادم يتعامل مع حركة المستخدمين، يجب أن يكون موثوقًا، لذلك يعمل على بنية تحتية نتحكم فيها، بدءًا من AWS، وسيعمل Jev محليًا في نهاية المطاف. والمواقع الآمنة تمرّ بالفعل مشفّرة، فلا يستطيع الخادم قراءتها. وسيحتاج وكيل العميل أيضًا إلى مصادقة حتى لا تستخدمه إلا الأجهزة المعتمدة، وإذا تعذّر الوصول إلى الخادم فسيعود العميل إلى اتصال مباشر، فلا يكون المستخدمون أسوأ حالًا مما هم عليه من دون شجرة.
إرشادات لجودة الخدمة والتجربة
- اربط الجلسات بالمستخدم لا بالشبكة. ينبغي أن يستمر الاتصال دون تغيير عندما ينتقل الجهاز إلى شبكة جديدة.
- أبقِ الرابط غير الموثوق قصيرًا. ينبغي ألا تمرّ المصافحات وإعادات الإرسال إلا بين الجهاز وخادم قريب ومستقر.
- اجلب ما يهم ما دامت الإشارة جيدة. نزّل الخرائط والتعليمات وجهات الاتصال قبل أن تنقطع التغطية.
- امنح الحركة الحية الأولوية. ينبغي أن تتقدّم المكالمات الصوتية والرسائل العاجلة دائمًا على التنزيلات الكبيرة.
- طابِق المحتوى مع الاتصال. على الروابط البطيئة، أرسل صورًا أصغر واترك أجزاء الصفحة التي لا تضيف شيئًا.
- احكم على الجودة بما يشعر به المستخدمون. قِس زمن التوقف وزمن التعافي وجودة المكالمات، لا سرعة التنزيل وحدها.