SPDY - скоростная альтернатива HTTP от Google

← →
TIF © (2009-11-14 04:09) [0]

Очереной отжиг от Google © ?

http://cnews.ru/news/top/print.shtml?2009/11/13/369703
http://dev.chromium.org/spdy

← →
Медвежонок Пятачок © (2009-11-14 19:56) [1]

Для ускорения загрузки данных SPDY использует целый ряд техник, включая поддержку большого количества http-запросов через единственное TCP-соединение

очередной ускоритель интернету.

← →
@!!ex © (2009-11-14 22:10) [2]

> [1] Медвежонок Пятачок © (14.11.09 19:56)
> очередной ускоритель интернету.

и что?

← →
Медвежонок Пятачок © (2009-11-15 00:36) [3]

непонятно что именно и главное как они собрались "ускорять".

← →
@!!ex © (2009-11-15 09:14) [4]

> [3] Медвежонок Пятачок © (15.11.09 00:36)

Спецификацию почитайте, там же все написано. :)

← →
DVM © (2009-11-15 15:41) [5]

Гуглу скорее всего не удастся убедить Microsoft, а без нее в массы не пойдет новый стандарт как ни крути.

← →
Медвежонок Пятачок © (2009-11-15 16:07) [6]

Спецификацию почитайте, там же все написано. :)

Чего там написано?
Много http запросов сквозь единственное tcp соединение?
каким волшебством это способно ускорить загрузку?
Пропускная способность канала - константа.
Размер полезного контента - тоже самое.
Много http запросов вместо одного = увеличение служебного трафика.
В результате реальная скорость загрузки контента только снижается.

← →
Kerk © (2009-11-15 16:13) [7]

> DVM © (15.11.09 15:41) [5]

Майкрософт как обычно пририсует с боку бантик и скажет, что это их идея.

> Медвежонок Пятачок © (15.11.09 16:07) [6]

Вообще-то все наоборот. Чем меньше tcp-соединений, тем меньше служебного трафика.

← →
Медвежонок Пятачок © (2009-11-15 16:58) [8]

ну так я и спрашиваю, каким макаром, увеличив число запросов на прикладном уровне, и используя тот же самый канал, мы волшебным образом ускорим загрузку контента (да еще и в целых два раза)

← →
Kerk © (2009-11-15 17:00) [9]

А где ты увидел увеличение числа запросов на прикладном уровне?

← →
Медвежонок Пятачок © (2009-11-15 17:04) [10]

Для ускорения загрузки данных SPDY использует целый ряд техник, включая поддержку большого количества http-запросов через единственное TCP-соединение

← →
Медвежонок Пятачок © (2009-11-15 17:06) [11]

короче новый гербалайф

← →
Kerk © (2009-11-15 17:31) [12]

> Медвежонок Пятачок © (15.11.09 17:04) [10]

Да. Количество TCP-соединений станет меньше, а HTTP-столько же. Учись читать слова и видеть смысл :)

← →
Медвежонок Пятачок © (2009-11-15 17:44) [13]

Вы мне на пальцах объясните. Я не догоняю.

Количество тсп соединений меньше одного не станет.
Кроме того, если ресурсы страницы на одном сервере, то с незапамятных времен прекрасно работает кип алайв, который через одно тсп соединение сосет скажем все пикчи прописанные на странице.

но это не в два раза быстрее.

здесь же нам говорят, что количество запросов возрастет.
то есть служебный трафик тоже неизбежно возрастет.
но время загрузки в два раза уменьшится.

← →
Медвежонок Пятачок © (2009-11-15 18:03) [14]

вот простейший эксперимент.
берем тсп сервер. в его памяти находится ресурс размером 10 метров.
канал в мегабит.
протокол такой:
как только клиент устанавливает соединение с сервером, сервер просто отдает клиенту все десять метров контента.
никаких заголовков.

засекаем время.

далее делаем то же самое, но десять метров делим на текст страницы, и скажем пять картинок.
протокол классический, http с connection close.

канал тот же самый.

снова засекаем время скачивания.

какова будет разница в результатах?

если они будут отличаться в два раза (а они не будут отличаться в два раза), я готов признать, что классический http настолько неээфективен, что его можно оптимизировать гугловым гербалайфом аж в два раза.

← →
Anatoly Podgoretsky © (2009-11-15 18:14) [15]

> Медвежонок Пятачок (15.11.2009 17:06:11) [11]

Ну да, это они так красиво обозвали всем известный keep-alive

← →
Piter © (2009-11-15 18:41) [16]

Anatoly Podgoretsky © (15.11.09 18:14) [15]
Ну да, это они так красиво обозвали всем известный keep-alive

ну да, тоже хотел сказать. Вообще-то, это давно используется в HTTP, более того по-умолчанию по спецификации именно этот режим и используется, когда соединение не рвется после очередной пары запрос-ответ. Правда, запросы чисто последовательные могут быть, может в гугловском стандарте они могут быть параллельны, но тогда это только усложнит текстовый протокол и увеличит тот самый служебный трафик.

← →
DVM © (2009-11-15 18:45) [17]

> может в гугловском стандарте они могут быть параллельны

через одно соединение не может быть параллельных запросов, только псевдопарарллелизм, что не ускорит, а наоборот скорее замедлит.

← →
Kerk © (2009-11-15 19:42) [18]

> Anatoly Podgoretsky © (15.11.09 18:14) [15]
> > Медвежонок Пятачок (15.11.2009 17:06:11) [11]
>
> Ну да, это они так красиво обозвали всем известный keep-
> alive

Оно было бы так, если б это было единственным нововведением.

← →
Демо © (2009-11-15 20:27) [19]

Я бы сказал, что нужно уметь читать.

Спецификация с точки зрения ускорения говорит следующее:

1. Создаётся одно соединение
2. Все запросы и ответы передаются по единственному соединению
3. Заголовок передаётся один раз при соединении.
4. Весь контент (в том числе и заголовки и запросы) передаются в жатом виде принудительно (GZIP)
5. Все запросы передаются пачкой последовательно не ожидая ответов на них.
6. Все ответы формируются пакетом и высылаются клиенту, который их разбирает.

Как раз все эти пункты вместе дают значительное ускорение.

← →
Демо © (2009-11-15 20:28) [20]

> DVM © (15.11.09 18:45) [17]
>
> > может в гугловском стандарте они могут быть параллельны
>
> через одно соединение не может быть параллельных запросов,
> только псевдопарарллелизм, что не ускорит, а наоборот скорее
> замедлит.

Не путай параллельные потоки в Windows и обмен данными.
Никакого замедления не будет.

← →
DVM © (2009-11-15 21:03) [21]

> Демо © (15.11.09 20:28) [20]

> Не путай параллельные потоки в Windows и обмен данными.

Я и не думал путать. Хотя сходство определенное просматривается.
Повторю еще раз, данные не могут передаваться параллельно по одному соединению. Т.е. невозможно одновременно два send(). Но можно устроить псевдопараллелелизм: каждый пакет(порция) будет содержать данные, относящиеся к разным запросам. В таком случае сборка/разбрка таких пакетов будет отнимать некоторое время, которое может и замедлить пересылку.

← →
DVM © (2009-11-15 21:06) [22]

Собственно ничего нового гугл не придумал. Keep-Alive + сжатие GZIP в HTTP позволяют достичь почти того же самого. Короче, в успех затеи я не верю. Пошумят-пошумят и дело заглохнет.

← →
atruhin © (2009-11-16 07:44) [23]

> Keep-Alive + сжатие GZIP в HTTP позволяют достичь почти
> того же самого.

GZIP в HTTP сжимает только данные, а они предлагают жать и заголовки. Также сейчас даже при keep-Alive, работа осуществляется в режиме запрос-ответ, т.е. сервер получает запрос, анализирует, отдает данные, клиент получает, анализирет, шлет новый запрос (причем на одну страницу таких запрос-ответ, часто десятки). Google предлагает механизм, клиент делает 1 запрос на получение страницы, и сервер пересылает вначале все заголовки (упакованны) и следом ВСЮ страницу, без дополнительных запросов.
Вообще, если на странице много мелких элементов, размер заголовков может превышать %20.
Так что на сложных страницах эффект будет, насколько большой - нужно тестировать.

← →
Медвежонок Пятачок © (2009-11-16 09:05) [24]

и следом ВСЮ страницу

Даже если на странице скажем <img src=""> на другие хосты?
то есть сервер должен еще и сам сдернуть их за клиента со всеми его куками и прочей ерундой?

← →
Дмитрий С © (2009-11-16 09:23) [25]

> Даже если на странице скажем <img src=""> на другие хосты?
>
> то есть сервер должен еще и сам сдернуть их за клиента со
> всеми его куками и прочей ерундой?

Ну это крайность.

> Собственно ничего нового гугл не придумал. Keep-Alive +
> сжатие GZIP в HTTP позволяют достичь почти того же самого.
> Короче, в успех затеи я не верю. Пошумят-пошумят и дело
> заглохнет.

Я такого же мнения.
+ кеш, конечно.

← →
Медвежонок Пятачок © (2009-11-16 09:36) [26]

эта "крайность" вообще-то была одной из основных фич, когда изобрели www.
документ, объединяющий ресурсы с разных уголков сети.

← →
Дмитрий С © (2009-11-16 09:41) [27]

> Медвежонок Пятачок © (16.11.09 09:36) [26]
>
> эта "крайность" вообще-то была одной из основных фич, когда
> изобрели www.
> документ, объединяющий ресурсы с разных уголков сети.

Нее. Крайность не эта фича.
ИМХО, разработчики нового протокола предусмотрят это. Это уж очень очевидная проблема.

PS.
Сначала одни придумывают XML, затем другие SPDY.

← →
Демо © (2009-11-16 11:20) [28]

> atruhin © (16.11.09 07:44) [23]
> > Keep-Alive + сжатие GZIP в HTTP позволяют достичь почти
>
> > того же самого.
>
> Google предлагает механизм, клиент делает 1 запрос
> на получение страницы, и сервер пересылает вначале все заголовки
> (упакованны) и следом ВСЮ страницу, без дополнительных запросов.
>

Немного не так.
- Клиент посылает один заголовок + пакет запросов на страницы.
- Сервер отвечает последовательно на все запросы в одном соединении.

> Медвежонок Пятачок © (16.11.09 09:05) [24]
> и следом ВСЮ страницу
>
> Даже если на странице скажем <img src=""> на другие хосты?
>

Ну в таком случае клиент будет запрашивать именно те хосты, где рисунки находятся...

> Ну в таком случае клиент будет запрашивать именно те хосты,
> где рисунки находятся...

и мы приходим обратно к старому доброму HTTP.

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

Ну и разумеется клиентов.

Более насущные вещи типа IPV6 и то никак не заработают, хотя уж поддержка везде обеспечена, а уж этот новый протокол скорее устареет чем достигнет пользователей. Утопия имхо.

Скорость загрузки страниц повлияет на ранжирование
http://www.webpronews.com/topnews/2009/11/13/google-page-speed-may-be-a-ranking-factor-in-2010
%-\

Вполне вероятно, что уже в следующем году Google модифицирует алгоритмы ранжирования таким образом, что будет учитывать не только релевантность контента и PR, но также и скорость загрузки каждой страницы, сказал один из ведущих программистов компании Мэтт Каттс (Matt Cutts) в интервью WebProNews.com.

> TIF © (17.11.09 03:40) [30]

> Google модифицирует алгоритмы ранжирования таким образом,
> что будет учитывать не только релевантность контента и
> PR, но также и скорость загрузки каждой страницы

То то порадуются дорвейщики, размер страниц которых как правило минимальный.

Вообще если это и будет учитываться, что последним из последних факторов, т.к. важна сама информация а не скорость ее загрузки. Надеюсь, у гугла хватит ума сделать все как надо.

← →
BlahBlahBlah (2009-11-17 18:35) [32]

Вполне вероятно, что уже в следующем году Google модифицирует алгоритмы ранжирования таким образом, что будет учитывать не только релевантность контента и PR, но также и скорость загрузки каждой страницы.

Следует читать:

Ожидается, что уже в следующем году Google модифицирует алгоритмы ранжирования таким образом, что будет учитывать не только релевантность контента, но и, в первую очередь, PR. Ничего личного, просто бизнес Google - реклама.

> BlahBlahBlah (17.11.09 18:35) [32]

Деточка не знает что такое PR?

> BlahBlahBlah (17.11.09 18:35) [32]

Все с точностью до ноборот. PR все меньше и меньше влияет на позицию в выдаче. Пожалуй вообще уже не влияет. И он уходит вообще.

По-моему гугл помешался на ускорении. Сначала скоростной джаваскрипт в хроме, потом SPDY, теперь ещё Google Public DNS:
http://code.google.com/intl/en-us/speed/public-dns/

> TIF © (03.12.09 22:58) [35]
> По-моему гугл помешался на ускорении. Сначала скоростной
> джаваскрипт в хроме, потом SPDY, теперь ещё Google Public
> DNS:http://code.google.com/intl/en-us/speed/public-dns/<Цитата>

Public DNS это вообще супер. Молодцы.

А в чем супер?
пинг до них в районе 80. каждый четвертый пинг - 25 % потерь.
пинг до локального днс - < 1 ms

> А в чем супер?

В IP-адресах 8.8.8.8 и 8.8.4.4 ;)))

> TIF (03.12.2009 23:41:38) [38]

Первый быстрее, цифры более обтекаемые

Вы все еще верите гуглю? Ню-ню. Некоторые социалки по сравнению с гуглевкими тулзами отдыхают. Отладчик в руки и вперед, сюрприз будет...

SPDY - скоростная альтернатива HTTP от Google Найти похожие ветки