Comments 83
Согласен.
ChatGPT говорит (возможно, ошибочно), что современные процы могут шифровать 10 ГБ/с и делать 10 тыс хэндшейков в секунду на эллиптических кривых. Т.е. на обычном процессоре за несколько сотен долларов мы можем обслужить до 25 миллиардов пользователей в месяц и отдать до 25 ПБ (петабайт) трафика. В статье явно преувеличена сложность шифрования и требуемые ресурсы.
С момента написания оригинала правда прошло 10 лет — за это время стоимость шифрования упала, но и 10 лет назад это было дёшево. Если у сайта больше миллиарда посещений за месяц, наверное, он найдёт несколько сотен долларов на дополнительный процессор. Если это видеохостинг, трафик тоже наверняка будет намного дороже, предполагаю, что какие-нибудь 600 ПБ трафика обойдутся не менее $200 000, на этом фоне несколько сотен долларов на процессор не такая большая сумма.
Стоимость шифрования упала, а объем HTTP-трафика также вырос в разы.
10 ГБ/с и 10 тыс. хендшейков это довольно мало для крупных сервисов. Вы очень странно пересчитали это в пользователей - оно разумеется не так и столько пользователей вы с такой низкой производительностью не обслужите.
Для сравнения, Netflix на своих серверах вынужден добиваться пиковой производительности до 800 Гб/c и таких серверов у них более десяти тысяч по всему миру.
Всего мировой трафик измеряется десятками эксабайт в день и немалую его часть составляет HTTP. Речь идет о протоколе, который будет использоваться отнюдь не на одном сервере, а во всей глобальной сети интернет. И тут стоит задуматься о том, какой вклад протокол вносит уже в энергопотребление всего человечества. По некоторым подсчетам: "20% of the world’s total electricity consumption may be used by the Internet by 2025" - в этот процент конечно входят затраты не только на передачу данных, но все равно она впечатляет и думать об энергоэффективности протокола имеет смысл.
Это один момент. А второй момент, заметная часть HTTP-клиентов - это мобильные устройства, где вопрос энергоэффективности также один из краеугольных сам по себе.
P.S. И спустя 10 лет можно с уверенностью сказать, что мистер Камп оказался во многом прав. Протокол HTTP/2 показал себя с не лучшей стороны, уязвимости в нем и вектора для DoS атак продолжают находить пачками по сей день. Пресловутый инновационный "server push" все браузеры повыкидывали, наигравшись и признав, что от этой технологии больше вреда нежели пользы, а работоспособность самого протокола в реальном мире оказалась местами хуже HTTP/1.1, что спешно начали изобретать замену в виде HTTP/3. Т.е. HTTP/2 не просуществовал и нескольких лет до того момента, как потребовалось создавать ему преемника.
На Youtube, если это неигровое видео, то битрейт на современных кодеках составляет 1 Мбит/с на FullHD. Сервер с шифрованием 10 ГБ/с позволяет обслужить 80 тыс таких пользователей одновременно, что, наверное, эквивалентно минимум 400 тыс активных пользователей сервиса, т.к. люди не смотрят Youtube весь день.
Пусть будет, что процессор служит минимум 4 года, тогда $400 на 400 тыс пользователей - это до 0.002 цента на человека в месяц (до $0.00002/мес). Один показ рекламы принесёт несравнимо больше.
Если это игровое видео, битрейт может быть до 5 Мбит/с, т.е. придётся тратить до $0.0001 на человека/мес, но и это достаточно мало.
На стриминговых сервисах с сериалами, если это качественный сервис, битрейт может достигать 20 Мбит/с, т.е. придётся тратить $0.0004/мес на человека, но при подписке $10/мес эта сумма тоже достаточно мала.
Для сравнения, Netflix на своих серверах вынужден добиваться пиковой производительности до 800 Гб/c
На Netflix достаточно низкие битрейты, вроде что-то около 2 Мбит/с (т.к. Netflix стримит в 720p по-умолчанию). Получается, по их требованиям 1 сервер должен обслуживать 3 миллиона одновременных пользователей, что может соответствовать активной аудитории до 15 миллионов человек. Согласно Википедии, у Netflix 277 млн пользователей, т.е. получается на весь Netflix должно быть 20 стримящих серверов. Я думаю, их всё-таки сильно больше.
Можно зайти с другой стороны. 277 млн пользователей → 50 млн одновременных пользователей → 15000 ГБ/с → 1500 дешёвых процессоров по 10 ГБ/с → $600 тыс → $150 тыс/год.
В 2020 году Netflix потратил $12 млрд на создание контента. $150 тыс на этом фоне не ощущается большой суммой. +Подписка на Netflix не бесплатная.
Вы очень странно пересчитали это в пользователей
В хэндшейках имелись ввиду разовые пользователи. Понятное дело, что у сервиса не может быть 50 млрд пользователей — на Земле просто не живёт столько людей.
Всего мировой трафик измеряется десятками эксабайт в день и немалую его часть составляет HTTP
Общий размер трафика неважен, важно какой % в стоимость вносит шифрование. И этот процент крайне мал. Я полагаю, что стоимость самого трафика где-то в 10 тыс раз превышает стоимость шифрования, а иногда эта разница может доходить и до 100 тыс раз. Стоит ли тогда оно того? Думаю, да.
Да и в целом для шифрования 40 ЭБ/день нужно 100 тыс процессоров по 10 ГБ/с, пусть будет $1 млн/мес. Не такая уж большая сумма для человечества.
Мобильные устройства, где вопрос энергоэффективности
Мне кажется:
Импакт очень маленький. К примеру, если батарея прослужит на 0.001 сек меньше, вряд ли пользователь это заметит. Надо посчитать импакт.
Какое-нибудь разжатие трафика съест несравнимо больше.
Если такие вещи критичны, я бы лучше тогда может бы пошёл со стороны отключения загрузки картинок. Они мало того, что потребляют трафик, но и требуют "разжатия", что прямо супер-дорогая операция по сравнению с шифрованием. Это действительно поможет продлить жизнь батареи может быть даже на несколько секунд или ещё больше (я на самом деле не знаю сколько).
Протокол HTTP/2 показал себя с не лучшей стороны
Может быть. Я когда читал о протоколах мне показалось странным, что QUIC был уже два года на момент выхода HTTP/2, но его не взяли, а потом всё-таки передумали и взяли, но уже в HTTP/3. Если протокол QUIC был плохой, значит его не нужно было брать вообще. Если хороший, то брать сразу. В итоге имеем два протокола вместо одного. При этом, как я понимаю, QUIC на самом деле действительно значительно лучше SPDY, т.е. нужно было брать QUIC.
Согласно Википедии, у Netflix 277 млн пользователей, т.е. получается на весь Netflix должно быть 20 стримящих серверов.
У Netflix-а около 18 000 серверов. У вас все расчеты имеют очень мало отношения к практике. Поэтому тут даже обсуждать нечего - всё это какие-то теоретические рассуждения исходя из того, что вам выдал чатгпт.
Я когда читал о протоколах мне показалось странным, что QUIC был уже два года на момент выхода HTTP/2
Вы что-то путаете. Финальная версия спецификации HTTP/2 появилась в мае 2015 году, а первый черновик в 2012.
QUIC стали придумывать ровно после того, как стала понятна неэффективность HTTP/2. Первый черновик спецификации на QUIC появился в в конце 2016, а финальная версия в 2021.
Кстати, я тут не согласен с автором. 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: плохой протокол, плохая политика