А мой веб-сервер точно нормально работает?

[achekalin]

Ну, важный момент: плохой IPv6 хуже, чем отсутствие IPv6.

[FSA]

Ахилесова пята. IPv6 делают по остаточному принципу, очень часто. В результате то. что по IPv6 должно работать не хуже. а даже лучше, может вообще не работать.

[achekalin]

А разные ос имеют разные приоритеты, через какой протокол пробовать, если есть и A, и AAAA записи для домена сайта.

И таймауты при неудачном ipv6 - такие, что юзер минутами не понимает, почему все колом встало.

[FSA]

А разные ос имеют разные приоритеты, через какой протокол пробовать, если есть и A, и AAAA записи для домена сайта.

У большинства ОС в приоритете IPv6. Но, например, в Linux можно накрутить в /etc/gai.conf и сделать приоритет для IPv4.

И таймауты при неудачном ipv6 - такие, что юзер минутами не понимает, почему все колом встало.

Чтобы с этим бороться, есть алгоритм Happy Eyeballs. Кстати, у моего провайдера есть обратная проблема со связностью через IPv4, что и показала моя утилита на моём сайте.

[korn3r]

для проблемы номер 2 есть же

        server {
                listen 80;
                location / { return 301 https://$host$request_uri; }
        }

[DennisP]

Именно это упомяното как проблема №3

по HTTP сказали, что нужно перейти на HTTPS версию сайта;

[korn3r]

сказали что нужно всегда ходить на https версию сайта.

[DennisP]

"всегда" это на время пока кешируется этот ответ

[korn3r]

и в чем именно проблема то? ну ткнется браузер в http, увидит перманентный редирект и пойдет на https. в чем проблема даже если это происходит каждые пару минут?

[DennisP]

ну не то чтобы у меня была проблема с этими миллисекундами, но в принципе все усовершенствования протокола http как раз про то, как избавиться от лишних миллисекунд, начиная от keep-alive в http 1.1, и этому в общем-то и посвещена эта статья

[achekalin]

Так и hsts для того же, оно куда надежнее работает

[FSA]

Проблем нет, но с помощью этой утилиты можно выявить странное поведение у некоторых пользователей. Например, не так давно я выносил часть сайта своего на отдельный домен и какое-то время не мог понять почему у меня при входе на этот сайт идёт редирект на основной. Я уже было грешил на 301 редирект, который когда-то подхватился, но это оказался не он. На компьютере рядом всё открывается и отображается, а у меня редирект. А потом нашёл корень проблемы: мой браузер увидел, что у сайта есть HTTP/3 и начал заходить на сайт через него. А я забыл HTTP/3 прописать в nginx. Как результат - запрос падал на дефолтный хост, а там было прописано перебрасывать на основной сайт, благо, хотя бы не перманентно :-) Вот после этого я и задумался о подобной утилите.

[FSA]

Обычно так и делают. Но первый раз запрос всё равно будет. Но новый тип записей в DNS убирает необходимость таких запросов даже первый раз. А этот тестер как раз покажет работает ли это у вас на сайте.

[Xelld]

А обычный curl ваши сценарии тестов не покрывает?

[FSA]

Теоретически можно и с помощью bash скрипта всё это проделать. Но я решил вот так попробовать. Если предложите свой вариант, буду только рад.