Ми запускаємо соціальну / локальну службу, яка виграє від геолокації 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 не спричинять жодного сприйнятого уповільнення чи нерівномірної поведінки.