Comments 79
Кстати, я тут не согласен с автором. SSL это один из немногих, если не единственный, способ, чтобы идентифицировать сервер для клиента. И даже если медиа-бизнесу наплевать, что клиенту подсунут вместо настоящего сайта фейк с троянами, то клиенту это вовсе не безразлично.
Можете предложить более точный и благозвучный перевод? В абзаце не идет речь о конкретной страничке, а скорее о том, что в условиях чрезвычайной ситуации приватность уходит на второй план и куда важнее сохранить возможность распространять информацию, чем тратить ресурсы на её шифрование.
P.S. Переименовал пока в "Сайт МЧС..."
белки_истерички.jpg
Во-вторых, если какая-то компания начнёт подписывать своим 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.» И нету ни одной причины, почему-бы их железо не стояло в других странах.
корпоративные CA почти всегда самоподписные, и для работы именно корпоративного MitM не нужно иметь «настоящий» CA, которому бы доверяли некорпоративные браузеры, тем более для тестирования
А кто сказал, что сертификат CA будут использовать именно для этого?
если какая-то компания начнёт подписывать своим CA левые сертификаты у неё этот CA очень быстро отберут, примеры были.
Я в курсе и не понимаю к чему эта паника. Была же история с разработчиками прокси-сервера, которые поставили свой сертификат на железку во внутренней сети и лишились его за нарушение CPS после запуска Хрома с google.com.
На реддите в топе отличный комментарий, где всё это разжовано.
Он нарушает целостность отдельных, ранее изолированных слоев, переусложнен, содержит кучу нестыковок, плохих компромиссов, упущенных возможностей и т. д.
Какую целостность, о чём вообще речь?
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.
Существуют категории людей, которые легально лишаются конфиденциального обмена информацией: дети, заключенные, финансовые трейдеры, аналитики ЦРУ
Если этим людям кто-то запрещает конфиденциальность — то это его дело обеспечить соблюдение данного запрета. Просто не разрабатывать какие-то технологии из-за того, что в мире есть люди, которым ими пользоваться будет нельзя — это чушь.
Какую целостность, о чём вообще речь?
Речь о том, что протокол представляет из себя один большой 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» как плацдарм для навязывания своей точки зрения.
занимается не тем, чем ему положено заниматься на данном уровне, а также лезет в соседние
Ок, занимается и лезет. Возьмите каждого первого пользователя и спросите его, что для него важнее, чтобы протокол не лез на чужие уровни ответственности сетевого стека или чтобы фейсбучек загружался на 1.5 секунды быстрее. Послушайте ответ и задумайтесь, что вообще первично — потребности пользователей или стройность картины мира в голове сетевиков и программистов.
Закрепляется на законодательном уровне в виде промежуточного прокси и сертификата, который все жители страны должны добавить в доверенные, иначе не смогут в интернет выйти.
Проблемы тоталитарных стран — это не вопрос к протоколу. Какой бы протокол не придумали — можно ввести в стране смертную казнь за пользование компьютером и вдруг окажется, что протокол на данной территории не эффективен, поскольку никто им не пользуется.
Никто никого не заставляет переходить на новый протокол срочно, в этом нет никакой острой необходимости.
Если бы был предложен кардинально новый протокол, требующий переписывания всего кода, то никто бы в жизни его не стал использовать. Ни сейчас, ни через 10 лет.
Гугл, в свою очередь, набив шишек со SPDY пошел копать в сторону QUIC
Ну, во-первых SPDY и QUIC начали пилиться примерно в одно время (см. википедию). Во-вторых, успех SPDY очевиден в виду его взятия за основу стандарта HTTP/2 и поддержки всеми основными браузерами. На сегодня протокол элементарно включается на стороне сервера и шустренько бегает у любого пользователя, за исключением свидетелей секты шестого IE, принципиально не обновляющихся. Успех QUIC пока очень ограничен, до массовости пока далеко.
Просто используется сторонниками «SSL everywhere» как плацдарм для навязывания своей точки зрения.
Типа их позиция — это какое-то зло и проталкивать её плохо?
Ок, занимается и лезет. Возьмите каждого первого пользователя и спросите его, что для него важнее, чтобы протокол не лез на чужие уровни ответственности сетевого стека или чтобы фейсбучек загружался на 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 правда тоже тот ещё прототип, но до тех пор, пока это дело одной компании, это никому не вредит.
Типа их позиция — это какое-то зло и проталкивать её плохо?
Да, зло, как и любая радикальная позиция, когда людям пытаются навязать что-то, в чем они не нуждаются, при этом делают это под видом заботы о конфиденциальности.
А покажите теперь, кто включил HTTP/2 и ему оказалось «медленнее, а иногда вообще никак»?
Тем у кого плохое соединение HTTP/2 не только не поможет, но и все сильно ухудшит. Потеря пакета в HTTP/1.x соединении приводит к задержке всего одного запроса, та же самая потеря в HTTP/2 тормозит все запросы. А заметное количество регулярно передаваемой туда и обратно служебной информации только умножает эту вероятность.
Использовать слово "мерял" по отношению к этой статейке на 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 в условиях ограниченного числа соединений и большого числа объектов.
Давайте не будем выдавать лень программистов за фичу. IMAPS/POPS/SMTPS/свежие версии Windows/Linux/Drupal/Wordpress ломали совместимость на отличненько, но никто не плакается, что что-то сломалось с выходом новой версии.
>И шифрование, и сжатие было можно включать и для HTTP/1.1. Более того, для HTTP/2.0 нужно сжимать\разжимать существенно меньше заголовков.
Вы не видите разницы между «можно» и «нужно»?
>Раздел о политике написан странно. Да, IETF подхватила инициативу Гугла, взяв уже и так неплохо работающий SPDY и сделав его лучше. А что надо было делать — с нуля писать? А зачем?
Вы так говорите, словно разработать протокол — это что-то плохое.
>То-то Youtube и Netflix насильно переводят все соединения в HTTPS.
У ютуба другая цель — завернуть все в HTTPS, чтобы было меньше фильтрации и больше просмотров, больше открутки рекламы, больше прибыли. Вы путаете полезность для пользователя с полезностью для корпорации.
>Если этим людям кто-то запрещает конфиденциальность — то это его дело обеспечить соблюдение данного запрета. Просто не разрабатывать какие-то технологии из-за того, что в мире есть люди, которым ими пользоваться будет нельзя — это чушь.
Вы как-то определитесь, то вам нужны куки из HTTP/1.1, то вам плевать на совместимость со старыми нормами.
Давайте не будем выдавать лень программистов за фичу.
Давайте не будем выдавать сломанную обратную совместимость за фичу. Одно дело сломать протокол типа IMAPS, которые в одной-двух библиотеках пофиксят и дальше все будут использовать новый, а другое дело осознанно сломать КАЖДОЕ веб-приложение в мире.
Вы не видите разницы между «можно» и «нужно»?
По-факту разницы конкретно в данном случае я не вижу. Всем, кому была важна производительность и безопасность, это было «нужно», а не «можно». Именно эти люди и HTTP/2 начнут использовать, по тем же причинам.
Вы так говорите, словно разработать протокол — это что-то плохое.
См. картинку о «теперь у нас 15 стандартов»
У ютуба другая цель — завернуть все в HTTPS, чтобы было меньше фильтрации и больше просмотров, больше открутки рекламы, больше прибыли. Вы путаете полезность для пользователя с полезностью для корпорации.
У ютюба много своих целей, да. HTTPS — средство достижения этих целей. И, если это средство делает возможным существование Youtube, то это удобство пользователя.
Вы как-то определитесь, то вам нужны куки из HTTP/1.1, то вам плевать на совместимость со старыми нормами.
Куки нужны, поскольку это обратная совместимость, да. Что касается этой надуманной проблемы с финансовыми трейдерами и аналитиками ЦРУ — ну так, блин, сделайте для них ПО, которое будет всё расшифровывать и куда надо складывать, заставьте их пользоваться только этим ПО. Наезды на HTTP/2 в этом плане — это как запрет разрабатывать автомобили, ездящие быстрее 5 км/ч, поскольку кое-где есть знаки, которые ограничивают скорость до этого уровня.
Полностью обратную совместимость никто и не ломал, в статье предлагается отказаться от одной вредоносной особенности протокола (с точки зрения пользователя). А пока что у нас получается не протокол для пользователей, а пользователи для протокола.
>По-факту разницы конкретно в данном случае я не вижу. Всем, кому была важна производительность и безопасность, это было «нужно», а не «можно». Именно эти люди и HTTP/2 начнут использовать, по тем же причинам.
И таких сайтов на весь интернет не наберется 1%. А когда протокол пишется под нужны корпораций, а затем навязывается большинству в качестве стандарта, но большинство от этого ничего не выигрывает — вас ничего в этом не настораживает?
>См. картинку о «теперь у нас 15 стандартов»
Какая разница, сколько у нас стандартов, если официальный — только от IETF.
>У ютюба много своих целей, да. HTTPS — средство достижения этих целей. И, если это средство делает возможным существование Youtube, то это удобство пользователя.
Ютуб и без https отлично существовал, а вот просмотр видео через https на смартфонах убивает заряд батареи раза в два быстрее. Вы опять пытаетесь выдать багу за фичу, нужды корпораций за потребности пользователей.
>Куки нужны, поскольку это обратная совместимость, да. Что касается этой надуманной проблемы с финансовыми трейдерами и аналитиками ЦРУ — ну так, блин, сделайте для них ПО, которое будет всё расшифровывать и куда надо складывать, заставьте их пользоваться только этим ПО. Наезды на HTTP/2 в этом плане — это как запрет разрабатывать автомобили, ездящие быстрее 5 км/ч, поскольку кое-где есть знаки, которые ограничивают скорость до этого уровня.
Так в том-то и дело, что фактически разработан автомобиль, который не умеет ездить медленнее, чем 10км/ч. Сел — и либо ты едешь быстрее 5 км/ч, либо не едешь никуда. В чем проблема сделать HTTP/2 без принудительного шифрования, как в HTTP/1.1, когда администратор сам решает, что ему надо — шифрование, производительность или и то, и то вместе взятое? Ну, кроме желания отдельной группы людей, вышедших под флагом «SSL everywhere» для обслуживания их коммерческих интересов?
Так в текущем стандарте это и предусмотрено: хочешь используй 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.
Повышает, поскольку его будут по-дефолтку включать с шифрованием, а чтобы включить его без шифрования — нужно будет ещё постараться и не факт, что выйдет.
Тут в чем проблема назревает, привив пользователю привычку «зеленый замочек — безопасно», для того чтобы злоумышленнику|корпорации|государству создать ложное чувство защищенности, будет достаточно просто этот замочек рисовать…
провайдеры мультимедиа-контента обожают его шифровать
Первый раз слышу, дадите ссылку почитать? Всегда думал что шифрованием контента в DRM целях (если это вообще делается) занимается издатель мультимедиа-контента, а не провайдер. И к протоколу передачи это никакого отношения не имеет.
Если передавать через TLS/SSL, то хотя бы ваш провайдер/сосед/дядяВася не узнает, что именно вы смотрите.
В общем, если у вас такое секретное видео, которое вы не хотите показывать случайным прохожим, ему вообще не место на ютубе.
Есть такая организация как CEET (Centre for Energy-Efficient Telecommunications), которая занимается этими вопросами. По их подсчетам на интернет уже к 2020 году будет приходиться до 10% от всей потребляемой человечеством энергии.
Мой же коммент был направлен на то, что изначально создатели браузеров/контента/или_кто_там_за_это_отвечает неправильно сделали видеоплеер в браузере, что он так много жрёт.
> Вы его не правильно смотрите.
Кстати, я ведь не только Youtube HD смотрю, но еще и Twitch люблю посмотреть. А тамошний стрим я даже не знаю какой плеер поддерживает.
В *nix системах уже по моему везде стоит данный пакет из коробки. (что кстати создает проблемы со старыми nvidia vdpau драйверами, но ....)
Что же до обязательного SSL, то я, наверное, поддержал бы эту затею. Все-таки затраты на поточную симметричную шифровку-дешифровку не так уж велики, а «ассиметричная» часть там все равно не зависит от размера передаваемого пакета.
Соглашусь лишь частично. 1.1 реализуется студентом, видимо, за венерианские сутки (и то, потому что оочень хочет жить). Объём спек, связанных с http/1.1 огромен и полностью 1.1 никто и не реализует, за ненадобностью.
Принципиальной разницы в защищенной имплементации текстового и бинарного протоколов нет. Переполнения, неправильная интерпретация символа NUL и т. п. ничем не отличается в этих двух случаях.
Касательно отладки — реально всё равно нужны инструменты: обычно трафик ходит по http не в plain text: используются tls, chuncked, gzip, с которыми протокол всё равно частично бинарный.
Принципиальной разницы в защищенной имплементации текстового и бинарного протоколов нет
Ну как же нет. Обычно текстовые протоколы это либо парсер, либо чтение с помощью терминальных символов. Последнее это как раз про HTTP и поле для потенциально эксплуатируемых ошибок тут куда меньше. Ошибка если и будет, то это будет DoS или еще что-то совершенно не связанное с RCE. Бинарный же протокол это практически всегда либо четко указанная длина блока, либо фиксированная длина, что уже дает огромное поле для разного рода ошибок, которые приводят к серьезным уязвимостям. От чего, собственно, так популярны фаззеры бинарных протоколов и форматов файлов.
% while true; do echo -n "HTTP/1.1 200 OK\r\n\r\n" | cat - index.html | netcat -lcp 8080; done
то с HTTP/2 такой фокус уже не пройдет.
> 2.а. Потенциально большая забагованность реализаций:
Я тоже не был фанатом HTTP/2 (и сейчас не фанат, но и опыта особого нет), однако где-то в статьях про него увидел переубеждение по этим вопросам. Бинарный протокол может быть более простым для реализации так как убирает работу по парсингу и вы получаете служебные данные (вроде Content-Length) уже как нужно программе. Более сложной вещь может сжатие заголовков (HPACK), мне трудно сказать насколько оно сложное и подвержено багам.
Странная статья со странными выводами. 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. Выбор будет всегда.
Т.е. для каналов с приличным % потери пакетов TCP считает, что пакеты теряются из-за шейпера и урезает окно. Но надо же смотреть в светлое будущее, а не в темное прошлое :-)
С торрентами немного другая история — там много соединений с разными сидами позволяет справляться с ситуацией, когда канал получателя шире канала отправителя.
Ну как с самого начала — сначала установить соединение, потом скачать хтмл, потом опять устанавливать соединения… При высоком пинге это сильно увеличивает latency. Особенно при использовании TLS. Читал где-то, что разрабатывается стандарт для упрощенного (в плане кол-ва round-trip-ов) TLS, но когда мы его увидим...
А вообще — когда вы сделаете HTTP/2 prefetch? Это будет мощный довод переходить на новый протокол для технологически продвинутых веб-мастеров.
HTTP/2 server push? Вообще с ним пока все не так хорошо в браузерах (как в общем и самим протоколом), кто пытается использовать — время от времени сталкивается не с ускорением, а с багами. Реализация и отладка HTTP/2 и так отняла столько ресурсов, что на данный момент пока никаких ETA на дополнительные работы по HTTP/2.
Ну это какая-то вообще наивность. Такой вой поднимется если какой-то крупный сервис не поддерживает безопасное соединение. Если вам оно не нужно, это не значит что всем остальным не нужно. Сейчас App Store/Google Play при приеме приложений начинают выдавать предупреждения если приложение устанавливает небезопасное HTTP соединение.
Вряд ли вы уведите сейчас как несколько TCP соединений работают быстрее чем одно, тогда HTTP/2 был бы медленнее на тестах, это не так (или быстрее или столько же для хорошо оптимизированных сайтов). Впрочем это должно быть возможно, особенно если кто-то шейпит трафик (провайдер, корпоративный firewall, сервер). Кроме накладных расходов на на безопасность, TCP соединение еще надо «разогреть», т.е. возможность работы через одно разогнанное TCP соединение может немного уменьшить задержку при работе с сайтом (хотя я не могу вот так из головы придумать сценарий — ведь не сильно важно сколько именно соединений разогревать — одно или несколько).
Достаточно сказать, что в двух соседних абзацах автор сначала жалуется на то, что HTTP/2 плохо структурирован и лезет в чужие уровни абстракции, а потом требует добавить в HTTP/2 шифрование и управление идентфикаторами сессий.
HTTP/2 неидеальный стандарт. Однако критиковать его бессмыссленно просто потому что он не окажет никакого воздействия на производительность сети. Ну да, некоторые крупные сервисы найдут на чем сэкономить пару процентов, но не более того.
Позвольте, а кто вам вообще сказал, что на неё (производительность сети) можно как-то повлиять на уровне протокола HTTP? HTTP — очень-очень-очень ограниченный протокол. Он всего лишь описывает заголовки выполнения операций над ресурсами. Всё остальное делается либо на предыдущих шести уровнях сетевого стека, либо на уровне веб-приложения. Ну вот да, в HTTP/2 понапихали всяких кросс-интеграций и оптимизаций, получив очень сложный стек с примерно нулевым влиянием на реальный мир.
Стандарт получился таким, каким получился, у многих была возможность высказать свои идеи. Какие-то были приняты, какие-то отвергнуты, где-то пошли на компромиссные решения. Назвать протокол халтурой — это неуважение к работе многих профессионалов.
Как в школе: никого не волнует, что «ты учил». Волнует, чтобы «выучил».
Тут: стандарт делали, да не доделали. Был бы он «доделан» — не было бы таких претензий. А как он есть, склепаный на скорую руку из того, что было, ни одно техническое противоречие не разрешено, ни одной фичи, которую нельзя было бы сделать без него — халтура, конечно.
HTTP/2.0 — Халтура от IETF: плохой протокол, плохая политика