Файл: 8.doc

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

Рис. 10.1. Соответствие между архитектурами OSI и TCP/IP

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

270 Глава 10______________________________________

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

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

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

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

Протоколы Интернет 271

управления телекоммуникационными сетями. Одним из решений проблемы согласования TCP/IP и OSI является метод шлюзов. Не слишком высокое быстродействие этого метода делает его недос­таточно эффективным для сетевых приложений, работающих в реальном времени, но для электронной почты или для пересылки небольших файлов его возможностей вполне достаточно. Доказа­тельством тому служит, в частности, наличие на рынке шлюзов прикладного уровня FTAM — FTP и Х.400 — SMTP. Известны так­же, весьма простой метод двухпротокольного стека и метод, преду­сматривающий использование моста транспортного сервиса (trans­port-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 — не ориентированный на соединение протокол.

272 Глава 10____________________________________

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

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

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

Поля порта источника (source port) и порта назначения (des­tination port) содержат номера портов взаимодействующих про­грамм. Это связано с тем, что адресация на уровне протокола TCP предназначена, скорее, для передачи дейтаграмм между логиче­скими объектами внутри компьютера, чем для фактического со­единения пользователя с сетью. Более того, и рассматриваемый в следующем параграфе адрес IP тоже не является физическим адресом,

Протоколы Интернет 273

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

Рис. 10.2. Заголовок TCP

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

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