10.1. Протоколы TCP/IP и модель OSI

10.2. Протокол управления передачей TCP

10.3. Протоколы UDP и ICMP

10.4. Межсетевой протокол IP

10.5. Протоколы нижнего уровня

10.6. Сетевые услуги в TCP/IP

10.7. Прогнозы по мотивам TCP/IP

10.1. Протоколы TCP/IP и модель OSI

В истории античных времен названы семь чудес света: египетские пирамиды, храм Артемиды в Эфесе, Мавзолей в Галикариасе, статуя Зевса в Олимпе, Колосс Родосский, висячие сады Семирамиды в Вавилоне и Александрийский маяк. Для истории XX века в семерку чудес света наряду с телефоном, радио, компьютером, вероятно, должна войти и всемирная сеть Интернет, базирующаяся на наборе протоколов TCP/IP (Transmission Control Protocol/Internet Protocol).

Протоколы TCP/IP были разработаны почти три десятилетия назад по заказу Управления перспективных исследований и разработок Министерства обороны США (ARPA) и внедрены в государственной сети Defense Data Network (DDN), включающей в себя сети ARPANET и MILNET. Первоначальная цель была связана с построением отказоустойчивой коммуникационной сети, которая могла бы функционировать даже при выходе из строя ее большей части, например, из-за ядерных бомбардировок. Широкое распространение TCP/IP получили в 1982 году, когда средства их поддержки были включены в ядро операционной системы UNIX 4.2BSD. Это объединение TCP/IP с ОС UNIX сделало протоколы TCP/IP доступными для всех UNIX-сетей. В том же году произошло еще одно важное событие в истории TCP/IP - в упомянутый комплект был включен протокол разрешения адреса ARP (Address Resolution Protocol), который ставит Ethernet-адреса в соответствие межсетевым TCP/IP-адресам. Затем протоколы TCP/IP были реализованы на рабочих станциях семейства Sun в сетевых файловых системах NFS (Network File System) для обеспечения межсетевых коммуникаций. Сейчас практически невозможно найти аппаратуру или операционную систему, где в той или иной форме не применялся бы протокол TCP/IP. Но самое главное для набора протоколов TCP/IP сегодня - обслуживание Сети сетей - Интернет.

В предыдущей, да и во многих других главах этой книги автор пропагандировал комплект протоколов OSI в качестве стандарта в области построения телекоммуникационных сетей. Происходящая буквально на глазах конвергенция сетей связи и компьютерных сетей позволяет предположить дальнейшую экспансию этой модели в область протоколов компьютерных сетей, но сегодня, тем не менее, стандартом де-факто для последних является набор протоколов TCP/IP.

Как видно из рис. 10.1, протоколы TCP и IP приблизительно соответствуют транспортному и сетевому уровням модели OSI, в связи с чем область применения TCP/IP не ограничена какими либо конкретными аппаратными платформами. Они могут работать также над рассмотренным в предыдущей главе протоколом передачи данных в сетях с коммутацией пакетов Х.25, который охватывает три нижних уровня модели OSI.

Различие между подходом модели OSI и прагматическим подходом семейства протоколов TCP/IP связано, в частности, с количеством уровней: пятиуровневая модель TCP/IP и семиуровневая модель OSI.

В предыдущей главе обсуждались реализованные в OSI принципы, ориентированные на максимальную общность и функциональность, что вносит, естественно, некоторую избыточность. Так, например, протокол Х.25 дублирует ряд функций на каждом уровне, чтобы обеспечить максимальную независимость уровней друг от друга. Подсчитываются контрольные суммы и устанавливается таймер на ожидание событий и на уровне звена, и на сетевом уровне, что повышает надежность, однако увеличивает стоимость реализации и снижает эффективность протокола в целом.

Подобная избыточность проявляется также в введении двух следующих уровней семиуровневой модели OSI: сеансового уровня и уровня представления данных. Наличие сеансового уровня можно считать целесообразным для телекоммуникационных протоколов, в которых необходимы процедуры установления сеанса (LOGIN) и завершения этого сеанса. Эти процедуры должны выполняться многократно, например, при организации доступа пользователей к общесетевым ресурсам. Но для целого ряда приложений функциональная полезность сеансового уровня вызывает сомнения. Не выглядит абсолютно необходимым и выделение в отдельный уровень телекоммуникационного протокола функций представления данных. Сжатие, конвертирование, кодирование, форматирование и распознавание структур данных выполняются не только на этом уровне, эти же самые операции выполняются на других уровнях - звена данных и прикладном.

Высказанные критические замечания к архитектуре OSI можно уравновесить не менее критическими оценками протоколов TCP/IP, причем не только ради справедливости, но и для технического анализа. Эта критика отчасти связана с различным функциональным наполнением одноименных уровней в протоколах TCP/IP и в модели OSI, что показано на рис. 10.1. Так, рассматриваемая ниже система пересылки файлов FTP представляется гораздо более тривиальной, чем протокол FTAM, а электронная почта TCP/IP, по мнению автора, выглядит несколько ограниченной на фоне почтового сервиса протокола Х.400, соответствующего модели OSI. Действительно, тезис о том, что наши недостатки являются продолжением наших достоинств, справедлив не только для человеческих характеров.

Особенности обеих архитектур обуславливают актуальность проблемы их совместного функционирования при обеспечении электронного обмена данными и реализации сложных функций управления телекоммуникационными сетями. Одним из решений проблемы согласования TCP/IP и OSI является метод шлюзов. Не слишком высокое быстродействие этого метода делает его недостаточно эффективным для сетевых приложений, работающих в реальном времени, но для электронной почты или для пересылки небольших файлов его возможностей вполне достаточно. Доказательством тому служит, в частности, наличие на рынке шлюзов прикладного уровня FTAM - FTP и Х.400 - SMTP. Известны также весьма простой метод двух протокольного стека и метод, предусматривающий использование моста транспортного сервиса (transport-service bridge). Такой мост, работая как маршрутизатор, позволяет выполнять прикладные программы OSI в TCP/IP-сетях. Он осуществляет маршрутизацию блоков данных протоколов OSI, упаковывая их так, чтобы они эмулировали TCP/IP.

Несколько слов о рассматриваемых в этой главе протоколах Интернет. TCP/IP - это не один протокол, а набор, содержащий более 100 протоколов, каждый из которых нацелен на конкретное приложение в рамках объединенной сети. Данный фактор делает TCP/IP чрезвычайно гибким, поскольку каждый протокол можно использовать независимо от других с разной технологией транспортировки, но ограничивает возможность вразумительно описать характеристики этих протоколов в одной главе.

10.2. Протокол управления передачей TCP

Протокол управления передачей (TCP — Transmission Control Protocol) приблизительно соответствует транспортному уровню модели OSI, но содержит и некоторые функции сеансового уровня. С его помощью реализуется организация сеанса связи между двумя пользователями в сети. Кроме того, в его функции включается исправление ошибок и, что очень важно, преобразование информации к виду дейтаграмм, передача дейтаграмм и отслеживание их прохождения по сети. TCP служит также для организации повторной передачи потерянных дейтаграмм и обеспечения их надежности. Наконец, в компьютере-адресате TCP извлекает сообщение из дейтаграммы и направляет его прикладной программе-адресату. Протокол TCP, как и протокол дейтаграммы пользователя UDP, считаются протоколами поставщика услуг, причем TCP является протоколом, ориентированным на соединение, в то время как UDP - не ориентированный на соединение протокол.

Оба они опираются на услуги протокола IP, но могут транспортироваться через сетевые уровни Х.25, ISDN или Frame Relay.

Рассматриваемые в параграфе 10.7 прикладные протоколы FTP, TELNET, NNTP и др. помещают данные в протокольные блоки данных PDL, уже упоминавшиеся в этом и в первом томах. В зависимости от контекста, на разных уровнях для этих PDL используются различные термины. Иногда блок данных PDL, передаваемый от транспортного уровня TCP к сетевому уровню IP, называется «сегментом». Термин «дейтаграмма» используется применительно к PDU, передаваемым из сетевого уровня IP в Ethernet. В протоколах, не ориентированных на соединение, например, в UDP, дейтаграммы зачастую называются «блоками данных», передаваемыми из IP на уровень звена данных. Если блок данных прошел через разные уровни и передается на физический уровень, он считается «кадром». Если блок данных прошел через сеть, он называется «пакетом». Эти термины и определения следует рассматривать не как охватывающий все и вся стандарт, а как попытку согласования различных терминологий, а более откровенно - как расплату за ранее принятое автором опрометчивое решение собрать в одной монографии разнообразные телекоммуникационные протоколы, терминология для каждого из которых имеет свою исторически обусловленную специфику.

Функционально, впрочем, все выглядит весьма просто. Для создания дейтаграммы протокол TCP добавляет к поступающим от прикладного уровня данным заголовок, содержащий управляющую информацию. Протокол IP добавляет к дейтаграмме свой заголовок, содержащий дополнительные инструкции. Локальная сеть вводит в дейтаграмму свою управляющую информацию в виде еще одного заголовка. Таким образом, дейтаграмма включает в себя три отдельных заголовка, каждый из которых содержит управляющую информацию различного назначения: Ethernet-заголовок, IP-заголовок и TCP-заголовок. Структура TCP-заголовка изображена на рис. 10.2.

Поля порта источника (source port) и порта назначения (destination port) содержат номера портов взаимодействующих программ. Это связано с тем, что адресация на уровне протокола TCP предназначена, скорее, для передачи дейтаграмм между логическими объектами внутри компьютера, чем для фактического соединения пользователя с сетью. Более того, и рассматриваемый в следующем параграфе адрес IP тоже не является физическим адресом, а характеризует соединение с сетью и идентифицирует пользователя. Поэтому номера портов назначения и источника представляют собой числа длиной 16 битов, идентифицирующие приложения, которые используют услуги TCP (например, FTP, TELNET, протоколы электронной почты SMTP, POP3 и т.п.). Номера порта от 0 до 255 определены заранее и не могут задаваться операторами, а номера после 255 могут произвольно определяться для каждой конкретной сети. Примеры фиксированных номеров портов, определяемые протоколом TCP: данные FTP - 20; управление FTP - 21; TELNET - 23; протокол SMTP - 25; сервер имен главного компьютера - 42; сервер имен домена - 53; почтовый протокол РОР2 - 109.

Порядковый номер блока данных (sequence number) длиной 32 бита используется для проверки того, что все блоки данных получены. Если принятый порядковый номер не соответствует очередности и срабатывает таймер TCP, все неподтвержденные блоки данных должны быть переданы повторно. Следует отметить, что предусматривается только положительное подтверждение, а отрицательных подтверждений не существует. Номер подтверждения (acknowledgement number) следует за порядковым номером и идентифицирует следующий ожидаемый порядковый номер.

Поле смещения данных (4 бита) определяет, где начинаются данные заголовка TCP, т.е. сколько 32-битовых слов находится в заголовке, предшествующем полю данных пользователя.

Несколько однобитовых полей, следующих за полем смещения данных, используются для обработки блока данных TCP. Бит срочности URG обозначает, что указатель срочности сообщения содержит значащую информацию. Указатель срочности представляет собой поле 16 битов, идентифицирующее смещение в поле данных пользователя, которое содержит срочные данные. Бит подтверждения АСК указывает на присутствие подтверждения в поле номера подтверждения и уведомляет приемное устройство о том, что этот номер подтверждает ранее полученные последовательности. Бит внеочередной обработки PSH аналогичен биту срочности. Он уведомляет принимающий главный компьютер о том, что полученный блок данных должен обрабатываться немедленно. Бит восстановления RST вызывает восстановление сеанса. Обычно это означает, что все очереди, связанные с сеансом, отключаются и все присоединенные счетчики и таймеры устанавливаются в нуль. Бит синхронизации SYN используется, когда устанавливается логическое соединение, и указывает на то, что порядковые номера должны быть синхронизированы. Бит завершения FIN указывает на то, что данных для посылки больше нет и сеанс должен быть закрыт Затем сеанс должен быть завершен, а ресурсы освобождены для другого сеанса.

Поле окна (16 битов) используется в течение установления сеанса. Стороны должны согласовывать, какое число блоков данных может быть послано до подтверждения. Это число называется размером окна и определяется размером очереди и объемом обработки данных, уже полученных от других сеансов. Размер окна не может быть изменен после того, как сеанс установлен

Поле контрольной суммы (checksum), длиной 16 битов используется для контроля ошибок в заголовке, а также в пользовательских данных. В следующем параграфе будет показано, что в IP контрольная сумма не контролирует пользовательские данные IP, а проверяет только заголовок.

Поле опций может содержать самую разную информацию, например, максимальный размер ТСР-дейтаграммы. В конце заголовок дополняется нулями до размера, кратного 32-битовому слову.

В заключение данного параграфа предлагается тезисное описание некоторых процедур протокола TCP.

Соединение устанавливается с помощью команды OPEN с аргументами в виде IP-адреса и номера порта удаленного процесса. Команда OPEN используется в обоих случаях: когда процесс намерен передавать информацию и когда он ожидает поступления информации. Процедура установления соединения использует специальный флаг синхронизации SYN и состоит из трех тактов квитирующих сообщений, позволяющих синхронизировать потоки данных Завершение соединения осуществляется обменом пакетами, содержащими команду FIN.

Для проверки того, что все данные, переданные на уровень TCP, отправлены, существует функция «проталкивания пакета» - PUSH-функция. Назначение этой функции и PUSH-флага состоит только в «проталкивании» данных к пользователю, минуя механизм кэширования и не производя никаких дополнительных группировок или других действий над данными.

Механизм присвоения порядкового номера каждому передаваемому пакету данных и проверки подтверждения доставки аналогичен уже рассмотренным ранее в этой книге подобным механизмам. Этот механизм позволяет протоколу TCP работать с поврежденными, потерянными, дублированными или поступившими с изменением порядка следования пакетами.

10.3. Протоколы UDP и ICMP

Протокол дейтаграмм пользователя UDP (user datagram protocol) относится к протоколам без установления логического соединения и предназначен для обмена дейтаграммами между процессами компьютеров, входящих в единую сеть с коммутацией пакетов.

В отличие от протокола TCP, в протоколе UDP отсутствует подтверждение приема блоков данных, что делает UDP намного проще, чем TCP, но относительно менее надежным. Данное обстоятельство не представляет опасности для таких применений как электронная почта и некоторые функции сетевого управления, когда мощные механизмы обеспечения надежности протокола TCP не требуются и когда протоколы верхнего уровня могут компенсировать недостатки UDP Преимущество протокола UDP состоит в том, что он требует минимум установок и параметров для соединения двух процессов между собой и, если не требуется большого объема обработки, блоки данных могут быть посланы и приняты с очень малым временем задержки.

Структура заголовка UDP представлена на рис 10.3 и гораздо проще, чем в TCP Отсутствие подтверждений исключает из заголовка порядковые номера и поля номера подтверждения или возможности обработки срочных данных.

Существуют номера порта-отправителя (source port) и порта назначения (destinaion port), поля длины (length) и контрольной суммы (checksum). Поле порта-отправителя может, если нужно, содержать номер порта, из которого был отправлен пакет (например, если отправитель ожидает ответа). Если это поле не используется, оно заполняется нулями. Поле длины содержит сведения о длине дейтаграммы (в байтах), включая заголовок и данные. Минимальная длина равна 8. Поле контрольной суммы UDP-пакета содержит побитное дополнение 16-битовой суммы 16-битовых слов (аналогично TCP).

Больше ничего не требуется. Очевидно, именно это позволяет принимающим главным компьютерам обрабатывать блоки данных гораздо быстрее, так как все, что требуется - это передать принятые блоки данных соответствующему приложению, идентифицируемому номером порта.

Могут возникать ситуации, когда при передаче дейтаграммы возникают ошибки, о которых необходимо сообщить отправителю или другому хост-компьютеру Для передачи этих сообщений или информации служебного характера предназначен протокол передачи управляющих сообщений ICMP (Internet Control Message Protocol). Как и протоколы TCP и UDP, протокол ICMP использует IP в качестве протокола нижнего уровня, однако по своей структуре и назначению ICMP является частью IP, рассматриваемого в следующем параграфе.

На рис. 10.4 показана структура заголовка ICMP-пакета. Данному заголовку ICMP предшествует обычный IP-заголовок без поля опций (Options) и выравнивания (Padding), а поля TOS=0, Protocol=l.

Различные типы сообщений ICMP определяются полем «типа», которое показывает, почему генерировалось сообщение ICMP, например, «destination unreachable» (пункт назначения недосягаем). Для протокола определено 13 типов сообщений. Поле «код заголовка» также носит служебный характер и обеспечивает дополнительную информацию об ошибке, расширяя иерархию сообщений данного типа. ICMP по несколько раз в день пользуются администраторы сетей и разработчики сетевого программного обеспечения, поскольку на его основе работают такие популярные утилиты, как пакетный межсетевой щуп PING (packet internetwork grouper) и TRACEROUTE, позволяющая просматривать путь маршрутизации пакета от пользователя до удаленного хост-компьютера.

Обычно шлюзы генерируют сообщение ICMP с исходящим хост-компьютером в качестве получателя. Это означает, что программное обеспечение ICMP, находящееся в шлюзах, является более сложным, чем находящееся в хост-компьютерах.

Следует подчеркнуть, что ICMP не обеспечивает обнаружение ошибок для IP, а является просто средством, используемым IP для передачи сообщений об ошибках хост-компьютерам.

10.4. Межсетевой протокол IP

Как уже подчеркивалось ранее в данной главе, протокол IP вовсе не обязателен для TCP. Протокол TCP может использовать для доставки данных почти любой протокол сетевого уровня, если тот способен обеспечить услуги маршрутизации и поддерживает интерфейс между двумя уровнями. Тем не менее, информация маршрутизации для данных от TCP, которые должны транспортироваться через сети, в подавляющем большинстве приложений обеспечивается протоколом IP. И это при том, что сам протокол не исправляет ошибки, а только сообщает об ошибках в исходящие хосткомпьютеры с помощью рассмотренного в предыдущем параграфе протокола ICMP, размещаемого на том же уровне 3 в хост-компьютере.

Структура IP-заголовка и его поля представлены на рис. 10.5. Поле «версия» (version, 4 бита) в заголовке IP предназначено для идентификации версии IP, использованной для создания заголовка. Если заголовок IP был создан в сети, использующей более новую версию IP, он может содержать информацию, которая не распознается более старой версией IP. В этом случае принимающая сеть, работающая со старой версией IP, уведомляется о необходимости пропустить нераспознаваемые поля. В данной главе рассматриваются версии 4 и 6.

Поле «длина заголовка» (IHL- Internet Header Length, 4 бита) содержит длину заголовка IP-пакета в 32-разрядных словах. Значение этого поля не может быть меньше 5.

В поле «тип обслуживания» (TOS - Type of Service, 8 битов) указывается требуемое качество обслуживания данных. В других протоколах это поле часто называют качеством обслуживания (QoS). Данное поле включает четыре параметра, содержащих информацию о приоритете дейтаграммы, о возможности поступления последовательности таких дейтаграмм с регулярными интервалами, о критичности ошибок, о важности скорости доставки дейтаграммы и, наконец, об относительной важности скорости по сравнению с надежностью на случай конфликта между двумя этими критериями. Введены следующие обозначения: РРР - приоритет, D - атрибуты задержки, Т - атрибуты пропускной способности, R - атрибуты надежности. Трехбитовый код РРР указывает уровень приоритета блока данных, применяемый для управления перегрузкой (блоки данных с меньшим приоритетом могут быть отброшены, в то время как блокам данных с более высоким приоритетом разрешается прохождение) и для управления потоком. Поле задержки D указывает, какова допустимая задержка при передаче пакета. Данное поле может принимать два значения: нормальная задержка и малая задержка. Значение 1 соответствует малой задержке. Поле пропускной способности Т указывает, какова должна быть пропускная способность средств доставки данного блока данных. Например, если блок данных сгенерирован приложением реального времени (интерактивный режим), приложение может запросить ускоренную доставку блоков данных, что требует высокой пропускной способности средств доставки. Допустимые значения - нормальная или высокая пропускная способность. Поле надежности R используется аналогичным образом, указывая, требует ли этот блок данных высокой или обычной надежности обслуживания.

Поле «общая длина» (Total length, 16 битов), аналогичное полю длины TCP-заголовка, содержит измеряемую в байтах суммарную длину дейтаграммы, включая длину IP-заголовка и данных. Этот параметр позволяет узлам определять длину поля данных путем вычитания из его значения длины заголовка. Максимально допустимая длина всей дейтаграммы целиком, считая байты, входящие в заголовок дейтаграммы, и данные, составляет 65535 байтов, т. е. длина дейтаграммы может достигать 216-1! байтов. Однако длинные дейтаграммы не используются при работе IP-протокола. Все хост-компьютеры и шлюзы сети, как правило, работают с длинами до 576 байтов. Число 576 выбрано из тех соображений, что этой длины пакета вполне достаточно для того, чтобы передать заголовок (64 байта) и блок данных (длиной 512 байтов).

Поле «идентификатор» (Identification, 16 битов) представляет собой уникальный номер, характеризующий конкретную дейтаграмму, и используется для связи фрагментов блока данных. Значение этого поля устанавливается отправителем и служит идентификатором дейтаграммы, например, в случае ее фрагментации.

Наличие поля флагов (Hags) и поля смещения (fragmentation) связано с тем, что, учитывая ограничения на длину кадра в конкретной реализации сети, протокол IP разбивает большой исходный блок данных на фрагменты и упаковывает их в пакеты. Для определения принадлежности пакетов - фрагментов одному блоку данных и обеспечения его правильной сборки, в поле флагов устанавливается специальный признак, а величины смещения помещаются в поле смещения. Поле флага содержит 3 бита: первый бит этого поля всегда имеет значение ноль, второй бит определяет, разрешена или нет фрагментация для блока данных. Величина поля смещения задает смещение в 64-битовых блоках. Первый фрагмент имеет нулевое смещение.

Поле «период жизни» (TTL - Time to live) содержит сведения о том, в течение какого времени дейтаграмме разрешено находиться в сети, и фактически представляет собой счетчик транзитов. Указанное в поле значение уменьшается на 1 на каждом этапе обработки дейтаграммы в процессе ее следования по сети, а при достижении нуля дейтаграмма уничтожается в целях экономии ресурсов сети. Таким же образом предотвращаются зацикленные маршруты в сети, когда группа маршрутизаторов может «гонять» блок данных по кругу из-за какой-то неисправности сети. Когда маршрутизатор обнаруживает, что значение параметра «период жизни» достигло нуля, он немедленно удаляет блок данных и передает сообщение источнику об ошибке с помощью рассмотренного выше протокола ICMP.

Поле «протокол» (protocol, 8 битов) содержит указание, какой протокол следует за IP. Каждый протокол, относящийся к TCP/IP, идентифицируется фиксированным номером. В таблице 10.1 содержатся номера, назначенные стандартами для наиболее распространенных протоколов. Если имеется TCP-заголовок, то в этом поле будет стоять его номер.

Поле контрольной суммы (Header checksum, 16 битов) служит для проверки правильности информации заголовка дейтаграммы. Контрольная сумма заголовка проверяет только данные заголовка, которые включают в себя адреса IP источника и пункта назначения. При проверке заголовка IP контрольная сумма анализирует правильность номера версии IP и подтверждает отличие поля «времени жизни» от нуля. Она также позволяет проверить отсутствие искажения заголовка IP и допустимость длины сообщения.

Поле опций содержит информацию о различных задачах, например, спецификации маршрутизации, и обычно используется сетевым управлением или для целей отладки. Данные, которые обеспечивают опции IP, варьируются и зависят от конкретного приложения, использующего их. Когда требуется услуга «записать маршрут», поле опции указывает и это.

Как это имело место в других протоколах, заголовок IP содержит поле выравнивания (padding), состоящее из нулей и выравнивающее 32-битовую границу.

Поля адресов IP-источника и IP-назначения используются маршрутизаторами и шлюзами в рамках сети для маршрутизации блока данных. Эти адреса остаются неизменными все время жизни блока данных и не преобразуются промежуточными сетями. Несмотря на то, что одной из основных функций межсетевого протокола IP является межсетевая и глобальная адресация, из соображений разумного объема книги целесообразно ограничиться только несколькими замечаниями о форматах адресов IP.

Для читателя, листающего эту книгу подряд главу за главой, уже стало привычным, что во всех протоколах адресация осуществляется на нескольких уровнях и определяет различные интерфейсы на всем пути передачи данных. Целесообразно начать рассмотрение с генерации адресов различных уровней, относящихся к IP. Первый уровень адресации определяет имя конкретного пользователя для приема данных. Например, при передаче кому-то сообщения по электронной почте нет необходимости задавать машинный адрес или индивидуальный IP-адрес. Все, что необходимо, - это адрес электронной почты, который может быть преобразован приемным сервером в имя пользователя и имя машины. Приложение уровня сети взаимодействия определит порт, который надо использовать для передачи, т.е внутренний логический адрес. Транспортный уровень определит адрес для протокола, который должен использоваться при передаче данных, и предоставит его приложению. Сетевой уровень будет, в зависимости от адресов IP, маршрутизировать блоки данных через разные сети, чтобы они достигли назначения. Маршрутизаторы будут считывать IP адреса, чтобы определить, через какой физический порт следует передать блок данных. Адреса, которые мы уже упоминали, прозрачны для уровня IP и обрабатываются только резидентным программным обеспечением хост-компьтера.

Рассмотренные в главе 3 данного тома точки доступа к услугам SAP в данном случае используются протоколом местной сети для адресации в пределах уровня логического управления звеном (LLC). Он является не частью протокола IP, а частью протоколов низших уровней, например Ethernet или Token Ring. Объединенные адреса IP и номера портов создают уникальный адрес гнезда (socket), обслуживаемый и контролируемый операционной системой. Гнездо идентифицирует логический объект над уровнем LLC и является комбинацией исходящего IP адреса и номера порта. Операционная система обслуживает установление логического соединения по протоколу и обеспечивает так называемое гнездо. Концепция гнезда позволяет многим пользователям (идентифицированным адресами IP) адресоваться к одному и тому же приложению (идентифицированному адресом порта). Данная концепция была впервые реализована в версии UNIX Калифорнийского университета Беркли в 60-х годах.

Несмотря на эффективность указанных принципов, ситуация в отношении IP-адресов весьма серьезна уже сегодня. Согласно некоторым расчетам, последний доступный IP-адрес будет занят где-то между 2005 и 2010 годами. Однако кризис нехватки IP-адресов может проявиться еще раньше, если бум в отношении Интернет, наблюдаемый в Северной Америке и Западной Европе, охватит Индию, Китай и другие перенаселенные страны [102]. Проблема еще более усугубляется распространением кабельных модемов, рассмотренных в главе 2 данного тома. Ее решение возможно путем расширения текущей четвертой версии протокола IP (IPv4) с помощью межсетевого протокола следующего поколения (IPng), также известного как Интернет Protocol version 6 (IPv6).

Протокол IPv6 решает потенциальную проблему нехватки IPадресов посредством использования 128-разрядных адресов вместо 32-разрядных адресов Ipv4, благодаря чему адресное пространство расширяется в 296 раз. Кроме того, в версии IPv6 предусмотрена возможность создания адресной иерархии со значительно большим количеством уровней. Добавление понятия зоны (scope) позволит при многопунктовой (multicast addressing) передаче отправлять дейтаграмму любому из группы адресов (anycast address). Некоторые поля заголовка IPv4, представленные на рис. 10.5, удалены или стали необязательными для использования. Введены также несколько новых функций, таких как поле метки идентификации пакетов, требующих специальной обработки; расширения заголовка для упрощения операций шифрования и идентификации, а также заголовок маршрутизации. 1Ру6-заголовок позволяет более эффективно использовать опции пересылки дейтаграмм по маршруту и предоставляет значительно больше возможностей для внесения изменений в опции и добавления новых параметров благодаря технологии «вложенных заголовков».

Поле «версия» (version, 4 бита) имеет значение, равное 6. Поле «приоритет» (prior, 4 бита) позволяет отправителю назначить дейтаграмме определенный уровень приоритета по отношению к другим отправляемым блокам данных. Возможные 16 значений этого поля разделены на две категории: значения поля от 0 до 7 используются для дейтаграмм, которые могут не передаваться при перегруженной линии, а значения от 8 до 15 назначаются пакетам, которые должны быть отправлены при любом состоянии линии. К первой категории относятся трафик TCP, передача e-mail, FTP, NFS, TELNET, X-interactive. Во второй категории приоритет 8 назначается пакетам, которые отправляются в последнюю очередь при перегруженной линии, а приоритет 15 - в первую.

Поле «метка потока» (flow label, 24 бита) используется отправителем для того, чтобы помечать пакеты, которые требуют специальной обработки сетевыми модулями IPv6. Хост-компьютеры или шлюзы, не поддерживающие этой опции, должны установить метку в 0 и игнорировать ее при обработке пакета. Поток представляет собой последовательность пакетов, отправляемых определенному получателю (или группе получателей), на пути к которым пакеты должны пройти специальную обработку. Таких потоков между одними и теми же хост-компьтерами может быть несколько, и значение этого поля позволяет идентифицировать определенный поток. Если значение этого поля установлено в 0, то считается, что дейтаграмма не принадлежит ни к какому потоку. Меткой потока служит случайно выбранное число в диапазоне 1 до FFFFFF. Все пакеты, принадлежащие одному потоку, должны отправляться по одному и тому же адресу назначения и с одним и тем же приоритетом. Кроме того, если одна из дейтаграмм потока содержит в своем заголовке какой-либо вложенный заголовок или опцию, все остальные пакеты потока тоже должны их содержать. Если шлюз, обрабатывающий пакет, заметил отклонение состава дейтаграммы от других дейтаграмм потока, он генерирует ошибку потока и уведомляет об этом отправителя.

Информация о потоке хранится в шлюзе в течение 6 с. Если за это время через шлюз не пройдет ни од на дейтаграмма потока, идентификатор данного потока освобождается. С другой стороны, хост-компьютер отправителя в случае перезапуска узла не сможет ранее чем через 6 с организовать новый поток.

Поле общей длины IPv4 было переименовано в протоколе IPv6 в поле «длина данных» («payload length»), т.к. оно содержит длину данных после заголовка, в то время как поле общей длины (total length) учитывает и длину заголовка. Поле «длина данных» (payload length, 16 бит) определяет количество байтов данных пакета, которые следуют за заголовком. Значение этого поля равное 0 означает, что размер дейтаграммы более 65535 и хранится в поле jumbo payload (сверх-длина).

Поле «следующий заголовок» (next header, 8 битов) содержит информацию типа заголовка, который следует за заголовком IPv6. Это поле представляет собой переименованное и измененное поле «протокол» (protocol) из IPv4 и позволяет вставлять дополнительные заголовки между данными IP и TCP или UDP. Оно также предоставляет информацию о наличии дополнительных заголовков, следующих за основным, и исключает необходимость в поле IHL (Internet header lehgth).

Поле «ограничение пересылок» (hop limit, 8 битов) соответствует полю «времени жизни» (time to live) в IPv4. Величина этого поля уменьшается на 1 при прохождении дейтаграммой шлюза или хост-компьютера, а если величина этого поля равна 0, дейтаграмма уничтожается.

10.5. Протоколы нижнего уровня

Как уже подчеркивалось выше, «универсальность» семейства TCP/IP заканчивается на сетевом уровне, а IP-адрес представляет собой логическое выражение, никак не связанное с конкретной физической реализацией сети, по которой передается дейтаграмма. Для рассмотрения работы IP с протоколами более низкого уровня - уровня звена данных - необходимо обратиться к конкретной реализации той или иной сети.

Семейство протоколов TCP/IP работает в различных сетевых средах и, в частности, в Ethernet. Сеть Ethernet была разработана Исследовательским центром корпорации Xerox в Пало Альто в 1970-м году и заполнила нишу между глобальными сетями, низкоскоростными сетями и специализированными сетями компьютерных центров, которые работали с высокой скоростью, но на очень ограниченном расстоянии. Сегодня Ethernet является наиболее распространенным протоколом локальных вычислительных сетей.

Другие возможные сетевые среды для работы TCP/IP - это локальные сети Token Ring, глобальные сети WAN, такие как сети передачи данных общего пользования типа Х.25. Сравнительно небольшое количество компьютеров может подключаться к каналам связи с непосредственным соединением «точка—точка», т.е. к последовательным каналам связи, например, телефонным линиям. Для работы по всем этим линиям определены стандарты инкапсуляции IP-протокола. Одним из таких стандартов работы по каналам последовательного доступа - Serial Line - является протокол SLIP (Serial Line Internet Protocol).

Протокол последовательной межсетевой связи (SLIP) обычно используется при связи по телефонной линии через модем. Он является протоколом, который поддерживает TCP/IP через линии последовательной связи, где маршрутизаторы и межсетевые интерфейсы не используются. SLIP не обеспечивает ни адресации, ни идентификации пакета, ни механизмов проверки ошибок. Благодаря своей простоте он стал быстро распространяться.

Протокол SLIP пакетирует информацию протокола IP или информацию, поступающую из уровней выше IP, и передает ее по линии последовательной связи, для чего используются два специальных символа: END=192 и ESC=219. Отправку пакета SLIP начинает с передачи двух END. После этого начинается передача потока данных. Если байт данных совпадает с END, вместо него отправляются два ESC и 220. Если в потоке данных встречается байт ESC, вместо него передаются два ESC и 221. После передачи последнего байта потока передается END.

Протокол «точка—точка» РРР (Point-to-Point Protocol) является новой версией протокола SLIP, обеспечивающей более быстродействующую и эффективную связь. Протокол РРР использует формат кадра HDLC с информационным полем, содержащим заголовок протокола IP. При этом РРР использует другой протокол управления линией связи LCP для установления соединения.

10.6. Сетевые услуги в TCP/IP

По причинам, приведенным в конце параграфа 10.1, описание основных протоколов TCP/IP дано кратко, основное внимание уделено тем идеям и возможностям, которые лежат в архитектуре. Практически за пределами главы остаются протоколы маршрутизации EGP, BGP, UGRP, OSPF, протоколы соотнесения адресов ARP и RARP и механизмы маршрутизации нового поколения CIDR. Только упоминаются протоколы прикладного уровня, такие как протокол пересылки файлов FTP, TELNET и протокол передачи новостей NNTP.

Эти протоколы сами по себе не являются реальными приложениями, но взаимосвязаны с разными приложениями, необходимыми для использования сетевых услуг. Они обеспечивают связь с удаленными устройствами, но не предоставляют пользователю интерфейс для взаимодействия с разными удаленными службами.

Это, прежде всего, протоколы электронной почты - SMTP, РОРЗ, IMAP4, протокол работы с системой новостей NNTP, протокол HTTP работы с World Wide Web. На рис. 10.1 видно, что сетевые услуги в TCP/IP предоставляются посредством прикладного протокола удаленного терминала TELN ЕТ, сетевой файловой системы NFS, мониторинга и управления сетями на основе SNMP, механизма вызова удаленных процедур RPC и др.

Протокол виртуального терминала TELNET предоставляет пользователю возможность работать не с терминалом конкретного типа, а со стандартным сетевым терминалом. Протокол TELNET позволяет реализовать принцип сетевых виртуальных терминалов NVT (Network Virtual Terminal). Соединение TELNET строится на базе TCP-протокола, предполагается, что каждый участник работает как виртуальный сетевой терминал NVT, а на прикладном уровне на стороне пользователя над TELNET находится либо программа поддержки реального терминала, либо прикладной процесс, который осуществляет доступ на правах удаленного терминала.

Сетевая файловая система NFS (Network File System) позволяет монтировать в единое целое файловые системы нескольких, возможно, удаленных друг от друга компьютеров и предоставить удаленный доступ к файлам каждого из них. Работа NFS-системы базируется на протоколе NFS, который предназначен для предоставления универсального интерфейса работы с файлами для различных типов компьютеров, операционных систем, сетевой архитектуры и транспортных протоколов. Протокол NFS, как правило, использует UDP-протокол, или протокол TCP, хотя конкретная реализация во многом зависит от спецификации используемой операционной системы.

Протокол NNTP (Network News Transport Protocol) - это прикладной протокол высокого уровня, который используется для обеспечения связи между различными серверами, работающими с программным обеспечением системы новостей UseNet (распределенная система ведения дискуссий).

Широко используемый протокол HTTP обеспечивает навигацию по сети World Wide Web (WWW) и аутентификацию пользователя, если этого требует сервер WWW, а также формирует информационные запросы и передает запрошенную информацию пользователю.

Протокол мониторинга и эксплуатационного управления сетью SNMP (Simple Network Management protocol) является протоколом прикладного уровня, предназначенным для обеспечения обмена эксплуатационной информацией между сетевыми устройствами.

10.7. Прогнозы по мотивам TCP/IP

То, что произошло в мире телекоммуникаций сегодня, можно квалифицировать скорее как революцию, чем эволюцию, настолько велико различие между тем, что представлял собой телефон вчера, и тем, как значительно возросло распространение информации и влияние сети Интернет сегодня.

Автору, проработавшему более четверти века в традиционной телефонии, совсем не хочется делать пессимистические прогнозы относительно будущего коммутации каналов с учетом развития возможностей IP-телефонии второго поколения, позволяющей, в частности, осуществлять в глобальном масштабе речевую связь с использованием протокола IP. Но и уклониться от этого было бы не совсем честно перед читателем, поэтому следует упомянуть вполне распространенное мнение, что через 10 лет существующая сегодня ТфОП и вместе с ней сама технология коммутации каналов будет уже на стадии вымирания. Ее место займет инфраструктура с коммутацией пакетов, которая сможет обслуживать передачу речи, видеоинформации и данных, о чем уже говорилось в главе 6 данного тома.

В сети Интернет второго поколения будет использоваться комбинация мультигигабитных и терабитных маршрутизаторов и коммутационного оборудования АТМ совместно с технологией высокоскоростного абонентского доступа xDSL, рассмотренной в главе 2 данного тома.

Прекрасной иллюстрацией к этим тезисам может служить разработка системы ТСАР over TCP/IP. Развитие интеллектуальных сетей увеличило потребность в узлах, поддерживающих сигнализацию ОКС-7. Соответствующее оборудование стоит дорого, а система ТСАР over TCP/IP позволяет уменьшить затраты на построение транспортной сети за счет передачи сообщений ТСАР сигнализации ОКС-7 через коммутационные узлы, не поддерживающие эту сигнализацию.

Еще одной иллюстрацией является организация запросов к базам данных, хранящим информацию об абоненте и оказываемых ему услугах. Организация доступа к базам данных является, к тому же, ключевым моментом при предоставлении услуг интеллектуальных сетей. Помимо сообщений ТСАР, система ТСАР over TCP/IP позволяет передавать через сеть IP сообщения INAP и MAP. Это дает возможность разрабатывать масштабируемые и рентабельные платформы интеллектуальных сетей.

И, если попытаться одной фразой выразить суть данного параграфа, то уместней старинной формулы «alia tempora, alia mores - иные времена, иные нравы» - найти трудно.