1 (1131253), страница 3
Текст из файла (страница 3)
Основная проблема, решаемая на сетевом уровне, - как маршрутизировать пакеты от отправителя к получателю. Маршруты могут быть определены заранее и прописаны в статической таблице, которая не изменяется. Они могут также определяться в момент установления соединения. Наконец, они могут строиться динамически по ходу передачи в зависимости от загрузки сети.
Если в транспортной подсети циркулирует слишком много пакетов, то они могут использовать одни и те же маршруты, что будет приводить к заторам или перегрузкам. Эта проблема также решается на сетевом уровне.
Поскольку за использование транспортной подсети, как правило, предполагается оплата, то на этом уровне присутствуют функции учета: как много байт (или символов) послал или получил абонент сети. Если абоненты расположены в разных странах, где действуют разные тарифы, то надо должным образом скорректировать цену услуги.
Если пакет адресован в другую сеть, то надо предпринять надлежащие меры: в ней может быть другой формат пакетов, способ адресации, размер пакетов, другие протоколы и т.д. - все эти проблемы решаются на сетевом уровне.
В сетях с вещательной передачей проблемы маршрутизации просты, и этот уровень часто отсутствует.
Основная функция транспортного уровня - принять данные с уровня сессии, разделить, если надо, на более мелкие единицы, передать на сетевой уровень и позаботиться, чтобы все они дошли в целостности до адресата. Все это должно быть сделано эффективно и так, чтобы вышележащий уровень не зависел от того, как именно это было сделано. В нормальных условиях транспортный уровень должен создавать специальное сетевое соединение для каждого транспортного соединения по запросу уровня сессии. Если транспортное соединение требует высокую пропускную способность, то транспортный уровень может потребовать у сетевого уровня создать несколько сетевых соединений, между которыми транспортный уровень буден распределять передаваемые данные. И наоборот, если требуется обеспечить недорогое транспортное соединение, то транспортный уровень может использовать одно и то же соединение на сетевом уровне для нескольких транспортных соединений. В любом случае такое мультиплексирование должно быть незаметным на уровне сессии.
Сетевой уровень определяет, какой тип сервиса предоставить вышележащим уровням и пользователям сети. Наиболее часто используемым сервисом является канал «точка-точка» без ошибок, обеспечивающий доставку сообщений или байтов в той последовательности, в какой они были отправлены. Другой вид сервиса - доставка отдельных сообщений без гарантии сохранения их последовательности или, например, рассылка одного сообщения многим в режиме вещания. В каждом конкретном случае сервис определяют при установлении транспортного соединения.
Транспортный уровень - это уровень, обеспечивающий соединение «точка-точка». Активности транспортного уровня на машине отправителя общаются с равнозначными активностями транспортного уровня на машине получателя. Этого нельзя сказать про активности на нижележащих уровнях. Они общаются с равнозначными активностями на соседних машинах. В этом одно из основных отличий уровней 1-3 от уровней 4-7. Последние уровни обеспечивают соединение «точка-точка». Это хорошо видно на рисунке 1-13.
Многие хост-машины - мультипрограммные, поэтому транспортный уровень для одной такой машины должен поддерживать несколько транспортных соединений. Чтобы определить, к какому соединению относится тот или иной пакет, в его заголовке помещается необходимая информация.
Транспортный уровень также отвечает за установление и разрыв транспортного соединения в сети. Это предполагает наличие механизма именования, что значит, что процесс на одной машине должен уметь указать, с кем в сети ему надо обменяться информацией. Транспортный уровень также должен предотвращать «захлебывание» получателя в случае «очень быстро говорящего» отправителя. Механизм для этого называется управление потоком. Он есть и на других уровнях. Однако, как мы увидим ниже, управление потоком между хостами отличен от управления потоком между маршрутизаторами.
Уровень сессии позволяет пользователям на А-машинах (напомним, что пользователем может быть программа) устанавливать между собой сессии. Сессия позволяет передавать данные, как это может делать транспортный уровень, но, кроме того, этот уровень имеет более сложный сервис, полезный в некоторых приложениях. Например, он может осуществлять вход в удаленную систему, передавать файл между двумя приложениями и т.п.
Один из видов услуг на этом уровне - управление диалогом. Потоки данных могут быть разрешены в обоих направлениях одновременно, либо поочередно в одном направлении. Сервис на уровне сессии будет управлять направлением передачи.
Другой вид сервиса на этом уровне - управление маркером. Для некоторых протоколов недопустимо выполнение одной и той же операции на обоих концах соединения одновременно. Для этого уровень сессии выделяет активной стороне маркер. Операцию может выполнять тот, кто владеет маркером. Другим примером сервиса на этом уровне является синхронизация. Пусть нам надо передать такой файл, что его пересылка займет два часа, между машинами, время наработки на отказ у которых - один час. Ясно, что «в лоб» передачу такого файла средствами транспортного уровня не решить. Уровень сессии позволяет расставлять контрольные точки. В случае отказа одной из машин передача возобновится с последней контрольной точки.
Уровень представления предоставляет решения для часто возникающих проблем, чем облегчает участь пользователей. В основном это проблемы семантики и синтаксиса передаваемой информации. Данный уровень имеет дело с информацией, а не с потоком битов.
Типичным примером услуги на этом уровне является унифицированная кодировка данных. Уровень представления работает со структурами данных в абстрактной форме, преобразует это представление во внутреннее для конкретной машины и из внутреннего, машинного представления, в стандартное представление для передачи по сети.
Уровень приложений обеспечивает работу часто используемых протоколов. Cуществуют сотни разных типов терминалов. Если мы захотим создать сетевой экранный редактор, то нам придется прописывать для каждого типа терминала свою версию.
Есть другой путь: определить сетевой виртуальный терминал и написать для него редактор. Для каждого типа терминала написать программу отображения этого терминала на сетевой виртуальный терминал. Все программное обеспечение для виртуального сетевого терминала расположено на уровне приложений.
На рисунке 1-14 показана последовательность действий при передаче данных в МОС-модели. Хотя данные движутся вертикально, каждый уровень предполагает их горизонтальное передвижение.
Рисунок 1-14. Пример передачи данных в модели МОС
Эталонная модель TCP/IP.
Здесь мы рассмотрим другую эталонную модель, прототипом для которой послужил прародитель всех компьютерных сетей - сеть ARPA.
С самого начала эта сеть задумывалась как объединение нескольких разных сетей. Одной из основных целей этого проекта было разработать унифицированные способы соединения сетей. С появлением спутниковых и радио цифровых каналов связи проблема становилась только актуальнее. Так появилась модель TCP/IP. Свое название она получила по именам двух основных протоколов: TCP - протокол управления передачей (Transmission Control Protocol), и IP - межсетевой протокол (Internet Protocol).
Другой целью проекта ARPA было создание протоколов, не зависящих от характеристик конкретных хост-машин, маршрутизаторов, шлюзов и т.п. Кроме этого, связь должна поддерживаться, даже если отдельные компоненты сети будут выходить из строя во время соединения. Другими словами, связь должна поддерживаться до тех пор, пока источник информации и получатель информации работоспособны. Архитектура сети не должна ограничивать приложения, начиная от простой передачи файлов до передачи речи и изображения в реальном времени.
В силу вышеперечисленных требований выбор организации транспортной среды был очевиден: сеть с коммутацией пакетов с межсетевым уровнем без соединений. Этот уровень называется межсетевым уровнем. Он является основой всей архитектуры. Его назначение - обеспечить доставку пакетов, движущихся в сети независимо друг от друга, даже если получатель принадлежит другой сети. Причем пакеты могут поступать к получателю не в том порядке, в котором они были посланы. Упорядочить их в надлежащем порядке - задача вышележащего уровня.
Межсетевой уровень определяет межсетевой протокол IP и формат пакета. Обратите внимание, что ни протокол, ни формат пакета не являются официальными международными стандартами, в отличие от протоколов эталонной модели МОС. Там большинство протоколов имеют статус международных стандартов.
Итак, назначение межсетевого уровня в TCP/IP - доставить IP-пакет по назначению. Это как раз то, за что отвечает сетевой уровень в МОС-модели. На рисунке 1-15 показано соответствие между уровнями этих двух эталонных моделей.
Рисунок 1-15. Соответствие между МОС и TCP/IP
Над межсетевым уровнем расположен транспортный уровень. Как и в МОС-модели, его задача - обеспечить связь «точка-точка» между двумя равнозначными активностями. В рамках TCP/IP модели было разработано два транспортных протокола. Первый - TCP (Transmission Control Protocol) - надежный протокол с соединением. Он получает поток байт, фрагментирует его на отдельные сообщения и передает их на межсетевой уровень. На машине-получателе равнозначная активность TCP-протокола собирает эти сообщения в поток байтов. TCP-протокол также обеспечивает управление потоком.
Второй протокол - UDP (User Datagram Protocol). Это ненадежный протокол без соединения для тех приложений, которые используют свои механизмы фрагментации и управления потоком. Он часто используется для передачи коротких сообщений в клиент-серверных приложениях, а также там, где скорость передачи важнее ее точности.
Над транспортным протоколом располагается уровень приложений. Этот уровень включает следующие приложения: виртуальный терминал - TELNET, передачу файлов - FTP, электронную почту - SMTP. Позднее к ним добавились: служба имен домена - DNS (Domain Name Service), отображающая логические имена хост-машин на их сетевые адреса, протокол для передачи новостей - NNTP и протокол для работы с гипертекстовыми документами во Всемирной паутине - HTTP.
Под межсетевым уровнем в TCP/IP-модели великая пустота. Модель ничего не говорит, что там происходит, кроме того, что хост-машина должна быть связана с сетью через некоторый протокол. Никаких ограничений на этот протокол, равно как и рекомендаций нет.
Сравнение моделей МОС и TCP/IP.
Обе модели имеют много общего. Обе имеют уровневую организацию, поддерживают понятие стека протоколов. Назначение их уровней примерно одинаково. Все уровни от транспортного и ниже используют протоколы для поддержки взаимодействия типа «точка-точка», не зависящего от организации сети. Все уровни выше транспортного ориентированы на приложения.
В модели МОС центральными являются три понятия:
-
сервис
-
интерфейс
-
протокол
Наибольшее методологическое значение этой модели - в четком выделении и разделении этих понятий.
Сервис определяет, что делает уровень, но ничего не говорит, как. Интерфейс уровня определяет для вышележащего уровня доступ к сервису. Протокол определяет реализацию сервиса.
В TCP/IP-модели нет столь же четкого выделения этих понятий. В ней понятие протокола четко «упрятано» и независимо от остальных частей модели. Этот факт есть следствие того, как создавались эти модели. TCP/IP-модель создавалась post factum, а МОС - до того, как появились протоколы. Поэтому понятие протокола там абсолютно не зависит от остальных частей модели. Например, изначально протоколы канального уровня в МОС-модели создавались для соединений «точка-точка». Позднее, когда появились средства типа вещания, на этот уровень были добавлены соответствующие протоколы. Никаких других изменений не последовало.
TCP/IP-модель была создана, когда TCP/IP-стек уже существовал. Поэтому эта модель прекрасно описывала этот стек, но только его, и никакой другой.
Модели имеют разное число уровней. Обе имеют уровень приложений, транспортный уровень и сетевой уровень. Все остальные уровни разные. МОС-модель поддерживает на сетевом уровне как сервис с соединением, так и без соединения. На транспортном уровне этой модели поддерживается сервис только с соединением. В TCP/IP наоборот: сетевой уровень обеспечивает сервис без соединения, но транспортный - как с соединением, так и без.
Недомтатки МОС:
-
Не вовремя.
-
Не технологичны.
-
Трудно реализуемы.
-
Неправильная стратегия.
«Не вовремя»: введение стандарта должно следовать за окончанием исследований, но прежде, чем начнутся крупные вложения в разработку.
Не технологичны:
-
Функциональность между семью уровнями распределена неравномерно.
-
МСО поспешило за IBM SNA (System Network Architecture).
-
Описание модели и ее протоколов очень сложно.
-
Некоторые функции, такие как управление потоком, исправление ошибок, адресация, повторяются на каждом уровне.
-
Для некоторых функций не ясно, на какой уровень их поместить (виртуальный терминал); шифрование и защита в модели отсутствуют.
-
Модель слишком ориентирована на сервис с соединениями и мало внимания уделяет сервису без соединений.
-
В модели доминирует связь, практически не отражена взаимосвязь между вычислениями и связью (indication vs. receive). В МОС-модели слушком велико влияние Международного комитета по телефонии и телеграфии (МКТТ).
Трудно реализуемы: первые реализации протоколов МОС были громоздки и неэффективны. Первые реализации TCP/IP были сделаны в университете Беркли в рамках проекта по созданию операционной системы UNIX.
Неправильная стратегия: модель МОС - результат усилий ЕС, европейских министерств и ведомств. Даже правительство США приложило руку. TCP/IP - плод академической среды. Распространение модели МОС шло через правительственные инстанции и государственные структуры, модели TCP/IP - через университеты и научные организации.
Недостатки эталонной модели TCP/IP:
-
В модели нет четкого разграничения понятий «сервис», «интерфейс», «протокол».
-
Модель годится только для описания стека TCP/IP.
-
Уровень «хост-сеть» по существу уровнем не является, это больше интерфейс.
-
В этой модели не разделяются физическая среда передачи и уровень канала данных.
Протоколы TCP и IP разработаны действительно тщательно и эффективно реализованы, чего нельзя сказать о многих других протоколах (протокол виртуального терминала, TELNET)















