Comments 46
>ускоряет загрузку веб-страниц
Но зачем, если гугл сам собирается вводить гигабитный интернет?
Но зачем, если гугл сам собирается вводить гигабитный интернет?
Гугл не мог изобрести Ajax. Ajax — это даже не технология, это просто подход к проектированию web-интерфейса. И все, задействованные в нем технологии были известны задолго до того, как гугл распиарил это слово.
Действительно, Ajax не самый удачный пример, удалил из топика. Кстати, в Википедии пишут, что Google просто тихо использовал эти технологии с 2004 года в Gmail и ничего не пиарил, а сам термин придумал 18 февраля 2005 года некий Jesse James Garrett, который вообще к Гуглу никаким боком.
Если гугл вовсю не пиарит это, значит не уверен, что это работает должным образом.
Я так и вижу уже баннеры и плакаты -«SPeeDY — speed up your Internet to 44–64%! Free!!!»
Я так и вижу уже баннеры и плакаты -«SPeeDY — speed up your Internet to 44–64%! Free!!!»
UFO just landed and posted this here
Или SCTP
На страничке SPDY есть вопрос про SCTP:
dev.chromium.org/spdy/spdy-whitepaper
Q: What about SCTP?
A: SCTP is an interesting potential alternate transport, which offers multiple streams over a single connection. However, again, it requires changing the transport stack, which will make it very difficult to deploy across existing home routers. Also, SCTP alone isn't the silver bullet; application-layer changes still need to be made to efficiently use the channel between the server and client.
Как я понимаю, их оттолкнуло что это потребует изменение стека. Выбрали нечто среднее — с одной стороны есть оптимизация, с другой старые маршрутизаторы и прокси должны справляться со SPDY без проблем.
dev.chromium.org/spdy/spdy-whitepaper
Q: What about SCTP?
A: SCTP is an interesting potential alternate transport, which offers multiple streams over a single connection. However, again, it requires changing the transport stack, which will make it very difficult to deploy across existing home routers. Also, SCTP alone isn't the silver bullet; application-layer changes still need to be made to efficiently use the channel between the server and client.
Как я понимаю, их оттолкнуло что это потребует изменение стека. Выбрали нечто среднее — с одной стороны есть оптимизация, с другой старые маршрутизаторы и прокси должны справляться со SPDY без проблем.
По словам одного из сотрудников, Google уже использует SPDY на 90% всего трафика если у вас стоит Chrome.
groups.google.com/group/spdy-dev/msg/dcc9c3a3e50c694f
Илья Григорик подробно описывает это в своём блоге
www.igvita.com/2011/04/07/life-beyond-http-11-googles-spdy/
groups.google.com/group/spdy-dev/msg/dcc9c3a3e50c694f
Илья Григорик подробно описывает это в своём блоге
www.igvita.com/2011/04/07/life-beyond-http-11-googles-spdy/
Думал, бросят эту затею. Но дожали. Молодцы.
UFO just landed and posted this here
Давно пора. Особенно в RIA, иногда передается пару байт информации и с ними сотни байт HTTP хедеров оверхед.
Пользуюсь гмылом и гуглохромом. В последнее время почта стала по-моему скорее наоборот, лагать, а не ускорилась.
ЧЯДНТ?
ЧЯДНТ?
> Кому-то это может напомнить ситуацию с Microsoft, которая «улучшала» стандарты в браузере IE таким образом, чтобы серверы IIS отвечали быстрее, чем Apache. Но здесь ситуация кардинально иная. Речь идёт не о получении какой-то монополии, а об обеспечении быстрого интернета для всех, что выгодно Google априори.
Конечно-конечно, ведь в первом случае это была всем известная «Корпорация Зла» — Microsoft, а во втором — всем известная «Корпорация Добра» — Google. :-}
Конечно же, вводя специальный протокол в совем собственном браузере для своих собственных серверов, Корпорация Добра стремится обеспечить быстрый интернет для всех, а не то, что вы все подумали (многочисленные теги ирони съел парсер)
Конечно-конечно, ведь в первом случае это была всем известная «Корпорация Зла» — Microsoft, а во втором — всем известная «Корпорация Добра» — Google. :-}
Конечно же, вводя специальный протокол в совем собственном браузере для своих собственных серверов, Корпорация Добра стремится обеспечить быстрый интернет для всех, а не то, что вы все подумали (многочисленные теги ирони съел парсер)
Два мальчика плевались на улице. Плохой мальчик плюнул в хорошего три раза, а хороший в плохого — семь раз. Прохожий попытался их пристыдить. Тогда они стали плевать в прохожего. Плохой мальчик попал в него девять раз, а хороший мальчик — двенадцать раз. Вот так добро побеждает зло.
Ваабще-то драфт SPDY довольно давно был опубликован. Сорсы открыты (как клиентская, так и серверная имплементация). Модуль под апачи есть (хотя бы в рамках пруф-оф-концепт)
То что они не стали ждать пока все заимплементят я считаю только плюсом — как бы сами на себе и обкатывают.
Можно, конечно, долго спорить насчет «опенсорсовости» гугловских проектов, но скачать и откомпилить уже выложенный код таки можно, чего не скажешь про IIS.
Можно сколько угодно разбрасываться терминами «корпорация зла-добра», но результат и сорсы то можно пощупать прямо сейчас и всем.
И это мне, как конечному пользователю, намного более важнее, чем меряние что у кого более открыто и кто раньше кого что имплементит.
То что они не стали ждать пока все заимплементят я считаю только плюсом — как бы сами на себе и обкатывают.
Можно, конечно, долго спорить насчет «опенсорсовости» гугловских проектов, но скачать и откомпилить уже выложенный код таки можно, чего не скажешь про IIS.
Можно сколько угодно разбрасываться терминами «корпорация зла-добра», но результат и сорсы то можно пощупать прямо сейчас и всем.
И это мне, как конечному пользователю, намного более важнее, чем меряние что у кого более открыто и кто раньше кого что имплементит.
Пытаться рекламировать request multiplexing в SPDY когда подобное уже есть в SCTP как-то странно. IMHO это стандартный гугловский not invented here syndrome.
С одной стороны понятно — SCTP не самый распространненый протокол (+ вроде как проблемы с NAT имеет) и Гугл Хром хочет решить проблему multiplexing и при этом не хочет мороки. Так что вместо реального решения предлагает еще один уровень абстракции поверх TCP. Но с другой стороны было бы лучше для всех если бы Google пропиарил SCTP примерно таким же образом как он пиарит IPv6.
Я если чесно рассматриваю SPDY как эксперемент — в конечном итоге mutliplexing должен быть реализован на транспортном уровне, а сжатие хедеров и другая оптимизация должна быть добавлена в протокол HTTP.
С одной стороны понятно — SCTP не самый распространненый протокол (+ вроде как проблемы с NAT имеет) и Гугл Хром хочет решить проблему multiplexing и при этом не хочет мороки. Так что вместо реального решения предлагает еще один уровень абстракции поверх TCP. Но с другой стороны было бы лучше для всех если бы Google пропиарил SCTP примерно таким же образом как он пиарит IPv6.
Я если чесно рассматриваю SPDY как эксперемент — в конечном итоге mutliplexing должен быть реализован на транспортном уровне, а сжатие хедеров и другая оптимизация должна быть добавлена в протокол HTTP.
Из комментариев по ссылкам
SCTP is an entirely different transport protocol. Almost no router supports it. SPDY however is built on top of TCP. If you read the SPDY specification then you’ll see that this is one of the most important reasons why they invented SPDY instead of using SCTP.
SCTP is an entirely different transport protocol. Almost no router supports it. SPDY however is built on top of TCP. If you read the SPDY specification then you’ll see that this is one of the most important reasons why they invented SPDY instead of using SCTP.
«SCTP is an entirely different transport protocol.» SPDY дублирует часть функциональности SCTP. Я как сторонник Оккама не люблю дублировать сущности без необходимости. SPDY поверх TCP может быть OK как временное решение, но более правильным было бы использование браузерами SCTP (и прощай проблема «6 tcp коннекшенов на домен»).
«Almost no router supports it.» Все основные ОС и языки прекрасно работают с SCTP — так что проблема (как и IPv6) это с существующей сетевой инфраструктурой. Мой поинт в том что пиар машина гугл могла бы поспособствовать продвижению SCTP (типа IPv6+SCTP-day).
«Almost no router supports it.» Все основные ОС и языки прекрасно работают с SCTP — так что проблема (как и IPv6) это с существующей сетевой инфраструктурой. Мой поинт в том что пиар машина гугл могла бы поспособствовать продвижению SCTP (типа IPv6+SCTP-day).
Я побуду немножко адвокатом дьявола, если вы не против :)
С точки зрения бизнеса стоит выбор между SPDY сегодня-завтра или SCTP неизвестно когда.
С точки зрения бизнеса стоит выбор между SPDY сегодня-завтра или SCTP неизвестно когда.
> так что проблема (как и IPv6) это с существующей сетевой инфраструктурой
дело как раз в этом. SPDY можно прямо сейчас, а под SCTP нужно менять оборудование, и через NAT не прокинешь. что дешевле?
дело как раз в этом. SPDY можно прямо сейчас, а под SCTP нужно менять оборудование, и через NAT не прокинешь. что дешевле?
Я не говорю, что надо всем бросится делать браузеры на SCTP прямо щас. Я не говорю что SPDY отстой. SPDY это хорошая попытка ускорить веб приложения и она удалась. SPDY хорош как временное решение, эксперемент. Но архитектурно это неверно помещать еще один слой между TCP и HTTP который выполняет функции обоих уровней (и сжатие заголовков и мультиплексирование потоков). Как я сказал выше — лучше бы активнее рекламировали SCTP ведь этот протокол пригодится не только браузерам, но и куче других приложений.
> а под SCTP нужно менять оборудование, и через NAT не прокинешь. что дешевле?
Вы ведь знаете про SCTP over UDP, правда ведь?
Более того нас в будущем ждет неминуемое событие называемое «переход на ipv6» где в любом случае придется менять оборудование — так почему бы не пропихнуть SCTP, тем более что этот протокол определенно заслуживает внимания.
> а под SCTP нужно менять оборудование, и через NAT не прокинешь. что дешевле?
Вы ведь знаете про SCTP over UDP, правда ведь?
Более того нас в будущем ждет неминуемое событие называемое «переход на ipv6» где в любом случае придется менять оборудование — так почему бы не пропихнуть SCTP, тем более что этот протокол определенно заслуживает внимания.
Ну, все верно. SPDY требует обновления браузера и сервера. Это все не так сложно: браузер у Chrome свой, плюс рядом есть друг-конкурент Mozilla, который не стесняется если что взять хороший опенсорсный код (например, реализация out-of-process plugins частично базируется на коде Хрома).
Браузеры обновляются быстро, пользователи сидят на последних версиях. Итого реален сценарий, при котором в течении года 30% пользователей будут иметь поддержку SPDY. Это уже достаточно, чтобы задуматься о включении поддержки на уровне сервера. Прямой результат виден.
Сравним с SCTP, который должен поддерживать весь маршрут.
Рано или поздно SCTP придет. Но это явно более длительный процесс, в то время как SPDY может ускорить веб уже в течении года.
Браузеры обновляются быстро, пользователи сидят на последних версиях. Итого реален сценарий, при котором в течении года 30% пользователей будут иметь поддержку SPDY. Это уже достаточно, чтобы задуматься о включении поддержки на уровне сервера. Прямой результат виден.
Сравним с SCTP, который должен поддерживать весь маршрут.
Рано или поздно SCTP придет. Но это явно более длительный процесс, в то время как SPDY может ускорить веб уже в течении года.
Так вот для чего гугл в хроме скрыл отображение протокола недавно!
[irony]Случилось чудо! Теперь порносайты смогут первыми инициировать соединение с клиентом.[/irony]
Мне кажется, что полезнее было бы допилить WebSocket'ы. Хотя интересно и то и другое, а особенно — вместе.
Мне кажется, что полезнее было бы допилить WebSocket'ы. Хотя интересно и то и другое, а особенно — вместе.
Насчет SPDY уже писал тут зачем это нужно. Вполне логично, почему именно Гугл инициировал такие работы над SPDY — просто у них дофига сервисов, использующих httpS, а с учетом ихнего количества юзеров, подозреваю что для них это уже сейчас является сущим адом.
Sign up to leave a comment.
Google SPDY: жизнь после HTTP 1.1