Comments 79
Валентин, вы согласны с автором?
Последний раздел «ЧП в вашей стране, вашем округе или городе?» ужасен. Несколько раз пытался продраться через дебри этого текста, и все еще не был уверен, правильно ли его понимаю. А потом посмотрел оригинал, и понял, что это перевод такой. Your Country, State, or County Emergency Webpage — это не ЧП, это сайт/страница МЧС, в наших реалиях, призванные сообщать о ЧП. И именно к сайту относится все, что написано про SSL.
Кстати, я тут не согласен с автором. SSL это один из немногих, если не единственный, способ, чтобы идентифицировать сервер для клиента. И даже если медиа-бизнесу наплевать, что клиенту подсунут вместо настоящего сайта фейк с троянами, то клиенту это вовсе не безразлично.
Кстати, я тут не согласен с автором. SSL это один из немногих, если не единственный, способ, чтобы идентифицировать сервер для клиента. И даже если медиа-бизнесу наплевать, что клиенту подсунут вместо настоящего сайта фейк с троянами, то клиенту это вовсе не безразлично.
Можете предложить более точный и благозвучный перевод? В абзаце не идет речь о конкретной страничке, а скорее о том, что в условиях чрезвычайной ситуации приватность уходит на второй план и куда важнее сохранить возможность распространять информацию, чем тратить ресурсы на её шифрование.
P.S. Переименовал пока в "Сайт МЧС..."
Так уже лучше. В принципе, сам автор неосознанно говоря про SSL смешивает разные вещи — конфиденциальность (и шифрование трафика), которая действительно нужна не всегда, и некоторые гарантии, например что сервер не подменили (взломав DNS или прокси). И это мешает понимать действительно разумные вещи.
Мне кажется здесь не идет речи, что весь SSL не нужен. Речь о том, что во многих случаях нужна всего лишь часть SSL — например, целостность данных. Многим не важно, открыт ли трафик. Для многих шифрование это даже неудобство и лишняя головная боль. Зато очень важно иметь гарантию, что данные дошли без изменений. SSL же содержит все и сразу. Можно конечно сказать, что есть NULL cipher, но, судя по всему, браузеры его не поддерживают, а значит мы получаем или все сразу, или вообще ничего.
Кстати, на счёт безопасности и NSA, тут недавно пробегала интересная новость: https://www.reddit.com/r/sysadmin/comments/4l7rld/bluecoat_a_company_which_makes_tls_mitm_equipment/
В чем новость? У Яндекса тоже есть свой CA, думаете через него ФСБ прослушивает трафик?
Производитель железа для TLS MitM и CA сертификат, которому доверяет абсолютное большинство браузеров? Нет, что вы, ничего страшного :)
Во-первых это производитель корпоративных файрволов, а во-вторых прочтите ветку комментариев по своей ссылке, в-третьих любая компания может получить свой подчинённый CA — это вопрос денег и времени.
белки_истерички.jpg
белки_истерички.jpg
Во-первых, корпоративные 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.» И нету ни одной причины, почему-бы их железо не стояло в других странах.
Во-вторых, если какая-то компания начнёт подписывать своим 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.
На реддите в топе отличный комментарий, где всё это разжовано.
Всё так до тех пор, пока условный Symantec (issuer) считает обладателя такого CA злоумышленником. Разработчик прокси-сервера — злоумышленник, компания, работающая по заказу какого либо правительства (желательно, конечно, правительство дружественной для США страны, т.к. Symantec всё же американская компания) — нет.
Он нарушает целостность отдельных, ранее изолированных слоев, переусложнен, содержит кучу нестыковок, плохих компромиссов, упущенных возможностей и т. д.
Какую целостность, о чём вообще речь?
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 правда тоже тот ещё прототип, но до тех пор, пока это дело одной компании, это никому не вредит.
Типа их позиция — это какое-то зло и проталкивать её плохо?
Да, зло, как и любая радикальная позиция, когда людям пытаются навязать что-то, в чем они не нуждаются, при этом делают это под видом заботы о конфиденциальности.
Я уже не первый раз вижу вот эти заявления, что «иногда будет быстрее, иногда медленнее, а иногда вообще никак». Это вообще кто мерял и по каким методикам? Вот, например, Яндекс мерял и пришел к выводу, что да, ресурсы экономятся, надо включать. Вот httpwatch.com мерял и обнаружил, что с HTTP/2 скорость загрузки выросла на 23%. Вот буквально на прошлой неделе Dropbox включил себе HTTP/2 и сказал, что входящий трафик снизился на 50%
А покажите теперь, кто включил HTTP/2 и ему оказалось «медленнее, а иногда вообще никак»?
А покажите теперь, кто включил HTTP/2 и ему оказалось «медленнее, а иногда вообще никак»?
UFO just landed and posted this here
UFO just landed and posted this here
Тем у кого плохое соединение 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/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 км/ч, поскольку кое-где есть знаки, которые ограничивают скорость до этого уровня.
>Давайте не будем выдавать сломанную обратную совместимость за фичу. Одно дело сломать протокол типа IMAPS, которые в одной-двух библиотеках пофиксят и дальше все будут использовать новый, а другое дело осознанно сломать КАЖДОЕ веб-приложение в мире.
Полностью обратную совместимость никто и не ломал, в статье предлагается отказаться от одной вредоносной особенности протокола (с точки зрения пользователя). А пока что у нас получается не протокол для пользователей, а пользователи для протокола.
>По-факту разницы конкретно в данном случае я не вижу. Всем, кому была важна производительность и безопасность, это было «нужно», а не «можно». Именно эти люди и HTTP/2 начнут использовать, по тем же причинам.
И таких сайтов на весь интернет не наберется 1%. А когда протокол пишется под нужны корпораций, а затем навязывается большинству в качестве стандарта, но большинство от этого ничего не выигрывает — вас ничего в этом не настораживает?
>См. картинку о «теперь у нас 15 стандартов»
Какая разница, сколько у нас стандартов, если официальный — только от IETF.
>У ютюба много своих целей, да. HTTPS — средство достижения этих целей. И, если это средство делает возможным существование Youtube, то это удобство пользователя.
Ютуб и без https отлично существовал, а вот просмотр видео через https на смартфонах убивает заряд батареи раза в два быстрее. Вы опять пытаетесь выдать багу за фичу, нужды корпораций за потребности пользователей.
>Куки нужны, поскольку это обратная совместимость, да. Что касается этой надуманной проблемы с финансовыми трейдерами и аналитиками ЦРУ — ну так, блин, сделайте для них ПО, которое будет всё расшифровывать и куда надо складывать, заставьте их пользоваться только этим ПО. Наезды на HTTP/2 в этом плане — это как запрет разрабатывать автомобили, ездящие быстрее 5 км/ч, поскольку кое-где есть знаки, которые ограничивают скорость до этого уровня.
Так в том-то и дело, что фактически разработан автомобиль, который не умеет ездить медленнее, чем 10км/ч. Сел — и либо ты едешь быстрее 5 км/ч, либо не едешь никуда. В чем проблема сделать HTTP/2 без принудительного шифрования, как в HTTP/1.1, когда администратор сам решает, что ему надо — шифрование, производительность или и то, и то вместе взятое? Ну, кроме желания отдельной группы людей, вышедших под флагом «SSL everywhere» для обслуживания их коммерческих интересов?
Полностью обратную совместимость никто и не ломал, в статье предлагается отказаться от одной вредоносной особенности протокола (с точки зрения пользователя). А пока что у нас получается не протокол для пользователей, а пользователи для протокола.
>По-факту разницы конкретно в данном случае я не вижу. Всем, кому была важна производительность и безопасность, это было «нужно», а не «можно». Именно эти люди и HTTP/2 начнут использовать, по тем же причинам.
И таких сайтов на весь интернет не наберется 1%. А когда протокол пишется под нужны корпораций, а затем навязывается большинству в качестве стандарта, но большинство от этого ничего не выигрывает — вас ничего в этом не настораживает?
>См. картинку о «теперь у нас 15 стандартов»
Какая разница, сколько у нас стандартов, если официальный — только от IETF.
>У ютюба много своих целей, да. HTTPS — средство достижения этих целей. И, если это средство делает возможным существование Youtube, то это удобство пользователя.
Ютуб и без https отлично существовал, а вот просмотр видео через https на смартфонах убивает заряд батареи раза в два быстрее. Вы опять пытаетесь выдать багу за фичу, нужды корпораций за потребности пользователей.
>Куки нужны, поскольку это обратная совместимость, да. Что касается этой надуманной проблемы с финансовыми трейдерами и аналитиками ЦРУ — ну так, блин, сделайте для них ПО, которое будет всё расшифровывать и куда надо складывать, заставьте их пользоваться только этим ПО. Наезды на HTTP/2 в этом плане — это как запрет разрабатывать автомобили, ездящие быстрее 5 км/ч, поскольку кое-где есть знаки, которые ограничивают скорость до этого уровня.
Так в том-то и дело, что фактически разработан автомобиль, который не умеет ездить медленнее, чем 10км/ч. Сел — и либо ты едешь быстрее 5 км/ч, либо не едешь никуда. В чем проблема сделать HTTP/2 без принудительного шифрования, как в HTTP/1.1, когда администратор сам решает, что ему надо — шифрование, производительность или и то, и то вместе взятое? Ну, кроме желания отдельной группы людей, вышедших под флагом «SSL everywhere» для обслуживания их коммерческих интересов?
> В чем проблема сделать 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.
Так в текущем стандарте это и предусмотрено: хочешь используй 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.
Повышает, поскольку его будут по-дефолтку включать с шифрованием, а чтобы включить его без шифрования — нужно будет ещё постараться и не факт, что выйдет.
Тут в чем проблема назревает, привив пользователю привычку «зеленый замочек — безопасно», для того чтобы злоумышленнику|корпорации|государству создать ложное чувство защищенности, будет достаточно просто этот замочек рисовать…
Главное что бы была возможность апгрейдить протокол в будущем без накладных расходов. А то выйдет как с ipv4 -> ipv6 когда и хочется и колется.
Учитывая насколько большая доля мультимедийного трафика, принудительное ссл выглядит странно.
Это уже больше не к странностям а к проблемам. Шифровать мультимедиа контент бред и лишняя трата ресурса. Достаточно было бы идентификации сервера и проверки подлинности. Думаю это можно было бы решить не используя TLS/SSL, ведь все таки не минорное изменение версии.
На самом деле провайдеры мультимедиа-контента обожают его шифровать (т.к. это позволяет сделать более развесистый DRM), но они очень не любят шифровать сессию, в которой он передается (т.к. на конфиденциальность клиента им плевать, а вот на загрузку серверов CDN — нет).
провайдеры мультимедиа-контента обожают его шифровать
Первый раз слышу, дадите ссылку почитать? Всегда думал что шифрованием контента в DRM целях (если это вообще делается) занимается издатель мультимедиа-контента, а не провайдер. И к протоколу передачи это никакого отношения не имеет.
Под провайдером я и подразумеваю издателя. Ну, к примеру, большая часть HLS-вещаний, с которыми я сталкивался, зашифрована по AES-128. Даже если это вещание эфирного канала. На уровне протокола, естественно, при этом используется HTTP без SSL/TLS. Клиентским устройствам приходится тратить ресурсы на декодирование видеопотока, но никакой выгоды клиенту от этого нет.
Если передавать через TLS/SSL, то хотя бы ваш провайдер/сосед/дядяВася не узнает, что именно вы смотрите.
Если передавать через TLS/SSL, то хотя бы ваш провайдер/сосед/дядяВася не узнает, что именно вы смотрите.
Почему шифровать мультимедиа — бред? Там что, не важна конфиденциальность, или копирайт, или защита канала? В видеопотоке точно так же могут быть личные данные, секретная информация, контент не для публичного показа и т.д.
Я написал, идентификации сервера и проверки подлинности нужна, остальное нет. Речь шла, о публикации общедоступного ММ контента. Если вы собираетесь показывать что-то не для публичного показа — ради бога, я не предлагал отказаться от HTTPS.
В публичном видео на ютубе — секретная информация? Конечно, конечно.
Есть видео которые доступны только по ссылке и не хотелось бы чтобы эту ссылку узнал кто то ещё.
Эта проблема вообще нерешаема в случае с «секретной ссылкой». Например, один из ваших доверенных, кому вы ссылку сообщаете, может оказаться жуком и сольёт её. Или кто-то случайно увидит из-за спины. Или сломают сам протокол, с помощью которого вы распространяете ссылку между доверенными. (Я не имею ввиду «техническое» понимание слова «протокол», а общее — «сломают протокол» может означать и, например, «заполучат письмо со ссылкой методами социальной инженерии».)
В общем, если у вас такое секретное видео, которое вы не хотите показывать случайным прохожим, ему вообще не место на ютубе.
В общем, если у вас такое секретное видео, которое вы не хотите показывать случайным прохожим, ему вообще не место на ютубе.
Отличная статья, но вот эти поэтические вступления и отсылы к глобальному потеплению уже утомляют у западных авторов. Хорошо хоть посвящения супруги и детям нет)
UFO just landed and posted this here
Помимо компьютеров и кучи различных клиетских девайсов, подключенных к сети, есть еще датацентры набитые серверами, под которые иногда целые электростанции строят, и всевозможные промежуточные машрутизаторы.
Есть такая организация как CEET (Centre for Energy-Efficient Telecommunications), которая занимается этими вопросами. По их подсчетам на интернет уже к 2020 году будет приходиться до 10% от всей потребляемой человечеством энергии.
Есть такая организация как CEET (Centre for Energy-Efficient Telecommunications), которая занимается этими вопросами. По их подсчетам на интернет уже к 2020 году будет приходиться до 10% от всей потребляемой человечеством энергии.
Ладно, пусть 10%. Но это совершенно не значит, что, оставшись на HTTP 1.1, мы сэкономим хоть какую-то заметную долю из этих 10%. Я, конечно, не считал, но просто по ощущениям тот же круизный лайнер (https://geektimes.ru/post/276182/) за один рейс выбросит намного больше всякой вредной фигни. Очень похоже на преждевременную оптимизацию.
В этом разрезе было бы интересно примерить влияние других новшеств на экологию. Переход с H264 SD на HEVC FHD (а то и 4K) нехило увеличивает нагрузку на всё — и на кодирующие фермы, и на каналы передачи данных, и на миллионы декодирующих устройств. Любые накладные расходы HTTP/2 на фоне 20-мегабитного видеопотока не просто малозначительны — они вообще незаметны. Надо подкинуть «зеленым» идею требовать запрета видеопотоков выше 1 мбита!
Согласен с вами. Когда смотришь онлайн-видео в HD, то проц нехило так весь проц отжирает (постоянно >70% ЦП). На этом фоне — небольшая дополнительная нагрузка в +1% на HTTP/2 выглядит смешно. Стоит нападать на создателей 4K за их наплевательское отношение к матушке-природе! И вообще надо все развлекательные сервисы выкинуть, пусть компы работают только для науки. </sarcаsm>
UFO just landed and posted this here
Я с вами полностью согласен, осталось только mpv player поставить каждому пользователю на планете, чтобы снизить выбросы Co2 в атмосферу.
Мой же коммент был направлен на то, что изначально создатели браузеров/контента/или_кто_там_за_это_отвечает неправильно сделали видеоплеер в браузере, что он так много жрёт.
> Вы его не правильно смотрите.
Кстати, я ведь не только Youtube HD смотрю, но еще и Twitch люблю посмотреть. А тамошний стрим я даже не знаю какой плеер поддерживает.
Мой же коммент был направлен на то, что изначально создатели браузеров/контента/или_кто_там_за_это_отвечает неправильно сделали видеоплеер в браузере, что он так много жрёт.
> Вы его не правильно смотрите.
Кстати, я ведь не только Youtube HD смотрю, но еще и Twitch люблю посмотреть. А тамошний стрим я даже не знаю какой плеер поддерживает.
Таки ваша придумка уже имхо лишняя. Современные браузеры используют VAAPI которое по сути пробрасывает декодирование до драйверов видеокарты, что позволяет при возможности декодировать видео силами хардварных декодеров.
В *nix системах уже по моему везде стоит данный пакет из коробки. (что кстати создает проблемы со старыми nvidia vdpau драйверами, но ....)
В *nix системах уже по моему везде стоит данный пакет из коробки. (что кстати создает проблемы со старыми nvidia vdpau драйверами, но ....)
UFO just landed and posted this here
А можно ли — для полноты картины — привести несколько примеров улучшений, которые были отвергнуты? Ну, те самые, которые «вне повестки» и т.п.? Интересно знать, что мы потеряли?
Что же до обязательного SSL, то я, наверное, поддержал бы эту затею. Все-таки затраты на поточную симметричную шифровку-дешифровку не так уж велики, а «ассиметричная» часть там все равно не зависит от размера передаваемого пакета.
Что же до обязательного SSL, то я, наверное, поддержал бы эту затею. Все-таки затраты на поточную симметричную шифровку-дешифровку не так уж велики, а «ассиметричная» часть там все равно не зависит от размера передаваемого пакета.
UFO just landed and posted this here
Соглашусь лишь частично. 1.1 реализуется студентом, видимо, за венерианские сутки (и то, потому что оочень хочет жить). Объём спек, связанных с http/1.1 огромен и полностью 1.1 никто и не реализует, за ненадобностью.
Принципиальной разницы в защищенной имплементации текстового и бинарного протоколов нет. Переполнения, неправильная интерпретация символа NUL и т. п. ничем не отличается в этих двух случаях.
Касательно отладки — реально всё равно нужны инструменты: обычно трафик ходит по http не в plain text: используются tls, chuncked, gzip, с которыми протокол всё равно частично бинарный.
Принципиальной разницы в защищенной имплементации текстового и бинарного протоколов нет
Ну как же нет. Обычно текстовые протоколы это либо парсер, либо чтение с помощью терминальных символов. Последнее это как раз про HTTP и поле для потенциально эксплуатируемых ошибок тут куда меньше. Ошибка если и будет, то это будет DoS или еще что-то совершенно не связанное с RCE. Бинарный же протокол это практически всегда либо четко указанная длина блока, либо фиксированная длина, что уже дает огромное поле для разного рода ошибок, которые приводят к серьезным уязвимостям. От чего, собственно, так популярны фаззеры бинарных протоколов и форматов файлов.
UFO just landed and posted this here
HTTP/2 не отменяет семантики HTTP/1.1, так что объем спек в совокупности получается ещё больше. Но только если простейший HTTP/1 сервер, способный отдать в браузер страничку любого объема, можно уместить в нечто подобное:
то с HTTP/2 такой фокус уже не пройдет.
% while true; do echo -n "HTTP/1.1 200 OK\r\n\r\n" | cat - index.html | netcat -lcp 8080; doneто с HTTP/2 такой фокус уже не пройдет.
> 2. Сложность имплементации: бинарный протокол сложно имплементировать,
> 2.а. Потенциально большая забагованность реализаций:
Я тоже не был фанатом HTTP/2 (и сейчас не фанат, но и опыта особого нет), однако где-то в статьях про него увидел переубеждение по этим вопросам. Бинарный протокол может быть более простым для реализации так как убирает работу по парсингу и вы получаете служебные данные (вроде Content-Length) уже как нужно программе. Более сложной вещь может сжатие заголовков (HPACK), мне трудно сказать насколько оно сложное и подвержено багам.
> 2.а. Потенциально большая забагованность реализаций:
Я тоже не был фанатом HTTP/2 (и сейчас не фанат, но и опыта особого нет), однако где-то в статьях про него увидел переубеждение по этим вопросам. Бинарный протокол может быть более простым для реализации так как убирает работу по парсингу и вы получаете служебные данные (вроде Content-Length) уже как нужно программе. Более сложной вещь может сжатие заголовков (HPACK), мне трудно сказать насколько оно сложное и подвержено багам.
Семантика HTTP/2 по большей части осталась от HTTP/1.x, о чем даже спецификация заявляет с самого начала. После распаковки вы получаете всё тот же Content-Length 100 в текстовом виде, который нужно всё также парсить. Можно там в 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. Выбор будет всегда.
UFO just landed and posted this here
Про скорость многопоточной закачки — я нашел вот это. Можете рассказать, почему два соединения будут быстрее, на уровне TCP/IP?
UFO just landed and posted this here
Т.е. для каналов с приличным % потери пакетов TCP считает, что пакеты теряются из-за шейпера и урезает окно. Но надо же смотреть в светлое будущее, а не в темное прошлое :-)
С торрентами немного другая история — там много соединений с разными сидами позволяет справляться с ситуацией, когда канал получателя шире канала отправителя.
У нескольких соединений будет суммарно больше окно, причем, что важно, с самого начала. Потеря пакета затронет только одно из нескольких соединений. Обработку нескольких соединений проще параллелить, они могут обрабатываться разными процессами, в том числе на уровне ядра или даже быть распределены по разным серверам, переданы по разным каналам.
Ну как с самого начала — сначала установить соединение, потом скачать хтмл, потом опять устанавливать соединения… При высоком пинге это сильно увеличивает latency. Особенно при использовании TLS. Читал где-то, что разрабатывается стандарт для упрощенного (в плане кол-ва round-trip-ов) TLS, но когда мы его увидим...
А вообще — когда вы сделаете HTTP/2 prefetch? Это будет мощный довод переходить на новый протокол для технологически продвинутых веб-мастеров.
Современные браузеры не ждут, пока html скачается, а открывают сразу несколько соединений. Единственная их проблема, что они по-умолчанию ограничены 6 соединениями по RFC и если уж запросили какую-то картинку, то не могут остановить передачу и запросить что-то другое не разрывая соединения. Собственно на этом HTTP/2 и выигрывает, только для реализации того же не нужно было столько всего городить.
HTTP/2 server push? Вообще с ним пока все не так хорошо в браузерах (как в общем и самим протоколом), кто пытается использовать — время от времени сталкивается не с ускорением, а с багами. Реализация и отладка HTTP/2 и так отняла столько ресурсов, что на данный момент пока никаких ETA на дополнительные работы по HTTP/2.
HTTP/2 server push? Вообще с ним пока все не так хорошо в браузерах (как в общем и самим протоколом), кто пытается использовать — время от времени сталкивается не с ускорением, а с багами. Реализация и отладка HTTP/2 и так отняла столько ресурсов, что на данный момент пока никаких ETA на дополнительные работы по HTTP/2.
UFO just landed and posted this here
> а остальные могли бы и не утруждать себя поддержкой TLS, ибо ничего ценного у них нет
Ну это какая-то вообще наивность. Такой вой поднимется если какой-то крупный сервис не поддерживает безопасное соединение. Если вам оно не нужно, это не значит что всем остальным не нужно. Сейчас App Store/Google Play при приеме приложений начинают выдавать предупреждения если приложение устанавливает небезопасное HTTP соединение.
Вряд ли вы уведите сейчас как несколько TCP соединений работают быстрее чем одно, тогда HTTP/2 был бы медленнее на тестах, это не так (или быстрее или столько же для хорошо оптимизированных сайтов). Впрочем это должно быть возможно, особенно если кто-то шейпит трафик (провайдер, корпоративный firewall, сервер). Кроме накладных расходов на на безопасность, TCP соединение еще надо «разогреть», т.е. возможность работы через одно разогнанное TCP соединение может немного уменьшить задержку при работе с сайтом (хотя я не могу вот так из головы придумать сценарий — ведь не сильно важно сколько именно соединений разогревать — одно или несколько).
Ну это какая-то вообще наивность. Такой вой поднимется если какой-то крупный сервис не поддерживает безопасное соединение. Если вам оно не нужно, это не значит что всем остальным не нужно. Сейчас App Store/Google Play при приеме приложений начинают выдавать предупреждения если приложение устанавливает небезопасное HTTP соединение.
Вряд ли вы уведите сейчас как несколько TCP соединений работают быстрее чем одно, тогда HTTP/2 был бы медленнее на тестах, это не так (или быстрее или столько же для хорошо оптимизированных сайтов). Впрочем это должно быть возможно, особенно если кто-то шейпит трафик (провайдер, корпоративный firewall, сервер). Кроме накладных расходов на на безопасность, TCP соединение еще надо «разогреть», т.е. возможность работы через одно разогнанное TCP соединение может немного уменьшить задержку при работе с сайтом (хотя я не могу вот так из головы придумать сценарий — ведь не сильно важно сколько именно соединений разогревать — одно или несколько).
Как человек, имевший некоторое (пусть и по касательной) отношение к обсуждению и утверждению HTTP/2 должен заметить, что статья совершенно безграмотна и с технической, и с архитектурной точки зрения.
Достаточно сказать, что в двух соседних абзацах автор сначала жалуется на то, что HTTP/2 плохо структурирован и лезет в чужие уровни абстракции, а потом требует добавить в HTTP/2 шифрование и управление идентфикаторами сессий.
HTTP/2 неидеальный стандарт. Однако критиковать его бессмыссленно просто потому что он не окажет никакого воздействия на производительность сети. Ну да, некоторые крупные сервисы найдут на чем сэкономить пару процентов, но не более того.
Позвольте, а кто вам вообще сказал, что на неё (производительность сети) можно как-то повлиять на уровне протокола HTTP? HTTP — очень-очень-очень ограниченный протокол. Он всего лишь описывает заголовки выполнения операций над ресурсами. Всё остальное делается либо на предыдущих шести уровнях сетевого стека, либо на уровне веб-приложения. Ну вот да, в HTTP/2 понапихали всяких кросс-интеграций и оптимизаций, получив очень сложный стек с примерно нулевым влиянием на реальный мир.
Достаточно сказать, что в двух соседних абзацах автор сначала жалуется на то, что HTTP/2 плохо структурирован и лезет в чужие уровни абстракции, а потом требует добавить в HTTP/2 шифрование и управление идентфикаторами сессий.
HTTP/2 неидеальный стандарт. Однако критиковать его бессмыссленно просто потому что он не окажет никакого воздействия на производительность сети. Ну да, некоторые крупные сервисы найдут на чем сэкономить пару процентов, но не более того.
Позвольте, а кто вам вообще сказал, что на неё (производительность сети) можно как-то повлиять на уровне протокола HTTP? HTTP — очень-очень-очень ограниченный протокол. Он всего лишь описывает заголовки выполнения операций над ресурсами. Всё остальное делается либо на предыдущих шести уровнях сетевого стека, либо на уровне веб-приложения. Ну вот да, в HTTP/2 понапихали всяких кросс-интеграций и оптимизаций, получив очень сложный стек с примерно нулевым влиянием на реальный мир.
Камп сам активно принимал участие в обсуждении стандарта http/2 практически с самого начала. У него всегда было много претензий, а также странных идей, как, например, вынести некоторые «транспортные» http-заголовки (host, url, length,..) вне шифрования и сжатия, чтобы было удобно организовать управление потоками в 1Тб/сек на varnish. При этом на замечание от других участников, что свои предложения лучше оформлять в виде драфта, жаловался, что ему никто не хочет платить денег за работу над стандартом http/2.
Стандарт получился таким, каким получился, у многих была возможность высказать свои идеи. Какие-то были приняты, какие-то отвергнуты, где-то пошли на компромиссные решения. Назвать протокол халтурой — это неуважение к работе многих профессионалов.
Стандарт получился таким, каким получился, у многих была возможность высказать свои идеи. Какие-то были приняты, какие-то отвергнуты, где-то пошли на компромиссные решения. Назвать протокол халтурой — это неуважение к работе многих профессионалов.
Смысл поста в том, что профессионалам должно быть стыдно под таким подписываться. Да, сил потрачено много, и это что, что-то значит?
Как в школе: никого не волнует, что «ты учил». Волнует, чтобы «выучил».
Тут: стандарт делали, да не доделали. Был бы он «доделан» — не было бы таких претензий. А как он есть, склепаный на скорую руку из того, что было, ни одно техническое противоречие не разрешено, ни одной фичи, которую нельзя было бы сделать без него — халтура, конечно.
Как в школе: никого не волнует, что «ты учил». Волнует, чтобы «выучил».
Тут: стандарт делали, да не доделали. Был бы он «доделан» — не было бы таких претензий. А как он есть, склепаный на скорую руку из того, что было, ни одно техническое противоречие не разрешено, ни одной фичи, которую нельзя было бы сделать без него — халтура, конечно.
(промахнулся, простите)
Sign up to leave a comment.
HTTP/2.0 — Халтура от IETF: плохой протокол, плохая политика