IPv6よりもIPv4着信接続を優先する

私たちは、ユーザーのIPを地理的に特定することから利益を得るソーシャル/ローカルサービスを実行します。問題は、IPv6では、ジオロケーションがIPv4よりもかなり小さいことです。

nginxを使用するUbuntuホストで、IPv6よりも着信接続を優先する方法はありますか？設定は次のようになります。

server {
    listen 80 default_server;
    listen [::]:80 ipv6only=off default_server;
}

IPv6 / IPv4設定は、接続の開始者、つまりWebブラウザによって決定されます。アドレス選択規則は、RFC 6724で定義されています。これらは上書きできますが、ユーザーがオペレーティングシステムを再構成することによってのみ上書きできます。

誰かにIPv4を強制的に使用させる唯一の方法は、IPv6をまったく提供しないことです。明らかに、これは中期でも実用的な解決策ではありません...

それでは、元の問題に戻りましょう。IPv6のジオロケーションは、「IPv4の場合よりもやや斑点があります」。

一部これは、位置情報データの取得場所に大きく依存します。たとえば、Maxmindは、都市がまったくなく、興味深い座標セットを持つIPv6アドレスを「米国」としてのみ提供しますが、Googleは少なくとも約50マイル離れた大都市圏を少なくとも正しく識別します。MaxmindとGoogleはどちらも修正の報告を許可しており、少なくともMaxmindの場合、誰でも任意のIPアドレスに対してこれを行うことができます。

この状況が長く続くとは思わないでしょう。IPv6の使用が拡大し続けると、このような位置情報サービスのユーザーはIPv6アドレスの精度を高める必要があり、最終的には、少なくとも有料の顧客については、それらの顧客が他の場所に行かないように提供する必要があります。

それまでの間、アプリケーションにユーザーを見つける他の方法があることを確認する必要があります。彼らがログインした場合、あなたは彼らの場所に関する手がかりのために既存のアカウントを読むことができます。ユーザーに明示的に国を選択するように依頼できます。等々...

他にできることの1つは、WebサイトのIPv4のみのサブドメインとIPv6のみのサブドメインを提供することです。それぞれがページの読み込みを試みます。その後、それらをクライアント側に関連付けて、サーバーに報告できます。偶然ではありませんが、Maxmindは既にこれを自社のWebサイトで行っています。

このような設定は、SRVレコードを使用して表現できます。残念ながら、これらはHTTPではサポートされていません。したがって、クライアントだけがIPv4とIPv6のどちらを選択するかという状況が残ります。

多くのクライアントは、SYN + SYN-ACKの往復時間を使用して、2つのうちどちらを使用するかを決定します。したがって、IPv6でのSYN-ACKパケットの送信を遅くすることにより、ほとんどのクライアントにIPv4を優先させることができます。しかし、あなたのサイトを故意に遅くすることは恐ろしいアプローチです。

代わりに、一歩下がって問題を調べます。より良い地理位置情報データが必要です。訪問者がサイトにアクセスするたびに、そのIPアドレスの1つをすぐに知ることができます。それがIPv4アドレスであるかIPv6アドレスであるかは、ブラウザがサーバーとの通信にどちらを好むかによります。

ページ内で、AJAXリクエストを使用して別のIPアドレスを知ることができます。IPv4を使用しているクライアントの場合、AJAX要求をIPv6専用ドメインに送信し、IPv6を使用しているクライアントの場合、AJAX要求をIPv4専用ドメインに送信します。

AJAX要求がサーバーに到着するとすぐに、ユーザーのIPv4アドレスとIPv6アドレスの両方がわかります。この通信を知ることで、2つのうちの1つだけを知るよりも、地理位置情報をより良くすることができます。

AJAXリクエストがサーバーに届かない場合がよくあります。これらのユーザーの場合、1つのIPアドレスのみに基づいて行うのが最善であるため、ジオロケーションを行う必要があります。しかし、そのAJAX要求への応答がクライアント側で何にも使用されない限り、ユーザーはこれらの失敗したAJAX要求にさえ気付かないでしょう。したがって、AJAXリクエストによって知覚されるスローダウンや不安定な動作は発生しません。