Apache HTTPD с SPDY 3.1

Проблема в том, что в Chrome 40.x потеряна поддержка SPDY/3 и поддерживается только SPDY/3.1, но модуль mod_spdy для Apache поддерживает только SPDY/3, поэтому в основном нет SPDY для пользователей Chrome, если вы используете Apache в качестве веб-сервера.

В настоящее время mod_spdy находится в плохом состоянии, и Google или Apache поддерживают его после того, как Google передал его Asf. Google недавно сделал заявление о том, что они откажутся от поддержки SPDY от Chrome в начале 2016 года, но они забыли сказать, что они уже начали отбрасывать более старые версии SPDY (включая SPDY/3) (кстати, эти частично верные утверждения мне нравятся) в общем, если вы работаете в Apache, то для пользователей Chrome вы не можете предоставить SPDY, кроме как самостоятельно внедрить SPDY/3.1.

Итак, как это было для "не делай зла"?:-)

Подробнее см.: https://groups.google.com/forum/ и https://code.google.com/p/mod-spdy/issues/detail?id=100&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20Stars

Один из вариантов, который вы могли бы рассмотреть, - это переключиться на Nginx и использовать там реализацию SPDY/3.1.

Как я не могу комментировать, из-за отсутствия репутации мне придется ответить, хотя это может быть так же "не по теме", как и у ответа Алексуса.

Я нашел описание, упомянутое несколько дней назад, и успешно запустил его. Совершенно прямо, если кто-то заинтересован в том, чтобы попробовать это. Хотя я должен отметить, что это, к сожалению, только добавляет поддержку SPDY/3 в мой домен, а не SPDY/3.1.

Chrome 36 и Firefox 31.4 ESR успешно подключаются к этому тестовому домену через SPDY/3. (С помощью индикатора SPDY AddOns для Firefox и Chrome.) Qualys SSL Labs подтверждает, что сервер получил поддержку SDPY/3 и SPDY/2.

При подключении к google.com с этими версиями браузера индикаторы SPDY говорят мне, что используется SPDY/3.1.

Но в Chrome 40 и 41 и Firefox 36+ индикатор SPDY остается серым при подключении к моему тестируемому домену. При подключении к google.com оба браузера говорят, что соединение уже использует HTTP/2. Так что не только Chrome, но и Firefox уже отказались от поддержки SPDY 3.0.

Я думаю, что это довольно неудачно. Сисадмины, пытающиеся поддержать наилучший возможный опыт и протокольную поддержку, как бы сбиты с толку, вложенная работа была напрасной.

Чтобы окончательно ответить на вопрос этой темы: Нет. Мне кажется, вы пока не получите какой-то "официальной" поддержки SPDY/3.1 для apache2. Как вы можете читать на github, они еще не говорят на нем. И так как этому "пока" уже около полугода, я бы предположил, что оно не придет. Итак, как уже упоминал Алексус, нужно придерживаться HTTP/2. Следите за этой страницей GitHub, где, надеюсь, скоро появится apache2.

И, наконец, "но"-часть.;) Вы можете отменить изменение, с которым я связан, и перекомпилировать mod_spdy, поэтому он предлагает SPDY/3.1. На моем тестовом компьютере это как-то работает, но у меня возникают некоторые проблемы с Firefox, когда говорят, что OCSP-сервер нужно попробовать позже, а прошло 5 минут. Но я действительно не знаю, вернутся ли браузеры к SPDY/3, но показывают ли они согласованный SPDY/3.1 или что-то в этом роде. Я не доверяю этой настройке прямо сейчас и мне нужно провести дополнительное тестирование. Итак, чтобы ответить на вопрос темы еще раз: Да, может быть!:) Если вы придерживаетесь описания, предоставленного hoppy, измените некоторые строки кода и скомпилируете его снова. Кажется, что-то работает, но я действительно не рекомендовал бы это прямо сейчас.

Google mod_spdy работает на Apache 2.2, но с портом 2.4 были некоторые проблемы, на нем уже есть нить.

Я нашел описание, как кому-то удалось его скомпилировать, но я еще не проверял.

Извините, если это немного не по теме, но я бы даже не стал беспокоиться, так как Google отказывается от SPDY и переходит к HTTP/2:

Блог Chromium: Привет HTTP/2, Прощай, SPDY

На самом деле я тестировал SPDY3.1, не удаляя спецификации заголовков 3.1 из исходного кода перед компиляцией.

Все работало нормально, кроме POST и загрузки файлов с помощью PHP-FPM. Кроме того, хотя в журнале ошибок не было подробностей об этом, трафик сократился на 30%. Конечно, это может быть совпадением, но пост и проблемы определенно реальны.

Он был протестирован на сервере с 200 000 просмотров страниц в день.