Протокол окостенения
Окостенение протоколов — это потеря гибкости, расширяемости и возможности развития сетевых протоколов . Во многом это происходит из-за промежуточных блоков, которые чувствительны к проводному образу протокола и которые могут прерывать или создавать помехи сообщениям, которые действительны, но которые промежуточный блок не распознает правильно. Это нарушение сквозного принципа . Вторичные причины включают негибкость реализаций протоколов на конечных точках.
Окостенение является серьезной проблемой при разработке и развертывании интернет -протоколов, поскольку оно может помешать развертыванию новых протоколов или расширений в Интернете или наложить ограничения на разработку новых протоколов; новые протоколы, возможно, придется инкапсулировать в уже развернутый протокол или имитировать проводной образ другого протокола. Из-за закостенения протокол управления передачей (TCP) и протокол пользовательских дейтаграмм (UDP) являются единственными практическими вариантами транспортных протоколов в Интернете, а сам TCP значительно закостенел, что затрудняет расширение или модификацию протокола.
Рекомендуемые методы предотвращения окостенения включают шифрование метаданных протокола, а также обеспечение использования точек расширения и максимально полного отображения изменчивости образа проводов; исправление существующей оссификации требует координации между участниками протокола. QUIC — первый транспортный протокол IETF , в котором были специально разработаны свойства предотвращения оссификации.
История
[ редактировать ]![[икона]](http://upload.wikimedia.org/wikipedia/commons/thumb/1/1c/Wiki_letter_w_cropped.svg/20px-Wiki_letter_w_cropped.svg.png){kind=small} | Этот раздел нуждается в расширении . Вы можете помочь, добавив к нему . ( ноябрь 2022 г. ) |
произошла значительная закостенелость К 2005 году в Интернете , и в том же году был опубликован анализ проблемы; [1] Аммар (2018) предполагает, что окостенение стало следствием того, что Интернет достиг глобального масштаба и стал основной коммуникационной сетью. [2]
Multipath TCP был первым расширением основного интернет-протокола, которое серьезно противостояло закостенению протокола во время его разработки. [3]
IETF создал рабочую группу Transport Services (taps) в 2014 году. [4] Его задача — смягчить оссификацию на уровне транспортного протокола . [5]
QUIC — первый транспортный протокол IETF , который намеренно минимизировал свой образ связи, чтобы избежать закостенения. [6]
Совет по архитектуре Интернета определил соображения проектирования, касающиеся раскрытия информации протокола сетевым элементам, как «развивающуюся область» в 2023 году. [7]
Причины
[ редактировать ]Основной причиной окостенения протокола является промежуточного блока . вмешательство [8] аннулирование сквозного принципа . [9] Промежуточные ящики могут полностью блокировать неизвестные протоколы или нераспознанные расширения известных протоколов, мешать согласованию расширений или функций или выполнять более агрессивную модификацию метаданных протокола. [10] Не все модификации промежуточного блока обязательно закостеневают; из тех, которые потенциально опасны, они непропорционально расположены на границе сети . [11] Миддлбоксы развертываются сетевыми операторами в одностороннем порядке для решения конкретных задач. [12] включая оптимизацию производительности, требования безопасности (например, межсетевые экраны), преобразование сетевых адресов или усиление контроля над сетями. [13] Подобные развертывания промежуточных устройств обеспечивают локализованную краткосрочную полезность, но ухудшают глобальную долгосрочную возможность развития Интернета, что является проявлением трагедии общего пользования . [12]
Изменения протокола должны быть допущены всеми посредниками на пути; если желательно широкое распространение изменений в Интернете, то это распространяется на большую часть посредников в Интернете. Промежуточный блок должен терпеть широко используемые протоколы, поскольку они использовались во время его развертывания, но он может не терпеть новые протоколы или изменения существующих, что фактически создает порочный круг , поскольку новые образы проводов не могут получить достаточно широкого распространения, чтобы обеспечить промежуточные устройства терпят новый образ проводной связи по всему Интернету. [9] Даже все участники, допускающие протокол, не являются гарантией использования: в отсутствие механизма согласования или обнаружения конечные точки могут по умолчанию использовать протокол, который считается более надежным. [14]
Помимо промежуточных блоков, окостенение также может быть вызвано недостаточной гибкостью реализации конечной точки. Ядра операционных систем медленно меняются и развертываются. [14] а протоколы, реализованные аппаратно, также могут ненадлежащим образом исправлять детали протокола. [15] Широко используемый API , который делает предположения о работе базовых протоколов, может препятствовать развертыванию протоколов, которые не разделяют эти предположения. [9]
Профилактика и исправление
[ редактировать ]В 2019 году Совет по архитектуре Интернета рекомендовал заменить неявные сигналы для наблюдателей сигналами, намеренно предназначенными для потребления этими наблюдателями, а сигналы, не предназначенные для их потребления, не должны быть им доступны (например, посредством шифрования); а также, что метаданные протокола должны быть защищены от изменений , чтобы их нельзя было изменить промежуточными устройствами. [16] Однако даже полностью зашифрованные метаданные не могут полностью предотвратить окостенение в сети, поскольку образ протокола все равно может отображать шаблоны, на которые можно положиться. [17] Сетевые операторы используют метаданные для различных целей управления. [18] Интернет-исследования также основаны на данных, собранных из метаданных протокола; [19] Разработчик протокола должен сбалансировать устойчивость к оссификации и наблюдаемость для оперативных или исследовательских нужд. [17] Аркко и др. (2023) дает дополнительные рекомендации по этим соображениям: раскрытие информации по протоколу в сети должно быть преднамеренным, [20] осуществляется с согласия получателя и отправителя, [21] аутентифицированы в той степени, в которой это возможно и необходимо, [22] действовал только в той степени, в которой он заслуживает доверия, [23] и сведены к минимуму и предоставлены минимальному числу субъектов. [24] [25]
Требуется активное использование точек расширения, чтобы они не окостенели. [26] Сокращение количества точек расширения, документирование инвариантов, на которые могут положиться участники протокола, а не случайных деталей, на которые нельзя полагаться, а также быстрое обнаружение проблем в развернутых системах могут помочь в обеспечении активного использования. [27] Однако даже активное использование может задействовать только узкую часть протокола, и оссификация все равно может произойти в тех частях, которые остаются инвариантными на практике, несмотря на теоретическую изменчивость. [28] [29] «Смазка» точки расширения, где в некоторых реализациях указана поддержка несуществующих расширений, может гарантировать, что фактически существующие, но нераспознанные расширения будут допустимы (см. Chaos Engineering ). [30] Заголовки HTTP являются примером точки расширения, которой удалось избежать существенного закостенения, поскольку участники обычно игнорируют нераспознанные заголовки. [31]
Новый протокол может быть разработан так, чтобы имитировать образ существующего закостеневшего протокола; [32] альтернативно, новый протокол может быть инкапсулирован в существующий допустимый протокол. Недостаток инкапсуляции заключается в том, что обычно приходится выполнять накладные расходы и избыточную работу (например, внешние контрольные суммы становятся избыточными в результате внутренних проверок целостности). [33]
Помимо промежуточных ящиков, можно противостоять и другим источникам окостенения. в пользовательском пространстве Реализация протоколов может привести к более быстрой эволюции. Если новый протокол инкапсулирован в UDP, возможна реализация в пользовательском пространстве. [34] [35] Если поддержка протоколов неопределенна, участники могут одновременно попробовать альтернативные протоколы за счет увеличения объема отправляемых данных. [36]
При достаточных усилиях и координации оссификацию можно обратить вспять. , День флага когда участники протокола согласованно вносят изменения, может разорвать порочный круг и наладить активное использование. Этот подход использовался для развертывания EDNS , которая раньше не допускалась серверами. [37]
Примеры
[ редактировать ]Протокол управления передачей пострадал от окостенения. [38] Одно измерение показало, что треть путей в Интернете сталкивается как минимум с одним посредником, который изменяет метаданные TCP, а 6,5% путей сталкиваются с вредным закостенелющим воздействием со стороны посредников. [39] Затронуты расширения TCP: конструкция MPTCP была ограничена поведением промежуточного блока, [3] [40] и развертывание TCP Fast Open также было затруднено. [41] [38]
Протокол передачи управления потоком мало распространен в Интернете из-за нетерпимости со стороны промежуточных устройств. [9] а также из-за очень распространенного API сокетов BSD, плохо соответствующего его возможностям. [42] На практике TCP и UDP являются единственными используемыми транспортными протоколами Интернета . [43]
Безопасность транспортного уровня (TLS) претерпела окостенение. TLS был исходным контекстом для введения точек расширения смазки. TLS 1.3 в первоначальном виде оказался непригодным для развертывания в Интернете: в промежуточных устройствах параметр версии протокола закостенел. Это было обнаружено на позднем этапе разработки протокола, во время экспериментального развертывания в веб-браузерах . В результате версия 1.3 имитирует образ провода версии 1.2. [44]
QUIC был специально разработан с возможностью развертывания, развития и обеспечения свойств, препятствующих оссификации; [45] это первый транспортный протокол IETF , который намеренно минимизировал образ проводной связи для этих целей. [6] Он смазан, [30] у него явно указаны инварианты протокола, [46] он инкапсулирован в UDP, а его метаданные протокола зашифрованы. [45] Тем не менее, приложения, использующие QUIC, должны быть готовы вернуться к другим протоколам, поскольку UDP блокируется некоторыми промежуточными процессорами. [47]
См. также
[ редактировать ]- Обратная совместимость
- Проблема коллективных действий
- Действительно стандарт
- Прямая совместимость
- Совместимость
- Закон Хайрама
- Сетевой эффект
- Принцип надежности
- Привязка к поставщику
Ссылки
[ редактировать ]- ^ Аммар 2018 , с. 57-58.
- ^ Аммар 2018 , с. 59.
- ^ Jump up to: а б Райчиу и др. 2012 , стр. 1.
- ^ «Транспортные услуги (краны) – История группы» . IETF .
- ^ «Транспортные услуги – чартер-ietf-taps-02» . IETF .
- ^ Jump up to: а б Trammell & Kuehlewind 2019 , с. 2.
- ^ Аркко и др. 2023 , 3. Дальнейшая работа.
- ^ Папастерджиу и др. 2017 , с. 619.
- ^ Jump up to: а б с д Папастерджиу и др. 2017 , с. 620.
- ^ Эделин и Доннет 2019 , с. 171.
- ^ Эделин и Доннет 2019 , с. 173-175.
- ^ Jump up to: а б Эделин и Доннет, 2019 , с. 169.
- ^ Хонда и др. 2011 , с. 1.
- ^ Jump up to: а б Папастерджиу и др. 2017 , с. 621.
- ^ Корбет 2015 .
- ^ Харди 2019 , с. 7-8.
- ^ Jump up to: а б Fairhurst & Perkins 2021 , 7. Выводы.
- ^ Fairhurst & Perkins 2021 , 2. Текущее использование транспортных заголовков в сети.
- ^ Fairhurst & Perkins 2021 , 3. Исследования, разработки и внедрение.
- ^ Аркко и др. 2023 , 2.1. Преднамеренное распространение.
- ^ Аркко и др. 2023 , 2.2. Контроль распространения информации.
- ^ Аркко и др. 2023 , 2.3. Защита информации и аутентификация.
- ^ Аркко и др. 2023 , 2.5. Ограничение воздействия информации.
- ^ Аркко и др. 2023 , 2.4. Минимизируйте информацию.
- ^ Аркко и др. 2023 , 2.6. Минимальный набор сущностей.
- ^ Томсон и Поли, 2021 , 3. Активное использование.
- ^ Томсон и Поли, 2021 , 4. Дополнительные методы.
- ^ Томсон и Поли 2021 , 3.1. Зависимость лучше.
- ^ Trammell & Kuehlewind 2019 , стр. 7.
- ^ Jump up to: а б Томсон и Поли 2021 , 3.3. Фальсификация активного использования.
- ^ Томсон и Поли, 2021 , 3.4. Примеры активного использования.
- ^ Папастерджиу и др. 2017 , с. 623.
- ^ Папастерджиу и др. 2017 , с. 623-4.
- ^ Папастерджиу и др. 2017 , с. 630.
- ^ Корбет 2016 .
- ^ Папастерджиу и др. 2017 , с. 629.
- ^ Томсон и Поли, 2021 , 3.5. Восстановление активного использования.
- ^ Jump up to: а б Томсон и Поли 2021 , А.5. ПТС.
- ^ Эделин и Доннет 2019 , с. 175-176.
- ^ Хесманс и др. 2013 , с. 1.
- ^ Рыбчинская 2020 .
- ^ Папастерджиу и др. 2017 , с. 627.
- ^ Маккуистин, Перкинс и Файед, 2016 , стр. 1.
- ^ Салливан 2017 .
- ^ Jump up to: а б Корбет 2018 .
- ^ Thomson 2021 , 2. Исправлены свойства всех версий QUIC.
- ^ Kühlewind & Trammell 2022 , 2. Необходимость отступления.
Библиография
[ редактировать ]- Траммелл, Брайан; Кюлевинд, Мирья (апрель 2019 г.). Образ сетевого протокола . дои : 10.17487/RFC8546 . RFC 8546 .
- Харди, Тед, изд. (апрель 2019 г.). Сигналы пути транспортного протокола . дои : 10.17487/RFC8558 . RFC 8558 .
- Томсон, Мартин (май 2021 г.). Независимые от версии свойства QUIC . дои : 10.17487/RFC8999 . РФК 8999 .
- Фэрхерст, Горри; Перкинс, Колин (июль 2021 г.). Соображения относительно конфиденциальности транспортного заголовка, сетевых операций и эволюции транспортных протоколов Интернета . дои : 10.17487/RFC9065 . РФК 9065 .
- Томсон, Мартин; Поли, Томми (декабрь 2021 г.). Долгосрочная жизнеспособность механизмов расширения протоколов . дои : 10.17487/RFC9170 . РФК 9170 .
- Кюлевинд, Мирья; Траммелл, Брайан (сентябрь 2022 г.). Применимость транспортного протокола QUIC . дои : 10.17487/RFC9308 . RFC 9308 .
- Аркко, Яри; Харди, Тед; Поли, Томми; Кюлевинд, Мирья (июль 2023 г.). Соображения по сотрудничеству приложений и сетей с использованием сигналов пути . дои : 10.17487/RFC9419 . РФК 9419 .
- Хонда, Мичио; Нисида, Ёсифуми; Райчу, Костин; Гринхал, Адам; Хэндли, Марк ; Токуда, Хидеюки (2011). Возможно ли еще расширить TCP? . Конференция ACM SIGCOMM 2011 г. по измерениям в Интернете. дои : 10.1145/2068816.2068834 .
- Райчу, Костин; Пааш, Кристоф; Барре, Себастьян; Форд, Алан; Хонда, Мичио; Дюшен, Фабьен; Бонавентура, Оливье; Хэндли, Марк (2012). Насколько это может быть сложно? Проектирование и реализация развертываемого многопутевого TCP . 9-й симпозиум USENIX по проектированию и внедрению сетевых систем (NSDI 12).
- Хесманс, Бенджамин; Дюшен, Фабьен; Пааш, Кристоф; Деталь, Грегори; Бонавентура, Оливье (2013). Являются ли TCP-расширения защищенными от промежуточного блока? . ХотМиддлбокс '13. CiteSeerX 10.1.1.679.6364 . дои : 10.1145/2535828.2535830 .
- Корбет, Джонатан (8 декабря 2015 г.). «Разгрузка контрольной суммы и окостенение протокола» . LWN.net .
- Корбет, Джонатан (20 июня 2016 г.). «Протоколы транспортного уровня в пользовательском пространстве» . LWN.net .
- МакКвистин, Стивен; Перкинс, Колин; Файед, Марван (июль 2016 г.). Реализация транспортных услуг в реальном времени через закостеневшую сеть . Семинар по прикладным сетевым исследованиям, 2016 г. дои : 10.1145/2959424.2959443 . hdl : 1893/26111 .
- Папастергиу, Гиоргос; Фэрхерст, Горри; Рос, Дэвид; Брунстрем, Анна; Гриннемо, Карл-Йохан; Хуртиг, Пер; Хадеми, Наим; Тюксен, Майкл; Вельцль, Майкл; Дамьянович, Драгана; Манджианте, Симона (2017). «Де-окостенение транспортного уровня Интернета: обзор и перспективы на будущее». Опросы и учебные пособия IEEE по коммуникациям . 19 : 619–639. дои : 10.1109/COMST.2016.2626780 . hdl : 2164/8317 . S2CID 1846371 .
- Салливан, Ник (26 декабря 2017 г.). «Почему TLS 1.3 еще нет в браузерах» . Блог Cloudflare . Проверено 14 марта 2020 г.
- Аммар, Мостафа (январь 2018 г.). «Ex Uno Pluria: цикл сервис-инфраструктура, окостенение и фрагментация Интернета». СИГКОММ Компьютер. Коммун. Ред. дои : 10.1145/3211852.3211861 . S2CID 12169344 .
- Корбет, Джонатан (29 января 2018 г.). «QUIC как решение проблемы закостенения протоколов» . LWN.net .
- Эделин, Кориан; Доннет, Бенуа (2019). Исследование окостенения транспортного слоя снизу вверх . Конференция по измерению и анализу сетевого трафика 2019 (TMA). дои : 10.23919/TMA.2019.8784690 .
- Рыбчинская, Марта (13 марта 2020 г.). «Быстрый взгляд на HTTP/3» . LWN.net .
Дальнейшее чтение
[ редактировать ]- Траммелл, Брайан; Кюлевинд, Мирья, ред. (октябрь 2015 г.). Отчет с семинара IAB по эволюции стека в промежуточном Интернете (SEMI) . дои : 10.17487/RFC7663 . РФК 7663 .