Цифровая система подвижной радиосвязи стандарта GPRS (стр. 5 из 16)
Функционально протокол разрешения адресов состоит из двух частей, одна из которых определяет физические адреса при посылке дейтаграммы, а другая — отвечает на запросы от других устройств в сети. Для уменьшения количества посылаемых запросов каждое устройство, использующее данный протокол, имеет
 |
память, называемую таблицей разрешения адресов, где хранятся сведения о соответствующих парах физических и IP-адресов.
Рассмотрим пример разрешения адресов двумя рабочими станциями А и В в локальной сети (рис. 14.6):
1 — станция А, которой необходимо передать информацию станки В, с помощью проверки IP-адреса и маски подсети определяет, что станция В находится в той же локальной сети;
2 — станция А проверяет свою таблицу разрешения адресов и, не находя в ней физического адреса станции В, посылает широковещательный ARP-запрос, содержащий IP-адреса обеих станций;
3 — станция В, получив запрос, сравнивает полученный адрес со своим собственным. Если адреса не совпадают, то запрос игнорируется;
4 — при совпадении адресов станция В посылает ответ станции А, в котором содержится физический адрес станции В, после чего обе станции обновляют свои таблицы разрешения адресов.
Каждая запись в таблице разрешения адресов имеет определенное время жизни (обычно 10 мин), и если с момента ее появления она не использовалось больше, чем заданный временной интервал, например 2 мин, то происходит ее удаление.
Протоколуправляющихсообщений
Протокол управляющих сообщений (ICMP— InternetControlMessageProtocol) является вспомогательным в TCP/IP и позволяет сообщать оконечному устройству об ошибках при передаче. Данный протокол является составной частью IPи включается в Каждую его реализацию, т.е. управляющие сообщения передаются в дейтаграммах. Причина использования Интернет-протокола для передачи управляющих сообщений заключается в том, что по мере продвижения к конечному пользователю они могут пройти несколько физически различных сетей, следовательно, необходим инвариантный к физической среде носитель, способный преодолевать все разнообразие сетевых топологий.
Существует два типа управляющих сообщений: собственно управляющие сообщения и сообщения об ошибках. В табл. 14.2. представлены основные типы управляющих сообщений. Сообщения ♦Ответ на эхо» и «Запрос эха» являются самыми используемыми Ири отладке, поскольку помогают идентифицировать возникающие |*сети проблемы. Так, проверка получения дейтаграммы и успешный прием ответа свидетельствуют о работоспособности основных частей транспортной системы.
Подчеркнем, что данный протокол не в состоянии корректировать ошибки — его задачей является лишь информирование о
| Номер | Тип сообщения | Номер | Тип сообщения |
| 0 | Ответ на эхо | 12 | Ошибка параметров в дейтаграмме |
| 3 | Получатель недостижим | 13 | Запрос временной отметки |
| 4 | Подавление источника | 14 | Ответ для временной метки |
| 5 | Изменение маршрута | 17 | Запрос маски адреса |
| 8 | Запрос эха | 18 | Ответ на запрос маски адреса |
| 11 | Превышено время для дейтаграммы |
них, и отправитель (терминал) должен сам принимать решения, связанные с использованием соответствующих приложений. При этом протокол управляющих сообщений не может быть использован для передачи сообщений об ошибках промежуточным устройствам, поскольку дейтаграмма содержит поля, которые определяют только адреса получателя и отправителя и не содержат никакой информации о предполагаемом маршруте движения. Когда дейтаграмма находится в одном из промежуточных узлов, нельзя узнать, какой путь она прошла до этого, следовательно, если обнаружена ошибка, нельзя определить, в каком месте находится первопричина этой ошибки или сбоя. Однако существует возможность послать отправителю сообщение об ошибке, предоставив ему самостоятельно принимать решение.
Протоколпользовательскихдейтаграмм
Протокол пользовательских дейтаграмм (UDP— UserDatagramProtocol) является одним из двух протоколов, функционирующих на более высоком, чем Интернет-протокол, уровне, поскольку предоставляет приложениям транспортные услуги. Этот протокол обеспечивает негарантированную доставку дейтаграмм получателю и не поддерживает установку соединений.
Взаимодействие между приложениями и протоколом пользовательских дейтаграмм осуществляется через протокольный порт, т.е. механизм, позволяющий рабочей станции поддерживать одновременно несколько сеансов связи. Когда рабочая станция получает из сети пакет на свой адрес, она может направить его определенному приложению, используя уникальный номер порта, который определяется во время установки сеанса.
Обеспечение передачи дейтаграмм между приложениями предполагает операции мультиплексирования и демультиплексирования, осуществляемые с использованием механизма назначения портов. Такой протокольный порт и его номер получаются каждым приложением от операционной системы, после чего приложение может послать дейтаграмму с указанием номера порта в соответствующем поле.
Функционирование протокольного порта подобно обслуживанию очереди, т.е. операционная система создает внутреннюю очередь, в которой хранятся поступающие сообщения. Если у какого-либо сообщения номер порта не входит в список используемых портов, то соответствующая дейтаграмма уничтожается и посылается сообщение протокола управляющих сообщений «Порт недоступен».
Существуют два способа назначения портов. Первый способ — это централизованное назначение портов из соответствующего списка, который публикуется центральным органом — Агентством по выделению имен и уникальных параметров протоколов (IANA— InternetAssignedNumbersAuthority). На данный момент этот список содержит 1 023 позиции, и в большинстве случаев такие порты используются системными процессами.
Второй способ предполагает динамическое назначение портов, осуществляемое по необходимости самой системой. Числовые значения таких портов находятся в пределах от 1 024 до 65 535. Для получения информации о текущем назначении портов необходимо послать соответствующий запрос.
Протоколуправленияпередачей
Протокол управления передачей (TCP — TransmissionControlProtocol) предназначен для использования в качестве транспортного средства при взаимодействии удаленных устройств, работающих в пакетных сетях. Функционируя на транспортном уровне, он устанавливает логическое соединение между приложениями и обеспечивает надежную транспортировку данных.
Для надежной транспортировки данных протокол управления передачей должен обеспечивать выполнение следующих основных задач:
• передачу данных;
• поддержку достоверности данных при передаче;
• управление потоком данных;
• разделение каналов передачи данных;
• обслуживание установленных соединений;
• установку приоритетов пользователей;
• обеспечение безопасности при передаче данных.
Единицей данных протокола управления передачей является сегмент. Изначально каждая прикладная программа вызывает программу протокола управления передачей и передает ей буфер данных, из которых формируются сегменты, т.е. некоторая непрерывная часть данных. Далее для передачи каждого сегмента вызывается Интернет-протокол, который осуществляет фрагментацию и сборку сегментов, необходимые для их передачи через множество сетей. Сегменты не обязательно должны быть одного размера, но в любом случае сегмент максимального размера должен полностью помещаться в дейтаграмму.
На приемном конце адресатом является соответствующий модуль протокола управления передачей, который помещает данные сегмента в буфер прикладной программы получателя. С каждым модулем TCPсвязан модуль IP, обеспечивающий передачу данных по локальной сети. При этом сегмент TCPпомещается в дейтаграмму IP, которая, в свою очередь, помещается в кадр канального уровня.
Надежность передачи обеспечивается механизмом подтверждения после приема блоков данных, а также использованием нумерации очередей, в которые выстраиваются передаваемые байты данных. Для этого первому байту в сегменте присваивается некоторый номер, называемый номером очереди для сегмента. Нумерация байтов в сегменте осуществляется в пределах диапазона 0...(232 - 1) таким образом, что первый байт после заголовка имеет наименьший номер, а последующие байты нумеруются по возрастанию.
Правильность передачи каждого сегмента должна подтверждаться квитанцией получателя, а в случае искажения или потери данных должна быть предусмотрена повторная передача. Когда TCPпередает сегмент данных, он создает его копию, которая помещается в очередь повторной передачи, после чего запускается таймер. Если в пределах назначенного срока приходит подтверждение передачи, то сохраненная копия удаляется из очереди, в противном случае сегмент посылается повторно.
Несмотря на достаточный диапазон номеров он оказывается мал для исключения появления так называемых дублей, которые возникают в случаях, когда весь диапазон номеров исчерпан, а отправленные сегменты не получили подтверждения. Так, в существующих сетях при скорости передачи 100 Мбит/с цикл использования всего диапазона номеров составляет около 5 мин. Если за это время не пришло подтверждение передачи, то двум разным сегментам могут быть назначены одинаковые номера, что, разумеется, может вызвать коллизии. Для решения таких проблем используется механизм опознавания, основанный на накоплении, т. е. опознание N-roномера означает, что получены и распознаны все байты с номерами N—l, N—2 и т.д.