Чому розмір MTU для кадрів Ethernet обчислювався як 1500 байт?

Чи є якийсь конкретний розрахунок, що було зроблено для досягнення цієї кількості, і які фактори були враховані для цього розрахунку.

Відповідь у проекті-ietf-isis-ext-eth-01 , розділи 3-5. Ethernet використовує ті самі два байти різних способів в інкапсуляції Ethernet II (DIX) та 802.3:

• Ethernet II використовує перші два байти після мак-адреси джерела Ethernet для типу
• 802.3 використовує ті самі два байти для поля « Довжина» .

Я включаю анотаційну діаграму нижче кожного типу кадру, яка точно показує, де розташовані суперечливі байти в заголовку Ethernet:

• RFC 894 (загальновідомий як кадри Ethernet II) використовують ці байти для Type

     +----+----+------+------+-----+
     | DA | SA | Type | Data | FCS |
     +----+----+------+------+-----+
               ^^^^^^^^
  
     DA      Destination MAC Address (6 bytes)
     SA      Source MAC Address      (6 bytes)
     Type    Protocol Type           (2 bytes: >= 0x0600 or 1536 decimal)  <---
     Data    Protocol Data           (46 - 1500 bytes)
     FCS     Frame Checksum          (4 bytes)
  

• IEEE 802.3 з 802.2 LLC / SNAP (використовується Spanning-Tree, ISIS) використовують ці байти для Length

     +----+----+------+------+-----+
     | DA | SA | Len  | Data | FCS |
     +----+----+------+------+-----+
               ^^^^^^^^
  
     DA      Destination MAC Address (6 bytes)
     SA      Source MAC Address      (6 bytes)
     Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
     Data    Protocol Data           (46 - 1500 bytes)
     FCS     Frame Checksum          (4 bytes)
  

І інкапсуляції Ethernet II, і 802.3 повинні мати можливість існувати на одному посиланні. Якщо IEEE дозволив корисному навантаженню Ethernet перевищувати 1536 байт (0x600 hex), то неможливо було б відрізнити великі кадри 802.3 LLC або SNAP від ​​кадрів Ethernet II; Значення типу ethernet починаються з шестнадцяти пікселів.

Редагувати:

Я включаю посилання на PDF-копії специфікації Ethernet версії 1 та специфікації Ethernet версії 2 , на випадок, коли хтось зацікавлений ...

На іншому кінці діапазону - 1500 байт, було два фактори, які призводять до введення цієї межі. По-перше, якщо пакети занадто довгі, вони вносять додаткові затримки до іншого трафіку за допомогою кабелю Ethernet. Іншим фактором був захисний пристрій, вбудований в ранні спільні кабельні приймачі. Цей запобіжний пристрій був системою проти бамбука.Якщо пристрій, підключений до приймача, розробив несправність і почав безперервно передавати, то це ефективно заблокує будь-який інший трафік від використання цього сегменту кабельної мережі Ethernet. Щоб захиститись від цього, ранні приймачі були розроблені для автоматичного відключення, якщо передача перевищувала приблизно 1,25 мілісекунди. Це прирівнюється до вмісту даних трохи більше 1500 байт. Однак, оскільки приймач використовував простий аналоговий таймер для відключення передачі, якщо було виявлено бабування, то межа 1500 був обраний як безпечне наближення до максимального розміру даних, який не запустить пристрій безпеки.

Джерело: http://answers.yahoo.com/question/index?qid=20120729102755AAn89M1

Коли Ethernet спочатку був розроблений як спільний носій або шина з 10Base5 та 10Base2, зіткнення кадрів були частими і очікувались як частина дизайну. Порівнюйте це з сьогоднішнім часом, коли більшість усе перемикається з окремими доменами зіткнення та працює повнодуплексним, коли ніхто не очікує зіткнення.

Механізм для спільного використання "ефіру", що використовується CMSA / CD (Детектор множинного доступу / зіткнення з носієм)

Sense Carrier означав, що станція, яка хоче передавати, повинна прослуховувати провід - сенс сигналу несучої - щоб переконатися, що ніхто більше не розмовляв, оскільки це був багаторазовий доступ на цьому носії. Allowing 1500 bytes (though an arbitrary number as far as I can tell) was a compromise that meant a station could not capitalize the wire too long by talking too much at one time. Чим більше байтів передається в кадрі, тим довше всі інші станції повинні чекати, поки ця передача завершиться. Іншими словами, коротший вибух або менший MTU означав, що інші станції отримують більше можливостей для передачі та справедливішу частку. Чим повільніше швидкість передачі середовища (10 Мбіт / с), станції матимуть довші затримки для передачі в міру збільшення MTU (якщо дозволяється перевищувати 1500).

Цікавим наслідком питання було б, чому мінімальний розмір кадру - 64 байти? Кадри передавались у "прорізи", що є 512 бітами, і вони займали 51,2us для поширення сигналу в зворотному напрямку. Станція повинна не тільки слухати, коли почати розмову, зондуючи IFG (міжфрагментний розрив у 96 біт), але й слухати зіткнення з іншими кадрами. Визначення зіткнення передбачає максимальну затримку розповсюдження і збільшується вдвічі, що (щоб бути безпечним), тому воно не пропускає передачу, починаючи приблизно з того самого часу від іншого кінця дроту або сигналу відбиття власної передачі, коли хтось забув кінцевий резистор на кінці кабелю. Станція не повинна завершувати надсилання своїх даних перед відчуттям зіткнення, тому очікування 512 біт або 64 байти гарантує це.

Спочатку макс. корисне навантаження було визначено як 1500 байт у 802,3. Ethernet v2 підтримує довжину кадру> = 1536, і для цього використовуються реалізації IP. Більшість постачальників класів операторів підтримують близько 9000 байт ("джамбо-кадри") в наші дні. Оскільки 1500 байт є стандартом, який повинні підтримувати всі реалізації Ethernet, це зазвичай встановлюється за замовчуванням у всіх інтерфейсах.

Мінімальний кадр Ethernet базується на Ethernet Slot Time, який становить 512 біт (64 байт) для 10M Ethernet. Віднявши 18 байт для заголовка Ethernet і CRC, ви отримаєте 46 байт корисного навантаження.

Час слота Ethernet був заданий, щоб CSMA / CD правильно функціонував. Потрібно бути впевненим, що мінімальний розмір кадру не перевищує найбільшу можливу довжину кабелю; якби це детерміновано виявлення зіткнення було б неможливим. Після виявлення зіткнення на максимальній довжині кабелю вам потрібен сигнал виявлення зіткнення, щоб повернутися до відправника.