Думается мне проблема глубже. Мы продолжаем мыслить старыми категориями вещественных товаров, когда как товары постепенно превращаются в информацию и жить по старым представлениям становится, как говориться, контрпродуктивно. Этот же кризис переживает авторское право.
Да все понятно. Автор и переводчик сливаясь в экстазе явно путаются в терминологии, сохраняя при этом умный вид и переступая через абстракции наводят тень на плетень, cшибая по дороге плюсики с лайками.
Мне уже начинает казаться что alizar — рузультат экспериментов яндекса с самообучающимися системами. Уже очень порой напоминает Яндекс.Рефераты. Вроде и слова правильные и по делу, но все вместе вызывает лютую ненависть.
Почитал оригинал.
Осмелюсь предположить, что хитрость в том что бы не дожидаться ack-ов во время отправки пакетов одного большого ответа в пределах одного запроса, а слать пакеты без остановки. А работает все только потому, что к моменту приезда к клиенту, последний уже успел отправить подтверждение и поэтому его переваривает как положено. Cобственно все.
Это даже не tcp — это манипулирование на уровне пакетов. Подойдет только для вещания или передачи действительно очень больших объемов по сети. Ну и требует работы на низком уровне. Для китайских камер самое оно, а вот для серьезных решений не уверен, что подойдет.
Автору следует бояться роутеров, которые проверяют консистентность трафика, а не обновлений браузера.
A spdy асинхронен совершенно по другому приниципу.
Что-то я не понимаю. Он шлет ответ на неотправленный запрос? До того как получил ack?
А как же seq/ack последовательности?
Или речь только о трансляции? Когда манипуляция происходит только внутри одного запроса? Там впринципе сиквенсы можно и предсказать. Тогда уж это баг не в http а в tcp.
Непонятная спорная какая-то статья без подробностей.
Что за глупости, при эксалации конфликта с начальником, в 100% случаев уходит подчиненный. Уверен, подобная предсказуемость и ловкость автора неплохо щелкнули самодура по носу.
Не иначе как, для отправки по одному кадру в пакете не дожидаясь на ack.
Про асинхронные запросы тут и речи нет.
Осмелюсь предположить, что хитрость в том что бы не дожидаться ack-ов во время отправки пакетов одного большого ответа в пределах одного запроса, а слать пакеты без остановки. А работает все только потому, что к моменту приезда к клиенту, последний уже успел отправить подтверждение и поэтому его переваривает как положено. Cобственно все.
Это даже не tcp — это манипулирование на уровне пакетов. Подойдет только для вещания или передачи действительно очень больших объемов по сети. Ну и требует работы на низком уровне. Для китайских камер самое оно, а вот для серьезных решений не уверен, что подойдет.
Автору следует бояться роутеров, которые проверяют консистентность трафика, а не обновлений браузера.
A spdy асинхронен совершенно по другому приниципу.
А как же seq/ack последовательности?
Или речь только о трансляции? Когда манипуляция происходит только внутри одного запроса? Там впринципе сиквенсы можно и предсказать. Тогда уж это баг не в http а в tcp.
Непонятная спорная какая-то статья без подробностей.
Запустил utorrent — получи свинца
После этого появился ru_stack.livejournal.com/