클라이언트 쪽에서 cURL 프록시 타이밍 읽기

연결, TLS, 첫 바이트, 전체 시간을 해석하되 관측되지 않은 상위 작업을 프록시 단독 측정으로 돌리지 마세요.

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를 쓴다고 해서 그 내부 타임스탬프를 받는 것이 아닙니다.

같은 조건의 전송끼리 비교하세요. 리디렉션은 여러 요청의 시간을 더하고, 연결 재사용과 다중화는 필요한 준비 작업을 바꿉니다. 한 프록시의 숫자를 다른 프록시와 비교하기 전에 이런 조건을 기록해 두세요.

관련 글