VPN経由のダウンロードが直接接続を上回ることがある理由
トンネルを通ると速くなる転送は、たいてい一つのポートに掛かった制限を指している。三つの統制された比較が、速度整形装置と本当の高速化を切り分ける。
トンネルを接続して大きなダウンロードを始めると、同じファイルをトンネルなしで落としたときのおよそ二倍の速さで進む。宣伝文句のように聞こえるが、家庭回線での本物の計測であることもある。よくある原因は、ひとつのポートに紐づいた速度制限だ。トンネルは転送を整形装置が見ていない場所へ運び、回線の本当の容量が初めて表に出る。
つまり重要な数字は、VPNがどれだけ速かったかではない。あなたがずっと受け取れていなかった回線の取り分と、その理由なのだ。
経路ではなくポートに従う制限
アクセス事業者は、プロトコルや宛先ポートごとに加入者あたりのスループットを制限できる。ポート80が好んで狙われるのは、日常の閲覧の多くがそこを使うからだ。制限は最初のパケットから適用されないことが多い。転送は回線速度の近くで始まり、バースト枠を使い切り、それから制限値に落ち着く。最初の数秒は健全に見え、残りの転送はそうではない。
同じバイトを別のポートから送れば、80番の整形装置はそれらを一度も見ない。トンネルはホップと暗号化と自前のオーバーヘッドを足したのに、直接接続に勝ったように見える。改善したのは経路ではなく、規則が存在しないことだ。
ファイルや宛先を変えても効果がこれほど一貫しているのも同じ理由だ。制限がポート側にあるなら、そのポートで運ばれるものはすべて同じ振る舞いをする。ファイルの大きさが何であれ、相手が誰であれ変わらない。別の規則を引き寄せる宛先は別の曲線を示し、その差自体が診断になる。
山頂ではなく平坦部を測る
山頂は転送で最も情報の少ない部分だ。バッファが埋まっている間は、どの接続も良く見える。速度がどこで落ち着き、そこにどれだけ留まるかを記録しよう。
curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/
同じ機械で、同じ時刻に、比べられるネットワークの相手に対して、二つの方法を続けて実行する。一度のサンプルでは何も証明できない。それぞれ二回ずつの曲線の形こそが、バースト枠と安定した上限を分ける。最初の一秒が示した値ではなく、速度が平らになる位置を書き留めよう。バーストはまさに整形装置が制限を始める前に与えるものだからだ。転送の最後まで保たれる静かな平坦部が、比較すべき数字になる。
ファイルはあらかじめ圧縮しておき、輸送時の圧縮を説明に持ち出せないようにする。PDFやアーカイブならその変数が消え、トンネルが中身を縮めたという主張もできなくなる。両方の転送が同じファイルを使うなら、残る違いは経路とポートだけだ。各数値のそばに道具とポートを書き添えよう。そうしなければ二回目は一回目と比べられない。
原因を切り分ける三つの比較
順番に試し、模様が見えたらそこで止める。それぞれが別の説明を排除するからだ。
- 同じダウンロードを、通常のウェブ経路と、別のポートの転送道具の両方で、同程度の能力の相手から繰り返す。
- 圧縮できないファイルで両方を繰り返し、圧縮の可能性を消す。
- トンネルのサーバーを自分で動かしているなら、80番ポートに結び直し、両端が一致するようクライアントの設定を直し、もう一度転送する。トンネルが制限されたウェブの速度に収まるなら、制限はVPNではなくポートに従っている。
三つ目の手順が決定的で、しかも設定変更が要るために飛ばされやすい。これがなければ、二つのことが違うと示しただけで、ポートが原因だとは示せていない。
この計測が支えられないこと
トンネルが一般に速いこと、何かを圧縮していること、回線の他のポートが制限なしであることは示さない。示すのはこの転送について、この回線で、この時刻の話だ。制限はセッション単位、加入者単位、時間帯単位で適用され得るし、予告なく変わることもある。
直接経路が壊れていることも証明しない。制限された経路も動いており、意図的に制限されている。意図された方針は修理を待つ故障ではない。
そしてすべてをトンネルに流すことを正当化はしない。80番のアプリは制限されたままで、迂回させたものは余分なホップと余分な故障のしかたに依存するようになる。
発見を実行できる形にする
観測は判定ではなく計測として書く。80番ポートの大きな転送は、同じファイルが別のポートで出る速度のおよそ半分で落ち着く。この時間帯、この回線で、このサンプルを添えて、と書けばよい。それなら誰かが調べられるサポート依頼になる。
「VPNのほうが速い」では、そうならない。暗号化のオーバーヘッドについての返信を招くだけで、その返信は技術的には正しくても誰の役にも立たない。サンプル数と時刻とポートを添えて、読み手が同じ模様を再現できるようにしよう。
大容量の転送に別のポートを使い続けるなら、自分の記録に但し書きを残しておく。待ち受けを80番へ移すと、そこにすでに結びついているウェブサーバーと衝突し、その故障はポートの競合ではなく壊れたトンネルのように見える。