IPローテーション:IPが変わるタイミング
IPローテーションは、サイトが通信を受け取るときに見る出口IPを変えます。新しいリクエスト、一定時間の経過、アプリによる別アドレスの要求で変更できます。適切な時点で切り替えると、独立リクエストを異なるIPに分散しつつ、関連操作を同じIPでまとめられます。
アドレスを固定するか変更するかの全般的な選択は、固定IPプロキシとローテーションプロキシで説明しています。ここでは、変更のきっかけと、すでに進行中のリクエストへの影響を見ていきます。
ローテーションで変わるもの
ローテーションゲートウェイでは、ソフトウェアに入力したアドレスが同じでも、サイトは異なる出口IPを見ます。同じホスト名とポートに接続し、サイトへの接続に使う出口をサービスが選びます。
たとえば価格監視で、1つの公開商品ページを192.0.2.14、別のページを198.51.100.27から取得できます。どちらも例のアドレスです。監視を実行するパソコンのインターネット接続は変わっておらず、リクエストが異なる出口からサイトへ届きます。
結果を決めるのは、出口をいつ選び直すかと、次の出口をどこから得るかという別々の判断です。タイマーで別の利用可能なプロキシを選ぶ場合も、モバイルモデムを再接続する場合もあります。きっかけが同じでも、操作と中断の内容は異なります。
リクエストごとのローテーション
リクエスト単位の方式では、独立して経路を決められる各リクエストについて、サービスが出口を選び直します。同じIPが不要な個別の商品ページ、公開リスト、検索に向きます。ただし「リクエスト」の意味に注意してください。HTTPSやSOCKS5のTCP通信では、通常、接続先への新しい接続を開いたときに切り替えます。
500の商品ページから価格を集めるとします。各ページが独立した結果を提供します。サービスは、すべてを1つのアドレスで送らず、利用可能な出口に分配できます。同時に実行する複数のリクエストも、異なる出口を使えます。
選び直しても、以前使ったアドレスが返る場合があります。プールは有限で、ランダムに選ぶ場合もあります。リクエスト単位というだけで、500回に500種類のIPを約束するものではありません。
リクエストと接続は異なる
アプリは1本の接続で複数のHTTPリクエストを送れます。プロキシ経由の通常のHTTPSでは、まず接続先へのトンネルを開きます。暗号化したリクエストが中を通り、プロキシは個々のリクエストを読まずにデータを転送します。
そのため、トンネルの出口は同じままです。「リクエストごと」と説明されるサービスでも、アプリが新しいトンネルや接続先接続を開くときに別の出口を選ぶ場合があります。既存トンネルの再利用では、以前のIPを保つ場合があります。
ブラウザーのページは、複数の接続で多数の資源を読み込みます。再読み込み時も、開いている接続を再利用できます。そのため、1クリック、1タブ、1回のページ読み込み全体が、1回のローテーションに対応するわけではありません。
一定間隔でのローテーション
時間方式では、IP割り当てが指定の時間枠だけ続き、その後に出口を選び直します。出口が使える限り、その間の関連リクエストは割り当てアドレスを共有できます。
セッションが10:00に始まり、有効時間を5分とします。同じ出口で商品一覧を開き、条件を絞り、次の結果ページを確認します。10:05に割り当てが失効し、その後の新しい接続は別アドレスを受け取る場合があります。5分は例で、全サービス共通の標準間隔ではありません。
タイマーの開始時点を確認してください。セッションの最初のリクエストから数える場合も、プロキシポートの予定に従う場合もあります。次の予定変更が1分後なら、今タスクを始めても5分間すべては使えません。別の非アクティブタイムアウトで、早く終わる場合もあります。
間隔は通常、特定のセッション、ポート、プロキシ接続設定に適用されます。アカウントの全接続が一度に切り替わるとは限りません。複数タスクで別々のIP割り当てが必要なら、サービスが対応する分離機能を使う必要があります。
複数のリクエスト間で割り当て出口を維持することを、一般にスティッキーセッションと呼びます。ローテーションサービスは、この方式で一時的に保持し、その後に選び直せます。
必要なタイミングでのローテーション
オンデマンド方式では、自分やアプリが別の出口を要求する時点を選びます。操作手段は、サービスによってダッシュボードのボタン、変更用URL、APIコマンドなどです。別のプロキシセッションを開始すると、新たに割り当てるサービスもあります。
関連する複数の手順があり、所要時間が分からないタスクに役立ちます。テストでフォームを開き、送信し、確認ページを待つとします。手順全体で現在の出口を保ち、次の独立テストを始める前に別の割り当てを要求できます。
オンデマンドの切り替えも自動化できます。タスク完了後や指定リクエスト数の後で、アプリが変更コマンドを送ります。「オンデマンド」は誰が時点を決めるかを表し、毎回人がボタンを押す必要はありません。
制御の範囲も重要です。1セッションだけ、プロキシポート全体、複数接続で共有する物理モデムに作用する場合があります。それらの接続全体の割り当てを変えるなら、同じ資源を使う別の作業にも影響し得ます。
進行中のリクエストはどうなるか
サイトへの通常のTCP接続では、出口IPはその接続の一部です。リクエストと応答は、同じ確立済み接続を使います。未完了のやり取りを、単純に別の出口IPへ移すことはできません。
切り替え境界の処理はサービスによって異なります。既存接続を現在の出口で完了させ、新しい割り当てを後の接続から適用する場合があります。一方、接続を閉じ、アプリに再接続を求める場合もあります。モデムの再接続も、その回線を通る通信を中断する場合があります。
定時変更の直前にダウンロードを開始したとします。接続を開いたままなら、タイマー終了後も元の出口で続けられます。閉じられた場合は、最初からやり直すか、対応していれば途中から再開します。間隔だけでは、進行中の転送の動作は分かりません。
次のIPはどこから来るか
プールから別の出口を選ぶ
プール型サービスは、使える出口を選びます。次の接続は、同じデータセンターサーバー上の別IP、別サーバー、家庭回線、モバイル端末を使う場合があります。プールからの選択に、直前のリクエストを運んだ端末の再接続は不要です。
地域やネットワークのフィルターに対応していれば、候補出口が絞られます。同じ国内で別IPを選ぶ際、国を変える必要はありません。範囲が狭いと使えるアドレスも減り、重複が増える場合があります。
モバイルモデムを再接続する
モデムの携帯データ接続を切断・再確立して切り替えるモバイルサービスもあります。その間は通信が一時停止し得ます。パブリックアドレスを決めるのは携帯通信事業者なので、再接続しても同じIPが戻る場合があります。
別のモバイルサービスは、プールからほかの利用可能な端末を選びます。どちらもモバイルプロキシのローテーションですが、進行中の作業への影響は異なります。その名称だけでは、使う仕組みは決まりません。
切り替えを誰が制御するか
ローテーションゲートウェイでは、事業者が指定の方式に従って出口を選びます。アプリ設定のゲートウェイは維持し、サービスに出口アドレスの管理を任せられます。
アプリが固定プロキシのリストを自分で切り替えることもできます。最初のタスクに1番目、次に2番目を使い、リストを進むなどの方法です。順番またはランダムに選び、独立リクエストごとに変更したり、タスク終了まで同じプロキシを使ったりできます。
したがって、固定IPのデータセンターやISPプロキシのリストでも、ローテーションするワークフローを作れます。各プロキシのIPは固定で、次の接続を運ぶプロキシをソフトウェアが変えます。仕事へのアドレス割り当てを自分で制御したいときに役立ちます。
契約内の購入済みアドレスの交換は、別の操作です。定期の入れ替えはアクセスできるIPセットを変えますが、アプリが作業中にその中を自動で切り替えるようにはなりません。
タスクに合わせて時点を決める
まず、同じ出口を保つ必要がある操作を特定します。次のリクエストやタスクで別IPを使える地点に、変更を置きます。
| タスク | 適した時点 | 理由 |
|---|---|---|
| 独立した公開商品ページの収集 | リクエストごと、または接続先への新規接続時 | 各結果を、別々に選んだ出口から取得できます。 |
| 既知の時間内で関連する複数の確認を実行 | 確認全体を覆う時間制の割り当て | 割り当て中は、リクエストが出口を共有できます。 |
| 所要時間が変わる一連の手順を完了 | 完了後にオンデマンドで変更 | 関連する手順がいつ終わったかを、アプリが把握しています。 |
長い転送では、短い切り替え間隔より既存接続の扱いが重要です。複数の同時タスクでは、制御が個別に適用されるか、共有資源に作用するかを確認してください。
IPを変えても、ブラウザーのCookieやアカウント情報は消えません。サイトはリクエストを同じセッションやアカウントに関連付けられます。ローテーションは通信を出口に分散するもので、あらゆる制限をリセットしたり、成功を保証したりしません。
本格的な実行前に、小規模テストで方式を確認します。新しい接続の出口IPと時刻を記録し、予定のタイマー境界をまたいで、または変更コマンド後に再確認します。開いた接続が残るかも調べます。これで実際の切り替えがタスクに合うか分かります。IPの重複だけでは、ローテーションの故障とは証明できません。
