Pull to refresh

Comments 35

UFO just landed and posted this here
В Opera Mini (и вероятно в Opera Turbo) это давно используется. Из новости не понял, делает ли SPDY бинаризацию HTML.
Из поясняющей картинки к посту можно предположить, что SPDY — машина для героев и самоубийц, время наработки которой на отказ составляет 2-3 часа в лучшем случае…
Если не ошибаюсь то машина HTTP на картинке, это Rolls — Royce. А как принято говорить, продукт лидирующий по качеству в своей сфере, это Роллс — Ройс среди этих продуктов. Значит HTTP — Роллс — Ройс среди протоколов.
Слишком — много — тире.
Ставил сколько надо, не знаю почему так вышло.
Тест: Роллс — Ройс.
Пробелы уберите, останется нормальное тире =)
Роллс-ройс
Что-то мне подсказывает, что на Хабре несколько дефисов подряд преобразуются в тире.
Тест — Тест
Тест — Тест
Тест — Тест
Смеялся до слёз. Спасибо!
В фильме сказанно что пилот veiler погиб 17.05.30-го в результате взрыва тех смесей.
Зачётный «ракетенваген» :)
Der Raketenmotor!

Аж в карму заплюсовал, спасибо!
Как-то под хромом скорость не впечатляет. Открывалось медленнее чем сайт джитхаба.
Не совсем понятно кто и почему в карму минусует. Кого-то обидел?
>SPDY «выйдет в народ» еще не скоро
Думаю гуглхром пользователи, при использовании сервисов гугл, опробуют очень даже скоро.
О чем новость? Сервисы у гугла работают на SPDY в Crome уже, наверное с год.
Наберите в Chrome about:net-internals
И там будет исчерпывающий список всех сервисов что используют SPDY.
дык давно уже gmail через spdy идёт: about:net-internals
Так. Че-то не вполне понятно. Читаю тут:
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 еще не скоро отойдут.
UFO just landed and posted this here
И я даже продолжу мысль — нужно было его предложить соответствующим стандартизирующим организациям, дабы это вошло в официальные спецификации стандартов. А иначе это на фиг никому ни сдалось… И вообще возникает ощущение, что Гугл прост решил лично для себя сделать ускорительную фишку, а о совершенствовании стандартов и скорости доступа в Интернет он в целом как-то не особо и задумывается…
UFO just landed and posted this here
В HTTP/1.1 давным-давно есть pipelined requests. Какое преимущество может дать спидошное мультиплексирование, я как-то не улавливаю.
Сходите по ссылочке, что у меня в комменте есть — они там про это тоже пишут. Если в тезисах, то при pipelined requests если один из реквестов тормозит, то остальные его стоят и ждут. А они все мультиплексируют и асинхронно фигачат по одному tcp-соединению — в этом и бонус.
Я ходил, но, похоже, слишком по диагонали читал и думал :)
Ждём заявление от мелкомягких о проблемах в безопасности данной технологии.
Sign up to leave a comment.

Articles

Change theme settings