Файл: Book2 Full.doc

С тех пор, как в исходных стандартах ISDN для коммутации пакетов неречевого трафика был использован стандарт Х.25, произошли значительные усовершенствования в среде передачи данных и в применяемых протоколах, позволяющие достичь очень низкого уровня ошибок. В нормативных документах ISDN, выпущенных после 1988 г., уже рекомендуется вместо коммутации пакетов Х.25 использовать технику Frame Relay, ориентированную лишь на минимальный контроль ошибок при передаче. Снижение непроизводительных затрат времени на контроль ошибок может позволить соответствующим образом увеличить скорость обмена данными.

Глава 10 протоколы интернет

Все реки текут в море, но море не переполняется: к тому месту, откуда реки текут, они возвращаются, чтобы опять течь, Екклесиаст (гл. 1, ст.4-11)

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.