ਮੰਨ ਲਓ 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 ਵਰਤਣ ਨਾਲ ਉਹ ਅੰਦਰੂਨੀ ਸਮਾਂ-ਨਿਸ਼ਾਨ ਨਹੀਂ ਮਿਲਦੇ।

ਸਮਾਨ ਤਬਦੀਲੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਰੀਡਾਇਰੈਕਟ ਕਈ ਬੇਨਤੀਆਂ ਦੇ ਸਮੇਂ ਜੋੜਦੇ ਹਨ, ਜਦਕਿ ਕਨੈਕਸ਼ਨ ਦਾ ਮੁੜ-ਵਰਤੋਂ ਅਤੇ ਮਲਟੀਪਲੈਕਸਿੰਗ ਬਦਲਦੇ ਹਨ ਕਿ ਕਿਹੜਾ ਤਿਆਰੀ ਦਾ ਕੰਮ ਲੋੜੀਂਦਾ ਹੈ। ਇੱਕ ਪ੍ਰੌਕਸੀ ਦੀਆਂ ਸੰਖਿਆਵਾਂ ਦੀ ਦੂਜੀ ਨਾਲ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸ਼ਰਤਾਂ ਲਿਖੋ।

ਸੰਬੰਧਿਤ ਲੇਖ