Comments 35
Из поясняющей картинки к посту можно предположить, что SPDY — машина для героев и самоубийц, время наработки которой на отказ составляет 2-3 часа в лучшем случае…
Если не ошибаюсь то машина HTTP на картинке, это Rolls — Royce. А как принято говорить, продукт лидирующий по качеству в своей сфере, это Роллс — Ройс среди этих продуктов. Значит HTTP — Роллс — Ройс среди протоколов.
spdy.indutny.com/ — А тут можно попробовать ;)
Warning! No SSL certificate at the moment!
Warning! No SSL certificate at the moment!
>SPDY «выйдет в народ» еще не скоро
Думаю гуглхром пользователи, при использовании сервисов гугл, опробуют очень даже скоро.
Думаю гуглхром пользователи, при использовании сервисов гугл, опробуют очень даже скоро.
О чем новость? Сервисы у гугла работают на SPDY в Crome уже, наверное с год.
Наберите в Chrome about:net-internals
И там будет исчерпывающий список всех сервисов что используют SPDY.
Наберите в Chrome about:net-internals
И там будет исчерпывающий список всех сервисов что используют SPDY.
Вообще да, gmail стал заметно живее бегать.
Так. Че-то не вполне понятно. Читаю тут:
Ну и вообще — пробежался глазами этот whitepaper — как-то не видно революции. Единственное, что существенное сделали: мультиплексируют передачу разных данных по одному tcp-соединению с возможностью грузить все одновременно, а не ждать, пока все прогрузится по этому соединению по очереди… Спрашивается — и это все???? Если уж вводить новые стандарты/протоколы, то прорыв должен быть и все такое… Или я чего-то не не так понял и чего-то существенного не увидел? Ткните тогда, плиз, пальцем в конкретику.
Q: Is SPDY a replacement for HTTP?
A: No. SPDY replaces some parts of HTTP, but mostly augments it. At the highest level of the application layer, the request-response protocol remains the same. SPDY still uses HTTP methods, headers, and other semantics. But SPDY overrides other parts of the protocol, such as connection management and data transfer formats.Ну и вообще — пробежался глазами этот whitepaper — как-то не видно революции. Единственное, что существенное сделали: мультиплексируют передачу разных данных по одному tcp-соединению с возможностью грузить все одновременно, а не ждать, пока все прогрузится по этому соединению по очереди… Спрашивается — и это все???? Если уж вводить новые стандарты/протоколы, то прорыв должен быть и все такое… Или я чего-то не не так понял и чего-то существенного не увидел? Ткните тогда, плиз, пальцем в конкретику.
Прорыв конечно нужен, но важно еще и соотношение пользы от этого «прорыва» со стоимостью модернизации уже существующего программного обеспечения. В данном случае, когда существует уже огромный набор работающих веб приложений (весь WWW), целесообразно делать изменения такими, которые бы обеспечивали прозрачную работу уже существующих приложений и серверов. Поэтому от многих парадигм HTTP еще не скоро отойдут.
И я даже продолжу мысль — нужно было его предложить соответствующим стандартизирующим организациям, дабы это вошло в официальные спецификации стандартов. А иначе это на фиг никому ни сдалось… И вообще возникает ощущение, что Гугл прост решил лично для себя сделать ускорительную фишку, а о совершенствовании стандартов и скорости доступа в Интернет он в целом как-то не особо и задумывается…
В HTTP/1.1 давным-давно есть pipelined requests. Какое преимущество может дать спидошное мультиплексирование, я как-то не улавливаю.
Сходите по ссылочке, что у меня в комменте есть — они там про это тоже пишут. Если в тезисах, то при pipelined requests если один из реквестов тормозит, то остальные его стоят и ждут. А они все мультиплексируют и асинхронно фигачат по одному tcp-соединению — в этом и бонус.
Ждём заявление от мелкомягких о проблемах в безопасности данной технологии.
"Microsoft seems to hate everything Google does," said Måns Jonasson, a web developer at IIS.
Sign up to leave a comment.
Поддержка протокола SPDY внедрена в сервисы Google