Мы запускаем социальную / локальную службу, которая получает преимущества от геолокации IP пользователей. Проблема в том, что с IPv6 геолокация немного более заметна, чем с IPv4.
Есть ли способ отдавать предпочтение входящим соединениям по IPv6 на хосте Ubuntu с nginx? Конфиг выглядит так:
server {
listen 80 default_server;
listen [::]:80 ipv6only=off default_server;
}
Ответы:
Предпочтение IPv6 / IPv4 определяется инициатором соединения, то есть веб-браузером. Правила выбора адреса определены в RFC 6724 . Хотя они могут быть переопределены, только пользователь может перенастроить свою операционную систему.
Единственный способ заставить кого-то использовать IPv4 - вообще не предлагать IPv6. Очевидно, что это не практическое решение даже в среднесрочной перспективе ...
Итак, давайте вернемся к исходной проблеме: геолокация для IPv6 «немного более заметна, чем с IPv4».
Частично это очень зависит от того, где вы получаете ваши данные геолокации. Например, Maxmind только дает мой IPv6-адрес как «Соединенные Штаты» без какого-либо города и интересного набора координат , в то время как Google по крайней мере правильно идентифицирует мегаполис, до которого они все еще находятся примерно в 50 милях. И Maxmind, и Google позволяют сообщать об исправлениях, и, по крайней мере, для Maxmind любой может сделать это для любого IP-адреса.
Я не ожидал бы, что эта ситуация продлится очень долго. Поскольку использование IPv6 продолжает расширяться, пользователи таких служб геолокации будут требовать большей точности для адресов IPv6, и им придется в конечном итоге предоставлять его, по крайней мере для платящих клиентов, чтобы эти клиенты не ушли куда-либо еще.
Тем временем вы должны быть уверены, что в вашем приложении есть другие способы поиска пользователей. Если они вошли в систему, вы можете прочитать их существующую учетную запись, чтобы понять, где они находятся. Вы можете попросить пользователя явно выбрать страну. И так далее...
Еще одна вещь, которую вы можете сделать, это предоставить субдомен только для IPv4 и субдомен только для IPv6 вашего веб-сайта, каждый из которых пытается загрузить ваши страницы. Затем вы можете сопоставить их на стороне клиента и сообщить об этом на сервер. Не случайно Maxmind уже делает это на своем веб-сайте.
Такие предпочтения могут быть выражены с использованием записей SRV. К сожалению, те не поддерживаются для HTTP. Таким образом, вы остаетесь в ситуации, когда один клиент делает выбор между IPv4 и IPv6.
Многие клиенты используют время туда-обратно SYN + SYN-ACK, чтобы решить, какой из них использовать. Таким образом, замедляя отправку пакета SYN-ACK по IPv6, вы можете сделать так, чтобы большинство клиентов предпочитали IPv4. Но намеренное замедление вашего сайта - ужасный подход.
Вместо этого я бы сделал шаг назад и посмотрел бы на проблему. Вы хотите лучше геолокационные данные. Каждый раз, когда посетитель посещает ваш сайт, вы сразу узнаете один из его IP-адресов. Будет ли это адрес IPv4 или IPv6, зависит от того, какой браузер предпочитает общаться с вашим сервером.
Внутри вашей страницы вы можете использовать AJAX-запрос, чтобы узнать другой IP-адрес. Для клиентов, использующих IPv4, отправьте запрос AJAX в домен только для IPv6, для клиентов, использующих IPv6, отправьте запрос AJAX в домен только для IPv4.
Как только запрос AJAX поступает на сервер, вы знаете как IPv4, так и IPv6-адреса пользователя. Знание этой переписки позволит вам выполнять геолокацию лучше, чем вы, зная только одну из двух.
Вы часто будете видеть случаи, когда запрос AJAX никогда не поступает на сервер. Для этих пользователей вам придется выполнять геолокацию, как вы можете лучше всего сделать, основываясь только на одном IP-адресе. Но до тех пор, пока ответ на этот запрос AJAX не используется ни для чего на стороне клиента, пользователь даже не будет замечать неудачные запросы AJAX. Таким образом, AJAX-запросы не будут вызывать замедления или ошибочного поведения.