मानौं 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 प्रयोग गर्नु मात्रले ती आन्तरिक समय-चिह्नहरू पाउँदैन।

समान स्थानान्तरणहरूको तुलना गर्नुहोस्। पुनर्निर्देशनले धेरै अनुरोधका समय थप्छ, जबकि जडान पुनःप्रयोग र मल्टिप्लेक्सिङले कुन तयारीको काम चाहिन्छ भन्ने बदल्छ। एउटा प्रोक्सीका संख्यालाई अर्कोसँग तुलना गर्नुअघि ती सर्तहरू लेख्नुहोस्।

सम्बन्धित लेखहरू