Наверно, пока еще пытаются придерживаться уровневой модели OSI и того, что на уровнях могут быть разные реализации, так что вместо ethernet может быть что-то менее надежное.

Другая причина в том, что пакеты не всегда отображаются один к одному. Пакет TCP может быть больше ethernet пакета и отправляться кусками. Но и при склеивании могут быть ошибки.

Ну понятно, что могут быть ошибки при передаче, наводки, скачки питания и т.д. Но какие ошибки при склейке, когда все пакеты с проверенными контрольными суммами уже лежат в памяти?

Какие угодно когда tcp over что-то. Я вот через CAN прокидывал. Tcp не обязан быть через Ethernet.

Но какие ошибки при склейке, когда все пакеты с проверенными контрольными суммами уже лежат в памяти?

ethernet не даёт никаких гарантий доставки пакета до адресата - подтверждения получения там нет

А почему ты думаешь что на пути между двумя хостами обязательно будет езернет?

Точно не помню, но кажется в заголовке УДП нетути контрольной суммы.

Есть, 16 бит, сразу за длиной.

прогулял семинар по сетям? потому что не обязательно езернет, и размер тспи может быть > езернет, а езернкет фрейм может полностью пропасть. в общем это хорошая практика проектирования, когда некий уровень абстракций полагается только на себя и не зависит от того что выше/ниже, даже при условии, что езернет был бы один и размеры были бы одинаковы.

Контрольные суммы вообще ненужны, ни в tcp, ни в ethernet - всё равно почти весь трафик это TLS, а там AEAD. Дискач.

В случае любой ошибки в одном бите вся TLS сессия будет разрываться, и всё будет начинаться заново. Как мило.

Кто сказал, что TCP/UDP будут over Ethernet?

Ну вон в ipv6 вообще выкинули)

так то уровнем ниже

в UDP поверх IPv6 она же никуда не делась?

У меня в телефоне иногда Ethernet отваливается, тут-то оно и выручает.

Наверно, пока еще пытаются придерживаться уровневой модели OSI

Последние сети с моделью OSI отмерли ещё в девяностые годы.

Модель IP - другая.

Кстасти, продуктом деятельности тех же маразматиков из ITU является и сраный X.509.

Ну, не самой модели, а уровневости.

Зачем в UDP нужна контрольная сумма – непонятно, может быть клиента устраивают повреждённые пакеты или у него есть своя система восстановления. А так из-за одного бита приходится пакет выкидывать.

А кстати при ошибке TLS сессия прям разрывается, или пакет отбрасывается?

Давно IP-протокол умеет работать ТОЛЬКО поверх Ethernet? :-)

Нет. В IPv6 чексумма в TCP и UDP включает в себя IPv6 заголовок.

Не только. PPP двухточечный протокол канального уровня (Data Link) сетевой модели OSI. Тоже имеет контрольную сумму. Сюрприз?

Потому что TCP/IP работает также поверх голубиной почты.
А там нет контрольных сумм.

Ты кажется не понял. Перефразирую по другому: все ли существующие протоколы канального уровня имеют поддержку CRC? Прежде чем ты скажешь «все существующие сейчас - имеют»(я не знаю насколько справедливо это выражение, гуглить лень), вспомни когда был стандартизирован протокол IP и подумай про обратную совместимость?

TL;DR - вопрос в стиле зачем нужен UDP, когда есть TCP. И то, и то передает пакеты, в TCP еще куча всяких ништяков есть. Но тем не менее UDP вполне себе применяется и даже более того, замещает в некоторых случаях TCP(QUIC, вот это вот всё).

OSI жива?

Последние сети с моделью OSI отмерли ещё в девяностые годы.

Ты щас запостил пост через сеть которая основана на модели OSI :D

Нет. Оно никогда и не рождалось. https://computer.rip/2021-03-27-the-actual-osi-model.html

TCP/IP с OSI в общем-то ничего общего не имеет.

Да.

Потому что TCP/IP работает также поверх голубиной почты.

Есть такой RFC 1149 от 1 апреля 1990г.

А там нет контрольных сумм.

Они там и ненужны, т.к. CRC-32 нужен для проверки корректности фреймов данных, переданных по физическому носителю (кабелю, радиоинтерфейсу и т.д. и т.п.) в устройство сетевого интерфейса. СRC считаются на уровне L2 модели TCP/IP. Network Lnterface Layer, который идёт после L1 (физического уровня) и перед L3 (уровень IP).

Как только в голубиной почте появятся фреймы данных (даже не пакеты ещё), контрольные суммы там появятся, я Вам это гарантирую. =)

Да есть там фреймы. Кусочек бумажки оборачивают вогруг ного голубя - это и есть фрейм. Чем крупнее голубь, тем больше фрейм. Типичный размер фрейма - 256 миллиграмм:

Frame Format

   The IP datagram is printed, on a small scroll of paper, in
   hexadecimal, with each octet separated by whitestuff and blackstuff.
   The scroll of paper is wrapped around one leg of the avian carrier.
   A band of duct tape is used to secure the datagram's edges.  The
   bandwidth is limited to the leg length.  The MTU is variable, and
   paradoxically, generally increases with increased carrier age.  A
   typical MTU is 256 milligrams.  Some datagram padding may be needed.

   Upon receipt, the duct tape is removed and the paper copy of the
   datagram is optically scanned into a electronically transmittable
   form.

Да! Точно!

Моя вина, забыл я про то, что там есть фреймы. Точно. Вы правы. =)))

Но тут физический способ передачи позволяет гарантировать то, что по пути следования фрейм не побъётся. Он может просто не дойти (кошка например, позарилась на средство доставки). Но, если дошёл, то гарантированно неизменный. =))) Без ошибок то есть.

Кроме того что они являются типичными класическими протоколами третьего и четвертого уровня модели OSI - да вообще ничего общего. Лол.

Два уровня совпало - это же большое дело!
OSI - мертворожденная модель, TCP/IP ложится на нее весьма условно.

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

Или под дождь попал…
Хотя там написано, что изолентой приматывают, по идее должно защищать от такого.

Синяя изолента же!

Впрочем, уже написали… =)))

Расскажи циске и джуниперу че... А то иос, катос и джунос не в курсе... теоретики фиговы... Че думаешь если у мплс метки нет своего уровня так все уже «не ложится» ?

«Теоретики фиговы» - это те, кто разработали OSI. И смотрят на все через OSI, игнорируя реальность.

Приведи пример почему твои сети совсем не соответствуют класификации и уровням абстракций можели OSI

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

А какие гарантии, что голубь не перехвачен по дороге, стаей специально обученных соколов?

Я уже про возможную кошку упомянул.

Стая соколов это тоже возможный вариант. Но в этом случае фрейма данных не будет, его контрольную сумму считать тем более ненужно.

Перехвачен, не значит уничтожен. Принудительная посадка и замена содержимого, затем продолжение доставки.

Протоколы транспортного уровня не имеют защиты.

Если рассматривается вопрос перехвата и подмены, то CRC Вам тут не поможет. Нужно поверх протокола прикручивать какую-либо шифрацию. А это уже выходит за рамки «транспортного протокола» как такового.

На примере. Есть https. Это http + tls/ssl. Т.е., в основе лежит http, а средства защиты нам даёт tls/ssl, который не является частью самого по себе протокола http.

Всегда было интересно, а как операторы инспектируют htts?

Это долго.

В общем и целом гуглите DPI (deep packet inspection).

P.S. Ну «долго» в смысле что я просто задолбаюсь Вам инторнеты пересказывать. =)))

как бы намекает на практическую ценность данной фичи