В долгосрочной перспективе, наиболее значительным событием 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-акселератора и кэширующего прокси) — прим. пер.]
Комментарии (78)
sshikov
29.05.2016 22:53Последний раздел «ЧП в вашей стране, вашем округе или городе?» ужасен. Несколько раз пытался продраться через дебри этого текста, и все еще не был уверен, правильно ли его понимаю. А потом посмотрел оригинал, и понял, что это перевод такой. Your Country, State, or County Emergency Webpage — это не ЧП, это сайт/страница МЧС, в наших реалиях, призванные сообщать о ЧП. И именно к сайту относится все, что написано про SSL.
Кстати, я тут не согласен с автором. SSL это один из немногих, если не единственный, способ, чтобы идентифицировать сервер для клиента. И даже если медиа-бизнесу наплевать, что клиенту подсунут вместо настоящего сайта фейк с троянами, то клиенту это вовсе не безразлично.
VBart
29.05.2016 23:04+2Можете предложить более точный и благозвучный перевод? В абзаце не идет речь о конкретной страничке, а скорее о том, что в условиях чрезвычайной ситуации приватность уходит на второй план и куда важнее сохранить возможность распространять информацию, чем тратить ресурсы на её шифрование.
P.S. Переименовал пока в "Сайт МЧС..."
sshikov
30.05.2016 08:56Так уже лучше. В принципе, сам автор неосознанно говоря про SSL смешивает разные вещи — конфиденциальность (и шифрование трафика), которая действительно нужна не всегда, и некоторые гарантии, например что сервер не подменили (взломав DNS или прокси). И это мешает понимать действительно разумные вещи.
creker
29.05.2016 23:10+1Мне кажется здесь не идет речи, что весь SSL не нужен. Речь о том, что во многих случаях нужна всего лишь часть SSL — например, целостность данных. Многим не важно, открыт ли трафик. Для многих шифрование это даже неудобство и лишняя головная боль. Зато очень важно иметь гарантию, что данные дошли без изменений. SSL же содержит все и сразу. Можно конечно сказать, что есть NULL cipher, но, судя по всему, браузеры его не поддерживают, а значит мы получаем или все сразу, или вообще ничего.
ToSHiC
29.05.2016 22:55Кстати, на счёт безопасности и NSA, тут недавно пробегала интересная новость: https://www.reddit.com/r/sysadmin/comments/4l7rld/bluecoat_a_company_which_makes_tls_mitm_equipment/
navion
29.05.2016 23:57В чем новость? У Яндекса тоже есть свой CA, думаете через него ФСБ прослушивает трафик?
ToSHiC
30.05.2016 00:15+5Производитель железа для TLS MitM и CA сертификат, которому доверяет абсолютное большинство браузеров? Нет, что вы, ничего страшного :)
navion
30.05.2016 00:36Во-первых это производитель корпоративных файрволов, а во-вторых прочтите ветку комментариев по своей ссылке, в-третьих любая компания может получить свой подчинённый CA — это вопрос денег и времени.
белки_истерички.jpgToSHiC
30.05.2016 12:58Во-первых, корпоративные 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.» И нету ни одной причины, почему-бы их железо не стояло в других странах.navion
02.06.2016 12:31корпоративные CA почти всегда самоподписные, и для работы именно корпоративного MitM не нужно иметь «настоящий» CA, которому бы доверяли некорпоративные браузеры, тем более для тестирования
А кто сказал, что сертификат CA будут использовать именно для этого?
если какая-то компания начнёт подписывать своим CA левые сертификаты у неё этот CA очень быстро отберут, примеры были.
Я в курсе и не понимаю к чему эта паника. Была же история с разработчиками прокси-сервера, которые поставили свой сертификат на железку во внутренней сети и лишились его за нарушение CPS после запуска Хрома с google.com.
На реддите в топе отличный комментарий, где всё это разжовано.ToSHiC
02.06.2016 13:15Всё так до тех пор, пока условный Symantec (issuer) считает обладателя такого CA злоумышленником. Разработчик прокси-сервера — злоумышленник, компания, работающая по заказу какого либо правительства (желательно, конечно, правительство дружественной для США страны, т.к. Symantec всё же американская компания) — нет.
tangro
29.05.2016 23:02Он нарушает целостность отдельных, ранее изолированных слоев, переусложнен, содержит кучу нестыковок, плохих компромиссов, упущенных возможностей и т. д.
Какую целостность, о чём вообще речь?
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.
Существуют категории людей, которые легально лишаются конфиденциального обмена информацией: дети, заключенные, финансовые трейдеры, аналитики ЦРУ
Если этим людям кто-то запрещает конфиденциальность — то это его дело обеспечить соблюдение данного запрета. Просто не разрабатывать какие-то технологии из-за того, что в мире есть люди, которым ими пользоваться будет нельзя — это чушь.VBart
29.05.2016 23:37+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» как плацдарм для навязывания своей точки зрения.tangro
30.05.2016 10:04занимается не тем, чем ему положено заниматься на данном уровне, а также лезет в соседние
Ок, занимается и лезет. Возьмите каждого первого пользователя и спросите его, что для него важнее, чтобы протокол не лез на чужие уровни ответственности сетевого стека или чтобы фейсбучек загружался на 1.5 секунды быстрее. Послушайте ответ и задумайтесь, что вообще первично — потребности пользователей или стройность картины мира в голове сетевиков и программистов.
Закрепляется на законодательном уровне в виде промежуточного прокси и сертификата, который все жители страны должны добавить в доверенные, иначе не смогут в интернет выйти.
Проблемы тоталитарных стран — это не вопрос к протоколу. Какой бы протокол не придумали — можно ввести в стране смертную казнь за пользование компьютером и вдруг окажется, что протокол на данной территории не эффективен, поскольку никто им не пользуется.
Никто никого не заставляет переходить на новый протокол срочно, в этом нет никакой острой необходимости.
Если бы был предложен кардинально новый протокол, требующий переписывания всего кода, то никто бы в жизни его не стал использовать. Ни сейчас, ни через 10 лет.
Гугл, в свою очередь, набив шишек со SPDY пошел копать в сторону QUIC
Ну, во-первых SPDY и QUIC начали пилиться примерно в одно время (см. википедию). Во-вторых, успех SPDY очевиден в виду его взятия за основу стандарта HTTP/2 и поддержки всеми основными браузерами. На сегодня протокол элементарно включается на стороне сервера и шустренько бегает у любого пользователя, за исключением свидетелей секты шестого IE, принципиально не обновляющихся. Успех QUIC пока очень ограничен, до массовости пока далеко.
Просто используется сторонниками «SSL everywhere» как плацдарм для навязывания своей точки зрения.
Типа их позиция — это какое-то зло и проталкивать её плохо?VBart
30.05.2016 12:10+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 правда тоже тот ещё прототип, но до тех пор, пока это дело одной компании, это никому не вредит.
Типа их позиция — это какое-то зло и проталкивать её плохо?
Да, зло, как и любая радикальная позиция, когда людям пытаются навязать что-то, в чем они не нуждаются, при этом делают это под видом заботы о конфиденциальности.tangro
30.05.2016 12:58+2Я уже не первый раз вижу вот эти заявления, что «иногда будет быстрее, иногда медленнее, а иногда вообще никак». Это вообще кто мерял и по каким методикам? Вот, например, Яндекс мерял и пришел к выводу, что да, ресурсы экономятся, надо включать. Вот httpwatch.com мерял и обнаружил, что с HTTP/2 скорость загрузки выросла на 23%. Вот буквально на прошлой неделе Dropbox включил себе HTTP/2 и сказал, что входящий трафик снизился на 50%
А покажите теперь, кто включил HTTP/2 и ему оказалось «медленнее, а иногда вообще никак»?
Ivan_83
30.05.2016 17:58+2Яндекс: «После наших исследований мы пришли к выводу, что SPDY нам ничего не ускорит, а оптимизация загрузки статики, уменьшение ее размера, оптимальное кеширование оказывают гораздо более — на порядки — заметные эффекты в скорости работы интерфейса.
Однако в SPDY мы нашли для себя неожиданный профит. За счет того, что многие клиенты перестали создавать на каждый файл по соединению, этих соединений стало заметно меньше, а значит, наши процессоры стали меньше нагружаться. То есть какая-никакая, а экономия есть.»
— тут ещё нужно посмотреть почему соединения плохо используются повторно.
У дропбокса, очевидно, много однотипных запросов типа HEAD (или тому подобных), поэтому их пожало и они получили профит.
Это означает, что им лучше было бы перейти на какой то более оптимизированный протокол для их нужд и отказаться от HTTP вообще в своём клиенте.
Что там у хтппватч — хз.
Aingis
30.05.2016 20:02Яндекс: «После наших исследований мы пришли к выводу, что SPDY нам ничего не ускорит…»
Угу, но в том эксперименте SPDY был включён только для статики(!) на отдельном сервере(!!), убивая главную идею с одним соединением. Кроме того, эксперимент проводился на довольно специфичном сайте, да ещё крайне оптимизированном под HTTP/1, что является антипаттерном для HTTP/2. Можно было бы, например, вместо объединения ресурсов в один спрайт/CSS/JS, наоборот, разбить всё на мелкие кусочки и грузить только нужные данные, снижая объём трафика. Я до сих пор не понимаю, как в том эксперименте должна была получиться выгода, несмотря на объяснения авторов.
Полноценного исследования с задействованием всех особенностей HTTP/2 не делалось. Да и nginx, кажется, ещё не всё поддерживает, например, Server push. Плюс, HTTP/2 мало включить, по-хорошему, его ещё надо настраивать, как-то задав приоритеты ресурсам.
Если уж и проводить эксперимент, то по-честному, задействовав все лучше практики. Кроме того, заявляется, что HTTP/2 поможет тем, у кого плохое соединение с высокими задержками, в частности, в мобильных сетях. Было бы интересно выделить такую группу пользователей. Может быть, у них всё стало гораздо лучше, но поскольку их общий вклад небольшой (кто будет пользоваться тяжёлым сайтом почты на 3G?), то в общей статистике этого не было заметно. Бывали даже анекдоты, что после оптимизации Ютюба статистика времени ответа ухудшилась из-за того, что его стали больше смотреть как раз в условиях плохого интернета.VBart
31.05.2016 00:43+1Тем у кого плохое соединение HTTP/2 не только не поможет, но и все сильно ухудшит. Потеря пакета в HTTP/1.x соединении приводит к задержке всего одного запроса, та же самая потеря в HTTP/2 тормозит все запросы. А заметное количество регулярно передаваемой туда и обратно служебной информации только умножает эту вероятность.
Aingis
31.05.2016 00:44Ну так, а что мешает QUIC в добавок включить? Это проблема TCP в первую очередь.
UPD. Вообще, сотовая связь очень сложно устроена. Там пакеты не сколько теряются, сколько задерживаются. Сотовая инфраструктура за такими вещами следит.VBart
31.05.2016 00:54QUIC пока что только один большой эксперимент с переизобретением сongestion сontrol и много того, что нам TCP и TLS дают практически бесплатно.
Aingis
31.05.2016 15:44До полноценного внедрения HTTP/2 дело тоже ещё не дошло.
…много того, что нам TCP и TLS дают практически бесплатно.
Если было бесплатно, не нужен был бы QUIC.
VBart
31.05.2016 00:36+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 в условиях ограниченного числа соединений и большого числа объектов.
albik
30.05.2016 00:03+2>И сломать миллионы веб-приложений.
Давайте не будем выдавать лень программистов за фичу. IMAPS/POPS/SMTPS/свежие версии Windows/Linux/Drupal/Wordpress ломали совместимость на отличненько, но никто не плакается, что что-то сломалось с выходом новой версии.
>И шифрование, и сжатие было можно включать и для HTTP/1.1. Более того, для HTTP/2.0 нужно сжимать\разжимать существенно меньше заголовков.
Вы не видите разницы между «можно» и «нужно»?
>Раздел о политике написан странно. Да, IETF подхватила инициативу Гугла, взяв уже и так неплохо работающий SPDY и сделав его лучше. А что надо было делать — с нуля писать? А зачем?
Вы так говорите, словно разработать протокол — это что-то плохое.
>То-то Youtube и Netflix насильно переводят все соединения в HTTPS.
У ютуба другая цель — завернуть все в HTTPS, чтобы было меньше фильтрации и больше просмотров, больше открутки рекламы, больше прибыли. Вы путаете полезность для пользователя с полезностью для корпорации.
>Если этим людям кто-то запрещает конфиденциальность — то это его дело обеспечить соблюдение данного запрета. Просто не разрабатывать какие-то технологии из-за того, что в мире есть люди, которым ими пользоваться будет нельзя — это чушь.
Вы как-то определитесь, то вам нужны куки из HTTP/1.1, то вам плевать на совместимость со старыми нормами.tangro
30.05.2016 09:54Давайте не будем выдавать лень программистов за фичу.
Давайте не будем выдавать сломанную обратную совместимость за фичу. Одно дело сломать протокол типа IMAPS, которые в одной-двух библиотеках пофиксят и дальше все будут использовать новый, а другое дело осознанно сломать КАЖДОЕ веб-приложение в мире.
Вы не видите разницы между «можно» и «нужно»?
По-факту разницы конкретно в данном случае я не вижу. Всем, кому была важна производительность и безопасность, это было «нужно», а не «можно». Именно эти люди и HTTP/2 начнут использовать, по тем же причинам.
Вы так говорите, словно разработать протокол — это что-то плохое.
См. картинку о «теперь у нас 15 стандартов»
У ютуба другая цель — завернуть все в HTTPS, чтобы было меньше фильтрации и больше просмотров, больше открутки рекламы, больше прибыли. Вы путаете полезность для пользователя с полезностью для корпорации.
У ютюба много своих целей, да. HTTPS — средство достижения этих целей. И, если это средство делает возможным существование Youtube, то это удобство пользователя.
Вы как-то определитесь, то вам нужны куки из HTTP/1.1, то вам плевать на совместимость со старыми нормами.
Куки нужны, поскольку это обратная совместимость, да. Что касается этой надуманной проблемы с финансовыми трейдерами и аналитиками ЦРУ — ну так, блин, сделайте для них ПО, которое будет всё расшифровывать и куда надо складывать, заставьте их пользоваться только этим ПО. Наезды на HTTP/2 в этом плане — это как запрет разрабатывать автомобили, ездящие быстрее 5 км/ч, поскольку кое-где есть знаки, которые ограничивают скорость до этого уровня.albik
30.05.2016 13:03+3>Давайте не будем выдавать сломанную обратную совместимость за фичу. Одно дело сломать протокол типа IMAPS, которые в одной-двух библиотеках пофиксят и дальше все будут использовать новый, а другое дело осознанно сломать КАЖДОЕ веб-приложение в мире.
Полностью обратную совместимость никто и не ломал, в статье предлагается отказаться от одной вредоносной особенности протокола (с точки зрения пользователя). А пока что у нас получается не протокол для пользователей, а пользователи для протокола.
>По-факту разницы конкретно в данном случае я не вижу. Всем, кому была важна производительность и безопасность, это было «нужно», а не «можно». Именно эти люди и HTTP/2 начнут использовать, по тем же причинам.
И таких сайтов на весь интернет не наберется 1%. А когда протокол пишется под нужны корпораций, а затем навязывается большинству в качестве стандарта, но большинство от этого ничего не выигрывает — вас ничего в этом не настораживает?
>См. картинку о «теперь у нас 15 стандартов»
Какая разница, сколько у нас стандартов, если официальный — только от IETF.
>У ютюба много своих целей, да. HTTPS — средство достижения этих целей. И, если это средство делает возможным существование Youtube, то это удобство пользователя.
Ютуб и без https отлично существовал, а вот просмотр видео через https на смартфонах убивает заряд батареи раза в два быстрее. Вы опять пытаетесь выдать багу за фичу, нужды корпораций за потребности пользователей.
>Куки нужны, поскольку это обратная совместимость, да. Что касается этой надуманной проблемы с финансовыми трейдерами и аналитиками ЦРУ — ну так, блин, сделайте для них ПО, которое будет всё расшифровывать и куда надо складывать, заставьте их пользоваться только этим ПО. Наезды на HTTP/2 в этом плане — это как запрет разрабатывать автомобили, ездящие быстрее 5 км/ч, поскольку кое-где есть знаки, которые ограничивают скорость до этого уровня.
Так в том-то и дело, что фактически разработан автомобиль, который не умеет ездить медленнее, чем 10км/ч. Сел — и либо ты едешь быстрее 5 км/ч, либо не едешь никуда. В чем проблема сделать HTTP/2 без принудительного шифрования, как в HTTP/1.1, когда администратор сам решает, что ему надо — шифрование, производительность или и то, и то вместе взятое? Ну, кроме желания отдельной группы людей, вышедших под флагом «SSL everywhere» для обслуживания их коммерческих интересов?
Myateznik
30.05.2016 22:31> В чем проблема сделать 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.
tmnhy
30.05.2016 00:28+1Повышает, поскольку его будут по-дефолтку включать с шифрованием, а чтобы включить его без шифрования — нужно будет ещё постараться и не факт, что выйдет.
Тут в чем проблема назревает, привив пользователю привычку «зеленый замочек — безопасно», для того чтобы злоумышленнику|корпорации|государству создать ложное чувство защищенности, будет достаточно просто этот замочек рисовать…
mantyr
29.05.2016 23:05-1Главное что бы была возможность апгрейдить протокол в будущем без накладных расходов. А то выйдет как с ipv4 -> ipv6 когда и хочется и колется.
zim32
30.05.2016 00:28+9Учитывая насколько большая доля мультимедийного трафика, принудительное ссл выглядит странно.
Alesh
30.05.2016 01:08+1Это уже больше не к странностям а к проблемам. Шифровать мультимедиа контент бред и лишняя трата ресурса. Достаточно было бы идентификации сервера и проверки подлинности. Думаю это можно было бы решить не используя TLS/SSL, ведь все таки не минорное изменение версии.
arteast
30.05.2016 09:15На самом деле провайдеры мультимедиа-контента обожают его шифровать (т.к. это позволяет сделать более развесистый DRM), но они очень не любят шифровать сессию, в которой он передается (т.к. на конфиденциальность клиента им плевать, а вот на загрузку серверов CDN — нет).
Alesh
30.05.2016 10:08+2провайдеры мультимедиа-контента обожают его шифровать
Первый раз слышу, дадите ссылку почитать? Всегда думал что шифрованием контента в DRM целях (если это вообще делается) занимается издатель мультимедиа-контента, а не провайдер. И к протоколу передачи это никакого отношения не имеет.arteast
31.05.2016 11:50Под провайдером я и подразумеваю издателя. Ну, к примеру, большая часть HLS-вещаний, с которыми я сталкивался, зашифрована по AES-128. Даже если это вещание эфирного канала. На уровне протокола, естественно, при этом используется HTTP без SSL/TLS. Клиентским устройствам приходится тратить ресурсы на декодирование видеопотока, но никакой выгоды клиенту от этого нет.
Если передавать через TLS/SSL, то хотя бы ваш провайдер/сосед/дядяВася не узнает, что именно вы смотрите.
tangro
30.05.2016 10:08-1Почему шифровать мультимедиа — бред? Там что, не важна конфиденциальность, или копирайт, или защита канала? В видеопотоке точно так же могут быть личные данные, секретная информация, контент не для публичного показа и т.д.
Alesh
30.05.2016 10:14+2Я написал, идентификации сервера и проверки подлинности нужна, остальное нет. Речь шла, о публикации общедоступного ММ контента. Если вы собираетесь показывать что-то не для публичного показа — ради бога, я не предлагал отказаться от HTTPS.
merlin-vrn
30.05.2016 14:31+2В публичном видео на ютубе — секретная информация? Конечно, конечно.
ivan386
31.05.2016 14:03Есть видео которые доступны только по ссылке и не хотелось бы чтобы эту ссылку узнал кто то ещё.
merlin-vrn
31.05.2016 15:00Эта проблема вообще нерешаема в случае с «секретной ссылкой». Например, один из ваших доверенных, кому вы ссылку сообщаете, может оказаться жуком и сольёт её. Или кто-то случайно увидит из-за спины. Или сломают сам протокол, с помощью которого вы распространяете ссылку между доверенными. (Я не имею ввиду «техническое» понимание слова «протокол», а общее — «сломают протокол» может означать и, например, «заполучат письмо со ссылкой методами социальной инженерии».)
В общем, если у вас такое секретное видео, которое вы не хотите показывать случайным прохожим, ему вообще не место на ютубе.
Alesh
30.05.2016 00:36+3Отличная статья, но вот эти поэтические вступления и отсылы к глобальному потеплению уже утомляют у западных авторов. Хорошо хоть посвящения супруги и детям нет)
vsb
30.05.2016 00:41+8Очень коробит упоминание экологии к программированию. Я не считал числа, но мой здравый смысл подсказывает, что влияние HTTP/2 на экологию настолько мизерно в сравнение с реальными экологическими проблемами, что не стоит упоминания. Тем не менее эта тема периодически всплывает и меня это несколько удивляет. Может быть кто-нибудь меня поправит? Вот чадящий жигулёнок 80-х годов под моим окном, это экологическая проблема: его выхлопы оседают в моих лёгких. Энергия в мой ноутбук приходит от ТЭЦ, которая расположена достаточно далеко от жилых районов города; снабжена хорошими фильтрами и другими очистительными системами. От того, что во всём городе возрастёт потребление электроэнергии персональными компьютерами на пару десятых процента, скорее всего общее потребление вообще не изменится за пределами статистической погрешности, не говоря уже о вредных выбросах.
VBart
30.05.2016 01:30+1Помимо компьютеров и кучи различных клиетских девайсов, подключенных к сети, есть еще датацентры набитые серверами, под которые иногда целые электростанции строят, и всевозможные промежуточные машрутизаторы.
Есть такая организация как CEET (Centre for Energy-Efficient Telecommunications), которая занимается этими вопросами. По их подсчетам на интернет уже к 2020 году будет приходиться до 10% от всей потребляемой человечеством энергии.hdfan2
30.05.2016 08:29Ладно, пусть 10%. Но это совершенно не значит, что, оставшись на HTTP 1.1, мы сэкономим хоть какую-то заметную долю из этих 10%. Я, конечно, не считал, но просто по ощущениям тот же круизный лайнер (https://geektimes.ru/post/276182/) за один рейс выбросит намного больше всякой вредной фигни. Очень похоже на преждевременную оптимизацию.
arteast
30.05.2016 09:18+2В этом разрезе было бы интересно примерить влияние других новшеств на экологию. Переход с H264 SD на HEVC FHD (а то и 4K) нехило увеличивает нагрузку на всё — и на кодирующие фермы, и на каналы передачи данных, и на миллионы декодирующих устройств. Любые накладные расходы HTTP/2 на фоне 20-мегабитного видеопотока не просто малозначительны — они вообще незаметны. Надо подкинуть «зеленым» идею требовать запрета видеопотоков выше 1 мбита!
TimsTims
30.05.2016 11:42+2Согласен с вами. Когда смотришь онлайн-видео в HD, то проц нехило так весь проц отжирает (постоянно >70% ЦП). На этом фоне — небольшая дополнительная нагрузка в +1% на HTTP/2 выглядит смешно. Стоит нападать на создателей 4K за их наплевательское отношение к матушке-природе! И вообще надо все развлекательные сервисы выкинуть, пусть компы работают только для науки. </sarcаsm>
Ivan_83
30.05.2016 13:23Вы его не правильно смотрите.
В фаерфокс ставится плагин watch-with-mpv и ставится mpv + youtube-dl, после чего mpv настраивается чтобы первым делом использовал аппаратное декодирование.
Дальше всё видео с ютупов и некоторых других сайтов смотрится не в браузере а в mpv.
По факту плагин просто передаёт ссылку в mpv, а он воспроизводит. Я таким образом могу ссылки из дирлистинга на домашнем серваке смотреть.
А уж удобство MPV при просмотре на порядки превосходит любое браузерное поделие.
В качестве бонуса для ютупа не показывается реклама и всякий ссылочный шлак поверх изображения.TimsTims
30.05.2016 14:56Я с вами полностью согласен, осталось только mpv player поставить каждому пользователю на планете, чтобы снизить выбросы Co2 в атмосферу.
Мой же коммент был направлен на то, что изначально создатели браузеров/контента/или_кто_там_за_это_отвечает неправильно сделали видеоплеер в браузере, что он так много жрёт.
> Вы его не правильно смотрите.
Кстати, я ведь не только Youtube HD смотрю, но еще и Twitch люблю посмотреть. А тамошний стрим я даже не знаю какой плеер поддерживает.
tsukasa_mixer
31.05.2016 23:08Таки ваша придумка уже имхо лишняя. Современные браузеры используют VAAPI которое по сути пробрасывает декодирование до драйверов видеокарты, что позволяет при возможности декодировать видео силами хардварных декодеров.
В *nix системах уже по моему везде стоит данный пакет из коробки. (что кстати создает проблемы со старыми nvidia vdpau драйверами, но ....)Ivan_83
01.06.2016 00:29Придумка увы не моя.
В фильме идиотократия чел смотрел ролик, при этом вокруг ролика была ещё куча всякой мигающей рекламы, по площади этот кашмар намного превышал то что смотрел чел.
Вот ютуп к этому стремится.
Даже если забыть что браузер у меня иногда подтормаживает из за кучи вкладок, забыть про мусор вокруг, забыть про рекламу которую я не вижу, то остаётся ещё удобство управления плеером.
Изначально это всё затевалось потому что фф валился при просмотре видео, но теперь я не хочу отказываться от комфорта и смотреть видео в свинарнике. Это как перестать смотреть телек/монитор через замочную скважину и уютно устроится в кресле напротив большого экрана.
eugzol
30.05.2016 01:02+7Когда компьютеры были медленные, а их время очень дорого, старались делать текстовые форматы хранения и обмена информацией для облегчения отладки её людьми. Когда компьютерное время стало стоить копейки, регресс обратно к бинарным форматам в угоду машин. Корпорациям выгодно плодить сложные и кривые протоколы для сохранения монополий на своих рынках. Ну а комитеты формализуют и закрепляют их волю. Так что да, политика.
Arenim
30.05.2016 01:17+3А можно ли — для полноты картины — привести несколько примеров улучшений, которые были отвергнуты? Ну, те самые, которые «вне повестки» и т.п.? Интересно знать, что мы потеряли?
Что же до обязательного SSL, то я, наверное, поддержал бы эту затею. Все-таки затраты на поточную симметричную шифровку-дешифровку не так уж велики, а «ассиметричная» часть там все равно не зависит от размера передаваемого пакета.
Ivan_83
30.05.2016 01:18+3Зачем то экологию приплели.
Понятно что в масштабах планеты это лишние пару гигаватт, если повсеместно внедрят, но CO2 чтобы примазывать нужно сравнивать с выделениями каких нибудь болот, и может статься что на фоне болот или других естественных источников этого и заметно не будет.
То что шифрование браузеры навязывают это фашизм, не иначе.
Мне оно ни разу не впёрлось когда лазаю в локалке по роутерам, свичам, точкам доступа и внутренним сайтам.
Да и большинство сайтов — мне ни шифрование ни даже аутентификация не вперлись.
Ещё хуже что самоподписные сертификаты объявляют невалидными без возможности это изменить.
Касательно самого протокола — думаю у него есть все шансы никогда не вытеснить 1.1, и для этого масса причин:
1. Тонны железа с вебадминками на 1.1 без перспектив апгрейда (да и не нужен он только ради 2.0)
1.1 HTTP/1.1 есть ещё в тоннах железок которые у всех дома: всё что UPnP/DLNA — там всё по http/1.1 ходит.
1.2 Всякие девайсы с IPTV — если там полноценный HLS то там уже есть шифрование AES, а если это mpeg2ts@HTTP/1.1 то оно там и не надо, но может быть тоже уже есть, кроме того оно часто в сетях провайдера а он и так знает кто какое порно когда смотрел.
2. Сложность имплементации: бинарный протокол сложно имплементировать, а тут ещё и TLS навязывают. 1.1 реализуется студентом за пару вечеров а над 2.0 надо пахать неделю как минимум и не студенту…
2.а. Потенциально большая забагованность реализаций: если реализации 1.1 в основном баговали из за не точностей/вариаций заголовков, и крайне редко крашились/повреждали память то вся история имплементации бинарных протоколов говорит о выходе за границы, повреждении стёка, зацикливание и тп. Вроде уже что то было из этой серии какой то реализации 2.0. (Тут самое время вспомнить старый добрый DNS, которому лет больше, чем HTTP/1.0 а в реализациях до сих встречаются всякие трагические неприятности)
3. Отсутствие понимания зачем оно надо: 1.1 вполне годно пашет, легко дебажится админами(!), легко сетапится.
С другой я вполне понимаю зачем оно было нужно гуглу, и теперь всяким нетфликсам.
Гуглу платят за показ рекламы, поэтому они экспериментировали со сжатием и ускорением, притом уже давно, когда то помнится у них был даже собственный открытый прокси для ускорения интернета.
Гуглу важно чтобы рекламу не фильтровали, не заменяли, не кешировали и ещё ему важно чтобы реклама успела хотя бы скачатся прежде чем юзер поймёт что эта страница ему не интересна.
Обычному юзеру секундой больше, секундой меньше разницы нет: у меня эта страница открыта столько, что можно было пару сотен гигов скачать на моём линке.
Собственно всё это и решено в пределах SPDY.
Нетфликсу и прочим оно надо чтобы показать как они борются с пиратством, типа смотрите, никто не сможет подсмотреть кино которое купил юзер.
grossws
30.05.2016 02:23+2Соглашусь лишь частично. 1.1 реализуется студентом, видимо, за венерианские сутки (и то, потому что оочень хочет жить). Объём спек, связанных с http/1.1 огромен и полностью 1.1 никто и не реализует, за ненадобностью.
Принципиальной разницы в защищенной имплементации текстового и бинарного протоколов нет. Переполнения, неправильная интерпретация символа NUL и т. п. ничем не отличается в этих двух случаях.
Касательно отладки — реально всё равно нужны инструменты: обычно трафик ходит по http не в plain text: используются tls, chuncked, gzip, с которыми протокол всё равно частично бинарный.
creker
30.05.2016 02:44Принципиальной разницы в защищенной имплементации текстового и бинарного протоколов нет
Ну как же нет. Обычно текстовые протоколы это либо парсер, либо чтение с помощью терминальных символов. Последнее это как раз про HTTP и поле для потенциально эксплуатируемых ошибок тут куда меньше. Ошибка если и будет, то это будет DoS или еще что-то совершенно не связанное с RCE. Бинарный же протокол это практически всегда либо четко указанная длина блока, либо фиксированная длина, что уже дает огромное поле для разного рода ошибок, которые приводят к серьезным уязвимостям. От чего, собственно, так популярны фаззеры бинарных протоколов и форматов файлов.
Ivan_83
30.05.2016 02:55+2Минимально рабочий вариант 1.1 это snprintf() для генерации заголовка и какой то довольно простой парсер, который и пишется пару вечеров.
А реализация что DNS что DHCP у меня отняла довольно много времени как на сборку так и на разбор пакетов, и это я ещё не делал компресии имён при формировании днс пакетов.
POP3, SMTP — заработали довольно быстро, ибо текстовые, хоть я и был начинающим.
Отличаются.
В текстовых протоколах весь парсинг намного очевиднее, хотя бы в силу этого ошибок реализации сильно меньше.
Для отладки 1.1 я использовал самописный терминал: http://netlab.dhis.org/wiki/ru:software:win:net:tcp_term
которым я отлаживал ещё и другие протоколы. Как админ я просто могу через tcpdump быстро глянуть заголовки и данные пролетающих мимо пакетов.
TLS используется далеко не всегда, к тому же отлаживаться можно и без него. А если приложение или сервер своё то TLS вообще никак не мешает видеть запросы и ответы. Для чужих приложений тоже есть варианты как снять TLS если они в подконтрольной среде.
chunked ни разу не мешает видеть что передаётся, просто добавляется номер в HEX и CRLF в данных.
gzip, deflate и тп — оно применяется к передаваемым данным, но не к заголовкам.
Кроме того и чункед и сжатие являются опциональными и влияют на payload а HTTP это больше про заголовки.
VBart
30.05.2016 03:02+5HTTP/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 такой фокус уже не пройдет.
orcy
30.05.2016 09:00> 2. Сложность имплементации: бинарный протокол сложно имплементировать,
> 2.а. Потенциально большая забагованность реализаций:
Я тоже не был фанатом HTTP/2 (и сейчас не фанат, но и опыта особого нет), однако где-то в статьях про него увидел переубеждение по этим вопросам. Бинарный протокол может быть более простым для реализации так как убирает работу по парсингу и вы получаете служебные данные (вроде Content-Length) уже как нужно программе. Более сложной вещь может сжатие заголовков (HPACK), мне трудно сказать насколько оно сложное и подвержено багам.VBart
30.05.2016 12:40+1Семантика HTTP/2 по большей части осталась от HTTP/1.x, о чем даже спецификация заявляет с самого начала. После распаковки вы получаете всё тот же Content-Length 100 в текстовом виде, который нужно всё также парсить. Можно там в HPACK это немного пооптимизировать, в смысле что не парсить каждый раз, а узнавать о том, что это такой же заголовок с таким же значением ещё на этапе распаковки, но реализацию это ни разу не упрощает, а наоборот.
Scf
30.05.2016 09:45Странная статья со странными выводами. 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. Выбор будет всегда.
Ivan_83
30.05.2016 10:38+6У меня для вас новость: 2 TCP соединения быстрее передадут тот же объём информации, чем одно. В некоторых случаях в два раза. Соответственно 6-8 соединений во столько же раз.
Я уже выше написал — задача гугла была показать рекламодателям что реклама загрузилась юзеру, они это решили в протоколе.
На практике мне плевать что сайт сбера открывается на 0,5 сек дольше, а остальные могли бы и не утруждать себя поддержкой TLS, ибо ничего ценного у них нет.
Единственная разумная для юзера причина использования TLS, кроме взаимодействия с фин/мед учреждениями это всякие дерьмопровайдеры которые инжектят своё говно или сливают заголовки третьим лицам.
Про ресурсы лучше не упоминать.
Даже в случае когда в проце есть аппаратное шифрование оно сильно медленее чем DMA копирование контроллером сетевухи и ощутимо прожорливее.
Тот же nginx используя sendfile() задействует все оффлоадинги доступные в ОС для отдачи, и если файл в кеше/тпмфс, то по факту сетевой контроллер получает задание переслать кусок памяти и на этом работа ОС и проца практически заканчивается.
Клиенты далеко не все поддерживают шифрование в проце, и я не только про ещё кучу живых систем на 775 и прочих машин которым более 5 лет, но и про всякие более новые атомы, и тем более арм/мипс.
Именно для таких гугл использовал Chacha20 — её легко запилить на SSE/NEON, да и в принципе она менее прожёрливая.
Использование ReGet в лохматых годах наглядно показало что для эффективной закачки в интернет хх соединений рулят.
Я всё к тому, что профиты для всех кто не гугл не очевидны, и больше смахивают на маркетинговый шум.
Ну есть ещё всякие дерьмо СЯО-МЯО у которых юзер тоже сбегает едва завидев их сайт и не дождавшись рекламы, желаю им не засорять интернет %)Scf
30.05.2016 10:45Про скорость многопоточной закачки — я нашел вот это. Можете рассказать, почему два соединения будут быстрее, на уровне TCP/IP?
Ivan_83
30.05.2016 12:20+1Потому что фактически окно передачи в TCP увеличивается, в этом большом окне ретрансмиты начинают выполнятся параллельно.
Редкие дропы скорее всего не заденут все соединения сразу, поэтому падение скорости будет в пределах нескольких соединений, те в сумме гораздо меньше.
После определённого количества соединений скорость начинает падать из за выросших накладных расходов на передачу служебной информации. На диалапе больше 4 соединений в качалке уже начинало становится заметно как скорость закачки уменьшается, на 128 килобит адсл оптимально где то в пределах 8. Да и сейчас, на линке более 100 мегабит 16 соединений обычно достаточно чтобы утилизировать линк, при условии что отдающая сторона может столько отдать. С торрентами приходится ставить больше, тк часто они медленно отдают.Scf
30.05.2016 12:34Т.е. для каналов с приличным % потери пакетов TCP считает, что пакеты теряются из-за шейпера и урезает окно. Но надо же смотреть в светлое будущее, а не в темное прошлое :-)
С торрентами немного другая история — там много соединений с разными сидами позволяет справляться с ситуацией, когда канал получателя шире канала отправителя.
VBart
30.05.2016 12:34+3У нескольких соединений будет суммарно больше окно, причем, что важно, с самого начала. Потеря пакета затронет только одно из нескольких соединений. Обработку нескольких соединений проще параллелить, они могут обрабатываться разными процессами, в том числе на уровне ядра или даже быть распределены по разным серверам, переданы по разным каналам.
Scf
30.05.2016 12:54Ну как с самого начала — сначала установить соединение, потом скачать хтмл, потом опять устанавливать соединения… При высоком пинге это сильно увеличивает latency. Особенно при использовании TLS. Читал где-то, что разрабатывается стандарт для упрощенного (в плане кол-ва round-trip-ов) TLS, но когда мы его увидим...
А вообще — когда вы сделаете HTTP/2 prefetch? Это будет мощный довод переходить на новый протокол для технологически продвинутых веб-мастеров.
VBart
30.05.2016 13:08Современные браузеры не ждут, пока html скачается, а открывают сразу несколько соединений. Единственная их проблема, что они по-умолчанию ограничены 6 соединениями по RFC и если уж запросили какую-то картинку, то не могут остановить передачу и запросить что-то другое не разрывая соединения. Собственно на этом HTTP/2 и выигрывает, только для реализации того же не нужно было столько всего городить.
HTTP/2 server push? Вообще с ним пока все не так хорошо в браузерах (как в общем и самим протоколом), кто пытается использовать — время от времени сталкивается не с ускорением, а с багами. Реализация и отладка HTTP/2 и так отняла столько ресурсов, что на данный момент пока никаких ETA на дополнительные работы по HTTP/2.Scf
30.05.2016 14:01Спасибо за информацию)
Наверное, браузеры в будущем будут открывать несколько соединений HTTP/2 параллельно по указанным вами причинам.
Ivan_83
30.05.2016 14:24+2У TCP пачка разных алгоритмов контроля перегрузки, все они работают по разному, для всех них есть только потеря пакетов, почему она произошла там предположений нет.
Никакого особенного прогресса с этими алгоритмами не предвидится, более того в той же FreeBSD htcp работает на порядок хуже, чем в линуксе на ртт более 70 и дропах.
Уже давно есть киаплив, есть пайплайнинг почти во всех текстовых протоколах.
И то что несколько TCP соединений заменяют одним никак не уменьшает количество служебки необходимой для передачи, а при передаче больших файлов наоборот увеличивает, потому что к обычному TCP добавляется ещё служебка HTTP/2.
orcy
30.05.2016 12:42> а остальные могли бы и не утруждать себя поддержкой TLS, ибо ничего ценного у них нет
Ну это какая-то вообще наивность. Такой вой поднимется если какой-то крупный сервис не поддерживает безопасное соединение. Если вам оно не нужно, это не значит что всем остальным не нужно. Сейчас App Store/Google Play при приеме приложений начинают выдавать предупреждения если приложение устанавливает небезопасное HTTP соединение.
Вряд ли вы уведите сейчас как несколько TCP соединений работают быстрее чем одно, тогда HTTP/2 был бы медленнее на тестах, это не так (или быстрее или столько же для хорошо оптимизированных сайтов). Впрочем это должно быть возможно, особенно если кто-то шейпит трафик (провайдер, корпоративный firewall, сервер). Кроме накладных расходов на на безопасность, TCP соединение еще надо «разогреть», т.е. возможность работы через одно разогнанное TCP соединение может немного уменьшить задержку при работе с сайтом (хотя я не могу вот так из головы придумать сценарий — ведь не сильно важно сколько именно соединений разогревать — одно или несколько).
forgotten
30.05.2016 10:20Как человек, имевший некоторое (пусть и по касательной) отношение к обсуждению и утверждению HTTP/2 должен заметить, что статья совершенно безграмотна и с технической, и с архитектурной точки зрения.
Достаточно сказать, что в двух соседних абзацах автор сначала жалуется на то, что HTTP/2 плохо структурирован и лезет в чужие уровни абстракции, а потом требует добавить в HTTP/2 шифрование и управление идентфикаторами сессий.
HTTP/2 неидеальный стандарт. Однако критиковать его бессмыссленно просто потому что он не окажет никакого воздействия на производительность сети. Ну да, некоторые крупные сервисы найдут на чем сэкономить пару процентов, но не более того.
Позвольте, а кто вам вообще сказал, что на неё (производительность сети) можно как-то повлиять на уровне протокола HTTP? HTTP — очень-очень-очень ограниченный протокол. Он всего лишь описывает заголовки выполнения операций над ресурсами. Всё остальное делается либо на предыдущих шести уровнях сетевого стека, либо на уровне веб-приложения. Ну вот да, в HTTP/2 понапихали всяких кросс-интеграций и оптимизаций, получив очень сложный стек с примерно нулевым влиянием на реальный мир.
cruxacrux
31.05.2016 16:07+1Камп сам активно принимал участие в обсуждении стандарта http/2 практически с самого начала. У него всегда было много претензий, а также странных идей, как, например, вынести некоторые «транспортные» http-заголовки (host, url, length,..) вне шифрования и сжатия, чтобы было удобно организовать управление потоками в 1Тб/сек на varnish. При этом на замечание от других участников, что свои предложения лучше оформлять в виде драфта, жаловался, что ему никто не хочет платить денег за работу над стандартом http/2.
Стандарт получился таким, каким получился, у многих была возможность высказать свои идеи. Какие-то были приняты, какие-то отвергнуты, где-то пошли на компромиссные решения. Назвать протокол халтурой — это неуважение к работе многих профессионалов.merlin-vrn
06.06.2016 08:36+1Смысл поста в том, что профессионалам должно быть стыдно под таким подписываться. Да, сил потрачено много, и это что, что-то значит?
Как в школе: никого не волнует, что «ты учил». Волнует, чтобы «выучил».
Тут: стандарт делали, да не доделали. Был бы он «доделан» — не было бы таких претензий. А как он есть, склепаный на скорую руку из того, что было, ни одно техническое противоречие не разрешено, ни одной фичи, которую нельзя было бы сделать без него — халтура, конечно.
kanstantsin
Валентин, вы согласны с автором?
VBart
Согласен.