Какой минимальный размер Ethernet-кадра и почему?
===================================================

 Буквально несколько дней здесь был задан вопрос на тему размера кадра в Ethernet. Вопрос был задан дилетантски, больше походил на copy-paste из какого-то сборника задач, получил несколько жалоб, и модераторы его снесли. Однако я успел оставить довольно широкий ответ. Чтобы мой ответ и время, потраченное на него, не пропадали в пустую, я сделаю копию того вопроса, и сам напишу к нему ответ.  

  

Собственно сам вопрос: **откуда взялся минимальный размер Ethernet-кадра**?  

  

Эксперты приглашаются к обсуждению) 

 Минимальное значение фрейма для обычного Ethernet равно 64 байта. Это известная вещь. Но вокруг этого образовалось множество легенд и домыслов.  

  

Такой размер фрейма идет еще с Ethernet I, это было сделано для корректной работы алгоритма CSMA/CD. Напомню, в общей среде передачи для устранения коллизий (это когда одновременно несколько устройств будут передавать по одному и тому же проводнику одновременно сигнал) в Ethernet для каждого устройства отводится свой слот времени на передачу. То есть одно устройство должно отправить, а другое - принять, за определенный тайм-слот (да, это механизм Time Division Multiplexing). На это у нас влияет физика в виде ограничения на скорость распространения света. Примем следующую формулу:  

  

```
2*L = C * t
t = S/Bandwidht
L = C * (S/Bandwidth)/2,

L - максимальная длина среды (провода)
t - время на прохождение сигнала
S - размер кадра
C - скорость распространения сигнала в среде (скорость света умноженная на коэффициент задержки сигнала в среде)
```
  

  

Это прямая пропорция к размеру пакета и обратная к скорости распространения сигнала: чем больше размер кадра, тем больше дистанция, чем больше пропускная способность, тем меньше дистанция. Это чисто математическая формула, естественно, дальше она ограничивается физикой распространения сигнала.  

  

Конкретные расчеты приводить не буду, но для 10М Ethernet дистанция получается 5,12 км, а для 100М - 512 м, для 1000М - 51,2 м. Это при 64 байтах. Уменьшаем размер фрейма - получаем расстояние в 2 раза меньше (уменьшаем же по степеням двойки).  

  

Умные люди подумали, что для 1000Base-T максимальное теоретическое расстояние в 51 метр слишком мало и сделали рекомендацию - минимальный размер кадра для 1000Base-T увеличить до 512 байт. При этом расстояние получилось около 409,6 м.   

  

Все это был вольный пересказ [ответа на стек-овер-флоу](https://stackoverflow.com/questions/33039394/why-is-the-minimum-ethernet-frame-64-bytes) .  

  

Теперь как это было реализовано. Формат кадра для 10/100М Ethernet представляет следующий вид:  

  

![5f87fc50751a7834877318.png](https://habrastorage.org/webt/5f/87/fc/5f87fc50751a7834877318.png)  

  

Pad-добиваем нулями до минимального размера кадра. Делается это на MAC-уровне (читай, на L2, привет, модель OSI).  

  

А для 1000Base-T уже добавляем еще и поле Carier Extension. Причем из интересного, в отличие от Pad Field, оно уже забивается не нулями, а специальной последовательностью символов, генерирующихся на PHY уровне (опять привет, модель OSI).  

  

А для 1000Base-T уже добавляем еще и поле Carier Extension. Причем из интересного, в отличие от Pad Field, оно уже забивается не нулями, а специальной последовательностью символов, генерирующихся на PHY уровне (опять привет, модель OSI).  

  

![5f87fcbf6c5aa609536799.png](https://habrastorage.org/webt/5f/87/fc/5f87fcbf6c5aa609536799.png)  

  

Такой минимальный размер кадра в 512 байт верен только для режима half-duplex Gigabit Ethernet с включенным CSMA/CD. При full-duplex он не добавляется. Иначе было бы невозможно строить линии на сотни километров через DWDM или даже спутник. Но минимум в 64 байта все же остается. Мне кажется, это не стали убирать из-за того, что куда уж меньше (64 байта - 14 байт на заголовки - 2 на FCS, а дальше уже внутренние заголовки надо вычитать…). Можете поэксперементировать хоть даже на виртуалках между виртуальными интерфейсами - фрейм добивается нулями. Подробнее со структурой посмотрите [здесь](https://www.cse.wustl.edu/~jain/cis788-97/ftp/gigabit_ethernet/index.html).  

  

Кроме того, значения значения в поле Type/Length согласно [IANA](https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml) должна быть представлена максимальная длина фрейма 0x0000-0x05DC (пусть этим сейчас никто и не пользуется, сейчас в большинстве случаев здесь будет 0x8000 - IPv4, ну или что-то другое с VLANами, если снимать дамп с транкового порта). Собственно, это причина, почему на коммутаторах максимальное значение L2 MTU равно 1500 байт.  

  

Пытливый читатель спросит, зачем использовать full-duplex в 1000Base-T, ведь там всегда сигнал передается в одну сторону по своим двум парам, в обратную - по другим. Ответ - для того, чтобы использовать гигабитные хабы. Когда вы используете хаб, уже по двум своим парам могут побежать пакетики от двух хостов. Другой вопрос, что в природе таких, наверно, не существовало.  

  

Если вы задумаете, зачем сейчас об этом думать, то есть и другие современные технологии с множественным доступом к одной среде. Например, всем известный wifi. И там также работает алгоритм CSMA/CD (только его вариация - CSMA/CA, там посылается отдельный типы фреймов RTS/CTS. Но, как говорится, это уже совсем другая история, о которой в деталях можно почитать [по ссылке](https://www.oreilly.com/library/view/80211-wireless-networks/0596100523/ch04.html). 

<https://ru.wikipedia.org/wiki/IPv4>