التكلفة المنسيّة لإعداد الاتصال

طلب إلى خادمك يستغرق ٦٠٠ مللي ثانية. خادمك يعالجه في ٥٠. الـ ٥٥٠ الأخرى موزّعة بين TLS و DNS و TCP، كلّها تحدث قبل أن يعمل كودك. معظم كتابات الأداء تعامل هذه ككلفة ثابتة. ليست. هذا حيث يعيش الوقت فعلاً، وأين تستردّ بعضه.

التفصيل#

طلب HTTPS بارد من هاتف على خلويّ إلى خادم في منطقة أخرى:

DNS resolution            ٧٠ مللي ثانية   (cache بارد)
TCP three-way handshake   ٨٠ مللي ثانية   (ذهاب وعودة واحد)
TLS 1.3 handshake        ١٨٠ مللي ثانية   (ذهاب وعودة واحد)
HTTP request              ٥ مللي ثانية
معالجة الخادم           يتفاوت
HTTP response             ٥ مللي ثانية
                       ────────
                      ≥٣٥٠ مللي ثانية قبل تبادل أيّ بيانات

ذلك الرقم لاتّصال صحّيّ في ظروف متوسّطة. الشبكات الخلويّة والريفيّة تضيف ١٠٠-٣٠٠ مللي ثانية ذهاب وعودة فوقها. قسنا ١٫٤ ثانية من overhead ما-قبل-البيانات على اتّصالات حقيقيّة من مصر إلى Frankfurt خلال ساعات الذروة.

النقطة هي أنّ «هذا التطبيق بطيء» المرئيّ للمستخدم غالباً ليس شيئاً فعله كود التطبيق بشكل خاطئ. هي كلفة قول مرحباً.

ما هو ثابت وما ليس#

ثلاث من الخطوات الأربع قابلة للتقليل.

DNS#

بحث DNS هو ذهاب وعودة أو اثنان إلى محلّل recursive. التخفيفات:

• سخّن DNS مسبقاً عند إطلاق التطبيق بإطلاق بحث hostname لنقطة نهاية API. البحث يحدث بالتوازي مع عمل الإقلاع الآخر؛ بحلول ضغط المستخدم على أيّ شيء، DNS مُخزَّن أصلاً.
• استخدم DNS مدعوم بـ CDN (Cloudflare، Route 53) لديه POPs قريبة من المستخدم. القرب الجغرافيّ يهيمن على زمن استجابة DNS.
• رمّز سجلّات A بشكل صلب لنقاط النهاية الثابتة في التطبيق، مع fallback TTL معقول. يلغي DNS بالكامل لمضيف API.

نستخدم الأوّلَين. لا نستخدم الثالث لأنّنا نريد القدرة على تغيير DNS بدون تحديث تطبيق.

TCP#

TCP three-way handshake هو ذهاب وعودة واحد ولا يمكن تجنّبه على اتّصال بارد. التخفيفات:

• HTTP/2 على اتّصال طويل العمر. TCP handshake واحد عند الإقلاع، ثمّ كلّ طلب يُعيد استخدام نفس الاتّصال. يوفّر الـ handshake على كلّ طلب لاحق.
• HTTP/3 / QUIC. TCP-و-TLS-في-واحد على UDP. الطلب الأوّل تقريباً بنفس كلفة HTTP/2؛ الطلبات اللاحقة بعد تغيير شبكة (handover خلويّ) تُعيد الاتّصال أسرع لأنّ QUIC لا يحتاج إعادة handshake.

نستخدم HTTP/2 مع connection pool. HTTP/3 في قائمتنا لكنّ الـ proxy أمام API لا يدعمه بنظافة بعد.

TLS#

TLS 1.3 ذهاب وعودة واحد. TLS 1.2 كان اثنَين. تأكّد أنّك على 1.3 من طرف لطرف. التحرّكات الأخرى:

• استئناف الجلسة. جهاز اتّصل من قبل يستطيع إعادة استخدام تذكرة الجلسة وتخطّي الـ handshake. يوفّر ~١٥٠ مللي ثانية على إعادات الاتّصال.
• 0-RTT (ميزة TLS 1.3). بيانات الطلب الأوّل تخرج مع الـ handshake المُستأنَف، بدون ذهاب وعودة إضافيّ. لها تحفّظات أمنيّة (هجمات replay)؛ آمنة فقط للطلبات idempotent. نستخدمها للقراءات، لا الكتابات.

استئناف الجلسة مُفعَّل افتراضيّاً في الـ stacks الحديثة. 0-RTT opt-in على معظم reverse proxies؛ افحص خاصّتك.

أين تستردّ الوقت#

بترتيب تقريبيّ لكم استرددنا لكلّ ساعة عمل:

Connection pooling (أكبر فوز)#

HttpClient Dart الافتراضيّ و HttpURLConnection Java يُبقيان الاتّصالات مفتوحة. غلاف HTTP الساذج لدينا كان يُنشئ client جديد لكلّ طلب. إعادة استخدام client واحد عبر التطبيق وفّر ذهاب وعودة TCP+TLS كاملاً على كلّ طلب بعد الأوّل. متوسّط زمن الطلب انخفض ٢٠٠ مللي ثانية.

// قبل
Future<Response> get(String url) async {
  final client = HttpClient();
  // ... استخدم client
  client.close();
}

// بعد
class Api {
  static final _client = HttpClient(); // مشترك، عمر التطبيق
  Future<Response> get(String url) async {
    // ... استخدم _client
  }
}

Pre-connect عند إقلاع التطبيق#

حين يبدأ التطبيق، نُصدِر طلب HEAD إلى جذر API. لا ينقل بيانات، لكن يُسخِّن DNS، يفتح اتّصال TCP، ويُكمل TLS handshake. بحلول قيام المستخدم بأيّ شيء حقيقيّ، الاتّصال جاهز.

Future<void> warmConnection() async {
  try {
    await _client.head(Uri.parse('https://api.aliyosef.online/health'));
  } catch (_) {
    // أفضل جهد. الشبكة قد تكون معطّلة. لا تحجب الإقلاع.
  }
}

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

انتقل إلى منطقة أقرب#

إن كان مستخدموك في منطقة جغرافيّة واحدة وخادمك في أخرى، لا يوجد قدر من تعديل البروتوكول سينقذك من سرعة الضوء. نقلنا API لدينا من EU-West إلى ME-Central لمستخدمينا السعوديّين والسوريّين. زمن استجابة الذهاب والعودة انخفض من ٢٢٠ مللي ثانية إلى ٣٠ مللي ثانية. تلك الحركة الواحدة وفّرت وقتاً أكثر من كلّ تحسين آخر مجتمعاً.

اضغط كلّ شيء#

Gzip على الردود رهان طاولة. Brotli أفضل لكنّه ليس مدعوماً عالميّاً. كلاهما يقلّل بايتات السلك، ممّا يقلّل كلفة multi-RTT على الروابط البطيئة. اضبط Accept-Encoding: gzip, br على العميل واضبط الخادم لضغط الردود فوق ~١ KB.

لا تقم بإعداد الاتّصال على المسار الحرج#

الإصلاح الأذكى هو عدم إجراء الذهاب والعودة في المقام الأوّل، وهي النقطة الكاملة لـ التصميم offline-first. الطلب الأوّل بعد الإقلاع يمكن الإجابة عليه من cache محلّيّ؛ الشبكة تُستخدم فقط لتحديث الـ cache، في الخلفيّة.

ما لم نفعله عمداً#

ثلاثة تحسينات اعتبرناها ورفضناها.

TCP Fast Open#

يوفّر ذهاب وعودة على TCP handshake لكنّه مدعوم بشكل سيّئ، خاصّة في middleboxes (proxies الشركات، بوّابات شركات الجوّال). صافٍ سلبيّ لقاعدة مستخدمينا؛ قد يكون لديك ملفّ مختلف.

Multiplexing عبر خدمات صغيرة كثيرة#

نشر الـ API عبر hostnames كثيرة يعني عمليّات DNS كثيرة، TLS handshakes كثيرة، اتّصالات TCP كثيرة. وحّدنا إلى hostname واحد خلف reverse proxy ووجّهنا حسب المسار. يوفّر على كلّ اتّصال بارد.

دفع HTTP/2 خادم عدوانيّ#

دفع الخادم له وعد على الورق لكن نادراً ما يجعل الأمور أسرع عملياً. إشارات preload للمتصفّح/العميل أسهل في الاستخدام وأفضل ضبطاً. لا نستخدم دفع الخادم.

ما نقيس#

رقمان محدّدان:

Time-to-first-byte (TTFB)، مفصّل#

كلّ نداء API يسجّل DNS، TCP-connect، TLS، request-write، server-wait، response-read. التفصيل يهمّ: إن كان DNS أكبر قطعة، الإصلاح مختلف عن «TLS أكبر قطعة». TTFB المُجمَّع يخفي أيّ جزء للتحسين.

معدّل إعادة استخدام الاتّصال#

من كلّ طلباتنا، ما النسبة المئويّة التي تُجرى على اتّصال كان مفتوحاً أصلاً؟ يجب أن تكون > ٩٥٪ في الحالة المستقرّة. إن انخفض، شيء يقتل الاتّصالات (timeouts proxy، حدود الخادم، سوء استخدام العميل).

الخلاصة المملّة#

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

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