Смекни!
smekni.com

Цифровая система подвижной радиосвязи стандарта 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номера означает, что получены и распознаны все байты с номерами Nl, N—2 и т.д.