فرض کنید 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 به‌تنهایی آن برچسب‌های زمانی درونی را دریافت نمی‌کند.

انتقال‌های هم‌ارز را با هم مقایسه کنید. تغییرمسیرها زمان چند درخواست را می‌افزایند، در حالی که استفاده دوباره از اتصال و چندگانه‌سازی تغییر می‌دهند که چه کار آماده‌سازی لازم است. پیش از مقایسه اعداد یک پراکسی با پراکسی دیگر، این شرایط را ثبت کنید.

مقالات مرتبط