GCP の静的 IP と VPN 速度：三つの変数、一つのテスト

アドレスを予約したあと転送は速くなり、結論はひとりでに書けた。ただし同じ変更がトンネルを UDP から TCP に切り替え、テストを別の夜に移し、おそらく別ゾーンの VM に着地させてもいる。外部アドレスの予約が直すのはライフサイクルの問題であり、再起動をまたいでエンドポイントを同じに保つ。パケットを加速する仕組みは持たないのだから、その実験の速度差は他の変数に属し、目の前の判断は次にどれを試すかである。

予約済みアドレスが実際に買うもの

Compute Engine は、インスタンスとともに割り当てられ解放される一時アドレスと、自分で予約して保持する静的アドレスを区別する。その違いは保持と課金についてのもので、パケットが通る経路についてではない。安定したエンドポイントは DNS レコード、リモートアクセスのプロファイル、パートナーの許可リスト、VM の再起動で変わってはならないファイアウォール規則にとって本当に有用である。

それらは予約する良い理由である。どれもスループットの理由ではない。

階層、アドレス、トランスポートを三つの変数として保つ

Google Cloud は Premium と Standard のネットワークサービス階層も販売しており、どちらも機能の可用性が異なる別々の経路でインターネットに出る。静的アドレス指定はどちらとも直交するので、静的と Premium は VM についての無関係な事実として扱い、同義語と考えないこと。実際の階層やリージョン、関与する相互接続やアタッチメントを記録すれば、アドレスのラベルが決してしない形で経路を説明できる。

三つの変数、三つの別々の実験、さもなければ結果は測定ではなく物語である。

一つの問いに答えるテストを設計する

承認済みの UDP と TCP のプロファイルを比較するあいだ、VM、アドレス、クライアントの場所、宛先、ワークロードを固定する。トランスポートごとのサーバーリスナーと、対応するファイアウォール規則の両方が必要である。クライアントのキーワードを書き換えてリスナーを変えなければ、あなたの忍耐だけが試される。

VM の CPU も見ておくこと、小さなインスタンスは暗号化や softirq の処理でネットワークよりはるかに早く飽和し、その上限はプロバイダーの制限とまったく同じに見えるからだ。

VM とクライアントの再送と損失のカウンターは経路の問題とトランスポートの問題を分けるが、進捗バーにはできない。iperf3 を使った実行可能な手順はトランスポートごとに十分ほどかかる。サーバーを遠い側で起動し、クライアントを各方向に三十秒動かし、各方向を三回繰り返す。各系列の最初の実行は捨て、そのうえで送信側と受信側の速度を、TCP の実行が印字する再送数とあわせて比べる。

UDP と TCP が機械的に違う理由

OpenVPN は UDP 上でデータグラムを運び、損失の扱いをアプリケーション自身のトランスポートに任せる。TCP 上ではトンネルの信頼できるストリームが、すでに信頼できるアプリケーションストリームの下に座るため、失われたセグメントが一つあるとその後ろがすべて止まり、外側の接続は独自の予定で再送する。この先頭詰まりの挙動は TCP を TCP の内側でトンネルする性質であり、プロバイダーの方針ではない。MTU と MSS の扱いも二つのモードで異なり、同じ経路での断片化の挙動を変える。

したがって速い TCP の試行が証明するのは、その日その経路で TCP が速かったということであり、それ以上一般的なことではない。

レビューに耐えるように結果を書く

擁護できる結論には形がある。このプロファイルが、このマシンサイズで、このネットワーク階層で、この測定済みのワークロードをこの方向にこの条件下で維持した、という形である。それより広い何かには一晩で供給できる以上の実行が要るので、遅い側の事例が説明されないままなら、どのプロバイダーの文書も記述しない制限をでっち上げるのではなく、パケットとリソースの証拠を添えた観察として残すこと。

アドレスの安定性と転送速度は同じ配備のどちらも重要になりうるし、有益な判断はそれぞれの変更でどちらを買っているかである。