Хотя конечно: https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/vOWBKZGoAQAJ?pli=1
Полезная ссылка. Можно смело забыть об экспериментах:To that end, we approve starting official deprecation of the feature now, with a (publicly communicated) goal to remove support from Chromium in the next 6-9 months. We recommend publishing a blog post describing what's happening and the recommended migration paths.
Абсолютно глупая затея. Вебпуш нужен только для "сиюминутных" данных, которые относятся только к конкретной странице и только сейчас.
Делал эксперименты с пушем лого и css - всё проталкивается, но время загрузки очень сильно возростает, а также до конца не проработан механизм кеширования в браузерах пуш-контента. Плюс при каждом новом просмотре вебсервер проталкивает заново то, что уже протолкнуто в предыдущем просмотре (можно в сессиях хранить информацию о том, что протолкнуто - но это уже вторая глупая затея).
Да, прочитал об этих проблемах. Но, все записи в сети о плохом кешировании - пятилетней давности. Сейчас тестирую. По моим тестам сегодня в Хроме кешируется отлично и повторно не запрашивается (пишет, что взял из кеша).
Лучше начать с <meta preload.
Это уже очень давно сделано. Сейчас preload разбираюсь.
Получить окно проверки на ботность на несколько секунд, вместо содержимого сайта - так себе решение. Я борюсь за каждые 0,1 сек скорости загрузки страницы. У меня страницы загружаются и прорисовываются целиком "мгновенно" (до 0.7 сек).А тут специально тормозить скорость загрузки.От серьезных атак скрипт не защитит, а проблемы пользователям создает. Лучше тогда на CF переехать.
1. Пока не получилось добиться работы SSL в IE 8 / XP : No FS 1 No SNI 2 Server sent fatal alert: handshake_failureУ Гугла получается: TLS_RSA_WITH_3DES_EDE_CBC_SHA
2. http2_push - пробовали грузить css, js, logo?
3. И почти каждый сотый юзер получает dns более секунды. Это уже не к http2, пытаюсь найти быстрый dns.
Я посмотрю еще день. И далее буду тестировать эти опции.Реально увеличилась скорость на http2. В цифрах это будет так:
Видно по SSL connect. Так и по полной cкорости загрузки для первых посещений сайта.
Экологически чистое зануление маршрута. 😀
Почему blackhole лучше/экологичнее?
пересоберите nginx с новым openssl - от системы это не зависит. в системе останется старый openssl.
примерно так (у меня тоже Debian 8, это не мешает абсолютно):
Еще раз спасибо. Собрал nginx c http2 на всех серверах. Прошло не так гладко. Точнее совсем не гладко, т.к. обновил попутно и апач, получив нерабочими старые конфиги и соотв. неработающие сайты. Но, в итоге все есть. На одном сервере не встала последняя версия openssl-1.1.1*. Пошагово опустил на 2 буквы ниже - все прошло.Пока не трогал ssl_buffer_size, ssl_session_cache, ssl_session_timeoutСильно увеличивают нагрузку на большом трафике?
<VirtualHost *:8080> ServerName site2.ru ServerAlias www.site2.ru ErrorDocument 403 /var/www/site2.ru/403.html ErrorDocument 404 /var/www/site2.ru/404.html ErrorDocument 500 /var/www/site2.ru/500.html DocumentRoot /var/www/site2.ru <Directory /> Options FollowSymLinks AllowOverride All Options +Includes </Directory> <Directory /var/www/site2.ru/> Options Indexes FollowSymLinks MultiViews AllowOverride All Options +Includes Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/ /var/www/site2.ru/cgi-bin/ <Directory "/var/www/site2.ru/cgi-bin"> AddHandler cgi-script .cgi .pl AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog /var/www/logs/site2.ru.error.log LogLevel warn CustomLog /var/www/logs/apache.access.log combined </VirtualHost>
При доступе к site2.ru запускаются страницы и скрипты с site1.ru При этом в переменных окружения HTTP_HOST и SERVER_NAME - находится site2.ru А в DOCUMENT_ROOT - /var/www/site1.ru/ Понятное дело, sudo a2enmod cgi - не поможет (первый сайт работает). Но, попробовал :)
