Работу над HTTP 2.0 предлагают начать заново

[@mentatxx]

А что конкретно не так со SPDY?
Какие проблемы не решает?
Статье не хватает конкретики, одни общие фразы.

[@Rondo]

А разгадка одна

Статья без конкретики, общие фразы,
Под офисным креслом чувствую жар,
Нам не сбежать от этой заразы,
Еще один пост написал Ализар.

[@zomby]

День поэзии на Хабре :)

[@Assorium]

Ну зато хоть стиль заголовков изменил

[@philpirj]

Cookies. Множество заголовков. Односторонняя связь. Все то же, что и в 1.2, лишь чуть меньше на tls и постоянное соединение.

[@tequilla4white]

Не знаю, что имел ввиду Пол-Хеннинг Камп, но у SPDY есть как минимум следующие проблемы:

a) Single packet delay induces head-of-line blocking for a stream. Since TCP only provides a single serialized stream interface, a delay of only one packet causes the entire set of SPDY streams to pause. A packet is routinely delayed when a packet is lost, such as due to congestion, and it must be retransmitted. A better multiplexed transport should delay only one stream when a single packet is lost.

b) Unfavorable congestion avoidance handling by TCP, leading to additional bandwidth reduction and serialization latency overhead: A single SPDY connection is routinely used to replace K separate (non-multiplexed) connections. When a single packet of a SPDY (over TCP) connection is lost, the congestion window for the entire connection was historically reduced by 50%, courtesy of TCP [TCP CUBIC default congestion window reduction is roughly 30%, but the factor of 2 simplifies the math in this paragraph’s exposition]. In contrast, a single packet loss among K non-multiplexed TCP connections only reduces the congestion window in one TCP connection. With only one of K streams impacted by a loss, the aggregate congestion window is reduced by roughly 1/2K of the pre-loss aggregate. With K commonly having a value of 6 (for multiple HTTP GET requests), a single packet loss causes bandwidth reduction to 11/12 of the pre-loss bandwidth (pre-loss congestion window size). As a result, TCP congestion avoidance favors sharded (multiple) TCP connections over a multiplexed TCP connection.

Source: QUIC: Design Document and Specification Rational

[@meta4]

>здесь Камп ссылается на Фредерика Брукса и книгу «Мифический человеко-месяц

Надо сказать что Брукс потом поменял точку зрения на эту тему (о чем он пишет в последних изданиях этой книги).

[@Xlab]

предлагают начать сначала

Open source разработчик Пол-Хеннинг Камп обратился

В чём смысл замены числа в заголовке, м?

[@philpirj]

Стоит, видимо, подождать развития SPDY, и ожидать что он станет стандартом де-факто. Эти комиссии не всегда влияют на разработку протоколов положительно, стоит вспомнить хотя бы OAuth2. Увы, SPDY приходится оглядываться на HTTP 2, а могли бы идти своей дорогой и вообще отойти в сторону от обратной совместимости (кроме как fallback при установлении соединения).

[@equand]

Я уже писал не раз, что HTTP 2.0 не решает проблемы HTTP, а решает проблемы Google, Microsoft, Facebook, Yahoo.

То есть добавка drm и трекинга пользователей + уменьшение соединений.

[@ProgerXP]

Эх, видимо прошли времена теплого лампового W3C и IETF. Особенно после принятия ими EME… Коммерция торжествует :(

[@bytecode_rus]

как именно http2 добавляет drm?

[@allter]

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

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

Собственно, усложнение спецификаций затрудняет понимание протокола программистом, из-за чего проверить утверждение «http2 НЕ добавляет DRM» — также сложно.

[@equand]

Оно не то что добавляет, а облегчает задачу использования нативного html5ого drm с функционалом мультиплексирования, бинарностью и односессионностью.

[@bytecode_rus]

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