cURL のプロキシ計測値をクライアント側から読む
接続・TLS・最初のバイト・合計の各タイミングを、観測できない上流の処理をプロキシだけの測定に帰さずに解釈します。
cURL が平文の HTTP プロキシへ新しい TCP 接続を開き、HTTPS トンネルを確立して 1 件の応答を取得するとします。各タイミングは、その経路上で 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 エントリを例のプロキシの代わりに使えます。値は累積の秒数です。足し合わせる 4 つの独立した所要時間ではありません。転送エラーと応答ステータスを数値と並べて残してください。接続に失敗した場合やトンネルが拒否された場合は、その後のマイルストーンに到達していません。
引き算でわかること
1 件の成功した応答では、time_total から time_starttransfer を引いた値が、最初のバイトが届いた後に残った区間を表します。これは主に後半の応答転送と、それに伴うクライアント側の処理です。プロキシがウェブサイトへ接続する時間ではありません。それは応答が届く前に起きているからです。
同様に、time_starttransfer から time_connect を引いた値には、トンネル構築、TLS、上流ネットワークの待ち、サーバーの処理などが含まれ得ます。その差の全体を「プロキシの遅延」と呼ぶと、複数の要素を 1 者の責任に押しつけることになります。
プロキシ側の上流 DNS・接続・応答の待ちを分離するには、プロキシ側の対応する観測やトレースを入手してください。クライアントは HTTP CONNECT を使うだけでは、そうした内部のタイムスタンプを受け取りません。
比較するときは同等の転送どうしを選びます。リダイレクトは複数リクエストの時間を加え、接続の再利用や多重化は必要な準備処理を変えます。あるプロキシの数値を別のプロキシと比べる前に、これらの条件を記録してください。