ДОПОЛНЕНИЕ ETHERNET: КРАТКИЙ ОБЗОР
Почему короткое сообщение может отображаться как более длинный кадр?
Ethernet может добавлять дополнение перед FCS, чтобы соответствовать минимальному формату MAC-кадра. Дополнение находится вне пакета IPv4 и не должно становиться данными приложения. Программное обеспечение захвата может наблюдать обработку до добавления дополнения или получать запись без FCS, поэтому одна лишь отображаемая длина не доказывает передачу недостаточного размера. Проверьте точку наблюдения и соглашение о длине.
Построение внешнего кадра
Дополнение обеспечивает внешний формат; оно не добавляет смысла приложению.
Определите точку наблюдения
Программное обеспечение может видеть иную стадию, чем физический канал.
Соблюдайте внутреннюю границу
Для IPv4 используйте общую длину из IP, а не трактуйте дополнение как данные.
Проверьте подсчёт
Укажите, какие заголовки, теги и байты FCS включает длина.
Проверьте захват
Зафиксируйте направление, разгрузки, сохранённую длину и настройки FCS.
Проверьте анализатор
Убедитесь, что длина верхнего уровня определяет допустимое содержимое приложения.
Контрольный список выбора и проверки — развернуть
| Проверка | Что подтвердить | Как проверить |
|---|---|---|
| Соглашение о кадре | Заголовки, теги и FCS | Задокументируйте точное начало и конец подсчёта. |
| Точка наблюдения | До NIC, на линии или у приёмника | Сохраняйте настройки интерфейса и сбора. |
| Полнота захвата | Исходная и сохранённая длина | Проверьте усечение и ограничения сбора. |
| Граница протокола | Допустимая длина IP или другого протокола | Проверьте указанную длину и поведение анализатора. |
| Свидетельства неисправности | Счётчики, направление и время | Сопоставьте известный трафик на обоих концах. |
Концептуальные примеры, не в масштабе, не являются измерениями или утверждениями о реализации конкретного продукта.
ПЛК отправляет короткое сообщение о состоянии, но содержимое, передаваемое по Ethernet, длиннее. Захват показывает 60 байт, тогда как документация описывает минимальный кадр размером 64 байт. Не спешите заключать, что коммутатор удалил четыре байта. Сообщение приложения, инкапсуляция Ethernet и программный захват — это разные уровни наблюдения. Размещение дополнения в правильном месте объясняет кажущееся противоречие.
Разделяйте сообщение, пакет IP и кадр Ethernet
Приложению важны состояние, команда или измерение, но для передачи нужна информация, которую распознаёт сетевое оборудование. Представьте сообщение как записку, пакет IP как его конверт, а кадр Ethernet как внешнюю упаковку для этого канала. Аналогия объясняет уровни, а не три физических блока: по проводу передаётся непрерывная последовательность битов.
В используемом здесь обычном примере Ethernet без тегов MAC-кадр простирается от адреса назначения до контрольной последовательности кадра, или FCS. MAC-адрес идентифицирует отправителя или получателя в канале; FCS помогает приёмнику проверить наличие ошибок передачи. Преамбула предшествует кадру, а межкадровый интервал — это время простоя между передачами. Ни то, ни другое не входит в этот подсчёт 64 байт.
Минимум применяется к внешнему MAC-кадру, а не к длине каждой инструкции ПЛК. При чтении документации или захватов сначала установите, где начинается и заканчивается подсчёт. Смешение данных приложения, заголовков и FCS может заставить обычную инкапсуляцию выглядеть как дополнительное содержимое приложения.
Добавляйте дополнение перед формированием контрольной последовательности кадра
Если предоставленное содержимое верхнего уровня слишком короткое, обработка передачи Ethernet добавляет дополнение после этого содержимого и перед FCS. Это как защитная упаковка: она занимает место, не добавляя слов к записке. Выполняет ли конкретную операцию программное обеспечение, драйвер или аппаратура, зависит от сетевого интерфейса или встроенной реализации.
Рассмотрим намеренно ограниченный пример: заголовок Ethernet без тегов размером 14 байт несёт пакет IPv4 размером 28 байт. Этот пакет IP может состоять из обычного заголовка IPv4 и заголовка UDP, без полезной нагрузки приложения UDP. Добавление 18 байт дополнения и четырёхбайтовой FCS даёт MAC-кадр размером 64 байт. Это иллюстрирует структуру; это не измерение устройства FCTEL.
Заполнение включено в содержимое, защищаемое контрольной суммой Ethernet. Его нельзя произвольно изменить после формирования FCS. Получатель проверяет принятый кадр, а не только прикладное сообщение. Для понимания последовательности не требуется вычисление CRC: сначала формируется требуемое содержимое кадра, затем генерируется соответствующее ему проверочное значение.
Заполнение не должно становиться дополнительными прикладными данными
Для IPv4 поле общей длины в заголовке IP определяет длину пакета IP, включая его заголовок и данные, но исключая внешнее заполнение Ethernet. Получатель передаёт часть IP наверх для дальнейшей интерпретации. RFC 894 явно отделяет заполнение от пакета IP и указывает заполнение нулевыми байтами, когда оно необходимо для описываемой инкапсуляции.
Парсер верхнего уровня не должен рассматривать все оставшиеся захваченные байты Ethernet как прикладное содержимое. Ему следует проверять длину и границы своего протокола, а не добавлять внешнее заполнение к команде. Не следует также просто удалять все завершающие нули: ноль может быть допустимыми данными. Границу определяет протокол, а не визуальный вид байта.
Другие протоколы второго уровня нуждаются в собственных правилах инкапсуляции; общую длину IPv4 нельзя механически применять к каждому протоколу. Заполнение не должно нести закрытые управляющие инструкции или неинициализированную память. Практическая привычка — проверять границу внешнего кадра и границу внутреннего сообщения по отдельности.
Почему программное обеспечение может отображать 60 байт или даже меньше
Программное обеспечение захвата не обязательно получает полное представление кадра на линии. Многие интерфейсы проверяют входящий FCS, не передавая эти четыре байта операционной системе. Поэтому программное обеспечение может записать 60 байт, соответствующих полному MAC-кадру размером 64 байт на линии. Документация Wireshark подчёркивает это различие: отображаемая длина всего 60 не доказывает передачу кадра недостаточного размера.
Захват на передающей стороне может наблюдать другую точку — до того, как оборудование добавит заполнение и FCS. Его запись может быть короче 60 байт, хотя оборудование впоследствии сформирует корректный переданный кадр. Экран отправителя, экран получателя и наблюдение на физической линии — это разные точки зрения. Сравнение только двух отображаемых длин не может доказать, что оборудование между ними удалило содержимое.
Следует также различать исходную длину и захваченную длину. Средство сбора может сохранять только начало каждого кадра, поэтому не каждый исходный байт обязательно сохраняется. Проверьте настройки захвата, доставку FCS, направление и поведение разгрузки, затем сравните данные с обеих сторон. Для доказательства представления на физической линии требуется подходящий метод испытаний с указанными условиями сбора.
Обработка VLAN не подразумевает одно фиксированное количество байт заполнения
Байты заполнения 18 относятся только к предыдущему примеру. Разные длины содержимого, тегирование и обработка инкапсуляции изменяют необходимое количество. Тег VLAN занимает часть области заголовка; не считайте его дважды, если он уже включён. Минимальный размер кадра и максимальный блок передачи, или MTU, — это также разные понятия.
Коммутатор принимает кадры, определяет назначение пересылки и формирует соответствующий вывод на следующем звене. Оборудование, добавляющее или удаляющее теги, должно соблюдать требования к выходному кадру. Упомянутый документ Cisco по устранению неполадок иллюстрирует конкретный случай платформы, когда при удалении тега требуется повторное заполнение. Он помогает объяснить границу обработки, а не универсальную внутреннюю реализацию для каждого коммутатора.
Обычное заполнение полного короткого сообщения не является неисправностью. Действительно недостаточный размер кадра, аномальная передача из-за повреждённого звена и запись захвата, сокращённая при сборе, требуют разных расследований. Названия и условия счётчиков портов зависят от оборудования. Сопоставление счётчиков со временем и направлением захвата полезнее, чем замена коммутатора только потому, что запись выглядит короткой.
Примените это различие к подключению промышленного коммутатора
Опубликованная страница пятипортового промышленного коммутатора Fast Ethernet с миниатюрным креплением на DIN-рейку FCTEL перечисляет пять электрических портов Ethernet и адаптацию 10/100M. Это даёт реальную продуктовую основу для сценария подключения ПЛК и HMI. Она не подтверждает наличие средств захвата, зеркалирования портов, специального управления заполнением или конкретных порогов ошибок. Проверяйте выбранную конфигурацию по её собственной документации.
Если один терминал многократно отправляет короткие сообщения о состоянии, а другой передаёт более крупный файл, одни лишь счётчики байт приложения не описывают нагрузку порта. Каждый кадр также расходует возможности инкапсуляции и передачи, включая требуемый интервал. Множество небольших сообщений может использовать ресурсы обработки и линии. Начните с наблюдений за частотой кадров, фактическим трафиком и циклом приложения, а не с требования сложных формул.
Если приложение, передаваемое прозрачно, по-видимому, получает дополнительные завершающие байты, сначала проверьте границы протокола и парсер. Сравните, что наблюдают источник, любой преобразователь и назначение. Не считайте автоматически заполнение Ethernet частью последовательного сообщения и не меняйте режимы оборудования только для устранения заполнения. Сначала установите затронутый уровень.
Используйте три вопроса, чтобы сузить полевое расследование
Во-первых, определите точку наблюдения: до передачи источником, после приёма одноранговым узлом или копию, предоставленную коммутатором. Во-вторых, задокументируйте соглашение о длине: включённые заголовки, доступность FCS и был ли сохранён полный кадр. В-третьих, сопоставьте длины протокола, полезную нагрузку и счётчики ошибок для одного и того же прикладного трафика. Одного снимка экрана, показывающего 60 байт, недостаточно.
Для сравнения используйте известное короткое сообщение в изолированной тестовой среде или в утверждённое окно обслуживания. Сохраняйте исходные записи захвата и параметры сбора с обеих сторон. Убедитесь, что приложение извлекает только своё допустимое содержимое и обычная связь продолжается. Такое испытание проверяет данную конфигурацию и путь; отображение одного инструмента не определяет каждый интерфейс и коммутатор.
Наконец, наблюдайте, следует ли аномалия за портом, кабелем или методом захвата. Сохраняйте необработанные доказательства, а не только аннотированные снимки экрана. Принцип прост: внешний кадр имеет минимальный формат, внутреннее приложение имеет собственную границу длины, а программное обеспечение захвата записывает один этап обработки. Разделение этих трёх аспектов помогает найти реальную неисправность.
Источники и подтверждение по продуктам
Wireshark: Ethernet; IETF RFC 894, апрель 1984; Документ Cisco по устранению неполадок с заполнением, обновлён в июле 16, 2021. Общие механизмы не переносят команды, специфичные для платформы, или выводы о дефектах на другое оборудование. Продуктовое подтверждение: Пятипортовый коммутатор Fast Ethernet FCTEL в миниатюрном корпусе для DIN-рейки, страница на китайском языке. Проверьте выбранную версию. Иллюстрации представляют собой общие концепции, созданные с помощью ИИ.
Перевод китайской технической статьи: Читать оригинальную китайскую статью.
Частые практические вопросы
Является ли захват размером 60 байт недопустимым коротким кадром?
Не обязательно. Обычный захват опускает четырёхбайтовый FCS. Проверьте точку наблюдения, исходную длину и захваченную длину.
Становится ли дополнение новой командой ПЛК?
Не должен. Парсер обязан использовать длину протокола верхнего уровня, а не рассматривать внешнее заполнение как дополнительные прикладные данные.
Нужны ли каждому короткому сообщению 18 байт дополнения?
Нет. Восемнадцать байт относятся только к примеру без тега в этой статье; фактическое заполнение определяют исходное содержимое и инкапсуляция.
Область применения и дополнительная литература
Общие концепции заполнения Ethernet и захвата, а не измерения или гарантированное поведение конкретной модели.
Связанное руководство по CRC и FCS · Связанное руководство по преамбуле и межкадровому интервалу
