IPv4 vs IPv6

Scrapeless Proxies は、対応サイトへ到達するために IPv6 出口を必要とするアプリケーション向けに IPv6 プロキシルーティングを提供します。

IPv4 と IPv6 で何が変わるのか？

IPv4 vs IPv6 は、エンドポイントを識別しネットワーク間でパケットを運ぶ 2 つの Internet Protocol バージョンを指します。多くの開発者が最初に直面する違いはアドレスです：IPv4 はドット付き 10 進表記を使用し、IPv6 は一般にコロン区切りの 16 進数グループを使用します。アプリケーションは、ソケットを開くとき、接続を受け付けるとき、ネットワークイベントを記録するときに、アドレスファミリーを理解していなければなりません。

この IPv4 パケット仕様 は 32 ビットのアドレスフィールドを定義しています。IPv6 はアドレスフィールドを 128 ビットに拡張し、パケットヘッダを変更します。このより大きな空間により、アドレス割り当てのアプローチを変えることができますが、アプリケーションには依然として到達可能な宛先、動作する DNS、適切なファイアウォールルール、および許可されたアプリケーションプロトコルが必要です。

ホスト名はどちらのアドレス形式とも別物です。同じ Web サイトが IPv4 と IPv6 の両方のアドレスを公開したり、どちらか一方だけを公開したり、ファミリーごとに異なるインフラを公開したりできます。したがって、すべての Web サイトを恒久的に 1 つのカテゴリに割り当てるのではなく、接続経路を選択することになります。

DNS とデュアルスタックが接続に与える影響

デュアルスタックとは、環境が IPv4 と IPv6 の両方をサポートしていることを意味します。DNS は IPv4 向けに A レコード、IPv6 向けに AAAA レコードを返すことができ、その後クライアントはアドレスを選択して接続を試みます。リゾルバ設定、アドレス選択、経路品質、クライアントの動作が、どちらのファミリーが使用されるかに影響します。

この Happy Eyeballs connection algorithm は、複数のアドレスファミリーが利用可能な場合の応答性に対処します。このアルゴリズムの存在は、両方のレコードタイプを公開しても両方の経路が同等に健全とは限らない、という有用な注意喚起になります。ブラウザと HTTP ライブラリは、実装や設定が異なるために、異なる選択をする可能性があります。

診断のために、解決されたアドレスと実際に使用されたアドレスを記録してください。ブラウザでのアクセス成功は、IPv6 のみのワーカーが同じサイトに到達できることの証明にはなりません。ブラウザは IPv4 を使用していたかもしれません。同様に、直接の IPv6 リクエストが失敗しても、IPv6 プロキシ出口が宛先に到達できないことを示すわけではありません。プロキシは独自のネットワーク経路を使用します。

ホスト名ベースのテストを手順に残してください。ホスト名を IP リテラルに置き換えると、単なるアドレス選択以上の変更が起こります。バーチャルホスティングや TLS 証明書検証は元の名前に依存している場合があります。要求ホストを変更する接続性テストは、プロトコルバージョンとは無関係な誤解を招く失敗を引き起こす可能性があります。

プロキシゲートウェイと出口を分けて考える

プロキシリクエストには、クライアントからプロキシへの接続と、プロキシから宛先への接続があります。コードが接続するゲートウェイは、宛先から見えるアドレスとは限りません。データ収集で IPv4 vs IPv6 を選ぶ際には、この区別が重要になります。

ホスティング環境が実用的な IPv4 接続しか提供していないワーカーを考えてみてください。そのワーカーは、プロキシサービスが互換性のあるゲートウェイを公開し、宛先への接続を IPv6 で実行する場合には、依然として IPv6 エグジットを利用できます。これはルーティングの取り決めであり、すべてのプロキシプロトコル内部で IPv4 パケットが直接 IPv6 パケットになるという主張ではありません。

逆のケースも重要です。IPv6 プロキシリソースを購入しても、すべてのクライアントライブラリがその接続情報を利用できることや、すべてのターゲットが IPv6 経路をサポートしていることは保証されません。生成されたゲートウェイアドレス、プロキシプロトコル、認証情報、およびサポートされる宛先ファミリーをまとめて確認してください。推測でアドレスファミリーを書き換えて接続文字列を編集するのではなく、割り当てられた設定をそのまま維持しましょう。

Scrapeless は、該当するセットアップを次の場所で解説しています。 IPv6 proxy configurationリソースが生成した接続情報を互換性チェックに使用してください。IP 観測に成功した場合、そのリクエストについて観測されたエグジットが確認されたことを意味しますが、今後のすべての宛先が保証されるわけではありません。

What IPv6 Does Not Guarantee

IPv6 は、より高速な転送、アプリケーション通信の暗号化、または宛先での受け入れを保証するものではありません。 IPv6 protocol specification が定義しているのはネットワークの挙動であり、アプリケーション性能のランキングではありません。経路の長さ、輻輳、ゲートウェイの配置、オリジンのインフラストラクチャ、レスポンスサイズは依然として重要です。

より大きなアドレス空間があっても、アプリケーションが匿名になるわけではありません。Web サイトは、クッキー、認証、リクエストヘッダー、ブラウザの挙動とともにネットワークエンドポイントを観測できます。異なるアドレスが同じ経路指定プレフィックスや同一ネットワーク事業者に属している場合もあります。そのため、個別のアドレス数を数えることは、実際のサービス要件を評価する代替指標としては適切とは言えません。

TLS は、正しく構成されていればアプリケーション接続を保護します。IPv4 から IPv6 に切り替えても、証明書検証が不要になったり、暗号化されていない HTTP リクエストが秘匿化されたりすることはありません。見落とされた IPv6 リスナーによって、IPv4 のみを対象としたファイアウォールレビューでは気づけなかったサービスが公開されてしまうことがあるため、両方のアドレスファミリーに同等のファイアウォールポリシーを適用してください。

有用な証拠を生み出す互換性テスト

有用な比較を行うには、アプリケーションタスクを一定に保ち、ネットワーク経路を意図的に変えます。想定しているワークロードを代表する、認可された公開ページを選びます。可能な限り、URL、言語、アカウント状態、抽出ルールを経路間で揃えてください。

1. 各宛先が必要なアドレスレコードを公開しているか、選択した環境にその経路が存在するかを確認します。
2. プロキシ認証を確認し、観測されたエグジットアドレスをゲートウェイアドレスとは別に記録します。
3. 対象ページをリクエストし、最終的な URL、HTTP ステータス、および期待されるコンテンツを検証します。
4. 接続時間、レスポンスサイズ、および下流コンシューマーが受け入れたフィールドを記録します。
5. 到達できないケースは、望んだデータを含まない有効なレスポンスとは分けて文書化します。

すべての失敗レコードを 1 つのネットワーク障害にまとめないでください。DNS の問題、拒否されたプロキシログイン、TLS 検証エラー、空のパーサー結果では、それぞれ異なる修正が必要です。これらのカテゴリを分けておくことで、本当にアドレスファミリーが原因なのかどうかを判断できます。

関連する IPv4 and IPv6 scraping comparison は、プロキシパスの区別について詳しく説明しています。その区別を行ってから available Scrapeless plansを比較してください。必要な宛先に到達できない安価な経路では、ワークロードを完了できないためです。

Which Address Family Should You Choose?

ワークロード内の宛先とツールにとって互換性があり受け入れられている経路である場合は IPv4 を選びます。宛先が IPv6 をサポートし、測定された経路が運用要件を満たしている場合は IPv6 を選びます。両方の環境を必要とするユーザーへの提供やアプリケーションの実行には、デュアルスタックサポートを維持してください。

宛先が混在している場合は、互換性を宛先と実行環境の属性として扱ってください。アドレスプールが大きいというだけの理由で、すべてのリクエストを IPv6 経由に強制するグローバルなルールは避けましょう。小さなルーティングインベントリでも、宛先ファミリーのサポート状況、プロキシリソースの種類、セッション要件、直近の有意な受け入れ結果を記録できます。

初回アクセスだけでなく、保守も計画に含めてください。DNS やホスティングの構成は変化しうるため、以前に互換性のあった経路は観測可能な状態を維持すべきです。到達性の変化を報告し、別の経路からの古いコンテンツで欠落した観測結果を黙って置き換えないようにしてください。

A Route Inventory Example

ルートインベントリでは、宛先の互換性とプロキシ構成を区別する必要があります。認可された監視ジョブが公開ドキュメントホストと地域カタログを訪問すると仮定しましょう。ドキュメントホストは両方のアドレスファミリー経由で到達可能かもしれませんが、カタログの必要なエンドポイントは、選択した環境からは実用的な IPv4 パスしか公開していない場合があります。最初のホストをテストしただけでジョブ全体が IPv6 互換だとみなすのではなく、それぞれの結果を個別に記録してください。

インベントリには、ゲートウェイのホスト名、観測されたエグジットファミリー、宛先ホスト名、受け入れ結果を保持します。その後カタログが IPv6 接続を正常に追加した場合でも、同じレコード構造を使って変更を記録でき、過去の観測の意味を書き換える必要はありません。失敗した経路は利用不可のままにしておき、実際に必要なコンテンツを配信した経路について、別の成功した観測結果を保存してください。これにより、互換性に関する判断の根拠となる証拠が維持されます。

Conclusion

IPv4 と IPv6 の選択は、互換性とルーティングに関する決定です。プロキシホップの両方を確認し、ホスト名を保持し、速度やコストを評価する前に要求したコンテンツを検証してください。アドレスファミリーは、そのタスクが要求する条件のもとで実際のアプリケーションタスクを完了できるときに有用になります。