قراءة توقيتات وكيل cURL من جهة العميل
فسّر توقيتات الاتصال وTLS والبايت الأول والإجمالي دون إسناد عمل علوي غير مرصود إلى قياس خاص بالوكيل وحده.
لنفترض أن cURL يفتح اتصال TCP جديدًا بوكيل HTTP عادي، ويُنشئ نفقًا لـHTTPS، ثم ينزّل استجابة واحدة. تصف هذه التوقيتات محطات رصدها cURL على ذلك المسار.
| القيمة | المحطة المقيسة من بداية النقل |
|---|---|
| time_connect | اكتمل الاتصال بالوكيل |
| time_appconnect | اكتملت مصافحة TLS المعنية |
| time_starttransfer | وصل أول بايت من الاستجابة |
| time_total | انتهى النقل |
لتوضيح عملية التقاط في صدفة POSIX:
curl --proxy http://proxy.example:8080 \
--output /dev/null \
--write-out 'connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/لإجراء مقارنة HTTPS عامة مسموح بها دون بيانات اعتماد للوكيل، يمكن أن يحل مدخل HTTP من قائمة وكلاء HTTP محل الوكيل المذكور في المثال. القيم بالثواني التراكمية. وهي ليست أربع مدد مستقلة تُجمع معًا. أبقِ خطأ النقل وحالة الاستجابة إلى جانب الأرقام: الاتصال الفاشل أو النفق المرفوض لم يصل إلى كل محطة لاحقة.
ماذا يخبرك الطرح
بالنسبة إلى استجابة واحدة ناجحة، يصف time_total ناقص time_starttransfer الفترة المتبقية بعد وصول أول بايت. وهي في الأساس نقل الاستجابة المتأخر وما يرتبط به من عمل على جهة العميل. وليست زمن اتصال الوكيل بالموقع، لأن ذلك حدث قبل أن تصل الاستجابة.
وعلى المنوال نفسه، قد يشمل time_starttransfer ناقص time_connect إنشاء النفق وTLS وانتظارات الشبكة العلوية وعمل الخادم ومعالجة أخرى. وتسمية الفرق كله «زمن استجابة الوكيل» تنسب مكوّنات متعددة إلى طرف واحد.
ولفصل انتظارات DNS والاتصال والاستجابة على جهة الوكيل، احصل على أرصاد أو آثار مقابلة من جانب الوكيل. فالعميل لا يتلقى تلك الطوابع الزمنية الداخلية بمجرد استخدام HTTP CONNECT.
قارن عمليات نقل مكافئة. فإعادة التوجيه تضيف توقيتات طلبات متعددة، بينما تغيّر إعادة استخدام الاتصال والتعددية أعمال التهيئة اللازمة. وسجّل تلك الظروف قبل مقارنة أرقام وكيل بأرقام وكيل آخر.