Пользователь
30,2
рейтинг
27 мая 2014 в 18:35

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

Open source разработчик Пол-Хеннинг Камп (Poul-Henning Kamp) обратился к членам HTTP Working Group с призывом выбросить текущие наработки по стандарту HTTP 2.0.

Пол-Хеннинг Камп — автор MD5crypt и большого количества системных компонентов FreeBSD, GBDE, UFS2, malloc и проч. Он считает, что рабочей группе HTTP следует признать поражение — и начать всё заново.

В качестве образцового фиаско Пол-Хеннинг Камп приводит пример SPDY. В классических произведениях по управлению проектами сказано, что «прототип системы всегда нужно выбрасывать», здесь Камп ссылается на Фредерика Брукса и книгу «Мифический человеко-месяц или Как создаются программные системы». По его словам, принятый за основу спецификаций HTTP 2.0 протокол SPDY является именно прототипом.

SPDY приняли ещё до того, как рабочая группа завершила выполнение своего предыдущего задания, а затем потратила много времени, чтобы довести SPDY до ума, исправляя недочёты и ошибки.

И потом все внезапно обнаружили, что SPDY даже близко не решает множество важных проблем, для которых придётся прибегнуть к некоторому упрощению самой концепции HTTP.

Письмо Кампа направлено в ответ на признание председателя рабочей группа Марка Ноттенгэма, что «мы можем не сделать всё правильно в HTTP 2.0, и до сих пор не со всем справились», и поэтому решено «начать обсуждение HTTP 3.0». Ноттенгэм подчёркивает, что рабочая группа трудится в условиях жёстких дедлайнов, в спешке.

«Теперь даже председатель рабочей группы публично признаёт, что результат работы — частичное фиаско и что нам придётся заменить HTTP 2.0 на что-то лучшее “скоро”, — возмущается Пол-Хеннинг. — Так что конкретно мы получаем от продолжения этой работы? Может быть, лучше гораздо глубже рассмотреть текущую ситуацию с криптографией и защитой приватных данных, чем публиковать протокол с криптографической “заплаткой”, которая не решает проблем и мешает во многих приложениях?»

По мнению разработчика, принятие стандарта HTTP 2.0 только потому, что пришёл дедлайн и это нужно сделать по процедуре, никому не нужно, а только отнимает у всех время, ведёт к дополнительным рискам безопасности без какой-либо существенной пользы.

«Не будет ли быстрее сразу приступить к решению настоящей задачи — созданию протокола, который _может_ заменить HTTP 1.1 во всех сценариях и действительно будет улучшением во _всех_ сценариях?», — задаёт риторический вопрос Пол-Хеннинг Камп. Он призывает считать SPDY интересным прототипом, который явно показал на необходимость улучшения HTTP 1.1, но немедленно приняться за разработку нового протокола, заменяющего HTTP 1.1 (с учётом всех наработок SPDY).
Анатолий Ализар @alizar
карма
749,5
рейтинг 30,2
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (19)

  • +12
    А что конкретно не так со SPDY?
    Какие проблемы не решает?
    Статье не хватает конкретики, одни общие фразы.
    • +139
      А разгадка одна
      Статья без конкретики, общие фразы,
      Под офисным креслом чувствую жар,
      Нам не сбежать от этой заразы,
      Еще один пост написал Ализар.
    • 0
      Я так понял, критику не нравятся решения в области криптографии и безопасности. Однако, конкретики действительно нет, предложение неконкретно, и почему нельзя подойти к вопросу итеративно, непонятно. В общем, критиковать может кто угодно, но вряд ли такая неконструктивная критика будет иметь сколь-либо значимые последствия. В рассылках есть много писем, тема для хабра высосана из пальца.
      • 0
        В рассылках есть много писем, тема для хабра высосана из пальца.
        Это, видимо, репост с фороникса
    • +5
      Cookies. Множество заголовков. Односторонняя связь. Все то же, что и в 1.2, лишь чуть меньше на tls и постоянное соединение.
    • +11
      Не знаю, что имел ввиду Пол-Хеннинг Камп, но у 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
      • 0
        Это проблемы на уровне сетевого протокола, то есть на уровне TCP, а не HTTP, поэтому и придумали QUIC вместо TCP. Он вполне может использоваться вместе со SPDY.
  • +2
    >здесь Камп ссылается на Фредерика Брукса и книгу «Мифический человеко-месяц

    Надо сказать что Брукс потом поменял точку зрения на эту тему (о чем он пишет в последних изданиях этой книги).
  • –1
    предлагают начать сначала
    Open source разработчик Пол-Хеннинг Камп обратился
    В чём смысл замены числа в заголовке, м?
  • +8
    Согласен с тезисом, что в таких важных документах, как HTTP 2.0 не стоит жёстко привязываться к дедлайну. Всё остальное достаточно спорно.
  • –2
    Стоит, видимо, подождать развития SPDY, и ожидать что он станет стандартом де-факто. Эти комиссии не всегда влияют на разработку протоколов положительно, стоит вспомнить хотя бы OAuth2. Увы, SPDY приходится оглядываться на HTTP 2, а могли бы идти своей дорогой и вообще отойти в сторону от обратной совместимости (кроме как fallback при установлении соединения).
  • +20
    Я уже писал не раз, что HTTP 2.0 не решает проблемы HTTP, а решает проблемы Google, Microsoft, Facebook, Yahoo.

    То есть добавка drm и трекинга пользователей + уменьшение соединений.
    • +1
      Эх, видимо прошли времена теплого лампового W3C и IETF. Особенно после принятия ими EME… Коммерция торжествует :(
    • +5
      как именно http2 добавляет drm?
      • –1
        Ну, например, мультиплексирование потоков затруднит атаки на EME связанные с попыткой анализа контента и тайминга его передачи.

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

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.