Обнаружение пути MTU
Обнаружение MTU пути ( PMTUD ) — это стандартизированный метод в компьютерных сетях для определения максимального размера единицы передачи (MTU) на сетевом пути между двумя хостами Интернет-протокола (IP), обычно с целью избежать фрагментации IP . PMTUD изначально предназначался для маршрутизаторов с протоколом Интернета версии 4 (IPv4). [1] Однако все современные операционные системы используют его на конечных точках. В IPv6 эта функция явно делегирована конечным точкам сеанса связи. [2] В качестве расширения стандартного обнаружения MTU пути метод, называемый обнаружением MTU пути на уровне пакетизации, работает без поддержки ICMP . [3]
Выполнение
[ редактировать ]Для пакетов IPv4 обнаружение Path MTU работает путем установки бита флага «Не фрагментировать» (DF) в IP-заголовках исходящих пакетов. Затем любое устройство на пути, чей MTU меньше пакета, отбросит его и отправит обратно протокола управляющих сообщений Интернета (ICMP) сообщение о необходимости фрагментации (тип 3, код 4), содержащее его MTU, что позволит исходному хосту уменьшить свой MTU. путь MTU соответственно. Процесс повторяется до тех пор, пока MTU не станет достаточно маленьким, чтобы пройти весь путь без фрагментации.
Поскольку маршрутизаторы IPv6 не фрагментируют нет опции «Не фрагментировать» пакеты, в заголовке IPv6 . Для IPv6 обнаружение MTU пути изначально предполагает, что MTU пути совпадает с MTU на интерфейсе канального уровня , откуда исходит трафик. Затем, как и в случае с IPv4, любое устройство на пути, чей MTU меньше, чем пакет, отбросит пакет и отправит обратно сообщение ICMPv6 « Слишком большой пакет (тип 2)», содержащее его MTU, что позволит исходному хосту соответствующим образом уменьшить MTU своего пути. Процесс повторяется до тех пор, пока MTU не станет достаточно маленьким, чтобы пройти весь путь без фрагментации. [4]
Если MTU пути изменится после установки соединения и станет меньше, чем ранее определенный MTU пути, первый большой пакет вызовет ошибку ICMP и будет найден новый, меньший MTU пути. Если путь изменится и новый MTU пути станет больше, источник не узнает об увеличении, поскольку все маршрутизаторы на новом пути будут способны ретранслировать все пакеты, которые отправляет источник, используя первоначально определенный, меньший MTU пути. [5] [6] [4]
Проблемы
[ редактировать ]Многие устройства сетевой безопасности блокируют все сообщения ICMP ради предполагаемых преимуществ безопасности, включая ошибки, необходимые для правильной работы PMTUD. Это может привести к тому, что соединения правильно завершат трехстороннее подтверждение TCP , но затем зависнут при попытке передачи данных. Это состояние называется соединением черной дыры . [7]
Некоторые реализации PMTUD пытаются обойти эту проблему, предполагая, что большие пакеты полезной нагрузки отбрасываются из-за MTU, а не из-за перегрузки канала. Одна из таких схем стандартизирована в RFC 8899, Обнаружение MTU пути уровня пакетирования дейтаграмм (DPLPMTUD). [3] При потере соединения DPLPMTUD использует тестовые пакеты контролируемых размеров для проверки MTU пути. Подтверждение пробного пакета указывает, что MTU пути не меньше размера этого пакета. Использование DPLPMTUD стандартизировано в QUIC . [8] Однако для того, чтобы протоколы транспортного уровня работали наиболее эффективно, сообщения ICMP Unreachable (тип 3) все равно должны быть разрешены.
Некоторые маршрутизаторы, включая ядро Linux [9] и Циско, [10] предоставьте возможность уменьшить максимальный размер сегмента (MSS), объявленный в подтверждении TCP, в качестве обходного пути. Это известно как зажим MSS .
Другая проблема заключается в том, что сетевые администраторы не обновляют должным образом MTU между двумя соседними переходами уровня 3, если канал между этими переходами состоит из нескольких сегментов уровня 2 с коммутаторами между ними. Обычно MTU на исходящем интерфейсе L3 берется из первого сегмента L2. Но если второй или последующий сегмент имеет более низкий MTU, коммутатор, находящийся между ними, просто молча отбросит пакет, не сообщая об ICMP (поскольку только переходы уровня 3 могут генерировать «слишком большой пакет» ICMP). Таким образом, в этом случае администраторы должны обновить MTU для каждого исходящего интерфейса L3 до минимального MTU сегментов уровня 2, используемых до следующего перехода L3.
Ссылки
[ редактировать ]- ^ Дж. Могул; С. Диринг (ноябрь 1990 г.). Путь обнаружения MTU . Сетевая рабочая группа. дои : 10.17487/RFC1191 . РФК 1191 . Проект стандарта. Устаревшие РФК 1063 .
- ^ Дж. Макканн; С. Диринг ; Дж. Могул (июль 2017 г.). Р. Хинден (ред.). Обнаружение MTU пути для IP версии 6 . IETF . дои : 10.17487/RFC8201 . СТД 87. RFC 8201 . Интернет-стандарт 87. Устарел . РФК 1981 .
- ^ Перейти обратно: а б Г. Фэйрхерст; Т. Джонс; М. Тюксен; И. Рюнгелер; Т. Фёлькер (сентябрь 2020 г.). Обнаружение MTU пути уровня пакетизации для транспорта дейтаграмм . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC8899 . ISSN 2070-1721 . РФК 8899 . Предлагаемый стандарт. Обновления RFC 4821 , 4960 , 6951 , 8085 и 8261 .
- ^ Перейти обратно: а б Дэвис, Джозеф (2012). Понимание IPv6 (3-е изд.). Редмонд: Microsoft Press. стр. 146–147. ISBN 978-0735659148 . OCLC 810455372 .
- ^ Э. Комер, Дуглас (2014). Межсетевое взаимодействие с TCP/IP, том 1 (6-е изд.). Пирсон. стр. 133–134. ISBN 0-13-608530-Х .
- ^ исходный код Linux (ipv4) и исходный код Linux (ipv6) см. строку с «mtu_expires» 10 * 60 секунд.
- ^ К. Лэхи (сентябрь 2000 г.). Проблемы TCP с обнаружением Path MTU . Сетевая рабочая группа. дои : 10.17487/RFC2923 . РФК 2923 . Информационный.
- ^ Дж. Айенгар; М. Томсон, ред. (май 2021 г.). QUIC: мультиплексированная и безопасная транспортировка на основе UDP . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC9000 . ISSN 2070-1721 . РФК 9000 . Предлагаемый стандарт.
- ^ «Исправление заголовков пакетов — nftables wiki» . wiki.nftables.org . Проверено 03 июля 2024 г.
- ^ «Концепция настройки Ethernet MTU и TCP MSS для соединений PPPoE» . Циско . Проверено 03 июля 2024 г.