ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.10.2024
Просмотров: 66
Скачиваний: 0
106 |
Глава 4 |
|
|
Протокол преобразования адресов (Address Resolution Protocol – ARP) преобразует IP&адреса в адреса, использующиеся в локаль& ных сетях (например, Ethernet). На некоторых рисунках, изображаю& щих архитектуру и взаимосвязь протоколов, ARP размещают ниже IP, чтобы показать его тесную взаимосвязь с Уровнем Сетевого Интерфейса.
Протокол контрольных сообщений – Internet Control Message Pro& tocol (ICMP) предоставляет возможность программному обеспече& нию рабочей станции или маршрутизатора обмениваться информа& цией о проблемах маршрутизации пакетов с другими устройствами в сети. Протокол ICMP – необходимая часть реализации стека про& токолов TCP/IP.
Когда дейтаграмма проходит по сети, она может быть потеряна или искажена. Транспортный уровень решает эту проблему и обес& печивает надежную передачу информации от источника к приемни& ку. Кроме того, реализации протоколов этого уровня образуют уни& версальный интерфейс для приложений, обеспечивающий доступ к услугам сетевого уровня. Наиболее важными протоколами транс& портного уровня являются TCP и UDP.
Конечные пользователи взаимодействуют с компьютером на уров& не приложений. Разработано множество протоколов, используемых соответствующими приложениями. Например, приложения переда& чи файлов используют протокол FTP. Web&приложения используют протокол HTTP. Оба протокола FTP и HTTP базируются на протоколе TCP. Приложение Telnet обеспечивает подключение удаленных тер& миналов. Протокол эксплуатационного управления сетью SNMP по& зволяет управлять конфигурацией оборудования в сети и собирать информацию об его функционировании, в том числе, и о аварийных ситуациях. Приложения, созданные для организации речевой связи и видеосвязи, используют протокол RTP для передачи информации, чувствительной к задержкам. X Window – популярный протокол для подключения к интеллектуальному графическому терминалу. Этот список можно продолжать практически бесконечно.
Таким образом, IP–сети используют для передачи информации разнообразные протоколы, причем функции протоколов не зависят от того, какие данные передаются. Иными словами, IP, ARP, ICMP, TCP, UDP и другие элементы стека протоколов TCP/IP предоставляют уни& версальные средства передачи информации, какой бы она ни была природы (файл по FTP, Web – страница или аудиоданные).
4.5Протокол IP версии 4
Вкачестве основного протокола сетевого уровня в стеке прото& колов TCP/IP используется протокол IP, который изначально проек&
Протоколы сети Интернет |
107 |
|
|
тировался как протокол передачи пакетов в сетях, состоящих из боль& шого количества локальных сетей. Поэтому протокол IP хорошо ра& ботает в сетях со сложной топологией, рационально используя на& личие в них подсистем и экономно расходуя пропускную способность низкоскоростных линий связи. Протокол IP организует пакетную пе& редачу информации от узла к узлу IP&сети, не используя процедур установления соединения между источником и приемником инфор& мации. Кроме того, Internet Protocol является дейтаграммным про& токолом: при передаче информации по протоколу IP каждый пакет передается от узла к узлу и обрабатывается в узлах независимо от других пакетов.
Протокол IP не обеспечивает надежность доставки информации, так как он не имеет механизмов повторной передачи. Он не имеет также и механизмов управления потоком данных (flow&control). Дей& таграммы могут быть потеряны, размножены, или получены не в том порядке, в каком были переданы.
Протокол IP базируется на протоколе уровня звена данных, кото& рый обеспечивает передачу данных по физической среде. Программ& ный модуль, реализующий протокол IP, определяет маршрут пере& носа данных по сети до точки назначения, или до промежуточного маршрутизатора, где дейтаграмма извлекается из кадра локальной сети и направляется в канал, который соответствует выбранному маршруту. Дейтаграммы могут разбиваться на более мелкие фраг& менты, или, наоборот, несколько дейтаграмм могут объединяться в одну на стыке разных сетей, если эти сети поддерживают передачу дейтаграмм разной длины.
В каждой рабочей станции, подключенной к IP&сети, обработка IP&дейтаграмм, производится по одним и тем же правилам адреса& ции, фрагментации и маршрутизации. Рабочие станции рассматри& вают каждую дейтаграмму как независимую протокольную единицу, так как протокол IP не использует логических соединений или каких& либо других средств идентификации виртуальных каналов3 .
На рис. 4.2 показана структура протокольной единицы протокола IP – дейтаграммы.
Поле версия (version) идентифицирует используемую версию про& токола IP, в рассматриваемом случае указывается версия 4. Необхо& димость этого поля объясняется тем, что в переходный период в сети могут использоваться протоколы разных версий.
Поле длина заголовка (header length), состоящее из 4 битов, оп& ределяет длину заголовка, причем длина указывается как количест& во блоков размером 32 бита. В типичном случае значение этого поля равно 5.
3 При рассмотрении протокола IP версии 6 и вопросов обеспечения качества обслуживания, мы увидим некоторые отклонения от этого принципа.
108 |
|
|
|
|
|
Глава 4 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Версия (Version) |
|
|
Длина заголовка |
|
|
|
Тип обслуживания |
|
|
|||
|
|
Общая длина |
|
|
||
|
Идентификатор фрагмента |
|
|
|||
|
Флаги |
|
|
Смещение фрагмента |
|
|
|
|
|
|
|
|
|
Время жизни
Протокол
Контрольная сумма заголовка
Адрес отправителя
Адрес получателя
Опциональные поля и заполнение
Данные
Рис. 4.2 IP&дейтаграмма
Поле тип обслуживания (Type of Service) содержит информацию, которая бывает нужна при поддержке сетью разных классов обслу& живания. Использование этого поля в Интернет будет возрастать по мере роста в IP&сетях возможностей передачи мультимедийного тра& фика с задаваемыми параметрами качества обслуживания. Более подробную информацию на эту тему можно найти в главе 10.
Поле общая длина (Total Length) определяет общую длину дейта& граммы в октетах (байтах), включая заголовок и полезную нагрузку. Максимальная длина дейтаграммы составляет 65535 октетов, одна& ко, на практике, все рабочие станции и маршрутизаторы работают с длинами, не превышающими 576 байтов. Это объясняется тем, что при превышении указанной длины, снижается эффективность рабо& ты сети.
Протокол IP использует 3 поля заголовка для управления фраг& ментацией/ сборкой дейтаграмм. Как уже упоминалось, фрагмента& ция необходима потому, что разные сети, по которым передаются дейтаграммы, имеют разные максимальные размеры кадра.
Идентификатор фрагмента (Identifier) обозначает все фрагменты одной дейтаграммы, что необходимо для ее успешной сборки на при& емной стороне.
Поле флагов (Flags) обеспечивает возможность фрагментации дейтаграмм и, при использовании фрагментации, позволяет иден& тифицировать последний фрагмент дейтаграммы.
Поле смещение фрагмента (Fragment Offset) определяет положе& ние фрагмента относительно исходной дейтаграммы в единицах, равных 8 октетам.
Протоколы сети Интернет |
109 |
|
|
Поле время жизни (TTL – Time To Live) используется для ограниче& ния времени, в течение которого дейтаграмма находится в сети. Ка& ждый маршрутизатор сети должен уменьшать значение этого поля на единицу, и отбрасывать дейтаграмму, если поле TTL приняло ну& левое значение. Наличие поля TTL ограничивает возможность бес& конечной циркуляции дейтаграммы по сети, например, в случае, если по какой&либо причине маршрут, по которому она следует, оказался «закольцованным».
Поле протокол (Protocol) идентифицирует протокол верхнего уровня (TCP, UDP и т.д.).
Поле контрольная сумма заголовка (Header Checksum) обеспечи& вает возможность контроля ошибок в заголовке. Алгоритм подсчета контрольной суммы весьма прост, поскольку обычно протоколы ниж& него уровня имеют более развитые средства контроля ошибок.
IP&дейтаграммы содержат в заголовке два адреса – отправителя (Source) и получателя (Destination), которые не меняются на протя& жении всей жизни дейтаграммы.
Подробнее структура и функции протокола IPv4 описаны в RFC&791.
4.6Протокол IP версии 6
Вначале 90&х годов интенсивное коммерческое использование Интернет привело к резкому росту количества узлов сети, измене& нию характеристик трафика и ужесточению требований к качеству обслуживания. Сообщество Интернет и весь телекоммуникационный мир начали решать новые задачи путем внедрения новых протоко& лов в рамках стека протоколов TCP/IP, таких как протокол резерви& рования ресурсов RSVP, MPLS и т.д. Однако стало ясно, что только таким путем развивать технологию нельзя – нужно идти на модерни& зацию святая святых стека – протокола IP, так как некоторые пробле& мы нельзя решить без изменения формата заголовка дейтаграмм
илогики его обработки.
Как уже отмечалось выше, самой насущной проблемой становит& ся нехватка адресного пространства, что требует изменения формата адреса.
Другой проблемой является недостаточная масштабируемость процедуры маршрутизации – основы IP–сетей. Быстрый рост сети вызывает перегрузку маршрутизаторов, которые уже сегодня выну& ждены поддерживать таблицы маршрутизации с десятками и сотня& ми тысяч записей, а также решать проблемы фрагментации пакетов. Облегчить работу маршрутизаторов можно, в частности, путем мо& дернизации протокола IP.