Как стать автором
Обновить

Комментарии 34

Было бы неплохо увидеть где уже применена эта технология и тестовые страницы чтобы самому сравнить.
НЛО прилетело и опубликовало эту надпись здесь
Gmail, Google Reader, Google Docs, собственно поиск.
В общем, если браузер поддерживает SPDY, то весь HTTPS с гуглом идет через SPDY (кроме 10% клиентов, у которых SPDY выключен в целях сравнения)
На Хабре уже где-то были примеры.
Если не ошибаюсь, то twitter.com работает с SPDY.
Видимо не для всех: у меня твиттер без SPDY работает
Правда, работать SPDY будет только с браузерами, уже поддерживающими этот протокол — это, согласно отчетам некоторых аналитических агентств, второй по популярности браузер Chrome и штатный браузер Android (в Firefox 11 также ожидается внедрение SPDY)

Вот это печалит немного. Но в любом случае — решение стоит внимания.
В Firefox 11 он уже есть, но выключен по умолчанию. При желании можно включить и попробовать.
Пользуюсь с момента выхода Firefox 11 в бету, проблем нет
То есть просто включаем этот чудесный модуль и мир становится лучше? )
Посмотрел статистику у себя, больше всего хромопользователей
Думаю да
И еще… оно только для https работает? Что то беглое гугление приводит к этому.
Да, только для HTTPS.
Имеет смысл ставить если apache работает как back-end сервер?
Зачем? С backend работают только frontend-сервера, пользователям туда доступа нет. Для ускореня получения frontend'ами информации с backend'ов — может быть, но там обычно проблемы не в скорости связи, а в скорости подготовки данных.
Еще бы выпустили модули поддержки SPDY для тех серверов, которые работают на действительно нагруженных сайтах. Модуль для Апача пригодится, и даже очень, но, появись аналогичный модуль для того же nginx, скорость проникновения протокола «в массы» заметно возросла бы.

Чем больше популярных, посещаемых сайтов поддерживало бы SPDY, тем больше браузерам будет иметь смысл по-умолчанию включать поддержку протокола, и остальным будет, ради чего подтягиваться за ними.
twitter.com/#!/nginxorg/status/150112670966747137
«re SPDY, this is planned to be available some time in the next few months»
Отлично!

P.S. Парсер адресов пора как-то ссылкам на твиты научить, а то он! уже не считает нормальным для URL символом.
Вроде бы обещают уже в конце мая.
Будем ждать, внедрять, радоваться и радовать!

А там, и правда, даже IE подтянется. Версии, этак, в 12-й.
Берите выше — минимум к 15.
Зачем так плохо о парнях думать? Они работают, стараются…

Только получается у них как у АвтоВАЗа — хорошие двери сделают, только при их закрывании багажник открывается. Починят дефект багажника — руль крутится не туда. Займутся рулем — мотор глохнет.

Так что даже и не знаю, ждать ли MS-реализацию SPDY, которая будет сделано хорошо, но — «фирменно», т.е. чуть не так, как у всех :(

На этом фоне про версию не думается.
Жаль только, что SPDY по умолчанию поддерживается только для HTTPS. Все-таки большая часть сайтов используют просто HTTP, да и поддержка HTTPS требует наличия валидных сертификатов, а они стоят денег.
Вот не понимаю, вам жалко $10 за сертификат на высоконагруженном проекте? Есть даже за $2 www.namecheap.com/ssl-certificates/exclusive-positive-ssl-offer.aspx (но нужно купить у них тогда и домен, в общем домен я думаю куда-нибудь и деть можно, а сертификат использовать для своих первоочередных нужд)
Ситуация обычно сложнее. Например, когда я реализую внедряемые в чужие сайты решения.
Но ведь https заметно замедляет работу сайта — с кешированием не все так замечательно становится, с установлением сессий, да мало ли.

Опять же, поголовное шифрование — лишняя нагрузка на сервер, тут уже недорогим VPS может не обойтись. Правда, сфера применения SPDY несколько другая, посерьезнее десятка посетителей в день — так и накладные расходы будут повыше, нежели чем для десятка посетителей.
Вот вы сами и пришли к правильному выводу.
Кстати, HTTPS — это не средство замедления коммуникации, а средство безопасного пользования сайтами.
Про пользу шифрования я догадываюсь, но — накладные расходы с ним растут, так что сильно нагруженный сайт будет нагружен еще больше, что может сказаться на user experience. Но человек, которому ваш комментарий выше был направлен — он, вроде, и не против https вообще, он просто не рад лишним накладным расходам там, где (судя по применению SPDY) скорость важна и интересна.
А чем www.startssl.com/ со своими бесплатными сертификатами не подходит? По крайней мере, для проверки подойдет, а далее — можно уже смотреть.
ИМХО проще тогда самоподписанный использовать. Попробуйте авторизоваться у них на сайте. FF, Chrome пишут «SSL peer was unable to negotiate an acceptable set of security parameters.» и «Google Chrome does not handle client certificate enrollment correctly, please use an alternative browser!». Знаете ли, я у такой конторы даже бесплатно сертификат брать не хочу.
Я какое-то время назад брал у них сертификат бесплатный — и прекрасно работал их сайт у меня в FF (тогдашней свежей версии). В общем, сайт (тогда) был доступен без TLS-ошибок.
Я к ним хожу с июня где-то раз в месяц (вот люди так же как и вы спрашивают «вот же есть на шару, зачем платить?»), ничего с июня не поменялось — можете погуглить, проблема древняя и все знают.
Ну, если с июня (это, погодите-ка, 11-й месяц уже?) хотеть бесплатный сертификат получить, то проще за $9 в год покупать в указанной Вами компании (ну, либо и правда подпасть под акцию, и купить домен и заплатить за первый год сертификата за $2 + еще сколько-то за домен.

В любом случае, раз в год 250 рублей не разорят ни компанию, ни частного пользователя, будя у них (у него) нужда в нехалявном сертификате :) Другое дело, что за эти деньги будет сертификат, не сильно лучший бесплатного у startssl — у него также будет не 100%, а «99.3% browser compatibility» (т.е. некоторые браузеры в списке своих корневых сертификатов данных этого центра сертификации не имеют). Другое дело, что у самовыписанного эта величина — 0% ровно :)
Про 99.3% я даже ничего сказать не могу, я пока не нашёл ни одного такого браузера чтобы не работало (мобильные, десктопные версии). Пользуюсь сертификатом за 9$ для сайта escalibro.com — пока встретил только глюки IE7/8 связанные не с самим сертификатом, а с косяками в определении mixed content HTTPS, поэтому сейчас делаю перенаправление на HTTP для этих браузеров. IE мы игнорируем при вёрстке, так что не вижу проблем в игнорировании HTTPS для них в нашем случае.
centos6, поставил модуль для апача, при работе через https перестала работать вебморда — horde…

[Thu Apr 19 22:30:37 2012] [warn] [client 31.xxx.xxx.xx] [stream 61] [5861:5863:WARNING:spdy_to_http_filter.cc(168)] Unsupported read mode (2) on stream 61

отключил — все заработало… сыроват продукт
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации