проблемы mod_spdy и предположения
В то время как BackupExec 12.5 также имеет агенты виртуализации в наличии, я не использую их. Я счастливо использовал BackupExec 12.5 и 2010 для резервного копирования моих виртуальных машин, как будто они были реальными машинами в течение нескольких лет теперь. Установите агент, когда Вы были бы на реальной машине, добавлять машину к соответствующему резервному списку (спискам) выбора, и необходимо быть в порядке.
Я пробую mod_spdy и столкнулся с проблемой - похоже, он несовместим с запросами AJAX и mod_php, как показано здесь: https://www.modspdy.com/blog/2012/04 / 15 / using-mod_spdy-with-php /
Похоже, решение состоит в том, чтобы запускать скрипты php через fastCGI. Теперь мой первый вопрос: почему? Может быть, есть какое-то обходное решение? Эта несовместимость временная?
Не могли бы вы пояснить, что вы имеете в виду в отношении AJAX?
mod_php не очень хорошо работает с mod_spdy , потому что SPDY мультиплексирует несколько запросов в одно соединение с потоковой передачей, что может вызвать проблемы с mod_php . Он хорошо описан в документации mod_spdy :
Как и MPM Apache Worker, mod_spdy обслуживает запросы, используя внутренний пул потоков (для реализации мультиплексирования SPDY), который может плохо взаимодействовать с небезопасными для потоков модулями Apache. В частности, если вы хотите обслуживать PHP поверх mod_spdy, настоятельно рекомендуется использовать mod_fcgid, а не mod_php , поскольку некоторые библиотеки PHP не являются потокобезопасными; использование mod_fcgid запустит PHP в отдельном процессе, что позволит избежать проблем с безопасностью потоков.
Каковы будут преимущества / недостатки этого?
См. этот вопрос о переполнении стека для обсуждения этой темы.
Также я не понимаю, зачем нужен https. Почему простой, скажем, статический веб-сайт не может набрать скорость от mod_spdy? Я ищу здесь простые предположения - вы думаете, что mod_spdy когда-нибудь будет доступен без требования mod_ssl, или архитектура настолько отличается, что я не должен ожидать этого в любое время?
Нет - SPDY намеренно создан для использования SSL. Конечно, говорить вам, что он никогда не откажется от требований SSL, также является спекуляцией ... но есть несколько серьезных причин, по которым он никуда не денется:
Это необходимо для работы протокола.
Протокол TLS Next. Расширение согласования необходимо для клиента и сервера, чтобы сообщить друг другу, что они оба поддерживают SPDY.
Это хорошо для Интернета.
Многие крупные игроки в Интернете, в том числе Google, пришли к идея, что сайты должны использовать SSL, даже если вы не даете им номер своей кредитной карты прямо сейчас.
Firesheep упростила захват файлов cookie, поэтому вы Вы заметите, что ваше соединение с Facebook или Twitter в наши дни всегда зашифровано. Тот же запрос был сделан из сети Stack Exchange, в которой вы читаете это. А безопасность соединения еще более беспокоит людей, живущих в условиях, запрещающих бесплатное использование Интернета.