HTTP/2.0 — Халтура от IETF: плохой протокол, плохая политика

Original author: Poul-Henning Kamp
  • Translation
Давным давно, в начале 1989 года, Рональд Рейган ещё был президентом, хотя до окончания его срока оставалось 19½ дней. А перед тем, как 1989 год подошел к концу, родилась Тейлор Свифт, а Андрей Сахаров и Сэмюэл Беккет скончались.

В долгосрочной перспективе, наиболее значительным событием 1989 скорее всего станет то, что Тим Бернерс-Ли заложил основы протокола HTTP и назвал результат «World Wide Web». (Одно примечательное свойство этого имени состоит в том, что аббревиатура «WWW» имеет в два раза больше слогов и требует больше времени для произнесения.)

Протокол HTTP, предложенный Тимом, работал в 10-мегабитных сетях с коаксиальными кабелями, а его компьютером был NeXT Cube с частотой 25 МГц. 26 лет спустя, в моем ноутбуке установлен процессор в сотни раз быстрее, а оперативной памяти в тысячи раз больше, чем было на компьютере Тима, но протокол HTTP всё тот же.

Несколько дней назад рабочая группа IESG (The Internet Engineering Steering Group) запросила последние комментарии по новому протоколу HTTP/2.0 (https://tools.ietf.org/id/draft-ietf-httpbis-http2) перед тем, как утвердить его в качестве официального стандарта.

[Спустя пару месяцев с минимальными изменениями стандарт был утвержден. — прим. пер.]

Ожидания будут отличаться


Кто-то ожидает, что существенное обновление наиболее распространенного в мире протокола станет шедевром, каноническим примером для будущих студентов в области дизайна протоколов. Кто-то ожидает, что протокол, разработанный во времена разоблачений Сноудена, должен повысить конфиденциальность. Другие же цинично ждут обратного. В целом есть ожидание некоторого «ускорения». Многие возможно также предполагают «экологичность». И некоторые из нас достаточно пресыщены, чтобы увидеть «2.0» и пробормотать «ой-ой, синдром второй системы».

Шпаргалка с ответами: нет, нет, скорее всего нет, возможно, нет, да.

Если это звучит разочаровывающе, то только потому, что так оно и есть.

HTTP/2.0 — это не шедевр технической мысли. Он нарушает целостность отдельных, ранее изолированных слоев, переусложнен, содержит кучу нестыковок, плохих компромиссов, упущенных возможностей и т. д. На моем (гипотетическом) курсе по разработке протоколов студенты провалились бы, если бы предложили такой протокол. HTTP/2.0 также не повысит вашу конфиденциальность. Запаковывание HTTP/2.0 в SSL/TLS может повысить, а может не повысить её, также как запаковывание HTTP/1.1 или любого другого протокола в SSL/TLS. Но HTTP/2.0 сам по себе не делает ничего для повышения конфиденциальности. Крайне иронично, учитывая что основное бремя HTTP — куки, которые являются настолько серьзной проблемой, что в Евросоюзе есть законодательное требование уведомлять о них. HTTP/2.0 мог бы избавиться от кук, заменив их на полностью контролируемый клиентом идентификатор сессии. Что дало бы пользователям четкое право распоряжаться тем, когда они хотят быть отслеживаемы, а когда нет — существенное улучшение по части конфиденциальности. Это бы также сэкономило трафик. Но предлагаемый стандарт не делает этого.

Хорошая новость в том, что HTTP/2.0 скорее всего и не понизит вашу конфиденциальность. Хотя он добавляет несколько возможностей для отслеживания со стороны сервера, но уже существует множество способов с помощью кук, JavaScript, Flash, т. д., что это, скорее всего, не имеет значения.

Вы можете заметить, что страницы загружаются быстрее с HTTP/2.0, но скорее всего только если у поставщика контента огромная сеть серверов. Отдельные компьютеры, включая ваш собственный, будут вынуждены тратить больше ресурсов, в особенности для больших объектов, как музыка, телепередачи, фильмы и т. д. Никто не продемонстрировал реализацию HTTP/2.0, которая бы могла приблизиться к современным скоростям передачи данных. Быстрее? Вовсе нет.

Есть и ответ на вопрос о влиянии на окружающую среду: HTTP/2.0 требует больше вычислительных ресурсов, нежели HTTP/1.1, и таким образом, повысив выбросы CO2, ускорит климатические изменения. Вы могли бы предполагать, что протокол предназначенный для десятков миллионов компьютеров будет объектом рассмотрения с точки зрения экологии, но к удивлению, по крайней мере моему, я не нашел каких-либо свидетельств тому, что IETF вообще заботилась о вопросах влияния на окружающую среду.

И да, синдром второй системы силен.

Принимая во внимание столь посредственный результат, вам скорее всего интересно, так почему HTTP/2.0 вообще рассматривается в качестве стандарта.

Ответ прост — политика


В Google придумали протокол SPDY, и поскольку у них имеется свой браузер, они могут экспериментировать как им угодно, оптимизируя протокол под их конкретные нужды. SPDY был хорошим прототипом, который ясно показал, что тут есть потенциал для улучшения в новой версии HTTP. Поклон Google за это. Но SPDY также стал чем-то вроде «сада за высокими стенами» для других людей и, что важно, для других компаний, вот политика и всплыла.

Организация IETF, очевидно ощущая свою никчемность, быстро «обнаружила», что протоколу HTTP/1.1 требуется обновление, озадачила рабочую группу подготовить его в нереально короткие сроки. Что исключило какую-либо иную основу для нового протокола HTTP/2.0, нежели протокол SPDY. Выбросив наиболее отвратительные огрехи SPDY и отклоняя любые другие попытки усовершенствования с резолюциями типа «вне повестки», «слишком поздно», «нет консенсуса», IETF теперь может показать свою причастность и объявить победу, пожертвовав практически всеми принципами, которыми дорожила, в обмен на привилегию штамповать инициативу Google.

Но политика на этом не заканчивается.

Причина, по которой HTTP/2.0 не повысит конфиденциальность, заключается в том, что большие покровительствующие корпорации построили свою бизнес-модель на отсутствии конфиденциальности. Их очень расстраивает, что NSA шпионит почти что за каждым во всем мире, но они не хотят делать что-либо, что помешало бы им заниматься тем же. Сторонники протокола HTTP/2.0 пытаются использовать его как рычаг для навязывания SSL повсеместно, несмотря на то, что для множества применений HTTP шифрование не требуется, оно нежелательно или даже может быть нелегальным.

Сайт МЧС в вашей стране, округе или городе


Местные власти не желают тратить ресурсы на SSL/TLS соединения с каждым смартфоном на территории, когда что-то взрывается, реки выходят из берегов или люди отравились. Крупнейшие новостные сайты аналогично предпочитают иметь возможность сообщить новость, чем скрыть тот факт, что они сообщают новости, особенно если что-то серьезное произошло. (Неужели в IETF все забыли график экспоненциального роста трафика на сайтах CNN 14 лет назад? — [прим. пер.: тут автор апеллирует к терактам 11 сентября 2001 в США]).

Так называемый «мультимедиа-бизнес» [имеется в виду порно — прим. пер.], что составляет почти 30% всего трафика в сети, также не желает вынуждено тратить ресурсы на бессмысленное шифрование. Существуют категории людей, которые легально лишаются конфиденциального обмена информацией: дети, заключенные, финансовые трейдеры, аналитики ЦРУ, и т. д. Всё же, несмотря на это, HTTP/2.0 будет работать только с SSL/TLS по крайней мере во всех основных браузерах с целью навязать конкретную политику. По иронии, те же самые браузеры рассматривают самоподписные сертификаты как смертельную опасность, несмотря на тот факт, что такие сертификаты позволяют легко добиться секретности. (Секретность означает, что только вы и другая сторона можете расшифровать переписку. Конфиденциальность — это секретность с идентифицированной или аутентифицированной стороной.)

История ярко показала то, что если вы хотите изменить мир к лучшему, то вам стоит представить хорошие инструменты для изменения мира к лучшему, а не политику для изменения его к лучшему. Я советую всем, у кого есть голос в этом деле, показать палец вниз HTTP/2.0: это не хороший протокол, и это даже не хорошая политика.

Об авторе


Поуль-Хеннинг Камп (phk@FreeBSD.org) один из основных разработчиков операционной системы FreeBSD, над которой работал с самого начала. Он широко «неизвестен» своим алгоритмом шифрования паролей на основе MD5, который защищает пароли на маршрутизаторах Cisco, Juniper, а также Linux и FreeBSD системах. Некоторые могли заметить, что он написал менеджер памяти, файловую систему и метод шифрования дисков, который реально работает. Камп живет в Дании со своей женой, сыном, дочерью, дюжиной компьютеров с FreeBSD, а также с одними из самых точных в мире NTP часов. Он зарабатывает на жизнь как независимый эксперт, занимаясь всевозможными задачами в области компьютеров и сетей.

[Также является автором Varnish (HTTP-акселератора и кэширующего прокси) — прим. пер.]
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 79

    0
    Валентин, вы согласны с автором?
      +7

      Согласен.

      0
      Последний раздел «ЧП в вашей стране, вашем округе или городе?» ужасен. Несколько раз пытался продраться через дебри этого текста, и все еще не был уверен, правильно ли его понимаю. А потом посмотрел оригинал, и понял, что это перевод такой. Your Country, State, or County Emergency Webpage — это не ЧП, это сайт/страница МЧС, в наших реалиях, призванные сообщать о ЧП. И именно к сайту относится все, что написано про SSL.

      Кстати, я тут не согласен с автором. SSL это один из немногих, если не единственный, способ, чтобы идентифицировать сервер для клиента. И даже если медиа-бизнесу наплевать, что клиенту подсунут вместо настоящего сайта фейк с троянами, то клиенту это вовсе не безразлично.
        +2

        Можете предложить более точный и благозвучный перевод? В абзаце не идет речь о конкретной страничке, а скорее о том, что в условиях чрезвычайной ситуации приватность уходит на второй план и куда важнее сохранить возможность распространять информацию, чем тратить ресурсы на её шифрование.


        P.S. Переименовал пока в "Сайт МЧС..."

          0
          Так уже лучше. В принципе, сам автор неосознанно говоря про SSL смешивает разные вещи — конфиденциальность (и шифрование трафика), которая действительно нужна не всегда, и некоторые гарантии, например что сервер не подменили (взломав DNS или прокси). И это мешает понимать действительно разумные вещи.
            +1
            Ну так проблему проверки достоверности информации можно было бы решить цифровой подписью ответа, который можно еще и закэшировать, что в результате решает проблему многократно эффективней нежели шифрование трафика между клиентом и сервером.
          +1
          Мне кажется здесь не идет речи, что весь SSL не нужен. Речь о том, что во многих случаях нужна всего лишь часть SSL — например, целостность данных. Многим не важно, открыт ли трафик. Для многих шифрование это даже неудобство и лишняя головная боль. Зато очень важно иметь гарантию, что данные дошли без изменений. SSL же содержит все и сразу. Можно конечно сказать, что есть NULL cipher, но, судя по всему, браузеры его не поддерживают, а значит мы получаем или все сразу, или вообще ничего.
          0
          Кстати, на счёт безопасности и NSA, тут недавно пробегала интересная новость: https://www.reddit.com/r/sysadmin/comments/4l7rld/bluecoat_a_company_which_makes_tls_mitm_equipment/
            0
            В чем новость? У Яндекса тоже есть свой CA, думаете через него ФСБ прослушивает трафик?
              +5
              Производитель железа для TLS MitM и CA сертификат, которому доверяет абсолютное большинство браузеров? Нет, что вы, ничего страшного :)
                0
                Во-первых это производитель корпоративных файрволов, а во-вторых прочтите ветку комментариев по своей ссылке, в-третьих любая компания может получить свой подчинённый CA — это вопрос денег и времени.

                белки_истерички.jpg
                  0
                  Во-первых, корпоративные CA почти всегда самоподписные, и для работы именно корпоративного MitM не нужно иметь «настоящий» CA, которому бы доверяли некорпоративные браузеры, тем более для тестирования.

                  Во-вторых, если какая-то компания начнёт подписывать своим CA левые сертификаты у неё этот CA очень быстро отберут, примеры были.

                  Ну и в третьих, «Blue Coat equipment has been sold to the governments of Bahrain, Burma (Myanmar), China, Egypt, India, Indonesia, Iran, Iraq, Kenya, Kuwait, Lebanon, Malaysia, Nigeria, Qatar, Russia, Saudi Arabia, Singapore, South Korea, Syria, Thailand, Turkey, the United Arab Emirates, and Venezuela.» И нету ни одной причины, почему-бы их железо не стояло в других странах.
                    0
                    корпоративные CA почти всегда самоподписные, и для работы именно корпоративного MitM не нужно иметь «настоящий» CA, которому бы доверяли некорпоративные браузеры, тем более для тестирования

                    А кто сказал, что сертификат CA будут использовать именно для этого?
                    если какая-то компания начнёт подписывать своим CA левые сертификаты у неё этот CA очень быстро отберут, примеры были.

                    Я в курсе и не понимаю к чему эта паника. Была же история с разработчиками прокси-сервера, которые поставили свой сертификат на железку во внутренней сети и лишились его за нарушение CPS после запуска Хрома с google.com.

                    На реддите в топе отличный комментарий, где всё это разжовано.
                      0
                      Всё так до тех пор, пока условный Symantec (issuer) считает обладателя такого CA злоумышленником. Разработчик прокси-сервера — злоумышленник, компания, работающая по заказу какого либо правительства (желательно, конечно, правительство дружественной для США страны, т.к. Symantec всё же американская компания) — нет.
            0
            Он нарушает целостность отдельных, ранее изолированных слоев, переусложнен, содержит кучу нестыковок, плохих компромиссов, упущенных возможностей и т. д.

            Какую целостность, о чём вообще речь?

            HTTP/2.0 также не повысит вашу конфиденциальность.

            Повышает, поскольку его будут по-дефолтку включать с шифрованием, а чтобы включить его без шифрования — нужно будет ещё постараться и не факт, что выйдет. С предыдущими стандартами было наоборот.

            HTTP/2.0 мог бы избавиться от кук, заменив их на полностью контролируемый клиентом идентификатор сессии.

            И сломать миллионы веб-приложений.

            Вы можете заметить, что страницы загружаются быстрее с HTTP/2.0, но скорее всего только если у поставщика контента огромная сеть серверов.

            Ну то есть каждый день при пользовании Google, Facebook, Gmail и т.д.

            HTTP/2.0 требует больше вычислительных ресурсов, нежели HTTP/1.1, и таким образом, повысив выбросы CO2, ускорит климатические изменения

            И шифрование, и сжатие было можно включать и для HTTP/1.1. Более того, для HTTP/2.0 нужно сжимать\разжимать существенно меньше заголовков.

            Раздел о политике написан странно. Да, IETF подхватила инициативу Гугла, взяв уже и так неплохо работающий SPDY и сделав его лучше. А что надо было делать — с нуля писать? А зачем?

            Так называемый «мультимедиа-бизнес», что составляет почти 30% всего трафика в сети, также не желает вынуждено тратить ресурсы на бессмысленное шифрование.

            То-то Youtube и Netflix насильно переводят все соединения в HTTPS.

            Существуют категории людей, которые легально лишаются конфиденциального обмена информацией: дети, заключенные, финансовые трейдеры, аналитики ЦРУ

            Если этим людям кто-то запрещает конфиденциальность — то это его дело обеспечить соблюдение данного запрета. Просто не разрабатывать какие-то технологии из-за того, что в мире есть люди, которым ими пользоваться будет нельзя — это чушь.
              +16
              Какую целостность, о чём вообще речь?

              Речь о том, что протокол представляет из себя один большой layering violation и занимается не тем, чем ему положено заниматься на данном уровне, а также лезет в соседние. HTTP/2.0 это ещё один транспортный уровень со своим собственным пакетным слоем, управлением потоком, QoS-ом и т.д. навернутый поверх другого транспортного протокола. Но этого мало, почему бы HTTP/2 ещё не вмешиваться в TLS? С какой-то стати спецификация HTTP/2 содержит требования к версии TLS и черный список шифров.

              Повышает, поскольку его будут по-дефолтку включать с шифрованием, а чтобы включить его без шифрования — нужно будет ещё постараться и не факт, что выйдет. С предыдущими стандартами было наоборот.

              Как только что-то начинает использоваться массово к месту и не к месту, то сразу на это находится соответвующая отмычка, а если не находится, то закрепляется на законодательном уровне в виде промежуточного прокси и сертификата, который все жители страны должны добавить в доверенные, иначе не смогут в интернет выйти.

              И сломать миллионы веб-приложений.

              Никто никого не заставляет переходить на новый протокол срочно, в этом нет никакой острой необходимости. Протокол, который работал последние 20 лет, может проработать и еще 10 без проблем. Но нет, давайте на коленке соберем из костылей и палок некое поделие и пропихнем его в качестве стандарта, чтобы потом разработчики веб-серверов и браузеров, мучились и локти грызли. А затем будут мучаться администраторы, потому что HTTP/2 — это еще какой вектор для DoS атак.

              К слову, HTTP/2 в плане поломки веб-приложений совсем не безгрешен.

              Ну то есть каждый день при пользовании Google, Facebook, Gmail и т.д.

              Желание определенных корпораций, чтобы выход в интернет ограничивался их сайтами — оно вполне понятно.

              И шифрование, и сжатие было можно включать и для HTTP/1.1. Более того, для HTTP/2.0 нужно сжимать\разжимать существенно меньше заголовков.

              Зато существенно больше служебных данных.

              Раздел о политике написан странно. Да, IETF подхватила инициативу Гугла, взяв уже и так неплохо работающий SPDY и сделав его лучше. А что надо было делать — с нуля писать? А зачем?

              Гугл, в свою очередь, набив шишек со SPDY пошел копать в сторону QUIC. SPDY — был прототипом, написанным маленькой группой людей под свои нужды, который реализовывал конкретную идею с определенной конкретной целью, хорошим его сложно было назвать, он просто работал, тяп-ляп, но работал. Брать и делать на скорую руку из этой поделки новый фундаментальный стандарт интернета — ну прямо скажем, идея очень плохая.

              То-то Youtube и Netflix насильно переводят все соединения в HTTPS.

              Политика. Технических показаний для этого нет, переводят и страдают. А вместе с тем страдает батарейка вашего смартфона.

              Если этим людям кто-то запрещает конфиденциальность — то это его дело обеспечить соблюдение данного запрета. Просто не разрабатывать какие-то технологии из-за того, что в мире есть люди, которым ими пользоваться будет нельзя — это чушь.

              Как явно обозначено в статье, HTTP/2.0, как протокол, не дает ровным счетом никаких технических средств для обеспечения конфиденциальности. Просто используется сторонниками «SSL everywhere» как плацдарм для навязывания своей точки зрения.
                0
                занимается не тем, чем ему положено заниматься на данном уровне, а также лезет в соседние

                Ок, занимается и лезет. Возьмите каждого первого пользователя и спросите его, что для него важнее, чтобы протокол не лез на чужие уровни ответственности сетевого стека или чтобы фейсбучек загружался на 1.5 секунды быстрее. Послушайте ответ и задумайтесь, что вообще первично — потребности пользователей или стройность картины мира в голове сетевиков и программистов.

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

                Проблемы тоталитарных стран — это не вопрос к протоколу. Какой бы протокол не придумали — можно ввести в стране смертную казнь за пользование компьютером и вдруг окажется, что протокол на данной территории не эффективен, поскольку никто им не пользуется.

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

                Если бы был предложен кардинально новый протокол, требующий переписывания всего кода, то никто бы в жизни его не стал использовать. Ни сейчас, ни через 10 лет.

                Гугл, в свою очередь, набив шишек со SPDY пошел копать в сторону QUIC

                Ну, во-первых SPDY и QUIC начали пилиться примерно в одно время (см. википедию). Во-вторых, успех SPDY очевиден в виду его взятия за основу стандарта HTTP/2 и поддержки всеми основными браузерами. На сегодня протокол элементарно включается на стороне сервера и шустренько бегает у любого пользователя, за исключением свидетелей секты шестого IE, принципиально не обновляющихся. Успех QUIC пока очень ограничен, до массовости пока далеко.

                Просто используется сторонниками «SSL everywhere» как плацдарм для навязывания своей точки зрения.

                Типа их позиция — это какое-то зло и проталкивать её плохо?
                  +9
                  Ок, занимается и лезет. Возьмите каждого первого пользователя и спросите его, что для него важнее, чтобы протокол не лез на чужие уровни ответственности сетевого стека или чтобы фейсбучек загружался на 1.5 секунды быстрее. Послушайте ответ и задумайтесь, что вообще первично — потребности пользователей или стройность картины мира в голове сетевиков и программистов.

                  Начать стоит с того, что иногда будет быстрее, иногда медленнее, а иногда вообще никак. Увеличение скорости отображения страницы достигается только при определенных условиях и на хорошем канале без потери пакетов. Если речь идет о той же мобильной сети, с нестабильными уловиями, плохом соединении или каких-то еще случаях выходящих за рамки определенных условий, то HTTP/2 даже проигрывает, поскольку одно TCP соединение — всегда хуже, чем 6. Плюс у HTTP/2 банально выше накладные расходы, на передачу того же объема данных в HTTP/2 по факту нужно послать больше информации, чем в HTTP/1.x. А 1.5 секунды вы можете увидеть только в маркетинговых материалах и на искуственных тестах в искуственных условиях. Реальные цифры не так впечатляют.

                  Второй момент заключается в том, что подход, а давайте сделаем костылей, зато сразу — он очень плохо работает в глобальном масштабе. Вы же обманите пользователя, если поставите вопрос в таком виде. Спросите лучше, а что ему важнее, гарантированная и стабильная работа или ускорение на 200-400 мс в некоторых случаях? Можно ещё также упомянуть, что в цену этих миллисекунд будут заложены десятки тысяч часов тысяч специалистов по всему миру, чтобы разработать, внедрить всё это, отлаживать и решать возникающие проблемы, текущие и будущие.

                  И с этим костылем придется теперь жить.

                  Вам когда дом будут строить и скажут, что вот цемента не хватает для хорошей смеси, подождать нужно, когда подвезут, а вы скажите — да ладно, давайте заливайте и так сойдет. Тут заклепок не хватает, нужно докупить, да ладно и одной достаточно. Главное же построить, ведь так?

                  Проблемы тоталитарных стран — это не вопрос к протоколу. Какой бы протокол не придумали — можно ввести в стране смертную казнь за пользование компьютером и вдруг окажется, что протокол на данной территории не эффективен, поскольку никто им не пользуется.

                  Все верно, поэтому не нужно заниматься точно таким же тоталитаризмом в протоколах, навязывать всем поголовно какие-то вещи, в которых они могут даже не нуждаться, как то шифрование.

                  Если бы был предложен кардинально новый протокол, требующий переписывания всего кода, то никто бы в жизни его не стал использовать. Ни сейчас, ни через 10 лет.

                  Тут опять же стоит начать с того, что HTTP/2 — это кардинально новый протокол, требующий переписывания значительного количества логики работы веб-сервера и клиента. До сих пор в основных браузерах багов с HTTP/2 уйма, до сколько нибудь полной реализации ещё долго и пройдет ни один год.

                  Многие не занимаются переписыванием только потому, что между их приложением и браузером стоит какой-нибудь nginx, который и занимается обработкой протокола.

                  Во-вторых, для решения тех же самых задач можно было пойти и другим путем, точно также не требующим переписывать код. Но ведь это подумать нужно было, а не скорее спеку клепать.

                  Ну, во-первых SPDY и QUIC начали пилиться примерно в одно время (см. википедию). Во-вторых, успех SPDY очевиден в виду его взятия за основу стандарта HTTP/2 и поддержки всеми основными браузерами. На сегодня протокол элементарно включается на стороне сервера и шустренько бегает у любого пользователя, за исключением свидетелей секты шестого IE, принципиально не обновляющихся. Успех QUIC пока очень ограничен, до массовости пока далеко.

                  Если почитать маркетинговые брошюры так и есть. С одной стороны да, костыли работают, не всегда и не во всех случаях правда, но работают. Но зачем всё это было подавать как новая версия HTTP? Чем SPDY, который, как вы сами заметили поддерживался основными браузерами, не устраивал? QUIC начали пилить примерно в то же время, потому что сразу было понятно, что SPDY — это путь в тупик. Сам QUIC правда тоже тот ещё прототип, но до тех пор, пока это дело одной компании, это никому не вредит.

                  Типа их позиция — это какое-то зло и проталкивать её плохо?

                  Да, зло, как и любая радикальная позиция, когда людям пытаются навязать что-то, в чем они не нуждаются, при этом делают это под видом заботы о конфиденциальности.
                    +2
                    Я уже не первый раз вижу вот эти заявления, что «иногда будет быстрее, иногда медленнее, а иногда вообще никак». Это вообще кто мерял и по каким методикам? Вот, например, Яндекс мерял и пришел к выводу, что да, ресурсы экономятся, надо включать. Вот httpwatch.com мерял и обнаружил, что с HTTP/2 скорость загрузки выросла на 23%. Вот буквально на прошлой неделе Dropbox включил себе HTTP/2 и сказал, что входящий трафик снизился на 50%

                    А покажите теперь, кто включил HTTP/2 и ему оказалось «медленнее, а иногда вообще никак»?
                    • UFO just landed and posted this here
                        0
                        Яндекс: «После наших исследований мы пришли к выводу, что SPDY нам ничего не ускорит…»
                        Угу, но в том эксперименте SPDY был включён только для статики(!) на отдельном сервере(!!), убивая главную идею с одним соединением. Кроме того, эксперимент проводился на довольно специфичном сайте, да ещё крайне оптимизированном под HTTP/1, что является антипаттерном для HTTP/2. Можно было бы, например, вместо объединения ресурсов в один спрайт/CSS/JS, наоборот, разбить всё на мелкие кусочки и грузить только нужные данные, снижая объём трафика. Я до сих пор не понимаю, как в том эксперименте должна была получиться выгода, несмотря на объяснения авторов.

                        Полноценного исследования с задействованием всех особенностей HTTP/2 не делалось. Да и nginx, кажется, ещё не всё поддерживает, например, Server push. Плюс, HTTP/2 мало включить, по-хорошему, его ещё надо настраивать, как-то задав приоритеты ресурсам.

                        Если уж и проводить эксперимент, то по-честному, задействовав все лучше практики. Кроме того, заявляется, что HTTP/2 поможет тем, у кого плохое соединение с высокими задержками, в частности, в мобильных сетях. Было бы интересно выделить такую группу пользователей. Может быть, у них всё стало гораздо лучше, но поскольку их общий вклад небольшой (кто будет пользоваться тяжёлым сайтом почты на 3G?), то в общей статистике этого не было заметно. Бывали даже анекдоты, что после оптимизации Ютюба статистика времени ответа ухудшилась из-за того, что его стали больше смотреть как раз в условиях плохого интернета.
                          +1

                          Тем у кого плохое соединение HTTP/2 не только не поможет, но и все сильно ухудшит. Потеря пакета в HTTP/1.x соединении приводит к задержке всего одного запроса, та же самая потеря в HTTP/2 тормозит все запросы. А заметное количество регулярно передаваемой туда и обратно служебной информации только умножает эту вероятность.

                            0
                            Ну так, а что мешает QUIC в добавок включить? Это проблема TCP в первую очередь.

                            UPD. Вообще, сотовая связь очень сложно устроена. Там пакеты не сколько теряются, сколько задерживаются. Сотовая инфраструктура за такими вещами следит.
                              0

                              QUIC пока что только один большой эксперимент с переизобретением сongestion сontrol и много того, что нам TCP и TLS дают практически бесплатно.

                                0
                                До полноценного внедрения HTTP/2 дело тоже ещё не дошло.

                                …много того, что нам TCP и TLS дают практически бесплатно.
                                Если было бесплатно, не нужен был бы QUIC.
                        +9

                        Использовать слово "мерял" по отношению к этой статейке на httpwatch — это какое-то издевательство. Открыть один раз страничку с google.co.uk и сделать скриншот — я даже не буду комментировать, ибо это смешно.


                        За время разработки модулей spdy/2, spdy/3.1 и http/2 в nginx, я собрал огромное количество статистики, отзывов, информации о работе протокола в реальных условиях и подводных камней, провел множество измерений. Некая квинтэссенция того, что можно выжать из типичного сайта с помощью HTTP/2, а именно те самые 200-300 мс показана на слайдах с прошлого доклада: слайды 58 и 59. Это на примере отлично подходящего по объектам для HTTP/2 сайта без каких-либо оптимизаций под HTTP/1.x, как то шардинга, CDN и прочего, что может негативно сказаться на результатах HTTP/2. А также без случайных потерь пакетов, которые просто смертельны для HTTP/2.


                        Вот BBC обнаружили, что HTTP/2 вообще не подходит для стриминга: http://www.bbc.co.uk/rd/blog/2015-07-performance-testing-results-of-adaptive-media-streaming-over-http


                        А здесь люди исследовали влияние различных факторов на производительность SPDY и выявили целый набор условий при которых SPDY не только не дает приемуществ, но даже и сказывается негативно: https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf


                        Ну и естественно, если вам просто нужно качать файлы, то вы будете разочарованы, как этот человек в списке рассылки:
                        http://mailman.nginx.org/pipermail/nginx-ru/2015-October/056870.html


                        Да, конечно, с одной стороны даже 200 мс — это здорово. Но вот эти 200-300 мс разницы никак не стоят той сложности нового протокола, головной боли, которую эта сложность приносит и ресурсов которые отъедает под себя каждое HTTP/2 соединение. Учитывая, что можно было приложить голову и потратить больше времени на разработку стандарта, сделав что-то нормальное. К сожалению, с технической точки зрения протокол очень плох и решает всего одну задачу оптимизации взаимодействия браузера и сервера по TLS в условиях ограниченного числа соединений и большого числа объектов.

                  +2
                  >И сломать миллионы веб-приложений.
                  Давайте не будем выдавать лень программистов за фичу. IMAPS/POPS/SMTPS/свежие версии Windows/Linux/Drupal/Wordpress ломали совместимость на отличненько, но никто не плакается, что что-то сломалось с выходом новой версии.

                  >И шифрование, и сжатие было можно включать и для HTTP/1.1. Более того, для HTTP/2.0 нужно сжимать\разжимать существенно меньше заголовков.
                  Вы не видите разницы между «можно» и «нужно»?

                  >Раздел о политике написан странно. Да, IETF подхватила инициативу Гугла, взяв уже и так неплохо работающий SPDY и сделав его лучше. А что надо было делать — с нуля писать? А зачем?
                  Вы так говорите, словно разработать протокол — это что-то плохое.

                  >То-то Youtube и Netflix насильно переводят все соединения в HTTPS.
                  У ютуба другая цель — завернуть все в HTTPS, чтобы было меньше фильтрации и больше просмотров, больше открутки рекламы, больше прибыли. Вы путаете полезность для пользователя с полезностью для корпорации.

                  >Если этим людям кто-то запрещает конфиденциальность — то это его дело обеспечить соблюдение данного запрета. Просто не разрабатывать какие-то технологии из-за того, что в мире есть люди, которым ими пользоваться будет нельзя — это чушь.
                  Вы как-то определитесь, то вам нужны куки из HTTP/1.1, то вам плевать на совместимость со старыми нормами.
                    0
                    Давайте не будем выдавать лень программистов за фичу.

                    Давайте не будем выдавать сломанную обратную совместимость за фичу. Одно дело сломать протокол типа IMAPS, которые в одной-двух библиотеках пофиксят и дальше все будут использовать новый, а другое дело осознанно сломать КАЖДОЕ веб-приложение в мире.

                    Вы не видите разницы между «можно» и «нужно»?

                    По-факту разницы конкретно в данном случае я не вижу. Всем, кому была важна производительность и безопасность, это было «нужно», а не «можно». Именно эти люди и HTTP/2 начнут использовать, по тем же причинам.

                    Вы так говорите, словно разработать протокол — это что-то плохое.

                    См. картинку о «теперь у нас 15 стандартов»

                    У ютуба другая цель — завернуть все в HTTPS, чтобы было меньше фильтрации и больше просмотров, больше открутки рекламы, больше прибыли. Вы путаете полезность для пользователя с полезностью для корпорации.

                    У ютюба много своих целей, да. HTTPS — средство достижения этих целей. И, если это средство делает возможным существование Youtube, то это удобство пользователя.

                    Вы как-то определитесь, то вам нужны куки из HTTP/1.1, то вам плевать на совместимость со старыми нормами.

                    Куки нужны, поскольку это обратная совместимость, да. Что касается этой надуманной проблемы с финансовыми трейдерами и аналитиками ЦРУ — ну так, блин, сделайте для них ПО, которое будет всё расшифровывать и куда надо складывать, заставьте их пользоваться только этим ПО. Наезды на HTTP/2 в этом плане — это как запрет разрабатывать автомобили, ездящие быстрее 5 км/ч, поскольку кое-где есть знаки, которые ограничивают скорость до этого уровня.
                      +3
                      >Давайте не будем выдавать сломанную обратную совместимость за фичу. Одно дело сломать протокол типа IMAPS, которые в одной-двух библиотеках пофиксят и дальше все будут использовать новый, а другое дело осознанно сломать КАЖДОЕ веб-приложение в мире.

                      Полностью обратную совместимость никто и не ломал, в статье предлагается отказаться от одной вредоносной особенности протокола (с точки зрения пользователя). А пока что у нас получается не протокол для пользователей, а пользователи для протокола.

                      >По-факту разницы конкретно в данном случае я не вижу. Всем, кому была важна производительность и безопасность, это было «нужно», а не «можно». Именно эти люди и HTTP/2 начнут использовать, по тем же причинам.

                      И таких сайтов на весь интернет не наберется 1%. А когда протокол пишется под нужны корпораций, а затем навязывается большинству в качестве стандарта, но большинство от этого ничего не выигрывает — вас ничего в этом не настораживает?

                      >См. картинку о «теперь у нас 15 стандартов»
                      Какая разница, сколько у нас стандартов, если официальный — только от IETF.

                      >У ютюба много своих целей, да. HTTPS — средство достижения этих целей. И, если это средство делает возможным существование Youtube, то это удобство пользователя.

                      Ютуб и без https отлично существовал, а вот просмотр видео через https на смартфонах убивает заряд батареи раза в два быстрее. Вы опять пытаетесь выдать багу за фичу, нужды корпораций за потребности пользователей.

                      >Куки нужны, поскольку это обратная совместимость, да. Что касается этой надуманной проблемы с финансовыми трейдерами и аналитиками ЦРУ — ну так, блин, сделайте для них ПО, которое будет всё расшифровывать и куда надо складывать, заставьте их пользоваться только этим ПО. Наезды на HTTP/2 в этом плане — это как запрет разрабатывать автомобили, ездящие быстрее 5 км/ч, поскольку кое-где есть знаки, которые ограничивают скорость до этого уровня.

                      Так в том-то и дело, что фактически разработан автомобиль, который не умеет ездить медленнее, чем 10км/ч. Сел — и либо ты едешь быстрее 5 км/ч, либо не едешь никуда. В чем проблема сделать HTTP/2 без принудительного шифрования, как в HTTP/1.1, когда администратор сам решает, что ему надо — шифрование, производительность или и то, и то вместе взятое? Ну, кроме желания отдельной группы людей, вышедших под флагом «SSL everywhere» для обслуживания их коммерческих интересов?
                        0
                        > В чем проблема сделать HTTP/2 без принудительного шифрования, как в HTTP/1.1, когда администратор сам решает, что ему надо — шифрование, производительность или и то, и то вместе взятое?

                        Так в текущем стандарте это и предусмотрено: хочешь используй HTTP/2 + SSL (h2), хочешь используй HTTP/2 only (h2c). Стандарт ни как принудительно не связывает HTTP/2 с SSL (только рекомендует), так же как и стандарт HTTP/1.1 не связывает его с SSL.

                        Например, за счёт одного TCP соединения HTTP/2 решает проблему съедаемого времени при открытии канала TCP+TLS, причём банально одно соединение = один handshake. Именно по этому его больше продвигают под флагом «SSL everywhere». Вообще воспринимать один TCP канал в HTTP/2 нужно как асинхронную, более долгосрочную альтернативу Keep-Alive в HTTP/1.1.
                    +1
                    Повышает, поскольку его будут по-дефолтку включать с шифрованием, а чтобы включить его без шифрования — нужно будет ещё постараться и не факт, что выйдет.


                    Тут в чем проблема назревает, привив пользователю привычку «зеленый замочек — безопасно», для того чтобы злоумышленнику|корпорации|государству создать ложное чувство защищенности, будет достаточно просто этот замочек рисовать…
                    –1
                    Главное что бы была возможность апгрейдить протокол в будущем без накладных расходов. А то выйдет как с ipv4 -> ipv6 когда и хочется и колется.
                      +9
                      Учитывая насколько большая доля мультимедийного трафика, принудительное ссл выглядит странно.
                        +1
                        Это уже больше не к странностям а к проблемам. Шифровать мультимедиа контент бред и лишняя трата ресурса. Достаточно было бы идентификации сервера и проверки подлинности. Думаю это можно было бы решить не используя TLS/SSL, ведь все таки не минорное изменение версии.
                          0
                          На самом деле провайдеры мультимедиа-контента обожают его шифровать (т.к. это позволяет сделать более развесистый DRM), но они очень не любят шифровать сессию, в которой он передается (т.к. на конфиденциальность клиента им плевать, а вот на загрузку серверов CDN — нет).
                            +2
                            провайдеры мультимедиа-контента обожают его шифровать

                            Первый раз слышу, дадите ссылку почитать? Всегда думал что шифрованием контента в DRM целях (если это вообще делается) занимается издатель мультимедиа-контента, а не провайдер. И к протоколу передачи это никакого отношения не имеет.
                              0
                              Под провайдером я и подразумеваю издателя. Ну, к примеру, большая часть HLS-вещаний, с которыми я сталкивался, зашифрована по AES-128. Даже если это вещание эфирного канала. На уровне протокола, естественно, при этом используется HTTP без SSL/TLS. Клиентским устройствам приходится тратить ресурсы на декодирование видеопотока, но никакой выгоды клиенту от этого нет.
                              Если передавать через TLS/SSL, то хотя бы ваш провайдер/сосед/дядяВася не узнает, что именно вы смотрите.
                            –1
                            Почему шифровать мультимедиа — бред? Там что, не важна конфиденциальность, или копирайт, или защита канала? В видеопотоке точно так же могут быть личные данные, секретная информация, контент не для публичного показа и т.д.
                              +2
                              Я написал, идентификации сервера и проверки подлинности нужна, остальное нет. Речь шла, о публикации общедоступного ММ контента. Если вы собираетесь показывать что-то не для публичного показа — ради бога, я не предлагал отказаться от HTTPS.
                                +2
                                В публичном видео на ютубе — секретная информация? Конечно, конечно.
                                  0
                                  Есть видео которые доступны только по ссылке и не хотелось бы чтобы эту ссылку узнал кто то ещё.
                                    0
                                    Эта проблема вообще нерешаема в случае с «секретной ссылкой». Например, один из ваших доверенных, кому вы ссылку сообщаете, может оказаться жуком и сольёт её. Или кто-то случайно увидит из-за спины. Или сломают сам протокол, с помощью которого вы распространяете ссылку между доверенными. (Я не имею ввиду «техническое» понимание слова «протокол», а общее — «сломают протокол» может означать и, например, «заполучат письмо со ссылкой методами социальной инженерии».)

                                    В общем, если у вас такое секретное видео, которое вы не хотите показывать случайным прохожим, ему вообще не место на ютубе.
                            +3
                            Отличная статья, но вот эти поэтические вступления и отсылы к глобальному потеплению уже утомляют у западных авторов. Хорошо хоть посвящения супруги и детям нет)
                              +8
                              Очень коробит упоминание экологии к программированию. Я не считал числа, но мой здравый смысл подсказывает, что влияние HTTP/2 на экологию настолько мизерно в сравнение с реальными экологическими проблемами, что не стоит упоминания. Тем не менее эта тема периодически всплывает и меня это несколько удивляет. Может быть кто-нибудь меня поправит? Вот чадящий жигулёнок 80-х годов под моим окном, это экологическая проблема: его выхлопы оседают в моих лёгких. Энергия в мой ноутбук приходит от ТЭЦ, которая расположена достаточно далеко от жилых районов города; снабжена хорошими фильтрами и другими очистительными системами. От того, что во всём городе возрастёт потребление электроэнергии персональными компьютерами на пару десятых процента, скорее всего общее потребление вообще не изменится за пределами статистической погрешности, не говоря уже о вредных выбросах.
                                +1
                                Помимо компьютеров и кучи различных клиетских девайсов, подключенных к сети, есть еще датацентры набитые серверами, под которые иногда целые электростанции строят, и всевозможные промежуточные машрутизаторы.

                                Есть такая организация как CEET (Centre for Energy-Efficient Telecommunications), которая занимается этими вопросами. По их подсчетам на интернет уже к 2020 году будет приходиться до 10% от всей потребляемой человечеством энергии.
                                  0
                                  Ладно, пусть 10%. Но это совершенно не значит, что, оставшись на HTTP 1.1, мы сэкономим хоть какую-то заметную долю из этих 10%. Я, конечно, не считал, но просто по ощущениям тот же круизный лайнер (https://geektimes.ru/post/276182/) за один рейс выбросит намного больше всякой вредной фигни. Очень похоже на преждевременную оптимизацию.
                                    +2
                                    В этом разрезе было бы интересно примерить влияние других новшеств на экологию. Переход с H264 SD на HEVC FHD (а то и 4K) нехило увеличивает нагрузку на всё — и на кодирующие фермы, и на каналы передачи данных, и на миллионы декодирующих устройств. Любые накладные расходы HTTP/2 на фоне 20-мегабитного видеопотока не просто малозначительны — они вообще незаметны. Надо подкинуть «зеленым» идею требовать запрета видеопотоков выше 1 мбита!
                                      +2
                                      Согласен с вами. Когда смотришь онлайн-видео в HD, то проц нехило так весь проц отжирает (постоянно >70% ЦП). На этом фоне — небольшая дополнительная нагрузка в +1% на HTTP/2 выглядит смешно. Стоит нападать на создателей 4K за их наплевательское отношение к матушке-природе! И вообще надо все развлекательные сервисы выкинуть, пусть компы работают только для науки. </sarcаsm>
                                      • UFO just landed and posted this here
                                          0
                                          Я с вами полностью согласен, осталось только mpv player поставить каждому пользователю на планете, чтобы снизить выбросы Co2 в атмосферу.
                                          Мой же коммент был направлен на то, что изначально создатели браузеров/контента/или_кто_там_за_это_отвечает неправильно сделали видеоплеер в браузере, что он так много жрёт.

                                          > Вы его не правильно смотрите.
                                          Кстати, я ведь не только Youtube HD смотрю, но еще и Twitch люблю посмотреть. А тамошний стрим я даже не знаю какой плеер поддерживает.
                                            0
                                            Таки ваша придумка уже имхо лишняя. Современные браузеры используют VAAPI которое по сути пробрасывает декодирование до драйверов видеокарты, что позволяет при возможности декодировать видео силами хардварных декодеров.

                                            В *nix системах уже по моему везде стоит данный пакет из коробки. (что кстати создает проблемы со старыми nvidia vdpau драйверами, но ....)
                                            • UFO just landed and posted this here
                                  • UFO just landed and posted this here
                                      +3
                                      А можно ли — для полноты картины — привести несколько примеров улучшений, которые были отвергнуты? Ну, те самые, которые «вне повестки» и т.п.? Интересно знать, что мы потеряли?

                                      Что же до обязательного SSL, то я, наверное, поддержал бы эту затею. Все-таки затраты на поточную симметричную шифровку-дешифровку не так уж велики, а «ассиметричная» часть там все равно не зависит от размера передаваемого пакета.
                                      • UFO just landed and posted this here
                                          +2

                                          Соглашусь лишь частично. 1.1 реализуется студентом, видимо, за венерианские сутки (и то, потому что оочень хочет жить). Объём спек, связанных с http/1.1 огромен и полностью 1.1 никто и не реализует, за ненадобностью.


                                          Принципиальной разницы в защищенной имплементации текстового и бинарного протоколов нет. Переполнения, неправильная интерпретация символа NUL и т. п. ничем не отличается в этих двух случаях.


                                          Касательно отладки — реально всё равно нужны инструменты: обычно трафик ходит по http не в plain text: используются tls, chuncked, gzip, с которыми протокол всё равно частично бинарный.

                                            0
                                            Принципиальной разницы в защищенной имплементации текстового и бинарного протоколов нет

                                            Ну как же нет. Обычно текстовые протоколы это либо парсер, либо чтение с помощью терминальных символов. Последнее это как раз про HTTP и поле для потенциально эксплуатируемых ошибок тут куда меньше. Ошибка если и будет, то это будет DoS или еще что-то совершенно не связанное с RCE. Бинарный же протокол это практически всегда либо четко указанная длина блока, либо фиксированная длина, что уже дает огромное поле для разного рода ошибок, которые приводят к серьезным уязвимостям. От чего, собственно, так популярны фаззеры бинарных протоколов и форматов файлов.
                                            • UFO just landed and posted this here
                                                +5
                                                HTTP/2 не отменяет семантики HTTP/1.1, так что объем спек в совокупности получается ещё больше. Но только если простейший HTTP/1 сервер, способный отдать в браузер страничку любого объема, можно уместить в нечто подобное:

                                                % while true; do echo -n "HTTP/1.1 200 OK\r\n\r\n" | cat - index.html | netcat -lcp 8080; done

                                                то с HTTP/2 такой фокус уже не пройдет.
                                                  0

                                                  Сложно не согласится, написание простого клиента или сервера стало сложнее.

                                                0
                                                > 2. Сложность имплементации: бинарный протокол сложно имплементировать,
                                                > 2.а. Потенциально большая забагованность реализаций:

                                                Я тоже не был фанатом HTTP/2 (и сейчас не фанат, но и опыта особого нет), однако где-то в статьях про него увидел переубеждение по этим вопросам. Бинарный протокол может быть более простым для реализации так как убирает работу по парсингу и вы получаете служебные данные (вроде Content-Length) уже как нужно программе. Более сложной вещь может сжатие заголовков (HPACK), мне трудно сказать насколько оно сложное и подвержено багам.
                                                  +1
                                                  Семантика HTTP/2 по большей части осталась от HTTP/1.x, о чем даже спецификация заявляет с самого начала. После распаковки вы получаете всё тот же Content-Length 100 в текстовом виде, который нужно всё также парсить. Можно там в HPACK это немного пооптимизировать, в смысле что не парсить каждый раз, а узнавать о том, что это такой же заголовок с таким же значением ещё на этапе распаковки, но реализацию это ни разу не упрощает, а наоборот.
                                                0

                                                Странная статья со странными выводами. HTTP/2 не нужна дополнительная функциональность и конфиденциальность — в плане функционала в HTTP/1.1 всё отлично. Новая версия протокола потребовалась прежде всего для решения проблем с производительностью, со скоростью загрузки сайтов.


                                                Нападки автора на TLS совершенно непонятны — он отлично решает задачу авторизации и конфиденциальности. И в HTTP/2 TLS быстрее — потому, что HTTP/1.1 устанавливает 6-8 TLS-соединений с сервером, а HTTP/2 — одно. Перерасход ресурсов на шифрование — сомнительно, в современных процессорах есть аппаратная поддержка AES.


                                                То же самое про кукисы. Полный контроль над ними у пользователя есть уже сейчас, а оверхед на передачу больших кукисов снижает HPACK. "идентификатор сессии" при желании можно засунуть в те же кукисы вместо реальных данных — веб-сайты заинтересованы в том, чтобы они быстрее открывались и не раздувают кукисы без нужды.


                                                Про быстрые реализации — ткните автора лицом в nginx.


                                                Про улучшения и нежелательность SSL. HTTP/2 был сделан полностью совместимым по функционалу не просто так — это позволяет всем существующим приложениям, говорящим на HTTP/1.1, получить преимущества нового протокола вообще без изменения кода — просто поставив перед ними тот же nginx, который будет заниматься перекодировкой 2 — > 1.1 и обратно.


                                                В целом, HTTP/2 рассчитан на использование в интернете для эффективной закачки контента веб-сайта в браузер. Что означает, что HTTP/1.1 никогда не умрет — как протокол для простых низконагруженных серверов, как протокол для REST. Выбор будет всегда.

                                                • UFO just landed and posted this here
                                                    0

                                                    Про скорость многопоточной закачки — я нашел вот это. Можете рассказать, почему два соединения будут быстрее, на уровне TCP/IP?

                                                    • UFO just landed and posted this here
                                                        0

                                                        Т.е. для каналов с приличным % потери пакетов TCP считает, что пакеты теряются из-за шейпера и урезает окно. Но надо же смотреть в светлое будущее, а не в темное прошлое :-)


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

                                                        +3
                                                        У нескольких соединений будет суммарно больше окно, причем, что важно, с самого начала. Потеря пакета затронет только одно из нескольких соединений. Обработку нескольких соединений проще параллелить, они могут обрабатываться разными процессами, в том числе на уровне ядра или даже быть распределены по разным серверам, переданы по разным каналам.
                                                          0

                                                          Ну как с самого начала — сначала установить соединение, потом скачать хтмл, потом опять устанавливать соединения… При высоком пинге это сильно увеличивает latency. Особенно при использовании TLS. Читал где-то, что разрабатывается стандарт для упрощенного (в плане кол-ва round-trip-ов) TLS, но когда мы его увидим...


                                                          А вообще — когда вы сделаете HTTP/2 prefetch? Это будет мощный довод переходить на новый протокол для технологически продвинутых веб-мастеров.

                                                            0
                                                            Современные браузеры не ждут, пока html скачается, а открывают сразу несколько соединений. Единственная их проблема, что они по-умолчанию ограничены 6 соединениями по RFC и если уж запросили какую-то картинку, то не могут остановить передачу и запросить что-то другое не разрывая соединения. Собственно на этом HTTP/2 и выигрывает, только для реализации того же не нужно было столько всего городить.

                                                            HTTP/2 server push? Вообще с ним пока все не так хорошо в браузерах (как в общем и самим протоколом), кто пытается использовать — время от времени сталкивается не с ускорением, а с багами. Реализация и отладка HTTP/2 и так отняла столько ресурсов, что на данный момент пока никаких ETA на дополнительные работы по HTTP/2.
                                                              0

                                                              Спасибо за информацию)


                                                              Наверное, браузеры в будущем будут открывать несколько соединений HTTP/2 параллельно по указанным вами причинам.

                                                            • UFO just landed and posted this here
                                                          0
                                                          > а остальные могли бы и не утруждать себя поддержкой TLS, ибо ничего ценного у них нет
                                                          Ну это какая-то вообще наивность. Такой вой поднимется если какой-то крупный сервис не поддерживает безопасное соединение. Если вам оно не нужно, это не значит что всем остальным не нужно. Сейчас App Store/Google Play при приеме приложений начинают выдавать предупреждения если приложение устанавливает небезопасное HTTP соединение.

                                                          Вряд ли вы уведите сейчас как несколько TCP соединений работают быстрее чем одно, тогда HTTP/2 был бы медленнее на тестах, это не так (или быстрее или столько же для хорошо оптимизированных сайтов). Впрочем это должно быть возможно, особенно если кто-то шейпит трафик (провайдер, корпоративный firewall, сервер). Кроме накладных расходов на на безопасность, TCP соединение еще надо «разогреть», т.е. возможность работы через одно разогнанное TCP соединение может немного уменьшить задержку при работе с сайтом (хотя я не могу вот так из головы придумать сценарий — ведь не сильно важно сколько именно соединений разогревать — одно или несколько).
                                                            +2
                                                            Несколько как раз разогреются быстрее и с самого начала будут быстрее. У них же в сумме стартовое окно в несколько раз больше.
                                                              +1
                                                              Это довольно интересно, надо будет иметь в виду. Спасибо.
                                                        0
                                                        Как человек, имевший некоторое (пусть и по касательной) отношение к обсуждению и утверждению HTTP/2 должен заметить, что статья совершенно безграмотна и с технической, и с архитектурной точки зрения.

                                                        Достаточно сказать, что в двух соседних абзацах автор сначала жалуется на то, что HTTP/2 плохо структурирован и лезет в чужие уровни абстракции, а потом требует добавить в HTTP/2 шифрование и управление идентфикаторами сессий.

                                                        HTTP/2 неидеальный стандарт. Однако критиковать его бессмыссленно просто потому что он не окажет никакого воздействия на производительность сети. Ну да, некоторые крупные сервисы найдут на чем сэкономить пару процентов, но не более того.

                                                        Позвольте, а кто вам вообще сказал, что на неё (производительность сети) можно как-то повлиять на уровне протокола HTTP? HTTP — очень-очень-очень ограниченный протокол. Он всего лишь описывает заголовки выполнения операций над ресурсами. Всё остальное делается либо на предыдущих шести уровнях сетевого стека, либо на уровне веб-приложения. Ну вот да, в HTTP/2 понапихали всяких кросс-интеграций и оптимизаций, получив очень сложный стек с примерно нулевым влиянием на реальный мир.
                                                          +1
                                                          Камп сам активно принимал участие в обсуждении стандарта http/2 практически с самого начала. У него всегда было много претензий, а также странных идей, как, например, вынести некоторые «транспортные» http-заголовки (host, url, length,..) вне шифрования и сжатия, чтобы было удобно организовать управление потоками в 1Тб/сек на varnish. При этом на замечание от других участников, что свои предложения лучше оформлять в виде драфта, жаловался, что ему никто не хочет платить денег за работу над стандартом http/2.

                                                          Стандарт получился таким, каким получился, у многих была возможность высказать свои идеи. Какие-то были приняты, какие-то отвергнуты, где-то пошли на компромиссные решения. Назвать протокол халтурой — это неуважение к работе многих профессионалов.
                                                            +1
                                                            Смысл поста в том, что профессионалам должно быть стыдно под таким подписываться. Да, сил потрачено много, и это что, что-то значит?

                                                            Как в школе: никого не волнует, что «ты учил». Волнует, чтобы «выучил».

                                                            Тут: стандарт делали, да не доделали. Был бы он «доделан» — не было бы таких претензий. А как он есть, склепаный на скорую руку из того, что было, ни одно техническое противоречие не разрешено, ни одной фичи, которую нельзя было бы сделать без него — халтура, конечно.
                                                            0
                                                            (промахнулся, простите)

                                                            Only users with full accounts can post comments. Log in, please.