Разница между надежной доставкой по протоколам связи и по TCP

Question

Есть цитата, которую я забыл, из какой сетевой книги я скопировал давным-давно.

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

Мы знаем, что TCP - это протокол транспортного уровня, а не протокол канального уровня.

Интересно, как понять разницу между надежной доставкой по протоколам связи и по TCP, как выделено жирным шрифтом? Спасибо!

Answer 1

Узел к узлу также известен как прыжок. Обеспечение надежности в течение одного скачка и оставление оставшихся скачков в тракте данных с неизвестной надежностью было бы полезно, если бы этот скачок по своей природе был более ненадежным, например, беспроводная связь. Беспроводные протоколы, такие как 802.11 и 802.15.4 (например, ZigBee), возможно, должны будут добавить функции Ack/Nak и повторить попытку, чтобы достичь минимального уровня надежности, аналогичного проводной сети. Современный проводной 802.3 Ethernet, использующий конфигурацию «звезда», как правило, достаточно надежен в течение одного скачка, даже без каких-либо издержек Ack/Nak. Беспроводная связь, с другой стороны, может быть очень ненадежной, а надежный протокол канального уровня может повысить (или, по крайней мере, не ухудшить) пропускную способность смешанной проводной и беспроводной сети.

TCP достигает своей надежности (несмотря на использование (ненадежного) IP в качестве базового протокола) в основном за счет использования ответов Ack и Nak получателем и тайм-аутов на передатчике, чтобы определить, был ли пакет доставлен. Nak-ответ или время ожидания ответа требуют повторной передачи исходного пакета. Пакеты также помечены порядковыми номерами для обнаружения пропущенных пакетов или прибытия не по порядку и для правильного упорядочения принятых пакетов.

Протокол канального уровня может повысить его надежность, используя аналогичные методы Ack/Nak/timeout. Хотя выполнение нескольких уровней протокола может показаться избыточным, общая производительность сети может выиграть, поскольку повторные передачи (при необходимости) будут локализованы только для канала (ов), в котором произошел сбой сообщения.

Answer 2

Нет никакой разницы в значении «надежная доставка». Независимо от уровня протокола, получатель должен подтвердить получение пакетов, а отправитель должен повторить передачу, если подтверждение не получено. Без этого нет надежности. Разница только в слоях. Преимущество TCP заключается в том, что он работает поверх IP, что позволяет маршрутизировать пакеты через несколько переходов для достижения конечного пункта назначения. На канальном уровне работающие там протоколы касаются только одного перехода.

Answer 3

Почему на верхнем уровне необходима (дополнительная) мера надежности: правильность. Даже если на канальном уровне была абсолютная надежность, пакеты все равно могли теряться на промежуточных хостах (переполненные очереди, сбойные маршрутизаторы и т.д.). Почему на уровне ссылок: эффективность.

Answer 4

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

Проблема в том, что TCP отстой, и хотя он работает в этих случаях, он просто ужасно медленный. Поэтому, когда вы используете сырой TCP на каналах, которые регулярно теряют 0,5% пакетов, вы получите гораздо меньшую производительность, чем теоретическая скорость передачи данных (link_data_rate / (1 - скорость потери пакетов)) на одном канале, из-за предположения TCP, что все потери пакетов вызваны перегрузкой.

TCP был разработан для сетей, которые редко теряют пакеты, поэтому TCP должен терпеть только потерю пакетов.

Одна из задач, связанных с надежной связью на втором уровне, заключается в основном здесь, чтобы компенсировать TCP-неудачу. Они не должны быть на 100% надежными, как TCP. Например, 802.11 допускает потерю пакета, если количество повторных передач превысит определенный порог, тогда как TCP не будет и будет повторять передачу вечно, пока приложение или пользователь не решат, что этого достаточно.

Надежная связь в слое 2 в основном для скорости. Например, в 802.11, механизм подтверждения также используется узлами, чтобы они могли уменьшить скорость модуляции, если ухудшается беспроводная связь. Когда 802.11 не может сделать ACK (например, для многоадресных кадров), он обычно использует самую низкую частоту модуляции, которая часто составляет 1 Мбит / с, чтобы получить максимальную надежность при огромных затратах скорости.

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

Исторически сложилось так, что TCP поднялся, потому что он позволял маршрутизаторам терять пакеты. Таким образом, маршрутизаторы были проще, быстрее, и глобальный результат состоял в том, что обработка надежности на конечных точках имела лучшую производительность, чем обработка в базовой сети.