温まったHTTPSと温まったVPN:同じリクエスト経路で比較する
HTTPS は API リクエストのたびにハンドシェイクするわけではないため、温まった接続と温まったトンネルは競合しません。選ぶ前に同じリクエストパターンで比較してください。
HTTPS は API リクエストのたびに新しい TCP 接続と新しい TLS ハンドシェイクを開くので、一時間つなぎっぱなしのトンネルのほうが安く見える、という説明を読んだことがあるでしょう。その前半はたいてい誤りです。サポートされたクライアントは確立済みの接続を多くのやり取りで再利用し、呼び出しごとに新しいクライアントを作る計測は保護ではなくライフサイクルを測っています。このページの残りは、代わりに何を測るべきかを説明します。
再利用が実際に必要とするもの
持続性は HTTP モデルの一部であり、小細工ではありません: 一本の接続が複数のリクエストとレスポンスのやり取りを運びます。接続は、どちらかの側が閉じたとき、サーバーが idle または過負荷の接続を引退させたとき、あるいはヘッダーやプロトコルの規則が再利用できないと定めているときに終わります。HTTPS はその会話を TLS の内側に置きますが、やり取りのたびに新しいハンドシェイクを要求しません。したがって 二回目のリクエストは、途中で何かが接続を終わらせない限り、一回目のハンドシェイクを繰り返しません。
再利用には、アプリケーションが壊しやすい条件がもう一つあります。接続を再利用するつもりのクライアントはレスポンス本文を最後まで読む必要があり、途中で捨てられたレスポンスは、誰も気づかないうちに接続プールが消える通常の原因です。
プールが有効か無効かを決めつけず、ライブラリがサポートするクライアントと接続プールのライフサイクルを確認してください。ネゴシエートされた HTTP バージョンも記録してください、HTTP/2 と HTTP/3 は HTTP/1.1 とは違う形で接続の再利用を扱うからです。ネゴシエートされたバージョンは脚注ではなく計測の一部として扱ってください。
比較がライフサイクルを測る理由
操作ごとに新しいクライアントを作り、一時間つながっているトンネルと比べるのは、接続の確立と定常状態を比べていることになります。それは妥当な計測ですが、HTTPS 対 VPN ではありません。同じクライアント設定での二回の実行は一回より挙動をよく表します、特に一回目がリゾルバーや接続キャッシュを温める場合がそうです。
API 操作、サーバー、アカウント、データを一定に保ってください、そうでなければ比較は複数の変数を抱えます。タイマーをどこに置くかを前もって決めてください、確立、TLS のネゴシエーション、アプリケーションの実行、レスポンスの配送は合計への寄与が異なるからです。最初のリクエストのタイマー一つでは確立を特徴づけるだけで、実際に流している定常トラフィックについては何も語りません。タイマーの境界は数字の隣に書き留めてください。
冷たい確立と温まったリクエストを分ける
最初のリクエストは、それに続くリクエストとは別に測ってください、そのうえでサービスが実際に見るものを加えます。idle の期間、バースト、同時実行、レスポンスの大きさ、再接続です。
両方の経路で証明書の検証と HTTPS を有効にしたままにしてください、それらを外すのは、より速い設計ではなく別のセキュリティ設計を測ることになります。トンネルが経路やゲートウェイの位置を変えるなら、時間の変化をすべて暗号化に帰さず、その違いを別に報告してください、経路、損失、待ち行列が小さなリクエストを支配することがあるからです。結論を出す前に、同じ経路で各経路を二回実行してください。ネゴシエートされたプロトコルとタイマーの境界は両方の実行とともに記録してください。
閉じる接続に備える
持続は永久ではありません。サーバー、プロキシ、ネットワークの変化は idle の期間に接続を閉じることがあり、クライアントはライブラリがサポートする挙動で回復しなければなりません。その回復には状態機械があります: リクエストはサーバーで完了したのか、サーバーが読む前に失敗したのかは分からず、閉じたソケットは呼び出し側にどちらが起きたかを伝えません。その位置での非 idempotent な操作は単純に再生できません、再生は未知の結果を二重の書き込みに変えるからです。ここで温まったトンネルと温まった接続は同じように振る舞います、どちらも作業が進行中の瞬間に失敗しうるからです。
ソケットを開き直すループではなく、サービスが文書化している再試行や idempotency の仕組みを使ってください。回復は明示的に試してください: idle の接続を閉じて、次にクライアントが何をするかを観察します。ソケットを開き直しても、状態を変える呼び出しの繰り返しは安全になりません。
まず境界を選び、それから調整する
何かを最適化する前に、アクセスと信頼の要件からネットワーク境界を選んでください。VPN は自分のピア間の区間を守りますが、アプリケーションのエンドポイントやトンネルの外の平文の区間は依然として重要です。そのうえで、その境界の内側で接続のライフサイクルを調整してください。安いトンネルという結論は、どのリクエストもハンドシェイクを繰り返すという信念からしか出てきません: ここで試されているのはその信念です。
RFC 9112 の持続性の節は、接続を終わらせる条件を含め、再利用が実際に何を約束するかの参照先です。それらを無視する計測を信じる前に一度読んでください。