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