Wir betreiben einen sozialen / lokalen Dienst, der von der Geolokalisierung der IP der Benutzer profitiert. Das Problem ist, dass die Geolokalisierung mit IPv6 etwas fleckiger ist als mit IPv4.
Gibt es eine Möglichkeit, eingehende Verbindungen auf einem Ubuntu-Host mit nginx IPv6 vorzuziehen? Die Konfiguration sieht folgendermaßen aus:
server {
listen 80 default_server;
listen [::]:80 ipv6only=off default_server;
}
Antworten:
Die IPv6 / IPv4-Präferenz wird vom Initiator einer Verbindung, dh dem Webbrowser, festgelegt. Die Adressauswahlregeln sind in RFC 6724 definiert . Diese können zwar überschrieben werden, jedoch nur, wenn der Benutzer sein Betriebssystem neu konfiguriert.
Die einzige Möglichkeit , jemanden zur Verwendung von IPv4 zu zwingen , besteht darin, IPv6 überhaupt nicht anzubieten. Offensichtlich ist dies auch mittelfristig keine praktische Lösung ...
Kehren wir also zum ursprünglichen Problem zurück: Die Geolokalisierung für IPv6 ist "etwas fleckiger als bei IPv4".
Zum Teil hängt dies sehr davon ab, woher Sie Ihre Geolokalisierungsdaten beziehen. Maxmind gibt zum Beispiel nur meine IPv6-Adresse als "USA" an, ohne Stadt und mit einem interessanten Satz von Koordinaten , während Google zumindest die Metropolregion korrekt identifiziert, in der sie sich noch ungefähr 50 Meilen entfernt befinden. Sowohl Maxmind als auch Google ermöglichen das Melden von Korrekturen, und zumindest für Maxmind kann dies jeder für jede IP-Adresse tun .
Ich würde nicht erwarten, dass diese Situation sehr lange anhält. Da die IPv6-Nutzung weiter zunimmt, werden Benutzer solcher Geolokalisierungsdienste eine höhere Genauigkeit für IPv6-Adressen verlangen und diese schließlich bereitstellen müssen, zumindest für zahlende Kunden, damit diese Kunden nicht woanders hingehen.
In der Zwischenzeit sollten Sie sicher sein, dass Ihre Anwendung andere Möglichkeiten zum Auffinden von Benutzern bietet. Wenn sie sich angemeldet haben, können Sie in ihrem vorhandenen Konto nach Hinweisen auf ihren Standort suchen. Sie können den Benutzer bitten, ein Land explizit auszuwählen. Und so weiter...
Sie können auch eine Nur-IPv4-Subdomain und eine Nur-IPv6-Subdomain Ihrer Website bereitstellen, die jeweils von Ihren Seiten geladen werden sollen. Sie können sie dann clientseitig korrelieren und an den Server zurückmelden. Nicht zufällig macht Maxmind dies bereits auf seiner eigenen Website.
Solche Präferenzen können mithilfe von SRV-Datensätzen ausgedrückt werden. Leider werden diese für HTTP nicht unterstützt. Sie haben also eine Situation, in der nur der Client die Wahl zwischen IPv4 und IPv6 trifft.
Viele Clients verwenden die Roundtrip-Zeit von SYN + SYN-ACK, um zu entscheiden, welche der beiden verwendet werden soll. Wenn Sie also das Senden eines SYN-ACK-Pakets auf IPv6 verlangsamen, können Sie die meisten Clients dazu bringen, IPv4 zu bevorzugen. Aber das absichtliche Verlangsamen Ihrer Website ist ein schrecklicher Ansatz.
Stattdessen würde ich einen Schritt zurücktreten und mir das Problem ansehen. Sie möchten bessere Geolokalisierungsdaten. Jedes Mal, wenn ein Besucher auf Ihre Website zugreift, erfahren Sie sofort eine seiner IP-Adressen. Ob dies eine IPv4- oder IPv6-Adresse ist, hängt davon ab, welchen Browser die Kommunikation mit Ihrem Server bevorzugt.
Innerhalb Ihrer Seite können Sie eine AJAX-Anfrage verwenden, um eine andere IP-Adresse kennenzulernen. Für Clients, die IPv4 verwenden, senden Sie die AJAX-Anforderung an eine Nur-IPv6-Domäne. Für Clients, die IPv6 verwenden, senden Sie die AJAX-Anforderung an eine Nur-IPv4-Domäne.
Sobald die AJAX-Anforderung auf dem Server eintrifft, kennen Sie sowohl die IPv4- als auch die IPv6-Adresse des Benutzers. Wenn Sie diese Korrespondenz kennen, können Sie die Geolokalisierung besser durchführen, als wenn Sie nur eine der beiden kennen.
Es werden häufig Fälle angezeigt, in denen die AJAX-Anforderung niemals auf dem Server eintrifft. Für diese Benutzer müssen Sie die Geolokalisierung durchführen, da dies am besten anhand einer einzigen IP-Adresse möglich ist. Solange die Antwort auf diese AJAX-Anforderung für nichts auf der Clientseite verwendet wird, wird der Benutzer diese fehlgeschlagenen AJAX-Anforderungen nicht einmal bemerken. Daher wird durch die AJAX-Anforderungen keine wahrgenommene Verlangsamung oder unberechenbares Verhalten verursacht.