Автор — Марк Ноттингем, член Internet Architecture Board и сопредседатель рабочих групп IETF по HTTP и QUIC
Когда Интернет стал популярным в 90-е годы, то основному трафику хватало всего нескольких протоколов: IPv4 маршрутизировал пакеты, TCP превращал их в соединения, SSL (позже TLS) шифровал эти соединения, DNS именовал хосты для подключения, а HTTP как прикладной протокол часто использовал их все.
За многие годы эти ключевые интернет-протоколы изменились совсем незначительно: в HTTP добавилось несколько новых заголовков и методов, TLS медленно сменил пару минорных версий, TCP приспособился к управлению заторами, а в DNS появились функции вроде DNSSEC. Сами протоколы в работе оставались практически неизменными очень долгое время (кроме IPv6, который уже получает достаточное внимание в сообществе операторов связи).
В результате операторы связи, вендоры и государственные органы, которые стремятся понять (а иногда и контролировать) Интернет установили некоторые практики на основании функциональности этих протоколов — для отладки, улучшения качества сервиса или соблюдения законодательства.
Теперь ключевые интернет-протоколы претерпят серьёзные изменения. Хотя они в целом должны быть совместимы с нынешним Интернетом (иначе не получат распространения), но это может иметь разрушительные последствия для тех, кто осмелился использовать недокументированные свойства протоколов или сделал предположение о неизменности протоколов в будущем.
Есть ряд факторов, определяющих эти изменения.
Во-первых, стали очевидными ограничения ключевых протоколов, особенно по производительности. Из-за структурных проблем прикладных и транспортных протоколов сеть не используется с максимальной эффективностью, что влияет на производительность у конечных пользователей (в частности, речь идёт о времени задержки).
Это важная причина, чтобы переделать или заменить протоколы, потому что есть много свидетельств, насколько значительно влияние даже небольшого улучшения производительности.
Во-вторых, со временем стало сложнее эволюционно улучшать протоколы Интернета на любом уровне, в основном из-за непредусмотренного использования, о чём говорилось выше. Например, если HTTP-прокси пытается сжимать ответы, то это усложняет развёртывание новых техник сжатия; TCP-оптимизации на промежуточных этапах мешают внедрять улучшения в TCP.
Наконец, сейчас в Интернете всё более широко используется шифрование. Этот процесс подстегнули разоблачения Эдварда Сноудена в 2015 году. На самом деле это отдельная тема, но здесь важно, что шифрование — один из лучших имеющихся инструментов для обеспечения развития протоколов.
Посмотрим, что произошло в прошлом и что произойдёт в будущем, как это может повлиять на сети и как сети влияют на архитектуру протокола.
HTTP/2 (на основе Google SPDY) стал первым заметным изменением. Его оформили в качестве стандарта в 2015 году. Этот протокол уплотняет много запросов по одному TCP-соединению без блокировки друг друга, тем самым устраняя необходимость в очереди запросов на стороне клиента. Сейчас он широко распространился, поддерживается всеми основными браузерами и веб-серверами.
С сетевой точки зрения HTTP/2 представляет собой несколько заметных изменений. Во-первых, это бинарный протокол, так что он не может работать ни с каким устройством, которое примет его за HTTP/1.1.
Такая несовместимость стала одной из главных причин другого важного новшества в HTTP/2: он фактически требует использования шифрования. Это помогает избежать вмешательства посторонней стороны, которая принимает его за HTTP/1.1 или предпринимает более тонкое вмешательство вроде очистки заголовков или блокировки новых расширений протокола — обе такие ситуации реально встречаются и доставляют значительные проблемы поддержки для некоторых инженеров, работающих над протоколом.
HTTP/2 при шифровании требует использования TLS/1.2 и запрещает наборы шифров, которые доказали свою небезопасность — при этом допуская только эфемерные ключи. По поводу потенциальных последствий см. раздел о TLS 1.3.
Наконец, HTTP/2 позволяет объединить в соединении запросы от более чем одного хоста, улучшая производительность за счёт уменьшения количества соединений (и следовательно, количества контекстов для контроля заторов), необходимых для загрузки страницы.
Например, вы можете подключиться к сайту
Несмотря на эти изменения, важно заметить, что HTTP/2 вроде бы не испытывает значительных проблем совместимости или помех от сетей.
TLS 1.3 сейчас проходит через последние этапы стандартизации и уже поддерживается в некоторых реализациях.
Пусть вас не вводит в заблуждение минорная смена номера; это абсолютно новая версия TLS с сильно модернизированным рукопожатием, которое позволяет обмен данными с самого начала (часто такой режим называют 0RTT). Новая архитектура полагается на обмен эфемерными ключами, исключая статические ключи.
Это вызвало озабоченность у некоторых сетевых операторов и вендоров — в частности у тех, кому нужна видимость, что происходит внутри этих соединений.
Например, дата-центр для банка, у которого видимость является требованием регулятора. Прослушивая трафик в сети и дешифруя его статическими ключами, они могут записывать легитимный трафик и выявлять вредоносный, будь то посторонние злоумышленники или утечка информации изнутри.
TLS 1.3 не поддерживает конкретно данную технику перехвата трафика, поскольку это один из видов атаки, от которой защищают эфемерные ключи. Однако поскольку для сетевых операторов действуют требования регуляторов одновременно и использовать современные протоколы шифрования, и отслеживать свои сети, они попадают в неловкое положение.
Было немало споров о том, требуют ли правила использования именно статических ключей, могут ли альтернативные подходы быть настолько же эффективны и оправдано ли ухудшение безопасности всего Интернета ради относительно небольшого количества сетей. В конце концов, трафик TLS 1.3 тоже можно расшифровать, просто нужен доступ к эфемерным ключам, а они действуют ограниченное время.
На данный момент непохоже, что TLS 1.3 изменится в угоду этим сетям, но идёт обсуждение создания другого протокола, который позволит третьей стороне сканировать трафик — а то и больше — в таких ситуациях. Посмотрим, насколько сообщество поддержит эту идею.
В процессе работы над HTTP/2 стало очевидно, что TCP страдает от похожих проблем неэффективности. Поскольку TCP — протокол доставки пакетов по порядку, то потеря одного пакета может помешать доставке приложению последующих пакетов из буфера. В мультиплексированном протоколе это может привести к большой потере производительности.
QUIC — попытка решить эту проблему с помощью эффективной перестройки семантики TCP (вместе с некоторыми аспектами потоковой модели HTTP/2) поверх UDP. Как и HTTP/2, разработка этого протокола началась усилиями Google, а сейчас перешла под крыло IETF. Изначально ставилась цель создать протокол HTTP-поверх-UDP и принять стандарт в конце 2018-го. Но поскольку Google уже внедрила QUIC в Chrome и на своих сайтах, на этот протокол уже приходится более 7% трафика в Интернете.
Почитать: Ответы на вопросы по QUIC
Кроме перехода такого значительного объёма трафика с TCP на UDP (и всех соответствующих сетевых настроек), и Google QUIC (gQUIC), и IETF QUIC (iQUIC) требуют обязательного шифрования для работы; нешифрованного QUIC не существует вообще.
iQUIC использует TLS 1.3 для установки ключей сессии, а затем шифрования каждого пакета. Но поскольку он основан на UDP, значительная часть информации о сессии и метаданных, открытых в TCP, шифруется в QUIC.
На самом деле текущий «короткий заголовок» iQUIC — который используется для всех пакетов, кроме рукопожатия — выдаёт только номер пакета, необязательный идентификатор соединения и байт состояния, необходимый для процессов вроде смены ключей шифрования и типа пакета (который тоже может быть зашифрован).
Всё остальное зашифровано — включая пакеты ACK, что значительно повышает планку для проведения атак с анализом трафика.
Но это означает, что более невозможна пассивная оценка RTT и потерь пакетов путём простого наблюдения за соединением; там недостаточно информации для этого. Отсутствие наблюдаемости вызвало серьёзную озабоченность у некоторых представителей сообщества операторов связи. Они говорят, что такие пассивные измерения критически важны для отладки и анализа их сетей.
Одно из предложений для решения этой проблемы — введение спин-бита. Это бит в заголовке, который меняет своё значение один раз по пути туда-обратно, так что наблюдатель может оценить RTT. Поскольку он не привязан к состоянию приложения, то не должен выдавать никакой информации о конечных точках, кроме примерной оценки местоположения сети.
Самое последнее изменение на горизонте — это DOH, то есть DNS поверх HTTP. Многие исследования показали, что сети часто используют DNS как средство навязывания правил (будь то в интересах сетевого оператора или властей более высокого уровня).
Некоторое время мы обсуждали обход такого рода контроля с помощью шифрования, но здесь имеется один недостаток (по крайней мере, с определённой точки зрения) — такой трафик можно отличить от нормального трафика и обработать его отдельно; например, используя номер порта для блокировки доступа.
DOH решает проблему, совмещая DNS-трафик с существующим соединением HTTP, тем самым устраняя любые дискриминаторы. Если сеть хочет блокировать доступ к определённому распознавателю DNS, то ей придётся при этом блокировать доступ к самому веб-сайту.
Например, если Google развернёт свой публичный DNS-сервис по протоколу DOH на
Работа над DOH только началась, но к этому протоколу уже проявляется довольно большой интерес, есть и первые попытки реализации. Посмотрим, как на это отреагируют сети (и правительства), которые используют DNS для навязывания правил.
Почитать: IETF 100, Сингапур: DNS поверх HTTP (DOH!)
Возвращаясь к мотивации разработки новых протоколов, нужно обратить внимание на вопрос, как разработчики протоколов всё чаще сталкиваются с проблемами из-за того, что сетевые операторы делают свои предположения о сетевом трафике.
Например, на последнем этапе разработки TLS 1.3 возникло немало проблем с промежуточными узлами, которые принимают его за старую версию протокола. gQUIC не работает в некоторых сетях, которые приглушают трафик UDP, потому что считают его вредным или низкоприоритетным.
Если протокол не может развиваться из-за того, что его точки расширения «замораживаются» при внедрении, мы говорим, что он окостенел. Сам TCP — это пример жесточайшего окостенения; так много промежуточных узлов делают такие разные вещи с TCP — от блокировки TCP-пакетов с нераспознанными опциями до «оптимизации» контроля заторов.
Необходимо предотвратить окостенение, чтобы гарантировать развитие протоколов для соответствия будущим нуждам Интернета. Иначе мы столкнёмся с «трагедией общин», где действия отдельных сетей — пусть и благонамеренные — повлияют на здоровье всего Интернета в целом.
Есть много способов предотвратить окостенение. Если данные в пакетах зашифрованы, то к ним не получит доступ никто, кроме владельца ключей, что предотвращает вмешательство. Если точка расширения зашифрована, но повсеместно используется таким способом, что нарушается видимость приложения (например, заголовки HTTP), то вероятность помех уменьшается.
Если разработчики протокола не могут использовать шифрование и точка расширения используется нечасто, то может помочь искусственная прокачка точки расширения. Мы называем это смазкой (greasing).
Например, QUIC подталкивает конечные точки к использованию диапазона значений при согласовании версии, чтобы избежать реализаций, которые полагают номер версии всегда неизменным (такое часто встречается в реализациях TLS, что ведёт к серьёзным проблемам).
Кроме желания избежать окостенения, новые протоколы также отражают эволюцию отношений между сетями и их пользователями. Долгое время предполагалось, что сеть всегда остаётся благожелательной — или хотя бы нейтральной — стороной. Но это больше не так, не только из-за вездесущего тотального мониторинга, но и из-за атак вроде Firesheep.
В итоге увеличиваются противоречия между нуждами интернет-пользователей в целом и интересами сетей, которые хотят получить доступ к определённому количеству данных, проходящих через них. Особенно пострадают сети, которые стремятся навязать пользователям определённые правила, например, корпоративные сети.
В некоторых случаях они могут достичь поставленных целей, установив специальный софт (или сертификат центра сертификации, или расширение браузера) на компьютерах пользователей. Но это непросто в тех случаях, когда оператор не имеет доступа к компьютеру. Например, сейчас часто сотрудники работают на собственных компьютерах, а у устройств IoT редко имеются соответствующие управляющие интерфейсы.
В результате многие дискуссии при разработке протоколов в IETF ведутся на тему противоречия нужд корпоративных и других «вложенных» сетей — и пользы для Интернета в целом.
Чтобы Интернет хорошо работал в долговременной перспективе, он должен иметь ценность для конечных пользователей, избегать окостенения и обеспечивать нормальную работу сетей. Происходящие сейчас изменения удовлетворяют всем трём целям, но нам нужно больше отзывов от сетевых операторов.
Если эти изменения повлияют на вашу сеть — или не повлияют — пожалуйста, сообщите об этом в комментариях к статье, а ещё лучше подключайтесь к работе в IETF, посетив рабочее заседание, подписавшись на список рассылки или оставив отзыв к черновику стандарта.
Выражаю благодарность Мартину Томпсону и Брайану Трэммелу за помощь в редактировании статьи.
Когда Интернет стал популярным в 90-е годы, то основному трафику хватало всего нескольких протоколов: IPv4 маршрутизировал пакеты, TCP превращал их в соединения, SSL (позже TLS) шифровал эти соединения, DNS именовал хосты для подключения, а HTTP как прикладной протокол часто использовал их все.
За многие годы эти ключевые интернет-протоколы изменились совсем незначительно: в HTTP добавилось несколько новых заголовков и методов, TLS медленно сменил пару минорных версий, TCP приспособился к управлению заторами, а в DNS появились функции вроде DNSSEC. Сами протоколы в работе оставались практически неизменными очень долгое время (кроме IPv6, который уже получает достаточное внимание в сообществе операторов связи).
В результате операторы связи, вендоры и государственные органы, которые стремятся понять (а иногда и контролировать) Интернет установили некоторые практики на основании функциональности этих протоколов — для отладки, улучшения качества сервиса или соблюдения законодательства.
Теперь ключевые интернет-протоколы претерпят серьёзные изменения. Хотя они в целом должны быть совместимы с нынешним Интернетом (иначе не получат распространения), но это может иметь разрушительные последствия для тех, кто осмелился использовать недокументированные свойства протоколов или сделал предположение о неизменности протоколов в будущем.
Почему мы должны изменить Интернет
Есть ряд факторов, определяющих эти изменения.
Во-первых, стали очевидными ограничения ключевых протоколов, особенно по производительности. Из-за структурных проблем прикладных и транспортных протоколов сеть не используется с максимальной эффективностью, что влияет на производительность у конечных пользователей (в частности, речь идёт о времени задержки).
Это важная причина, чтобы переделать или заменить протоколы, потому что есть много свидетельств, насколько значительно влияние даже небольшого улучшения производительности.
Во-вторых, со временем стало сложнее эволюционно улучшать протоколы Интернета на любом уровне, в основном из-за непредусмотренного использования, о чём говорилось выше. Например, если HTTP-прокси пытается сжимать ответы, то это усложняет развёртывание новых техник сжатия; TCP-оптимизации на промежуточных этапах мешают внедрять улучшения в TCP.
Наконец, сейчас в Интернете всё более широко используется шифрование. Этот процесс подстегнули разоблачения Эдварда Сноудена в 2015 году. На самом деле это отдельная тема, но здесь важно, что шифрование — один из лучших имеющихся инструментов для обеспечения развития протоколов.
Посмотрим, что произошло в прошлом и что произойдёт в будущем, как это может повлиять на сети и как сети влияют на архитектуру протокола.
HTTP/2
HTTP/2 (на основе Google SPDY) стал первым заметным изменением. Его оформили в качестве стандарта в 2015 году. Этот протокол уплотняет много запросов по одному TCP-соединению без блокировки друг друга, тем самым устраняя необходимость в очереди запросов на стороне клиента. Сейчас он широко распространился, поддерживается всеми основными браузерами и веб-серверами.
С сетевой точки зрения HTTP/2 представляет собой несколько заметных изменений. Во-первых, это бинарный протокол, так что он не может работать ни с каким устройством, которое примет его за HTTP/1.1.
Такая несовместимость стала одной из главных причин другого важного новшества в HTTP/2: он фактически требует использования шифрования. Это помогает избежать вмешательства посторонней стороны, которая принимает его за HTTP/1.1 или предпринимает более тонкое вмешательство вроде очистки заголовков или блокировки новых расширений протокола — обе такие ситуации реально встречаются и доставляют значительные проблемы поддержки для некоторых инженеров, работающих над протоколом.
HTTP/2 при шифровании требует использования TLS/1.2 и запрещает наборы шифров, которые доказали свою небезопасность — при этом допуская только эфемерные ключи. По поводу потенциальных последствий см. раздел о TLS 1.3.
Наконец, HTTP/2 позволяет объединить в соединении запросы от более чем одного хоста, улучшая производительность за счёт уменьшения количества соединений (и следовательно, количества контекстов для контроля заторов), необходимых для загрузки страницы.
Например, вы можете подключиться к сайту
www.example.com, но также использовать его для запросов к images.example.com. Будущие расширения протокола могут позволить добавлять в соединение дополнительные хосты, даже если они не указаны в изначальном сертификате TLS, который используется для соединения. В результате никогда нельзя полагать, что трафик в соединении будет ограничен тем предназначением, для которого он изначально предполагался.Несмотря на эти изменения, важно заметить, что HTTP/2 вроде бы не испытывает значительных проблем совместимости или помех от сетей.
TLS 1.3
TLS 1.3 сейчас проходит через последние этапы стандартизации и уже поддерживается в некоторых реализациях.
Пусть вас не вводит в заблуждение минорная смена номера; это абсолютно новая версия TLS с сильно модернизированным рукопожатием, которое позволяет обмен данными с самого начала (часто такой режим называют 0RTT). Новая архитектура полагается на обмен эфемерными ключами, исключая статические ключи.
Это вызвало озабоченность у некоторых сетевых операторов и вендоров — в частности у тех, кому нужна видимость, что происходит внутри этих соединений.
Например, дата-центр для банка, у которого видимость является требованием регулятора. Прослушивая трафик в сети и дешифруя его статическими ключами, они могут записывать легитимный трафик и выявлять вредоносный, будь то посторонние злоумышленники или утечка информации изнутри.
TLS 1.3 не поддерживает конкретно данную технику перехвата трафика, поскольку это один из видов атаки, от которой защищают эфемерные ключи. Однако поскольку для сетевых операторов действуют требования регуляторов одновременно и использовать современные протоколы шифрования, и отслеживать свои сети, они попадают в неловкое положение.
Было немало споров о том, требуют ли правила использования именно статических ключей, могут ли альтернативные подходы быть настолько же эффективны и оправдано ли ухудшение безопасности всего Интернета ради относительно небольшого количества сетей. В конце концов, трафик TLS 1.3 тоже можно расшифровать, просто нужен доступ к эфемерным ключам, а они действуют ограниченное время.
На данный момент непохоже, что TLS 1.3 изменится в угоду этим сетям, но идёт обсуждение создания другого протокола, который позволит третьей стороне сканировать трафик — а то и больше — в таких ситуациях. Посмотрим, насколько сообщество поддержит эту идею.
QUIC
В процессе работы над HTTP/2 стало очевидно, что TCP страдает от похожих проблем неэффективности. Поскольку TCP — протокол доставки пакетов по порядку, то потеря одного пакета может помешать доставке приложению последующих пакетов из буфера. В мультиплексированном протоколе это может привести к большой потере производительности.
QUIC — попытка решить эту проблему с помощью эффективной перестройки семантики TCP (вместе с некоторыми аспектами потоковой модели HTTP/2) поверх UDP. Как и HTTP/2, разработка этого протокола началась усилиями Google, а сейчас перешла под крыло IETF. Изначально ставилась цель создать протокол HTTP-поверх-UDP и принять стандарт в конце 2018-го. Но поскольку Google уже внедрила QUIC в Chrome и на своих сайтах, на этот протокол уже приходится более 7% трафика в Интернете.
Почитать: Ответы на вопросы по QUIC
Кроме перехода такого значительного объёма трафика с TCP на UDP (и всех соответствующих сетевых настроек), и Google QUIC (gQUIC), и IETF QUIC (iQUIC) требуют обязательного шифрования для работы; нешифрованного QUIC не существует вообще.
iQUIC использует TLS 1.3 для установки ключей сессии, а затем шифрования каждого пакета. Но поскольку он основан на UDP, значительная часть информации о сессии и метаданных, открытых в TCP, шифруется в QUIC.
На самом деле текущий «короткий заголовок» iQUIC — который используется для всех пакетов, кроме рукопожатия — выдаёт только номер пакета, необязательный идентификатор соединения и байт состояния, необходимый для процессов вроде смены ключей шифрования и типа пакета (который тоже может быть зашифрован).
Всё остальное зашифровано — включая пакеты ACK, что значительно повышает планку для проведения атак с анализом трафика.
Но это означает, что более невозможна пассивная оценка RTT и потерь пакетов путём простого наблюдения за соединением; там недостаточно информации для этого. Отсутствие наблюдаемости вызвало серьёзную озабоченность у некоторых представителей сообщества операторов связи. Они говорят, что такие пассивные измерения критически важны для отладки и анализа их сетей.
Одно из предложений для решения этой проблемы — введение спин-бита. Это бит в заголовке, который меняет своё значение один раз по пути туда-обратно, так что наблюдатель может оценить RTT. Поскольку он не привязан к состоянию приложения, то не должен выдавать никакой информации о конечных точках, кроме примерной оценки местоположения сети.
DOH
Самое последнее изменение на горизонте — это DOH, то есть DNS поверх HTTP. Многие исследования показали, что сети часто используют DNS как средство навязывания правил (будь то в интересах сетевого оператора или властей более высокого уровня).
Некоторое время мы обсуждали обход такого рода контроля с помощью шифрования, но здесь имеется один недостаток (по крайней мере, с определённой точки зрения) — такой трафик можно отличить от нормального трафика и обработать его отдельно; например, используя номер порта для блокировки доступа.
DOH решает проблему, совмещая DNS-трафик с существующим соединением HTTP, тем самым устраняя любые дискриминаторы. Если сеть хочет блокировать доступ к определённому распознавателю DNS, то ей придётся при этом блокировать доступ к самому веб-сайту.
Например, если Google развернёт свой публичный DNS-сервис по протоколу DOH на
www.google.com, а пользователи соответствующим образом настроят свои браузеры, то если сеть захочет (или от неё требуют) блокировать этот сервис, то ей придётся эффективно блокировать весь Google (поскольку так они размещают свои сервисы).Работа над DOH только началась, но к этому протоколу уже проявляется довольно большой интерес, есть и первые попытки реализации. Посмотрим, как на это отреагируют сети (и правительства), которые используют DNS для навязывания правил.
Почитать: IETF 100, Сингапур: DNS поверх HTTP (DOH!)
Окостенение и смазка
Возвращаясь к мотивации разработки новых протоколов, нужно обратить внимание на вопрос, как разработчики протоколов всё чаще сталкиваются с проблемами из-за того, что сетевые операторы делают свои предположения о сетевом трафике.
Например, на последнем этапе разработки TLS 1.3 возникло немало проблем с промежуточными узлами, которые принимают его за старую версию протокола. gQUIC не работает в некоторых сетях, которые приглушают трафик UDP, потому что считают его вредным или низкоприоритетным.
Если протокол не может развиваться из-за того, что его точки расширения «замораживаются» при внедрении, мы говорим, что он окостенел. Сам TCP — это пример жесточайшего окостенения; так много промежуточных узлов делают такие разные вещи с TCP — от блокировки TCP-пакетов с нераспознанными опциями до «оптимизации» контроля заторов.
Необходимо предотвратить окостенение, чтобы гарантировать развитие протоколов для соответствия будущим нуждам Интернета. Иначе мы столкнёмся с «трагедией общин», где действия отдельных сетей — пусть и благонамеренные — повлияют на здоровье всего Интернета в целом.
Есть много способов предотвратить окостенение. Если данные в пакетах зашифрованы, то к ним не получит доступ никто, кроме владельца ключей, что предотвращает вмешательство. Если точка расширения зашифрована, но повсеместно используется таким способом, что нарушается видимость приложения (например, заголовки HTTP), то вероятность помех уменьшается.
Если разработчики протокола не могут использовать шифрование и точка расширения используется нечасто, то может помочь искусственная прокачка точки расширения. Мы называем это смазкой (greasing).
Например, QUIC подталкивает конечные точки к использованию диапазона значений при согласовании версии, чтобы избежать реализаций, которые полагают номер версии всегда неизменным (такое часто встречается в реализациях TLS, что ведёт к серьёзным проблемам).
Сеть и пользователь
Кроме желания избежать окостенения, новые протоколы также отражают эволюцию отношений между сетями и их пользователями. Долгое время предполагалось, что сеть всегда остаётся благожелательной — или хотя бы нейтральной — стороной. Но это больше не так, не только из-за вездесущего тотального мониторинга, но и из-за атак вроде Firesheep.
В итоге увеличиваются противоречия между нуждами интернет-пользователей в целом и интересами сетей, которые хотят получить доступ к определённому количеству данных, проходящих через них. Особенно пострадают сети, которые стремятся навязать пользователям определённые правила, например, корпоративные сети.
В некоторых случаях они могут достичь поставленных целей, установив специальный софт (или сертификат центра сертификации, или расширение браузера) на компьютерах пользователей. Но это непросто в тех случаях, когда оператор не имеет доступа к компьютеру. Например, сейчас часто сотрудники работают на собственных компьютерах, а у устройств IoT редко имеются соответствующие управляющие интерфейсы.
В результате многие дискуссии при разработке протоколов в IETF ведутся на тему противоречия нужд корпоративных и других «вложенных» сетей — и пользы для Интернета в целом.
Включайтесь в работу
Чтобы Интернет хорошо работал в долговременной перспективе, он должен иметь ценность для конечных пользователей, избегать окостенения и обеспечивать нормальную работу сетей. Происходящие сейчас изменения удовлетворяют всем трём целям, но нам нужно больше отзывов от сетевых операторов.
Если эти изменения повлияют на вашу сеть — или не повлияют — пожалуйста, сообщите об этом в комментариях к статье, а ещё лучше подключайтесь к работе в IETF, посетив рабочее заседание, подписавшись на список рассылки или оставив отзыв к черновику стандарта.
Выражаю благодарность Мартину Томпсону и Брайану Трэммелу за помощь в редактировании статьи.
