В данном разделе обсуждаются следующие вопросы:
Протоколом называется набор правил, задающих форматы сообщений и процедуры, которые позволяют компьютерам и прикладным программам обмениваться информацией. Эти правила соблюдаются каждым компьютером в сети, в результате чего любой хост-получатель может понять отправленное ему сообщение.
Набор протоколов TCP/IP можно рассматривать как многоуровневую структуру.
Рис. 3-1. Набор протоколов TCP/IP. На рисунке показаны уровни протокола TCP/IP. Начиная с верхнего: уровень приложения, транспортный, сетевой, интерфейсный и аппаратный.
В протоколе TCP/IP строго зафиксированы правила передачи информации от отправителя к получателю. Сообщение или поток данных приложения отправляется протоколу Internet транспортного уровня, то есть Протоколу пользовательских дейтаграмм (UDP) или Протоколу управления передачей (TCP). Получив данные от приложения, эти протоколы разделяют всю информацию на небольшие блоки, которые называются пакетами. К каждому пакету добавляется адрес назначения, а затем пакет передается на следующий уровень протоколов Internet, то есть сетевой уровень.
На сетевом уровне пакет помещается в дейтаграмму протокола Internet (IP), в которую помимо пакета входят заголовок и суффикс. Протоколы сетевого уровня определяют адрес следующего пункта назначения IP-дейтаграммы (она может отправлена сразу к получателю или передана на промежуточный шлюз) и передают ее на уровень сетевого интерфейса.
Уровень сетевого интерфейса принимает IP-дейтаграммы и передает их в виде кадров с помощью аппаратного обеспечения, такого как адаптер Ethernet или Token-Ring
Рис. 3-2. Передача информации от отправляющего приложения принимающему хосту. На рисунке показан поток информации в протоколе TCP/IP при передаче от приложения хосту.
Кадры доставляются на компьютер получателя, после чего они проходят все уровни протоколов в обратном порядке. На каждом уровне обработки удаляются соответствующие этому уровню заголовки, после чего исходные данные передаются на уровень приложения.
Рис. 3-3. Передача информации от хоста приложению. На рисунке показан поток информации в протоколе TCP/IP при передаче от хоста в приложение.
Кадры передаются на уровень сетевого интерфейса (в данном случае, адаптеру Ethernet). Уровень сетевого интерфейса отбрасывает заголовок Ethernet и отправляет дейтаграмму на верхний сетевой уровень. На сетевом уровне Протокол Internet отбрасывает IP-заголовок и отправляет пакет на верхний транспортный уровень. На транспортном уровне TCP (в данном случае) отбрасывает заголовок TCP и отправляет данные на верхний уровень приложения.
Хосты в сети получают и передают информацию одновременно. На рисунке "Передача и прием данных" показан процесс взаимодействия хостов.
Рис. 3-4. Передача и прием данных. На рисунке показан поток данных в уровнях TCP/IP.
Протокол Internet (IP) версии 6 (IPv6 или IPng) - это следующее поколение IP, значительно усовершенствованное по сравнению с IP версии 4 (IPv4). Хотя протокол IPv4 поддерживал развитие глобальной сети Internet, он исчерпал свои возможности, так как у него есть два основных недостатка: ограниченное адресное пространство и сложная схема маршрутизации. Формат 32-разрядных адресов протокола IPv4 недостаточно гибок для обеспечения маршрутизации в глобальной сети Internet. Внедрение нового стандарта Бесклассовой междоменной маршрутизации (CIDR) продлило время жизни протокола IPv4 на несколько лет, однако маршрутизация по устаревшей схеме требует слишком много усилий. Даже если масштаб маршрутизации IPv4 будет увеличен, в Internet в конечном счете перестанут применяться классы сетей.
Инженерный консорциум разработчиков стандартов Internet (IETF) признал, что IPv4 не способен обеспечить неограниченный рост Internet, поэтому была создана рабочая группа IETF IPng. Из всех предложенных вариантов в качестве следующего протокола IP был выбран Простой протокол Internet плюс (SIPP) После завершения работы над RFC1883 в декабре 1995 года он был переименован в IPng.
В IPv6 значительно увеличено адресное пространство в соответствии с ростом популярности сети Internet. IPv6 - новая версия протокола IPv4, поэтому в одной и той же сети могут применяться и старый, и новый стеки протоколов. В результате переход от IPv4 (32-разрядная адресация) к IPv6 (128-разрядная адресация) в любой сети может осуществляться постепенно.
В данном обзоре описаны общие принципы работы протокола IPng. За дополнительной информацией обратитесь к RFC 1883, 1884, 1885, 1886, 1970, 1971 и 2133.
В IPv6 размер IP-адреса увеличен с 32 до 128 разрядов, при этом поддерживается большее число уровней иерархии адресов, значительно большее число адресуемых узлов, а также упрощена процедура автоматической настройки.
В IPv6 поддерживается три типа адресов:
| обычный | Обычный адрес идентифицирует один интерфейс, а пакет с обычным адресом
доставляется конкретному адресату. Обычные адреса в свою очередь
подразделяются на категории: адреса уровня линии связи, уровня сайта и
глобальные. Существует два специальных адреса этого типа:
|
| групповой | Групповой адрес идентифицирует группу интерфейсов, а пакет с таким адресом доставляется всем членам группы. В групповом адресе указывается префикс ff::/8. Групповые адреса также разделяются на области: адреса уровня узла, уровня линии связи, уровня сайта и уровня организации. |
| нечеткий | Пакет с нечетким адресом отправляется от одного хоста и доставляется
только одному интерфейсу из заданной группы (обычно, ближайшему члену этой
группы в соответствии с метрикой расстояния протокола маршрутизации).
Например, несколько Web-серверов могут быть объединены в группу с нечетким
адресом. Запрос с таким адресом будет доставляться только одному
Web-серверу из данной группы.
Нечеткие адреса ничем не отличаются от обычных адресов. Обычный адрес становится нечетким, если несколько интерфейсов объединяются в группу с таким адресом. |
Примечание: В IPv6 не предусмотрены адреса оповещения. Их функции выполняют групповые адреса.
В IPv4 для загрузки узла и его последующего взаимодействия с другими узлами сети было предусмотрено три способа: номер интерфейсной платы узла, а также серверы BOOTP и DHCP.
В IPv6 было введено понятие области IP-адресов, одна из которых - область линии связи. Адреса этой области состоят из предопределенного префикса локальной линии связи и локального идентификатора. Локальным идентификатором обычно является адрес MAC настраиваемого интерфейса. Такие адреса позволяют отправлять данные серверу путем многоцелевой рассылки, а не с помощью оповещения, при этом в изолированных сетях могут применяться адреса только этого типа.
В протоколе IPv4 особое значение имели только адреса оповещения (обычно, адреса, состоящие из всех 1 или всех 0), которые распознавались всеми хостами сети, и классы адресов (например, класс D применялся для групповой передачи). В IPv6 в адресе указывается префикс, который можно быстро проверить и определить область адреса (например, область локальной линии связи), тип адреса и механизм выделения адреса (по принадлежности к провайдеру или по принадлежности к географической области).
Информация о маршрутизации может быть указана в явном виде в первых битах адреса, но это не было окончательно стандартизовано IETF (для адресов, предоставленных провайдером, информация о маршрутизации содержится в адресе неявно).
С помощью автоматической настройки после инициализации или повторной инициализации интерфейса для него выделяется пробный адрес уровня линии связи (при этом адрес не присваивается). После этого интерфейс отправляет сообщение neighbor discovery узлам, адреса которых относятся к той же области линии связи. Узел отправляет сообщение с групповым адресом и узнает, был ли ранее присвоен данный адрес уровня линии связи, и если да, то выбирает другой адрес. Таким образом исключается возможность присовения двум интерфейсам, относящимся к одной и той же линии связи, одинаковых адресов. (Если узлы не относятся к одной линии связи, то им могут быть выделены одинаковые глобальные адреса.)
Протокол Neighbor Discovery (NDP ) для IPv6 применяется узлами (хостами и маршрутизаторами) для поиска адресов соседей уровня линии связи, подключенных по конкретной линии связи, а также для создания таблиц маршрутизации до каждого пункта назначения для каждого активного соединения. Кроме того, протокол ND применяется для поиска соседних маршрутизаторов, которые будут пересылать пакеты от своего имени и отслеживать изменение адресов уровня линии связи. NDP применяет Протокол управляющих сообщений Internet (ICMP) версии 6 и связанные с ним типы сообщений. Протокол IPv6 Neighbor Discovery представляет собой комбинацию Протокола преобразования адресов IPv4 (ARP), протокола Распространения информации о маршрутизаторах ICMP (RDISC) и протокола ICMP Redirect (ICMPv4), однако по сравнению с ними он обладает многими преимуществами.
В IPv6 предусмотрен механизм автоматической настройки структурных и бесструктурных адресов. Для автоматической настройки бесструктурных адресов не требуется настройка хостов вручную или настройка дополнительных серверов. Возможно, потребуется внести небольшие изменения в конфигурацию маршрутизаторов. Такой способ позволяет хостам создавать собственные адреса на основе локальной информации и информации, полученной от маршрутизаторов. Маршрутизаторы выделяют префиксы адресов для подсетей, связанных с данной линией связи, а хосты генерируют маркер интерфейса, однозначно определяющий интерфейс подсети. Адрес состоит из двух частей. Если маршрутизаторы отсутствуют, то хост может создавать только адреса уровня линии связи. Однако этого достаточно для установления соединений между узлами, подключенными к одной и той же линии связи.
Для упрощения маршрутизации адреса IPv6 были разделены на две части:
префикс и ИД. На первый взгляд может показаться, что это ничем не
отличается от разбиения адресов в IPv4 на адрес сети и адрес хоста, однако у
этого способа есть два преимущества:
| отсутствие классов | Длина префикса и ИД не ограничена, что позволяет избежать проблем при увеличении размера сети. |
| вложенность | Изменяя длину префикса адреса, можно разделить сеть на любое число подсетей. |
Пример 1
| 128 бит |
|---|
| адрес узла |
Пример 2
| n бит | 128-n бит |
| Префикс подсети | ИД интерфейса |
Пример 3:
| n бит | 80-n бит | 48 бит |
| Префикс подписчика | ИД подсети | ИД интерфейса |
Пример 4:
| s бит | n бит | m бит | 128-s-n-m бит |
| Префикс подписчика | ИД области | ИД подсети | ИД интерфейса |
В общем случае IPv4 ограничивается примером 3, даже в случае Маски подсети переменной длины (VLSM - это способ распределения IP-адресов по подсетям в соответствии с их конкретными задачами, а не общими сетевыми правилами). Это является следствием как недостаточной длины адреса, так и отсутствия префикса переменной длины.
В IPv6 структура IP-заголовка была упрощена за счет удаления или вынесения в дополнительный заголовок некоторых полей заголовка IPv4. В результате формат дополнительного заголовка, в котором задается необязательная информация, стал более гибким. В частности, были удалены такие поля, как:
Заголовок IPv4:
| Версия | IHL | Тип сервиса | Суммарная длина | |
| Идентификатор | Флаги | Смещение фрагмента | ||
| Время жизни | Протокол | Контрольная сумма заголовка | ||
| Адрес источника | ||||
| Целевой адрес | ||||
| Опции | Дополнение | |||
Заголовок IPv6:
| Версия | Приоритет | Метка | ||
| Длина данных | Следующий заголовок | Ограничение на пересылку | ||
| Исходный адрес | ||||
| Целевой адрес | ||||
По сравнению с IPv4 в IPng улучшена структура поля опций. Опции IPv6 размещаются в отдельных дополнительных заголовках, которые расположены в пакете между заголовком IPv6 и заголовком транспортного уровня. Большинство дополнительных заголовков не просматриваются и не обрабатываются маршрутизаторами в процессе доставки пакета, пока пакет не будет принят в пункте назначения. Такое разделение поля опций значительно повышает производительность обработки пакетов с этим полем маршрутизаторами. Если в заголовке IPv4 были указаны какие-либо опции, то маршрутизатор должен был проверять все поле опций.
Другое преимущество структуры поля опций IPv6 состоит в том, что дополнительные заголовки могут быть произвольной длины, а общий объем опций не ограничен 40 байтами. Эта особенность в сочетании со способом обработки заголовка пакета позволяет разместить в заголовке IPv6 опции, которые не применялись в IPv4, например, опции идентификации и защиты IPv6.
Для того чтобы упростить обработку заголовков опций и заголовка транспортного уровня, длина дополнительного заголовка IPv6 всегда кратна 8 байтам.
Применение дополнительных заголовков вместо поля идентификатора протокола и поля опций позволяет легко добавить новые опции.
В настоящий момент определены следующие дополнительные заголовки:
Хотя качество обслуживания может обеспечивать специальный протокол, например, RSVP, в IPv6 приоритет пакетов указывается явно в поле приоритета IP-заголовка. Значение приоритета устанавливается узлом и отражает относительный приоритет пакета или набора пакетов, в зависимости от которого этот узел, маршрутизатор или хост-получатель решают, сбрасывать этот пакет или нет.
В IPv6 существует два типа приоритетов: для потоков с управлением перегрузками и без. Считается, что между двумя типами приоритетов взаимосвязь отсутствует.
Поток с управлением перегрузками - это поток, в котором при
возникновении перегрузки применяется алгоритм возврата или другой алгоритм,
ограничивающий нагрузку линии. Приоритеты для потока с управлением
перегрузками:
| 0 | дейтаграмма не принадлежит никакому потоку |
| 1 | поток-"заполнитель" (например, новости) |
| 2 | неконтролируемая передача данных (например, электронная почта) |
| 3 | (зарезервирован) |
| 4 | контролируемая передача массивов данных (например, FTP) |
| 5 | (зарезервирован) |
| 6 | передача данных по интерактивному соединению (например, Telnet) |
| 7 | передача управляющей информации (например, сообщения протоколов маршрутизации) |
Поток без управления перегрузками - это поток, из которого при возникновении перегрузки сбрасываются (или не пересылаются) такие пакеты, как видео или аудиоданные, а также другие пакеты реального времени. Для потока с управлением перегрузками применяются примерно следующие правила задания приоритета:
Эти правила применимы только для потоков данных от конкретного отправителя. Приоритет потока с управлением перегрузками от одного отправителя не обязательно выше, чем приоритет контролируемой передачи массивов данных от другого отправителя.
Помимо основных приоритетов потока, в IPv6 определен механизм для идентификации отдельного потока пакетов. В IPv6 поток - это последовательность пакетов, отправляемых от конкретного отправителя определенному получателю (или группе получателей), на пути к которому пакеты должны пройти определенную обработку.
Метка потока применяется для задания приоритета, а также для других целей.
Метка потока представляет собой случайное число, которое предназначено только для идентификации данного потока. Это означает, что маршрутизатор, анализируя метку потока, не может узнать конкретный тип пакета. Однако он может узнать, что данный пакет принадлежит к той же последовательности, что и предыдущий пакет с такой же меткой.
Примечание: Метка потока применяется в основном в экспериментальных целях, так как IPv6 пока не стал общепризнанным стандартом. Применение и управление метками потока еще не было определено или стандартизовано.
В IPv4 размер пакета не превосходил 64 Кб. В IPv6 с помощью дополнительных заголовков большой длины размер пакета может быть увеличен до 232 октетов (немного больше 4 гигабайт).
Пакеты IPv6 будут эффективно передаваться только в том случае, если они смогут обрабатываться уже существующими хостами и маршрутизаторами IPv4. Совместимость IPv4 с IPv6 - одна из основных задач при переходе к новому протоколу IP.
В течение этого времени для передачи пакетов IPv6 может применяться существующая инфраструктура IPv4. Эту задачу можно решить, в частности, с помощью туннелирования.
Хосты и маршрутизаторы IPv6 передают дейтаграммы IPv6 через сети IPv4,
помещая их в пакеты IPv4. Существует несколько типов
туннелирования:
| Маршрутизатор-маршрутизатор | Пакеты IPv6 могут передаваться через сеть IPv4 от одного маршрутизатора IPv6 или IPv4 к другому такому же маршрутизатору. В этом случае туннель - это один из транзитных участков на пути пакета IPv6. |
| Хост-маршрутизатор | Хост IPv6 может передавать пакеты IPv6 маршрутизатору IPv6 через сеть IPv4. Такой туннель представляет собой первый транзитный участок пути пакета. |
| Хост-хост | Пакеты IPv6 могут передаваться через сеть IPv4 от одного хоста IPv6 или IPv4 к другому такому же хосту. В этом случае туннель - это весь путь пакета. |
| Маршрутизатор-хост | Маршрутизаторы IPv6/IPv4 могут передавать пакеты IPv6 своим хостам-получателям IPv6 или IPV4. Такой туннель представляет собой последний транзитный участок пути пакета. |
Типы туннелирования отличаются друг от друга способом, которым узел в начале туннеля определяет адрес узла в конце туннеля. В туннелировании маршрутизатор-маршрутизатор и хост-маршрутизатор пакет IPv6 передается по туннелю маршрутизатору. В туннелировании хост-хост и маршрутизатор-хост пакет IPv6 передается хосту-получателю.
Узел в начале туннеля (узел, помещающий пакет IPv6 в пакет IPv4) создает заголовок пакета IPv4 и передает этот пакет. Узел в конце туннеля (узел, извлекающий пакет IPv6 из пакета IPv4) получает пакет IPv4 с вложенным пакетом IPv6, удаляет заголовок IPv4, изменяет заголовок IPv6 и обрабатывает полученный пакет. Однако для пересылки пакетов IPv6 узел в начале туннеля должен хранить для каждого туннеля параметры соединения, например, максимальный блок передачи (MTU) туннеля.
Более подробная информация о защите IP версий 4 и 6 приведена в разделе Защита протокола Internet (IP).
У хоста может быть несколько интерфейсов. Хост с двумя и более интерфейсами называется хостом с несколькими адресами. С каждым интерфейсом связан адрес уровня линии связи. Адреса уровня линии связи позволяют установить соединение между двумя узлами, подключенными к одной линии связи.
С хостом может быть связано несколько адресов уровня связи. В
реализации IPv6 для AIX предусмотрено 4 опции для управления преобразованием
адресов уровня линии связи в хостах с несколькими адресами. По
умолчанию применяется опция 1.
| Опция 0 | На хосте активен только один интерфейс. Данные будут передаваться через интерфейс, с которым связан первый адрес уровня линии связи. Если преобразование адресов выполняется с помощью протокола Neighbor Discovery (NDP), то он отправляет сообщение Neighbor Solicitation каждому интерфейсу с адресом уровня линии связи. NDP заносит пакеты в очередь до тех пор, пока не будет получено первое сообщение Neighbor Advertisement. После этого пакеты будут переданы получателю сообщения. |
| Опция 1 | Если преобразование адресов выполняется с помощью протокола NDP (т.е. если пакеты данных для хоста-отправителя и информация о следующем узле линии связи не сохраняется в кэше соседнего узла), протокол рассылает сообщение Neighbor Solicitation всем интерфейсам с адресом уровня линии связи. NDP помещает пакеты данных в очередь до тех пор, пока не будет получена информация о ближайшем соседнем узле, подключенном к этой линии связи. После этого NDP ожидает, пока не будет получен ответ от каждого интерфейса. В этом случае гарантируется доставка пакетов нужному интерфейсу. Если бы протокол NDP не ожидал получения ответов от всех интерфейсов, а отвечал на первое полученное сообщение Neighbor Advertisement, пакеты данных могли быть отправлены по линии, не связанной с адресом получателя. Из-за ожидания NDP при отправке первого пакета произойдет задержка. Следует отметить, что задержка будет и в том случае, если будет ожидаться первый ответ. |
| Опция 2 | Настройка нескольких интерфейсов разрешена, но отправка пакетов может выполняться только интерфейсом с меткой main_if6. Если преобразование адресов выполняется с помощью протокола NDP, протокол рассылает сообщение Neighbor Solicitation всем интерфейсам с адресом уровня линии связи. Затем он ожидает сообщение Neighbor Advertisement от интерфейса с меткой main_if6 (см. описание команды no). После получения ответа от этого интерфейса пакеты отправляются по соответствующей линии связи. |
| Опция 3 | Настройка нескольких интерфейсов разрешена, однако отправка пакетов может выполняться только интерфейсом с меткой main_if6, а пакеты с адресами уровня сайта будут отправляться только интерфейсу main_site6 (см. описание команды no). Протокол NDP будет работать точно так же, как и в случае Опции 2. Пакеты приложений с адресами уровня сайта будут отправляться только по адресу, связанному с интерфейсом main_site6. |
Трассировка пакетов - это процесс проверки пути пакета к пункту назначения через уровни протоколов. Команда iptrace выполняет трассировку пакетов на уровне сетевого интерфейса. Вывод команды ipreport с данными о трассировке пакета представлен как в шестнадцатеричном формате, так и в формате ASCII. Команда trpt выполняет трассировку пакета на уровне протокола транспортного уровня для TCP. Вывод команды trpt содержит более подробные сведения, в том числе время, состояние TCP и порядок пакетов.
На уровне сетевого интерфейса к передаваемым данным добавляются заголовки пакетов.
Рис. 3-5. Поток пакетов в структуре сетевого интерфейса. На рисунке показан двусторонний поток данных между уровнями структуры сетевых интерфейсов. Данные передаются от верхнего (прикладного) уровня на сетевой, уровень интерфейса, драйверу устройства и сетевому адаптеру или соединению.
После этого пакеты отправляются через сетевой адаптер в нужную сеть. Прежде чем достичь получателя, пакет может пройти через много шлюзов. В сети получателя заголовки отделяются от пакетов, а полученные данные отправляются хосту-получателю.
Ниже описан формат заголовка пакета для некоторых наиболее распространенных сетевых интерфейсов.
Заголовок кадра Протокола
Internet Protocol ( IP) или Протокола преобразования
адресов ( ARP) для адаптера Ethernet состоит из трех полей,
показанных в следующей таблице.
| Заголовок кадра адаптера Ethernet | ||
| Поле | Длина | Определение |
| DA | 6 байт | Адрес получателя. |
| SA | 6 байт | Адрес источника. Если нулевой бит этого поля равен 1, то в кадре содержится информация о маршрутизации (RI). |
| Тип | 2 байта | Указывает тип пакета: IP или ARP. Ниже перечислены значения, соответствующие различным типам. |
| IP | 0800 |
| ARP | 0806 |
Заголовок MAC (Управления доступом
к среде передачи данных) адаптера Token-Ring состоит из пяти полей, описанных
в приведенной ниже таблице.
| Заголовок MAC Token-Ring | ||
| Поле | Длина | Определение |
| AC | 1 байт | Управление доступом. Значение x'00' устанавливает приоритет, равный 0. |
| FC | 1 байт | Управляющее поле. Значение x'40' означает кадр Управления логическим каналом связи. |
| DA | 6 байт | Адрес получателя. |
| SA | 6 байт | Адрес источника. Если нулевой бит этого поля равен 1, то в кадре содержится информация о маршрутизации (RI). |
| RI | 18 байт | Информация о маршрутизации. Ниже описаны допустимые значения этого поля. |
Заголовок MAC состоит из двух
полей информации о маршрутизации размером по 2 байта: управление
маршрутизацией и номера сегментов. Можно указать не более восьми
номеров сегментов, идентифицирующих получателей при ограниченном
оповещении. Информация RC содержится в нулевом и первом байтах поля
RI. Значения первых двух битов поля RC:
Заголовок LLC (Управления
логическим каналом связи) состоит из пяти полей, описанных в приведенной ниже
таблице.
| Заголовок LLC 802.3 | ||
| Поле | Длина | Определение |
| DSAP | 1 байт | Целевая служебная точка доступа. Значение этого поля - x'aa'. |
| SSAP | 1 байт | Исходная служебная точка доступа. Значение этого поля - x'aa'. |
| CONTROL | 1 байт | Содержит команды и ответы LLC. Ниже приведены допустимые значения этого поля. |
| PROT_ID | 3 байта | ИД протокола. Это зарезервированное поле. Его значение равно x'0'. |
| TYPE | 2 байта | Указывает тип пакета: IP или ARP. |
Заголовок MAC адаптера
802.3 содержит два поля, указанные в следующей таблице.
| Заголовок MAC 802.3 | ||
| Поле | Длина | Определение |
| DA | 6 байт | Адрес получателя. |
| SA | 6 байт | Адрес источника. Если нулевой бит этого поля равен 1, то в кадре содержится информация о маршрутизации (RI). |
Заголовок LLC 802.3 аналогичен заголовку MAC Token-Ring.
Протоколы Internet сетевого уровня обеспечивают соединение между двумя компьютерами в сети. Другими словами, этот уровень отвечает за маршрутизацию TCP/IP. Эти протоколы принимают запросы на отправку пакетов (с указанием целевого адреса) от транспортного уровня, преобразуют пакеты в дейтаграммы и отправляют их на уровень сетевого интерфейса для дальнейшей обработки.
Рис. 3-6. Сетевой уровень набора протоколов TCP/IP.. На рисунке показаны уровни набора протоколов TCP/IP. Верхний (прикладной) уровень состоит из приложения. На транспортном уровне работают UDP и TCP. Сетевой уровень представлен сетевым (аппаратным) интерфейсом. Аппаратный уровень - это физическая сеть.
В стек TCP/IP включены не только протоколы, предусмотренные в RFC 1100 (Official Internet Protocols), но и много других популярных протоколов, применяемых хостами Internet.
Примечание: Использование сети Internet, номеров версий, сокетов, портов служб и протоколов в TCP/IP также соответствует RFC 1010 (Assigned Numbers).
Базовый протокол сетевого уровня - это Протокол преобразования адресов (ARP). ARP выполняет динамическое преобразование IP-адресов в уникальные физические адреса хостов локальных сетей.
Проиллюстрируем работу ARP на примере двух узлов: X и Y. Если узел X хочет установить соединение с Y, и при этом X и Y расположены в различных локальных сетях (LAN), то X и Y взаимодействуют через мосты, маршрутизаторы или шлюзы с помощью IP-адресов. Внутри LAN узлы обмениваются данными с помощью низкоуровневых аппаратных адресов.
Если узлы подключены к одному и тому же сегменту LAN, то они определяют физические адреса партнеров по протоколу ARP. В этом случае узел X рассылает запрос ARP об аппаратном адресе узла Y всем узлам сети. В запросе ARP содержится аппаратный и IP-адрес узла X, а также IP-адрес узла Y. Узел Y получает запрос ARP и помещает запись для X в свой кэш ARP (применяемый для быстрого преобразования IP-адресов в аппаратные адреса), затем он отправляет непосредственно узлу X ответ ARP, содержащий аппаратный и IP-адрес узла Y. Когда узел X получает от узла Y ответ ARP, он помещает запись для узла Y в свой кэш ARP.
После того как в кэш ARP узла X добавлена запись для узла Y, узел X может отправлять пакеты непосредственно узлу Y без обращения к ARP (после удаления записи кэша ARP для узла Y ARP будет вынужден снова обратиться к Y).
В отличие от большинства протоколов, в протоколе ARP не зафиксирован формат заголовков. Сообщения ARP поддерживаются в различных локальных сетях:
Протокол ARP неприменим для протоколов SLIP (Протокол подключения к Internet по последовательной линии) и SOCC (Протокола преобразования последовательной оптической линии), так как эти протоколы предназначены для работы с двухточечными соединениями.
Таблицы преобразования обслуживаются ядром OC, поэтому у пользователей и приложений нет доступа непосредственно к ARP. При отправке IP-пакета одному из драйверов интерфейса, драйвер запрашивает преобразование соответствующего адреса. Если в таблице нет соответствующего аппаратного адреса, ARP рассылает пакет с запросом драйвера интерфейса всем хостам локальной сети.
Полные записи хранятся в таблице ARP в течение 20 минут; неполные - в течение 3 минут. Для создания постоянной записи в таблице преобразования ARP вызовите команду arp с параметром pub:
arp -s 802.3 host2 0:dd:0:a:8s:0 pub
Когда хост, поддерживающий протокол ARP, получает пакет с запросом ARP, он проверяет аппаратный адрес и IP-адрес запрашивающего хоста и при необходимости обновляет свою таблицу ARP. Если IP-адрес хоста-получателя не совпадает с адресом, указанным в запросе, то хост отбрасывает пакет с запросом. Если IP-адрес совпадает, то хост-получатель отправляет пакет с ответом запрашивающей системе. Запрашивающая система сохраняет новую запись преобразования и передает все ожидающие IP-пакеты.
Протокол управляющий сообщений Internet (ICMP) - это еще один из основных протоколов сетевого уровня TCP/IP. ICMP - обязательная часть любой реализации IP. ICMP отправляет сообщения об ошибках и управляющие сообщения протоколу IP. С помощью этого протокола шлюзы и хосты отправляют источнику пакетов отчеты о неполадках. ICMP поддерживает следующие функции:
Примечание: Как и протоколы более высокого уровня, протокол ICMP использует базовые функции IP. Однако в действительности ICMP представляет собой часть протокола IP и должен быть реализован в каждом модуле IP.
Протокол ICMP - это всего лишь средство обмена информацией о неполадках в сети. Он не повышает надежность протокола IP. Таким образом, ICMP не гарантирует надежной доставки IP-пакета, а также доставки сообщения ICMP в случае, если IP-пакет не был получен или получен в искаженном виде.
Сообщения ICMP отправляются в следующих ситуациях:
TCP/IP отправляет и принимает сообщения ICMP нескольких типов. Протокол ICMP встроен в ядро и для него не предусмотрен интерфейс прикладных программ (API).
ICMP отправляет и
получает сообщения следующих типов:
Третий протокол сетевого уровня в семействе TCP/IP - Протокол Internet (IP). Он доставляет пакеты по сети Internet без гарантии доставки и без установки соединения. IP работает "без соединения", так как каждый пакет данных передается независимо. Этот протокол ненадежный, так как он не гарантирует доставку пакетов: хост-отправитель, хост-получатель и промежуточные хосты не отправляют подтверждения.
Протокол IP обеспечивает интерфейс с протоколами уровня сетевого интерфейса. Данные передаются по физическим соединениям в виде кадров, содержащих заголовок и данные. В заголовке указываются адреса отправителя и получателя. В IP данные передаются в виде IP-дейтаграмм, формат которых аналогичен формату кадра. У дейтаграммы также есть заголовок, в котором содержатся IP-адреса отправителя и получателя.
IP задает формат всех данных, передаваемых в Internet.
Рис. 3-7. Заголовок пакета в протоколе Internet. На рисунке показаны первые 32 бита типичного заголовка IP-пакета. Более подробно поля заголовка рассмотрены в таблице.
Заголовок IP автоматически добавляется ко всем отправляемым пакетам. В принимаемых пакетах заголовок IP удаляется перед передачей данных протоколу более высокого уровня. Протокол IP поддерживает универсальную адресацию хостов Internet.
Протоколы TCP/IP транспортного уровня позволяют приложениям обмениваться данными с другими приложениями.
Рис. 3-8. Транспортный уровень набора протоколов TCP/IP.. На рисунке показаны уровни набора протоколов TCP/IP. Верхний (прикладной) уровень состоит из приложения. На транспортном уровне работают UDP и TCP. Сетевой уровень представлен сетевым (аппаратным) интерфейсом. Аппаратный уровень - это физическая сеть.
Основные протоколы транспортного уровня, поддерживающие соединения хостов Internet, - это Протокол пользовательских дейтаграмм (UDP) и TCP. Как TCP, так и UDP позволяют программам обмениваться сообщениями с приложениями других хостов. Когда приложение отправляет запрос на транспортный уровень, UDP или TCP разбивают информацию на пакеты, добавляют заголовок пакета, содержащий адрес получателя, и отправляют пакеты для дальнейшей обработки на сетевой уровень. Для определения конкретного приложения, которому адресовано сообщение, TCP и UDP применяют порты.
Протоколы более высокого уровня и приложения применяют протокол UDP для передачи дейтаграмм, а TCP - для передачи данных в потоковом режиме. Эти протоколы представляют собой часть интерфейса сокетов операционной системы.
Иногда возникает необходимость отправить сообщение от одного приложения другому приложению или процессу, выполняемому на другом компьютере, подключенном к сети. UDP обеспечивает передачу данных дейтаграмм между приложениями хостов Internet. Так как отправитель не знает, какие процессы активны в настоящий момент, для отправки сообщений одному из приложений хоста UDP применяет целевой порт протокола (или абстрактные целевые точки доступа хоста-получателя), представляющий собой положительное целое число. Полученные сообщения помещаются в очередь, связанную с портом протокола, пока приложение не сможет их обработать.
Для отправки дейтаграмм UDP применяет протокол IP, поэтому UDP так же не устанавливает соединения, как и IP. Он не гарантирует доставку дейтаграммы и не обеспечивает защиту от дублирования данных. Однако UDP позволяет отправителю задать для сообщения исходный и целевой порты и обеспечивает проверку целостности данных и заголовка сообщения с помощью контрольной суммы. Эти два свойства позволяют отправляющему и принимающему приложениям проверить правильность доставки сообщения.
Рис. 3-9. Заголовок пакета в протоколе UDP. На рисунке показаны первые 32 бита типичного заголовка пакета UDP. Первые 16 бит содержат адрес исходного порта и длину. Вторые 16 бит содержат адрес целевого порта и контрольную сумму.
Для надежной доставки дейтаграмм с помощью UDP в приложении должны быть предусмотрены процедуры проверки. Для надежной доставки потоков данных предназначен протокол TCP.
Поля заголовка дейтаграммы
UDP
Интерфейс прикладных программ (API) для UDP - это набор библиотечных процедур, основанных на интерфейсе сокетов.
Протокол TCP обеспечивает надежную доставку потока данных между двумя хостами Internet. Как и UDP, TCP в качестве протокола нижнего уровня для передачи дейтаграмм применяет Протокол Internet, а также поддерживает передачу непрерывного потока дейтаграмм. В отличие от UDP, TCP обеспечивает надежную доставку сообщений. TCP гарантирует достоверность и порядок доставки, а также обеспечивает защиту от потери и дублирования данных. Это позволяет программистам не встраивать специальные механизмы защиты передачи данных в свои прикладные программы.
Ниже перечислены рабочие
характеристики протокола TCP:
На рисунке Заголовок пакета TCP показаны все упоминавшиеся свойства.
Рис. 3-10. Заголовок пакета в протоколе TCP. На рисунке показано содержимое заголовка пакета TCP. Поля заголовка описаны в следующей таблице.
Интерфейс прикладных программ для TCP представляет собой набор библиотечных процедур, основанных на интерфейсе сокетов.
Самый высокий уровень TCP - это уровень приложений или прикладной уровень.
Рис. 3-11. Прикладной уровень набора протоколов TCP/IP.. На рисунке показаны уровни набора протоколов TCP/IP. Верхний (прикладной) уровень состоит из приложения. На транспортном уровне работают UDP и TCP. Сетевой уровень представлен сетевым (аппаратным) интерфейсом. Аппаратный уровень - это физическая сеть.
При отправке данных от одного приложения приложению другого хоста сети, данные приложения передаются на нижний транспортный уровень, где информация подготавливается к передаче.
Ниже приведен список стандартных протоколов Internet прикладного уровня:
Помимо стандартных протоколов, в TCP реализован ряд других популярных протоколов Internet прикладного уровня. Среди них такие протоколы, как:
В TCP/IP не предусмотрены API для этих протоколов прикладного уровня.
Протокол имен доменов (DOMAIN позволяет хосту выступать в качестве сервера имен для других хостов. DOMAIN в качестве протокола нижнего уровня применяет UDP или TCP. С помощью этого протокола имена хостов локальной сети одного домена могут присваиваться независимо от других доменов. Обычно протокол DOMAIN работает на основе UDP. Однако если ответные сообщения протокола UDP урезаются, то вместо него применяется TCP. Протокол DOMAIN в TCP/IP поддерживает оба транспортных протокола.
В иерархической системе имен доменов для преобразования имен и адресов Internet применяются локальные процедуры преобразования, работающие на основе локальной базы данных имен, которая обслуживается демоном named. Если запрошенное хостом имя отсутствует в локальной базе данных, процедура преобразования обращается к удаленному серверу имен DOMAIN. Если необходимая информация не найдена и на удаленном сервере, то процедура преобразования просматривает файл /etc/hosts.
Примечание: TCP/IP настраивает локальные процедуры преобразования для протокола DOMAIN на работу с файлом /etc/resolv.conf. Если этот файл не существует, то TCP/IP настраивает локальные процедуры преобразования на применение базы данных /etc/hosts.
Протокол DOMAIN реализован в TCP/IP в виде демона named и процедур преобразования. Для него не предусмотрен API.
Протокол внешних шлюзов (EGP) позволяет внешними шлюзам автономных систем обмениваться информацией о маршрутизации.
Автономная система - это набор сетей и шлюзов, которые находятся под единым управлением. Если шлюз расположен в той же самой автономной системе, то он называется внутренним соседом, а если в другой автономной системе, то внешним соседом. Шлюзы, которые применяют EGP для обмена информацией о маршрутизации, называются равноправными шлюзами EGP или соседями. С помощью EGP шлюзы автономных систем предоставляют доступ к информации своим соседям EGP.
С помощью протокола EGP внешние шлюзы могут запрашивать у других внешних шлюзов согласие на обмен информацией о досягаемости сетей, проверять работоспособность соседей EGP и передавать вспомогательные сообщения с информацией о досягаемости соседей EGP.
Протокол EGP позволяет внешним шлюзам обмениваться информацией о досягаемости подсетей только для своих автономных сетей. Таким образом, внешний шлюз передает с помощью EGP информацию своим соседям EGP , но не распространяет информацию о соседях EGP за пределы автономной системы.
Протокол EGP не анализирует метрики расстояний, которые указываются в сообщениях о маршрутизации, передаваемых другими протоколами. В поле расстояния EGP указывает, существует ли данный путь (значение 255 означает, что сеть недостижима). Это значение не применяется для выбора наикратчайшего из двух маршрутов, если эти маршруты не относятся к одной автономной системе. Поэтому EGP не применяется в качестве алгоритма маршрутизации. В результате существует только один путь от внешнего шлюза до любой сети.
В отличие от Протокола информации о маршрутизации (RIP), который применяется в автономных системах Internet для динамической настройки маршрутов, маршруты EGP фиксированы и заданы в файле /etc/gated.conf. EGP применяет IP в качестве протокола нижнего уровня.
В TCP/IP протокол EGP реализован в виде сервера gated, и для него не предусмотрен API.
Протокол передачи файлов (FTP) предназначен для обмена данными между хостами различных типов, а также для обмена файлами между внешними хостами через промежуточные системы. FTP выполняет такие задачи, как просмотр списка удаленных каталогов, переход в другой удаленный каталог, создание и удаление удаленных каталогов и передача набора файлов по одному запросу. FTP обеспечивает защиту данных при передаче, отправляя внешнему хосту пароль пользователя и учетного файла пользователя. Хотя в основном FTP предназначен для приложений, этот протокол также применяется для интерактивного диалога между пользователями.
Для передачи файлов протокол FTP применяет соединения TCP/IP, обеспечивающие надежную доставку данных в режиме потока, а для передачи команд и ответов - соединения Telnet. FTP распознает некоторые форматы файлов, в том числе NETASCII, IMAGE и Local 8.
В TCP/IP протокол FTP реализован в виде команд клиента (ftp) и сервера (ftpd). Для него не предусмотрен интерфейс прикладных программ (API).
При создании анонимных пользователей и каталогов ftp убедитесь в том, что эти каталоги (например, /u/ftp) принадлежат пользователю root и не допускают записи (например, dr-xr-xr-x). Для создания учетных файлов таких пользователей, файлов и каталогов предназначен сценарий /usr/samples/tcpip/anon.ftp.
Протокол Telnet (TELNET) предназначен для взаимодействия устройств и процессов терминала. TELNET часто применяется программами эмуляции терминала для входа в удаленную систему. TELNET также обеспечивает взаимодействия терминал-терминал и взаимодействия между процессами. Кроме того, TELNET применяется другими протоколами (например, FTP) для создания управляющего канала протокола.
В TCP/IP протокол TELNET реализован в виде команд клиента (tn, telnet и tn3270). Демон telnetd не предоставляет для TELNET интерфейс прикладных программ.
В TCP/IP предусмотрены
следующие параметры TELNET, которые могут применяться по
согласованию между клиентами и серверами:
Примечание: Для поддержки кодовой страницы ISO 8859 Latin клиент и сервер TELNET должны поддерживать передачу 8-разрядных данных в режиме ASCII. Это необходимо для работы команд TCP/IP с данными на разных языках.
Упрощенный протокол передачи файлов (TFTP) предназначен для обмена файлами с внешними хостами. Для передачи файлов TFTP применяет ненадежный Протокол пользовательских дейтаграмм, поэтому обычно он работает быстрее, чем FTP. Как и FTP, TFTP поддерживает передачу файлов в формате NETASCII и в 8-разрядном двоичном формате. В отличие от FTP, TFTP не поддерживает просмотр каталогов или переход в другой каталог внешнего хоста. В нем также не предусмотрена защита с помощью пароля. Кроме того, TFTP работает только с общими каталогами.
В TCP/IP протокол TFTP реализован в виде команд клиента (tftp и utftp) и сервера (tftpd). Команда utftp применяется в конвейере вместо команды tftp. В TCP/IP не предусмотрен API для данного протокола.
Протокол Name/Finger (FINGER) - это протокол Internet прикладного уровня, предоставляющий интерфейс для передачи данных между командой finger и демоном fingerd. Демон fingerd предоставляет информацию о пользователях, которые в настоящий момент работают на указанном удаленном хосте. Если в команде finger вы укажете пользователя отдельного хоста, то будет показана информация об этом пользователе. Протокол FINGER должен поддерживаться как удаленным, так и запрашивающим хостом. FINGER основан на Протоколе управления передачей (TCP).
Примечание: В TCP/IP не предусмотрен API для данного протокола.
Протокол локальной сети (HELLO) - это протокол внутренних шлюзов для автономной системы. (Более подробная информация приведена в разделе Автономные системы.) HELLO обслуживает информацию о соединениях, маршрутах и времени прохождения пакетов по определенному маршруту. С помощью этой информации любой компьютер сети может определить наикратчайший маршрут к целевому хосту на основе временной задержки, а затем динамически обновить информацию о маршрутах к данному хосту.
Протокол распределенной вычислительной сети (DCN) - это одна из версий протокола локальной сети. Он реализован в виде сервера gated.
Протокол удаленного выполнения команд позволяет запускать команды на удаленных хостах, поддерживающих этот протокол. Он реализован в виде команд клиента (rexec) и сервера (rexecd).
Протокол удаленного входа в систему позволяет пользователям входить в удаленные системы и работать с их терминалами так, как если бы они были напрямую подключены к этим системам. Этот протокол реализован в виде команд клиента (rlogin) и сервера (rlogind).
Протокол удаленной оболочки позволяет запускать командную оболочку на удаленных хостах, поддерживающих этот протокол. Он реализован в виде команд клиента (rsh) и сервера (rshd).
Протокол информации о маршрутизации (RIP) собирает информацию о длине маршрута в транзитных участках, а также обслуживает записи таблиц маршрутизации ядра. Он реализован в виде серверов routed и gated.
Демон timed применяется для синхронизации системного времени хостов. Он построен по принципу клиент/сервер.
Для обеспечения совместимости с общей сетевой средой большинству протоколов, служб, компонентов и сетей в рамках Internet были присвоены стандартные номера. Кроме того, некоторым компьютерам, сетям, операционным системам, протоколам, службам и терминалам были присвоены стандартные имена. В TCP/IP правила именования и нумерации соответствуют RFC 1010, Стандартные номера.
В IP-заголовке пакета в Протоколе Internet (IP) предусмотрено поле размером 4 бита, в котором указывается версия общего межсетевого протокола, которая применяется в настоящее время. Для IP десятичное значение номера версии равно 4. За более подробной информацией о стандартных номерах и именах TCP/IP обратитесь к файлам /etc/protocols и /etc/services, поставляемым вместе с TCP/IP. За дополнительной информацией о стандартных номерах и именах обратитесь к RFC 1010 и файлу /etc/services.