فرض کریں کہ cURL ایک سادہ HTTP پراکسی سے نیا TCP کنکشن کھولتا ہے، 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 استعمال کرنے سے وہ داخلی وقت کے نشانات نہیں پاتا۔

مساوی منتقلیوں کا موازنہ کریں۔ ری ڈائریکٹ متعدد درخواستوں کے اوقات شامل کرتے ہیں، جبکہ کنکشن کا دوبارہ استعمال اور ملٹی پلیکسنگ بدلتے ہیں کہ کون سا تیاری کا کام درکار ہے۔ ایک پراکسی کے اعداد کا دوسری سے موازنہ کرنے سے پہلے وہ شرائط لکھ لیں۔

متعلقہ مضامین