فرض کړئ چې cURL يو نوی TCP اړيکه د ساده HTTP پروکسي سره پرانيزي، د HTTPS تونل جوړوي او يو ځواب ډاونلوډ کوي. دا وختونه هغه پړاوونه بيانوي چې cURL په دې لار کې ليدلي دي.

ارزښتهغه پړاو چې د لېږد له پيل څخه اندازه شوی
time_connectله پروکسي سره اړيکه بشپړه شوه
time_appconnectاړوند TLS لاس ورکول بشپړ شول
time_starttransferد ځواب لومړی بايټ ترلاسه شو
time_totalلېږد پای ته ورسېد

د يوې بېلګې POSIX-shell ثبت لپاره:

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 په کارولو سره هغه داخلي وخت-نښې نه ترلاسه کوي.

سمې لېږدونه پرتله کړئ. بياځلي لېږدونه د څو غوښتنو وختونه زياتوي، په داسې حال کې چې د اړيکې بيا کارول او څوچنده کول بدلوي چې کوم چمتووالی کار ته اړتيا ده. له دې شرطونو څخه مخکې يې ولیکئ چې د يو پروکسي عددونه له بل سره پرتله کوئ.

اړوندې مقالې