Наверно, пока еще пытаются придерживаться уровневой модели OSI и того, что на уровнях могут быть разные реализации, так что вместо ethernet может быть что-то менее надежное.
Другая причина в том, что пакеты не всегда отображаются один к одному. Пакет TCP может быть больше ethernet пакета и отправляться кусками. Но и при склеивании могут быть ошибки.
Ну понятно, что могут быть ошибки при передаче, наводки, скачки питания и т.д. Но какие ошибки при склейке, когда все пакеты с проверенными контрольными суммами уже лежат в памяти?
прогулял семинар по сетям? потому что не обязательно езернет, и размер тспи может быть > езернет, а езернкет фрейм может полностью пропасть. в общем это хорошая практика проектирования, когда некий уровень абстракций полагается только на себя и не зависит от того что выше/ниже, даже при условии, что езернет был бы один и размеры были бы одинаковы.
Зачем в UDP нужна контрольная сумма – непонятно, может быть клиента устраивают повреждённые пакеты или у него есть своя система восстановления. А так из-за одного бита приходится пакет выкидывать.
Ты кажется не понял. Перефразирую по другому: все ли существующие протоколы канального уровня имеют поддержку CRC? Прежде чем ты скажешь «все существующие сейчас - имеют»(я не знаю насколько справедливо это выражение, гуглить лень), вспомни когда был стандартизирован протокол IP и подумай про обратную совместимость?
TL;DR - вопрос в стиле зачем нужен UDP, когда есть TCP. И то, и то передает пакеты, в TCP еще куча всяких ништяков есть. Но тем не менее UDP вполне себе применяется и даже более того, замещает в некоторых случаях TCP(QUIC, вот это вот всё).
Потому что 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.
Моя вина, забыл я про то, что там есть фреймы. Точно. Вы правы. =)))
Но тут физический способ передачи позволяет гарантировать то, что по пути следования фрейм не побъётся. Он может просто не дойти (кошка например, позарилась на средство доставки). Но, если дошёл, то гарантированно неизменный. =))) Без ошибок то есть.
Расскажи циске и джуниперу че... А то иос, катос и джунос не в курсе... теоретики фиговы... Че думаешь если у мплс метки нет своего уровня так все уже «не ложится» ?
Если рассматривается вопрос перехвата и подмены, то CRC Вам тут не поможет. Нужно поверх протокола прикручивать какую-либо шифрацию. А это уже выходит за рамки «транспортного протокола» как такового.
На примере. Есть https. Это http + tls/ssl. Т.е., в основе лежит http, а средства защиты нам даёт tls/ssl, который не является частью самого по себе протокола http.