Comments 22
Ну, важный момент: плохой IPv6 хуже, чем отсутствие IPv6.
Ахилесова пята. IPv6 делают по остаточному принципу, очень часто. В результате то. что по IPv6 должно работать не хуже. а даже лучше, может вообще не работать.
А разные ос имеют разные приоритеты, через какой протокол пробовать, если есть и A, и AAAA записи для домена сайта.
И таймауты при неудачном ipv6 - такие, что юзер минутами не понимает, почему все колом встало.
А разные ос имеют разные приоритеты, через какой протокол пробовать, если есть и A, и AAAA записи для домена сайта.
У большинства ОС в приоритете IPv6. Но, например, в Linux можно накрутить в /etc/gai.conf и сделать приоритет для IPv4.
И таймауты при неудачном ipv6 - такие, что юзер минутами не понимает, почему все колом встало.
Чтобы с этим бороться, есть алгоритм Happy Eyeballs. Кстати, у моего провайдера есть обратная проблема со связностью через IPv4, что и показала моя утилита на моём сайте.
для проблемы номер 2 есть же
server {
listen 80;
location / { return 301 https://$host$request_uri; }
}
Именно это упомяното как проблема №3
по HTTP сказали, что нужно перейти на HTTPS версию сайта;
сказали что нужно всегда ходить на https версию сайта.
"всегда" это на время пока кешируется этот ответ
и в чем именно проблема то? ну ткнется браузер в http, увидит перманентный редирект и пойдет на https. в чем проблема даже если это происходит каждые пару минут?
ну не то чтобы у меня была проблема с этими миллисекундами, но в принципе все усовершенствования протокола http как раз про то, как избавиться от лишних миллисекунд, начиная от keep-alive в http 1.1, и этому в общем-то и посвещена эта статья
Так и hsts для того же, оно куда надежнее работает
Нет, hsts это другое. Клиент получает hsts заголовок уже когда он подключен к https, т.е. оно не работает для первого коннекта
Я про то, что, скажем, человек в жизни своей первый раз идет на хабр, а хабр, скажем, в hsts preload list не включён. Он написал в адресной строке браузера habr.com, а браузер не отправил адрес сначала в гугл, и у браузера не включена политика https first - то тогда браузер идет на http://habr.com
Там его перекидывает на https://habr.com - и в ответе к этому запросу он получает hsts заголовок.
И всё, до истечения значения max-age все запросы будут всегда отправляться на https вариант адреса.
Те речь только о том, что будет или нет первый редирект. И то, если в списке доменов в браузере (hsts preload list) таковой не значится.
Последнее можно проверить через hstspreload.org.
Проблем нет, но с помощью этой утилиты можно выявить странное поведение у некоторых пользователей. Например, не так давно я выносил часть сайта своего на отдельный домен и какое-то время не мог понять почему у меня при входе на этот сайт идёт редирект на основной. Я уже было грешил на 301 редирект, который когда-то подхватился, но это оказался не он. На компьютере рядом всё открывается и отображается, а у меня редирект. А потом нашёл корень проблемы: мой браузер увидел, что у сайта есть HTTP/3 и начал заходить на сайт через него. А я забыл HTTP/3 прописать в nginx. Как результат - запрос падал на дефолтный хост, а там было прописано перебрасывать на основной сайт, благо, хотя бы не перманентно :-) Вот после этого я и задумался о подобной утилите.
Обычно так и делают. Но первый раз запрос всё равно будет. Но новый тип записей в DNS убирает необходимость таких запросов даже первый раз. А этот тестер как раз покажет работает ли это у вас на сайте.
А обычный curl ваши сценарии тестов не покрывает?
Читаю проблему номер три... Ну прямо хочется про матчасть воскликнуть!
HTTP/1.0 и HTTP/1.1 — не одно и то же. HTTP/1.0 стандартизировали в 1996 году: запросы, ответы, заголовки, типы содержимого, коды состояния. Обычно каждый объект загружался через отдельное TCP-соединение.
HTTP/1.1 появился в 1997 году и был уточнён в 1999-м. Он ввёл постоянные соединения по умолчанию, обязательный Host, конвейеризацию запросов, частичную загрузку и более развитое кеширование. Именно HTTP/1.1, а не абстрактный «HTTP/1», десятилетиями обслуживал основную часть Веба.
HTTP/2 стандартизировали в 2015 году. Семантика HTTP сохранилась, но передача стала бинарной: несколько запросов и ответов мультиплексируются внутри одного TCP-соединения, заголовки сжимаются, сокращаются задержки и количество соединений.
HTTP/3 стандартизировали в 2022 году. Это уже не HTTP поверх TCP, а HTTP поверх QUIC и UDP. Потеря пакета в одном потоке не останавливает остальные, быстрее устанавливается защищённое соединение, а подключение легче переживает смену сети.
То есть 1.0 и 1.1 заметно различаются, HTTP/2 существенно меняет способ передачи данных, а HTTP/3 заменяет ещё и нижележащий транспорт. Это не последовательные косметические обновления одного и того же протокола.
И это еще не говоря, что прямвльный вид любого домена имеет точку справа (habr.com.) и веб-сервер, настроенный на habr.com, должен в голове сделать некие преобразования. Так вот в апаче можно настроить два разных виртхоста, для habr.com, и для habr.com., и это будут разные хосты. Nginx, от греха, разницы не делает.
Тут ещё не все перешли на 5G, о каком ipv6 вообще речь?
Это никак не связанные вещи. Вы можете даже в РФ подключиться к МТС и Мегафону и иметь IPv6. Более того, я на Мегафоне отключил вообще IPv4. Пока никаких проблем не замечаю, т.к. у них есть всё что нужно для нормальной работы моего телефона с хостами на IPv4.
Ну а саму утилиту просто можете запустить на другой VPS. Получить IPv6 на VPS вообще большой проблемы не составляет на нормальных хостингах. Когда тестируешь из дома, могут быть ложные сообщения об ошибках. Например, у меня показывает, что мой сайт не работает через QUIC по IPv4. Но если проверить из нормальной сети, то сразу видно, что всё работает как надо.
А мой веб-сервер точно нормально работает?