Представлена (http://mailman.nginx.org/pipermail/nginx-devel/2012-June/002...) первая бета-версия модуля с реализацией поддержки второго чернового варианта протокола SPDY (http://www.chromium.org/spdy/spdy-protocol) для экспериментальной ветки http-сервера nginx 1.3.x. В течение следующих нескольких месяцев код поддержки SPDY планируется доработать и включить в состав основных исходных текстов nginx. В настоящее время реализация SPDY для nginx не поддерживает push-операции со стороны сервера, не работает с rate-лимитами и директивой post_action.Протокол SPDY, который продвигается для включения в состав будущего стандарта HTTP/2.0, был создан специально для минимизации задержек при соединении и обмене данными между клиентом и сервером. При обслуживании соединения SPDY использует похожий на HTTP механизм взаимодействия в форме запрос/ответ. SPDY добавляет сеансовый уровень поверх SSL, что даёт возможность обеспечить передачу нескольких одновременных потоков в рамках одного TCP-соединения. При использовании HTTP запросы в рамках одного потока обслуживаются последовательно, задействование SPDY даёт возможность мультиплексировать запросы ресурсов, обрабатывать их параллельно и отправлять запросы с учетом динамически рассчитываемых приоритетов, увеличивая текущую пропускную способность.
Использование SSL одновременно позволяет решить проблему с прохождением запросов через прокси серверы и позволяет организовать доставку данных по инициативе сервера, без специального запроса клиента (технология Server push). Дополнительное ускорение достигается за счёт сжатия HTTP-заголовков запроса и ответа, что уменьшает размер передаваемых данных и заметно ускоряет загрузку страниц, порождающих большое число мелких запросов (CSS, JavaScript файлы, картинки), особенно при использовании медленных каналов связи. По данным Google ускорение загрузки страниц при использовании SPDY составляет от 15% до 50%, но по результатам (http://www.guypo.com/technical/not-as-spdy-as-you-thought/) тестирования критиков протокола, ускорение составило 4.5% (тестирование проводилось с использовании обратного прокси для 500 крупнейших сайтов по рейтингу Alex. Низкие показатели объясняются тем, что на страницах большинства сайтов используются внешние вставки, в то время как SPDY ускоряет загрузку только с одного сервера).
URL: http://mailman.nginx.org/pipermail/nginx-devel/2012-June/002...
Новость: http://www.opennet.me/opennews/art.shtml?num=34140
Я ковырялся с этим протоколом.
Скажу что он слишком переоценен.
Он незначительно быстрее https.
Но он медленнее обычного http, после применения стандартных трюков, с аля разнос ресурсов по поддоменам и многоуровневое кеширование.
При этом не совместим с shared хостингами.
Вывод - B топку.
А детальнее? Насколько медленнее? Потому что если разница невелика - то уже ради возможности избавиться от "трюков" его уже стоит использовать. О shared хостинге молчу - когда vds стоит $10 сидеть на shared - дикость.
>О shared хостинге молчу - когда vds стоит $10 сидеть на sharedЗачем за те же деньги еще и осуществлять работу администратора?
Мне чтоб развернуть сайт с нуля нужно перетащить мышкой архив на фтп, и все.
Сравните с
- развертыванием образа,
- обновлением os,
- установкой и настройкой апача,
- установкой и настройкой nginx,
- установкой и настройкой mysql,
- установкой и настройкой *ftp, , php, python, архивирование ...
и еще потом периодической поддержкой и обновлением этого добра.Нет если сайтов пара, то хостить его можно хоть на iPhone.
С другой стороны, когда у клиента, не рестартует апач, слетает база, кораптятся файлы, надо обновить tzdata, и прочая и прочая, я их просто отсылаю в поддержку хостера.
Я слишком ленив, что бы работать ночами и по выходным, и слишком жаден, что бы работать бесплатно.
С третьей стороны с vds за 10$, (которые через один являются оверселом блевотного хертснера) вы со SPDY далеко не уедите, так как процессорное время он жрет как не в себя.
150-200 уников день макс.[сообщение отредактировано модератором]
>150-200 уников день макс.Мистическим образом потерялся при отправке нолик.
> Я слишком ленив, что бы работать ночами и по выходным, и слишком жаден, что бы работать бесплатно.Ленивый злой жадина, уникальное достижение, продолжайте в том же духе :)
Я еще женщин люблю и покушать. Так что на:
"Давайте срочно поменяем весь работающий, отлаженный, софт на новый, ради 2% прироста!"
- совсем времени нет.
Угу. Зато на идиотские извращения вроде разбрасывания по доменам и спрайтов время находится.
Сразу видно кондового php-шника. Ну-ну, попробуйте развернуть на шареде сайт на чем-то другом - на питоне или там рельсах. А LAMP спокойно ставится из панели нажатием пары кнопок. Это если хостер не предоставляет готовые соответствующие образы - с апачами и тому подобным. Зато с гарантией не будешь материться, выяснив, что нет нужного модуля сервера или не установить расширения php.А vds за 10 баксов даёт сам хетзнер, и работают они очень даже уютно, это у вас религиозная ненависть к нему, видать.
>на питоне или там рельсахКак правило, никому кроме гиков-студентов это не нужно.
> Как правило, никому кроме гиков-студентов это не нужно.А потом оказывается что у пыха настройки не те, нет того, сего, и вообще, как только нагрузка на сайт выше трех анонимусов в неделю - извольте платить как за два вдсника, потому что тормозной утюг апаче видите ли напрягается хостить не просто кусок барахла которое лежит на диске и ничего не делает, а еще и работать регулярно изволит.
> Вы, извините, идиот? Зачем за те же деньги еще и осуществлять работу администратора?Затем что когда оказывается что "а вот для этого надо вот это, а шаред так в принципе не умеет" - остается делать или убожеский сайт "на дворе 2000 год" или все-таки валить на что-то более приличное. Не говоря о том что очень смещно когда хакеры из-за дыр в страничке Пупкина вскрывают и пачку wannabe-Ынтырпрайзных сайтов, wannabe-магазинов и какой там еще наколенной требухи, которые совсем как настоящие, но проживающие в общественном туалете со всякими бомжами.
> Зачем за те же деньги еще и осуществлять работу администратора?Действительно, вот еще не хватало - толчок за собой чистить! Можно же в общественный туалет ходить, избавив себя от этой проблемы!
С удовольствием приглашу вас в гости - вантус под раковиной чистящее средство в шкафу.
Приходите каждую вторую среду месяца. Конечно, платить я вам не буду. Вы же любите лишнюю работу?
Извини, дядя, сантехник^W сисадмин по вызову - удовольствие доргое :)
> Я ковырялся с этим протоколом.= прочитал пост на хабре. Знаем.
+1«Ковырялся» он.
Дык, кто мешает поковыряться самому и опубликовать сенсационное опровержение?
Благо у них и rpm -ы уже появились - ставь, покупай ssl и ковыряйся на здоровье.
Да чего тут опровергать. Я не ковырялся и то знаю, что для SPDY SSL нет необходимости делать.
Опровержение можно прочитать там же. Такой невзрачный результат это последствие того, что не все домены с которых грузился контент поддерживали SPDY. Да и сам исследователь назвал протокол хорошим.
> Я ковырялся с этим протоколом. Скажу что онКовырялся пальцем в носу.
> Он незначительно быстрее https.
> Но он медленнее обычного http,Иначе знал бы, что это _не _протокол. Это ускоренная(, но несовместимая) _реализация _хэндшейка https. Поэтому c http= его сравнивать бессмысленно, а быть быстрее https (при хэндшейке, да) это просто таки его дизинг гол.
>Иначе знал бы, что это _не _протокол.Да? Жаль разработчики SPDY этого не знают и на главной странице проекта пишут:
>SPDY: An experimental >protocol< for a faster webhttp://dev.chromium.org/spdy/spdy-whitepaper
>Поэтому c http= его сравнивать бессмысленно
Да? Почему же?
Кстати, вышеупомянутые разработчики SPDY, почему то так не считаю и сравнивают SPDY именно с http:
>Unfortunately, HTTP was not particularly designed for latency. Furthermore, the web pages transmitted today are significantly different from web pages 10 years ago and demand improvements to HTTP that could not have been anticipated when HTTP was developed. The following are some of the features of HTTP that inhibit optimal performance: Single request per connection. Because HTTP can only fetch one resource at a time (HTTP pipelining helps, but still enforces only a FIFO queue), a server delay of 500 ms prevents reuse of the TCP channel for additional requests. Browsers work around this problem by using multiple connections. Since 2008, most browsers have finally moved from 2 connections per domain to 6.
>Exclusively client-initiated requests. In HTTP, only the client can initiate a request. Even if the server knows the client needs a resource, it has no mechanism to inform the client and must instead wait to receive a request for the resource from the client.
>Uncompressed request and response headers. Request headers today vary in size from ~200 bytes to over 2KB. As applications use more cookies and user agents expand features, typical header sizes of 700-800 bytes is common. For modems or ADSL connections, in which the uplink bandwidth is fairly low, this latency can be significant. Reducing the data in headers could directly improve the serialization latency to send requests.
>Redundant headers. In addition, several headers are repeatedly sent across requests on the same channel. However, headers such as the User-Agent, Host, and Accept* are generally static and do not need to be resent....
В статье в качестве заключения надо было добавить информацию о браузерах, которые поддерживают этот протокол.
> В статье в качестве заключения надо было добавить информацию о браузерах, которые
> поддерживают этот протокол.Срочно! http://ru.wikipedia.org/wiki/SPDY#.D0.9A.D0.BB.D0.B8.D0.B5.D... Срочнисимио воспользуйся кнопочкой [Исправить].
> Использование SSL одновременно позволяет решить проблему с прохождением запросов через прокси серверыХм. Культурно.
Но правильно так:
Использование SSL одновременно позволяет наплевать на прокси серверы
>Использование SSL одновременно позволяет наплевать на прокси серверыДооо.
cat /var/log/squid/access.log
1340179391.614 60308 199.199.9.199 TCP_MISS/200 4481 CONNECT cool_porno,ru/hardcore/zoo/muzjic_u_koza.WMV:443 - DIRECT/210.99.227.239 -
Штирлиц не мог понять что послужило причиной провала, то ли волевой взгляд настоящего коммуниста, то ли парашют за спиной.
>Штирлиц не мог понять что послужило причиной провала, то ли волевой взгляд настоящего коммуниста, то ли парашют за спиной.Причина обычная ― не знание матчасти. Например чем проксирование отличается от туннелирования.
Ключевые фразы
> поверх SSL, что даёт возможность обеспечить передачу нескольких одновременных потоков в рамках одного TCP-соединения.Подчеркну - В рамках одного.
И
> технология Server pushИ второе уже прокси не отслеживается.
Зыж
Да, кстати, ждём тунелей поверх сабжа.
А что? Чем хуже пингов? :D
> А что? Чем хуже пингов? :DА еще:
- Туннелят через CONNECT. Самое очевидное и вполне прокатывает.
- И просто энкапсулируя в HTTP запросы туннелируют. Достаточно тормозно, но на безрыбье...
- Есть тунелинг через DNS. Особенно хорошо прокатывает с недотепами-провайдерами wi-wi например.
а в этоже самое время в Lighttpd творится следущее:* http://redmine.lighttpd.net/issues/2322
* http://redmine.lighttpd.net/boards/3/topics/5201# p.s.: надеюсь успех Nginx их както подстегнёт.. а то ведь Lighttpd довольно грамотно сделан
Lighttpd мертв. Последний коммит был полгода назад.
> Последний коммит был полгода назад.Это говорит о качестве проекта - он не требует доработки :-P
Чем более программа необходима, тем больше в ней ошибок.
Следствие. Ошибок не содержит лишь совершенно ненужная программа.
> Чем более программа необходима, тем больше в ней ошибок.
> Следствие. Ошибок не содержит лишь совершенно ненужная программа.Лемма: все пр. содержат ошибки.
Сл.: в ненужных они просто не будут обнаружены.
> Чем более программа необходима, тем больше в ней ошибок.Интересная теорема. Реквестирую доказательство.
>> Чем более программа необходима, тем больше в ней ошибок.
> Интересная теорема. Реквестирую доказательство.Забей, это неправильная теорема. Правильно так: ..."больше в ней ошибок будет найдено, исправлено, а по пути добавлено, и так по кругу. Сходимость не доказана."
> Lighttpd мертв. Последний коммит был полгода назад.вы про этот коммит?
http://redmine.lighttpd.net/projects/lighttpd/repository/rev...
http://redmine.lighttpd.net/projects/lighttpd/repository/rev...