Å lese cURLs proxytider fra klientens side

Tenk deg at cURL åpner en ny TCP-forbindelse til en vanlig HTTP-proxy, setter opp en HTTPS-tunnel og laster ned ett svar. Tidene beskriver milepælene cURL observerte på denne veien.

For en illustrerende opptak i et POSIX-skal:

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/

For en tillatt offentlig HTTPS-sammenligning uten proxy-legitimasjon kan en HTTP-oppføring fra listen over HTTP-proxyer erstatte eksempelproxyen. Verdiene er summerte sekunder. De er ikke fire uavhengige varigheter som skal legges sammen. Hold overføringsfeilen og svarstatusen ved siden av tallene: en mislykket forbindelse eller en avvist tunnel nådde ikke hver senere milepæl.

Hva subtraksjon kan fortelle

For ett vellykket svar beskriver time_total minus time_starttransfer intervallet som gjenstår etter at den første byten kom. Det er hovedsakelig den senere svaroverføringen og tilhørende arbeid på klientsiden. Det er ikke proxyens tid til å koble seg til nettstedet, for det skjedde før svaret kunne komme.

På samme måte kan time_starttransfer minus time_connect omfatte tunneletablering, TLS, venting i overliggende nett, serverarbeid og annen behandling. Å kalle hele forskjellen «proxylatens» tilordner flere komponenter til én deltaker.

For å skille proxyens venting på DNS, forbindelse og svar, skaff tilsvarende observasjoner eller spor fra proxysiden. Klienten mottar ikke disse interne tidsstemplene bare ved å bruke HTTP CONNECT.

Sammenlign likeverdige overføringer. Omdirigeringer legger til tider fra flere forespørsler, mens gjenbruk av forbindelser og multipleksing endrer hvilket forberedelsesarbeid som trengs. Noter disse forholdene før du sammenligner tallene til én proxy med en annens.