Главная  Классификация протоколов сигнализации 

[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159] [ 160 ] [161] [162] [163] [164] [165] [166] [167] [168] [169]

последних является набор протоколов TCP/IP.

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

Архитектура протоколов OSI

Архитектура TCP/IP

Прикладной уровень

Уровень представления

Сеансовый уровень

Простой протокол пересылки почты (SMTP)

Протокол передачи файлов (FTP)

Программа эмуляции терминала (Telnet)

Транспортный уровень

Сетевой уровень

Уровень звена данных

Физический уровень

>- -4-

Ethernet

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

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

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

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

Высказанные критические замечания к архитектуре OSI можно уравновесить не менее критическими оценками протоколов TCP/IP, причем не только ради справедливости, но и



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

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

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

10.2. ПРОТОКОЛ УПРАВЛЕНИЯ ПЕРЕДАЧЕЙ TCP

Протокол управления передачей (TCP - Transmission Control Protocol) приблизительно соответствует транспортному уровню модели OSI, но содержит и некоторые функции сеансового уровня. С его помощью реализуется организация сеанса связи между двумя пользователями в сети. Кроме того, в его функции включается исправление ошибок и, что очень важно, преобразование информации к виду дейтаграмм, передача дейтаграмм и отслеживание их прохождения по сети. TCP служит также для организации повторной передачи потерянных дейтаграмм и обеспечения их надежности. Наконец, в компьютере-адресате TCP извлекает сообщение из дейтаграммы и направляет его прикладной программе-адресату. Протокол TCP, как и протокол дейтаграммы пользователя UDP, считаются протоколами поставщика услуг, причем TCP является протоколом, ориентированным на соединение, в то время как UDP - не ориентированный на соединение протокол. Оба они опираются на услуги протокола ГР, но могут транспортироваться через сетевые уровни Х.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, РОРЗ и т.п.). Номера порта от О до 255 определены заранее и не могут задаваться операторами, а номера после 255 могут произвольно определяться для каждой конкретной сети. Примеры фиксированных номеров портов, определяемые протоколом TCP: данные FTP - 20; управление FTP - 21; TELNET - 23; протокол SMTP - 25; сервер имен главного компьютера - 42; сервер имен домена - 53; почтовый протокол Р0Р2 - 109.

Порт источника (16 битов)

Порт назначения (16 битов)

Порядковый номер (32 бита)

Номер подтверждения (32 бита)

Смещение

Резерв

данных

(4 бита)

битов)

Контрольная сумма (16 битов)

Опции (перемещенные)

Размер окна (16 битов)

Указатель срочности (16 битов)

Накопление

Данные (перемещенные)

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

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

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



[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159] [ 160 ] [161] [162] [163] [164] [165] [166] [167] [168] [169]

0.0032