プロキシの利用上限

事業者が制限できるもの

一定期間に消費する資源を定める上限もあれば、ある時点の負荷を抑えたり、接続そのものを許可するか決めたりする制限もあります。プランがこのうち1つか2つしか宣伝していない場合でも、次の違いを押さえておくと役立ちます。

事業者はこうした規則でネットワーク容量と処理資源を配分し、コストを管理して、望ましくない活動を制限します。効果はそれぞれ異なります。接続数の上限を引き上げれば同時に使える接続が増え、ブロック対象へのアクセスを許可すれば実行できる作業の種類が変わります。ある条件を変えても、ほかの条件が自動的に変わるわけではありません。

同時接続

同時接続数の上限は、一度に開いたままにできる接続数を定めます。ブラウザーなどのアプリケーションは、1つの作業で複数の接続を開くことがあります。そのため、タブ、ブラウザープロファイル、プログラムのスレッドの数だけでは、接続枠をどれだけ使っているか正確には分かりません。

リクエストの合間にも接続は開いたままになり得ます。また、HTTP/2は1つの接続で複数のリクエストを運べます。1分あたりのリクエスト数を減らしても、使用中の接続が解放されるとは限りません。同時接続の記事では、何が接続枠を使うのか、なぜリクエスト数とは異なるのかを説明します。

上限同士が影響し合うこともあります。大きなレスポンスの転送に時間がかかると、その接続の占有時間が長くなる場合があります。プログラムが新しい処理を起動し続けると、リクエスト頻度が同じでも接続数の上限に達することがあります。その時点で並列処理を増やしても、完了する処理量は増えず、待ち時間や失敗だけが増える可能性があります。

ブロックされたウェブサイトとアプリ

事業者は、特定のウェブサイト、アドレス、操作へのアクセスを制限できます。通信量が無制限で接続枠に空きがあっても、接続先がブロックリストに載っている場合があります。同じ事業者でも製品によってアクセス権限が異なることがあります。ブロックされたウェブサイトとアプリの記事では、こうしたリストが作られる理由と、特定のリソースへのアクセスを決める条件を説明します。

アプリケーションが複数の接続先を使う場合、メインページは開いても、別の機能が動かないことがあります。プロキシ事業者がアクセスを許可していても、接続先サイトが独自に制限することもあります。失敗の原因を知るには、まず利用できないリソースと、どちら側がリクエストを拒否したかを特定してください。

ブロックされたポート

ウェブサイトにアクセスできても、同じサーバー上のすべてのネットワークサービスを使えるとは限りません。事業者はウェブ通信を許可しながら、メール送信用ポートをブロックすることがあります。ここで重要なのは、アプリケーションが要求する接続先ポートです。ブロックされたポートの記事では、プロキシ自体に接続するためのポートとの違いを説明します。

必要なトランスポートへの対応も、アクセス条件の一部です。TCPとUDPは異なるデータ転送方式であり、ある番号のTCPポートにアクセスできても、同じ番号のUDPポートにアクセスできるとは限りません。製品が必要なトランスポートに対応し、利用を許可している必要があります。IP数や接続枠を増やしても、不足しているアクセス権限は得られません。

データ量、転送速度、リクエスト数

通信量

通信量は、事業者や製品により無制限の場合も、データ枠付きの場合もあります。月ごとにギガバイト単位のパッケージなど、一定量のデータを販売する事業者もあります。その場合は、有効期間、枠がリセットされる時期、未使用データの繰り越し可否を確認してください。これらはデータ枠のある製品に適用される計上規則であり、あらゆるプロキシアクセスに共通する条件ではありません。

保存した結果の大きさだけでは、通信量を正確に見積もれません。短い価格や商品名を抽出するにも、ページ全体のダウンロードが必要なことがあります。ブラウザーは画像、スクリプトなどのファイルも要求します。再試行すれば同じデータを再転送する場合もあります。実際のアプリケーションで測定すると、ネットワーク負荷を見積もりやすくなります。通信量課金の製品なら、事業者がどの転送バイトを計上するかも確認してください。

転送速度

転送速度の上限は、単位時間に通過できるデータ量を制限します。通常はMbpsなどの1秒あたりのビット数、またはMB/sなどの1秒あたりのバイト数で表します。1バイトは8ビットなので、プロトコルのオーバーヘッドを除けば、80 Mbpsは10 MB/sに相当します。これらは速度の単位であり、GBで表す月間枠とは別の量です。

宣伝される速度の適用範囲が重要です。サーバーのポートに一定の速度が表示されていても、すべての利用者や接続にその速度が割り当てられるとは限りません。複数の転送が同じ枠を共有することもあります。実際の速度は経路、接続先サーバー、クライアント自身の回線にも左右されるため、事業者の公表上限は、すべてのダウンロードで達成できる速度を保証するものではありません。

転送速度だけでなく、応答時間も重要です。バイトを転送する容量に余裕があっても、小さなレスポンスを送り始めるまでサーバーがアプリケーションを待たせることがあります。大きなダウンロードでは持続的な転送速度の影響が大きく、多数の短いリクエストでは、応答の遅れや許可されるリクエスト頻度の影響が大きい場合があります。

リクエスト枠とリクエスト頻度

リクエスト枠は、計上対象の操作が何回含まれるかを示します。リクエスト頻度の上限は、それらをどれだけ短い間隔で送れるかを示します。残り枠が多くても、それを短時間にまとめて使えるとは限りません。この2つの上限は、通信量課金ではない製品も含め、独立して存在できます。

何を1回の操作として数えるかも、明確な定義が必要です。クリック、ページ訪問、HTTPリクエスト、完了したスクレイピング作業は別々の出来事です。1回のページ訪問で多数のHTTPリクエストが発生することも、1つのマネージドAPIタスクで事業者が複数回試行することもあります。その試行が利用者の枠を消費するかどうかは、製品の計上規則次第です。

頻度の上限には、時間枠と短時間の集中送信に関する規則もあります。1分あたりの上限を60で割ると平均は出ますが、一括送信された処理をサービスがどう扱うかは分かりません。許可された処理を時間的に分散すれば、総量を変えずに頻度の上限内に収められることがあります。ただし、すでに使ったリクエスト枠が回復するわけではありません。

どのアカウント、IP、製品が上限を共有するか

数値は、それを何が共有するか分かって初めて役立ちます。事業者は、アカウント、注文、個々のプロキシIP、認可されたクライアントIPなど、定義した単位に上限を適用できます。たとえば、アカウント全体の転送速度枠は、そのアカウントを使うプログラム間で共有されます。各プログラムに異なる出口IPを与えても、それぞれに独立した枠が生まれるわけではありません。

複数の階層に上限がある場合もあります。サービスがプロキシIPごとの上限と、パッケージ全体の上限を併設することがあります。処理を複数のIPに分散すれば前者には対処できますが、パッケージ全体の上限は残ります。クライアントのパブリックIPに紐づく上限を、そのアドレスからインターネットに出る複数の端末が共有することもあります。

製品ごとの規則も重要です。同じ事業者の直接プロキシ接続、マネージド型スクレイピングAPI、別のネットワークでは、枠やアクセス権限が異なる場合があります。APIの計上単位は、ネットワーク接続ではなくタスクや結果であることもあります。アカウント固有の設定も含め、実際に使う製品の上限を確認してください。

上限に達すると何が起きるか

サービスの対応は規則によって異なります。転送速度の上限では、制限された速度でデータ転送が続く場合があります。リクエスト頻度の上限では、超過した処理が待機または拒否されることがあります。接続数の上限では、既存の接続は利用できても、新規接続が拒否されることがあります。通信量やリクエストの枠がある製品では、使い切った後に更新や追加購入が必要な場合があります。選べる対応は事業者の条件によって決まります。

そのため、「無制限」には、通信量、リクエスト、接続などの対象が必要です。それぞれ1つの項目を表しています。通信量無制限でも、転送速度や接続数には上限がある場合があります。継続的な高負荷利用の後に枠を変更する公平利用条件があるなら、それもプランの一部です。「無制限」という言葉だけでは、規則全体は分かりません。

一般的な失敗表示より、事業者の明確なメッセージの方が役立ちます。HTTP 429は、応答したサービスが、自らの規則ではリクエスト数が多すぎると判断したことを示します。まず、応答元がプロキシサービスか接続先かを確認してください。タイムアウトには、接続先の遅さやネットワーク障害など、ほかの原因もあります。利用統計、エラーの詳細、試行時刻は、枠の問題とほかの箇所の障害を区別する手掛かりになります。

拒否された処理を繰り返し送り直すと、頻度の問題が悪化し、追加の枠を消費する場合があります。対策は確認できた条件に合わせます。送信頻度を下げる、不要な接続を閉じる、使い切った枠を追加する、接続先へのアクセス権限を確認する、といった対応です。一般的なパッケージのアップグレードも、その条件を変える場合に限って役立ちます。

作業全体に合う上限を選ぶ

まず、必要な結果と期限を定めます。計算例として、ある作業で6,000件のHTTPリクエストを30分以内に完了する必要があり、平均レスポンスが0.5 MBだとします。平均で1分あたり200件のリクエストとなり、十進単位でレスポンスデータは約3 GBです。この見積もりには送信データ、ブラウザーの追加リソース、再試行は含みません。実際の作業で発生し、サービスが計上する場合は、それらも加える必要があります。

これらの合計だけでは、必要な接続枠はまだ分かりません。アプリケーションの実際の並列動作と、接続が占有される時間をテストしてください。同じ上限を共有するほかのプログラムや、複数の作業が同時に始まるときの短いピークも含めます。データ量、リクエスト頻度、同時接続数は別々に測定してください。1つのカウンターで3つすべてを代用することはできません。

予定している製品と接続先を使い、作業完了に必要なアプリケーションの機能も含めてテストしてください。小さな確認の成功は、1つの操作が動いたことを示します。代表的な実行では、持続的な負荷、ピーク、作業全体が必要とする資源についても確認できます。平均値を安全な最大値とせず、テストで観測した変動に備えて余裕を残してください。

条件が不明な場合は、製品、対象ホスト、接続先ポートとトランスポート、予想データ量、リクエスト頻度、接続数のピーク、正確なエラーを具体的にサポートへ伝えてください。これにより、事業者は該当する枠やアクセス権限を確認できます。必要なのは、サービスが示す上限と、実行予定の負荷が合っていることです。