Рассмотрим напоследок одну из вариаций протокола ARP – протокол ARP с представителем. Это самый обычный ARP, только с небольшим дополнением для шлюза – когда приходит ARP-запрос на другую сеть, и шлюз обнаруживает, что сеть эта в его ведении, он высылает ответ модулю IP вопрошающего узла ответ со своим Ethernet адресом. Узел отправляет пакет на этот адрес в полной уверенности, что шлюз и есть этот самый затребованный компьютер с данным IP адресом. Например: некий узел (пусть это будет А с адресом 192.173.7.17) спрашивает всех в сети о соответствии адреса 192.173.7.33 (компьютер Е) адресу Ethernet. Шлюз, видя такое дело, отвечает: «указанному тобой адресу соответствует адрес…», и высылает свой Ethernet адрес. Тогда неугомонный узел отправляет пакет, в IP-заголовке которого указано 192.173.7.33, а в кадре Ethernet – адрес шлюза. Шлюз не теряется и переправляет пакет в сеть 192.173.7.32 компьютеру 192.173.7.33, как он распознает Ethernet адрес этого компьютера, мы уже знаем. То есть он как бы представляет компьютера Е его перед компьютером А в его сети. Потому и протокол так назвали. Область его применения – когда какая-нибудь глупая машина в обход протоколов маршрутизации вдруг запросила ARP-соответствие. Ну не умеет она работать в сетях с маршрутизацией, или неверно реагирует на сообщения перенаправления, а может нет шлюза по умолчанию, или программное обеспечение узла не способно восстанавливаться при сбоях на маршрутах.
Обзор Internet-протоколов и протоколов транспортного уровня
Начнем с транспортных протоколов, а именно с протокола UDP. Аббревиатура UDP означает user datagram protocol, протокол пользовательских датаграмм. Для него характерны негарантированная доставка и не поддерживает соединений из конца в конец. После формирования датаграммы, она отправляется по линиям связи, инкапсулированная в протокол IP, а на приемном конце принимается целиком. Если мы отправили 10 датаграмм, «та» сторона столько же раз примет датаграммы, и все они будут того же размера, что и у нас, будут содержать каждая ту информацию, что мы в них вложили. Этот протокол поддерживает механизм портов, посредством которого прикладные программы будут распознавать датаграммы. Иначе говоря, при помощи порта датаграмма «находит» своего владельца из числа процессов ее ожидающих.
Протокол ТСР, в отличие от предыдущего, устанавливает канал до «той» стороны, посылая регулярно пакеты туда и получая подтверждения, по таймаутам модули ТСР судит о состоянии созданного ими виртуального канала связи. Канал является дуплексным, то есть оба модуля ТСР могут одновременно передавать и принимать данные. Для уровня ТСР безразлично, какую структуру имеет сеть, им не важна информация о мостах, шлюзах и т. п., для модуля ТСР важен лишь IP-адрес оконечного узла, сеть имеет как бы однородную структуру. При установлении канала модули начинают общаться на подобие двух людей в лесу, где кроме них присутствуют еще люди. Время от времени оба человека перекликаются по имени: «Ау! Вася, ты меня слышишь?», «Да, Петро! Слышу!». Они установили диалог друг с другом, изредка они передают важную с их точки зрения информацию: «О! Здесь так много грибов!». Аналогия почти абсолютная. Все пересылки информации должны быть подтверждены приемной стороной, причем подтверждение можно может передаваться вместе с отправляемыми в ответ данными. В модуле ТСР также присутствует механизм портов, посредством которого использующие его прикладные процессы выделяют из общего потока пакетов «свои». В отличие от UDP, ТСР гарантирует доставку, однако не гарантирует, что пакеты придут на приемный конец в неизменном виде. Мы можем отправить 10 пакетов одной длины, а принимающая сторона получит, например, 20 другой длины, или примет все данные за раз. То есть протокол ТСР не сохраняет границ между отдельными записями. А зачем? И так дойдет…
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.