Ler os tempos do proxy do cURL pelo lado do cliente
Interprete os tempos de conexão, TLS, primeiro byte e total sem atribuir trabalho a montante não observado a uma medição apenas do proxy.
Suponha que o cURL abre uma nova conexão TCP com um proxy HTTP simples, estabelece um túnel HTTPS e baixa uma resposta. Os tempos descrevem marcos que o cURL observou nesse caminho.
| Valor | Marco medido desde o início da transferência |
|---|---|
| time_connect | A conexão com o proxy foi concluída |
| time_appconnect | O handshake TLS correspondente foi concluído |
| time_starttransfer | O primeiro byte da resposta foi recebido |
| time_total | A transferência terminou |
Para uma captura ilustrativa em shell 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/Para uma comparação HTTPS pública permitida sem credenciais de proxy, uma entrada HTTP da lista de proxies HTTP pode substituir o proxy do exemplo. Os valores são segundos acumulados. Não são quatro durações independentes que se somam. Mantenha o erro de transferência e o status da resposta ao lado dos números: uma conexão que falhou ou um túnel recusado não chegou a cada marco posterior.
O que a subtração pode dizer
Para uma única resposta bem-sucedida, time_total menos time_starttransfer descreve o intervalo restante depois que o primeiro byte chegou. Isso é sobretudo a transferência posterior da resposta e o trabalho associado no lado do cliente. Não é o tempo do proxy para se conectar ao site, porque isso ocorreu antes de a resposta poder chegar.
Da mesma forma, time_starttransfer menos time_connect pode incluir a criação do túnel, TLS, esperas da rede a montante, trabalho do servidor e outro processamento. Chamar toda a diferença de "latência do proxy" atribui vários componentes a um único participante.
Para separar as esperas do proxy em DNS, conexão e resposta, obtenha observações ou rastreamentos correspondentes do lado do proxy. O cliente não recebe esses carimbos de tempo internos apenas por usar HTTP CONNECT.
Compare transferências equivalentes. Redirecionamentos acrescentam tempos de várias requisições, enquanto a reutilização de conexões e a multiplexação mudam o trabalho de preparação necessário. Registre essas condições antes de comparar os números de um proxy com os de outro.