Шрифт:
Закладка:
Вследствие опасений Пентагона потерять в один миг часть своих драгоценных хостов, маршрутизаторов и межсетевых шлюзов в результате атаки Советского Союза, была поставлена еще одна важная цель. Сеть должна продолжать нормальную работу, без разрыва текущих разговоров, даже в случае потери аппаратного обеспечения подсети. Другими словами, Пентагон хотел, чтобы соединения поддерживались до тех пор, пока работают отправляющее и целевое устройства, даже если некоторые узлы или линии передачи между ними внезапно вышли из строя. Более того, архитектура должна была быть гибкой, поскольку предполагалось использование приложений с нестандартными требованиями, от передачи файлов до передачи голоса в режиме реального времени.
Канальный уровень
С учетом этих требований была выбрана сеть с коммутацией пакетов, основанная на уровне без соединений, работающем в различных сетях. Низший уровень модели, канальный уровень (link layer), описывает, какими должны быть каналы связи (например, последовательные линии связи и традиционный Ethernet) для удовлетворения потребностей межсетевого уровня без соединений. На самом деле это даже не уровень в обычном смысле этого слова, а скорее интерфейс между хостами и линиями передачи. В первых описаниях модели TCP/IP он игнорировался.
Межсетевой уровень
Межсетевой уровень (internet layer) — краеугольный камень всей архитектуры. Он показан на илл. 1.33. Его задача — сделать так, чтобы хосты могли внедрять пакеты в произвольную сеть для последующего движения к пункту назначения (возможно, расположенного в другой сети) независимо друг от друга. Эти пакеты даже могут прибывать совершенно не в том порядке, в каком они были отправлены. Если необходимо соблюдение очередности, высшие уровни должны упорядочить пакеты.
Здесь можно провести аналогию с обычной почтой. Бросаем пачку международных писем в почтовый ящик в одной стране, и, если повезет, большинство из них попадут по нужным адресам в стране назначения. Скорее всего, эти письма
Илл. 1.33. Эталонная модель TCP/IP
по дороге пройдут через один или несколько международных сортировочных центров, но пользователи об этом не узнают. Более того, от пользователей скрыт тот факт, что в каждой стране (то есть сети) свои почтовые марки, размеры конвертов и правила доставки.
Межсетевой уровень определяет официальный формат пакетов, IP (Internet Protocol — межсетевой протокол), а также вспомогательный протокол ICMP (Internet Control Message Protocol — протокол управления межсетевым обменом сообщениями). Задача межсетевого уровня заключается в доставке IP-пакетов по месту назначения. Главная проблема состоит в маршрутизации пакетов, а также в контроле перегруженности сети. Задача маршрутизации в основном уже решена, но справиться с перегруженностью нельзя без помощи вышележащих уровней.
Транспортный уровень
Непосредственно над межсетевым уровнем в модели TCP/IP располагается уровень, обычно называемый транспортным (transport layer). Он был создан для обеспечения связи объектов одного ранга, расположенных на разных хостах, аналогично транспортному уровню OSI. В нем определено два сквозных транспортных протокола. Первый, TCP (Transmission Control Protocol — протокол управления передачей данных), — надежный, ориентированный на установление соединения протокол, с помощью которого можно доставить без ошибок байтовый поток с одного компьютера на любой другой. Он разбивает входящий поток на отдельные сообщения и передает их по одному в межсетевой уровень. В пункте назначения получающий TCP-процесс собирает полученные сообщения в выходной поток. TCP также управляет движением данных, чтобы быстрый отправитель не перегрузил медленного получателя чрезмерным числом сообщений.
Второй протокол этого уровня, UDP (User Datagram Protocol — протокол пользовательских дейтаграмм), представляет собой ненадежный протокол без соединений. Он предназначен для приложений, которым не требуется TCP для разбиения на сообщения и управления потоками; они выполняют данную задачу сами (или обходятся без этого). UDP также широко применяется для однократных клиент-серверных запросов и приложений, работающих по принципу «запрос/ответ». Для таких приложений важнее быстрота доставки, чем ее точность, например, в случае передачи голоса или видео. Взаимосвязи IP, TCP и UDP приведены на илл. 1.34. IP был реализован во множестве сетей с момента разработки модели TCP/IP.
Илл. 1.34. Модели TCP/IP и некоторые протоколы, которые мы изучим позднее
Прикладной уровень
В модели TCP/IP нет сеансового и представительского11 уровней — в них нет необходимости. Вместо этого приложения просто включают все необходимые для них функции, связанные с сеансами или представлением. Опыт доказал правильность такого подхода: эти уровни бесполезны для большинства приложений; в результате они практически исчезли.
Над транспортным уровнем располагается прикладной уровень (application layer), он же уровень приложений. Он включает все высокоуровневые протоколы. Самые первые протоколы подобного рода — протокол виртуального терминала TELNET (Teletype network), протокол передачи файлов FTP (File transfer protocol) и протокол электронной почты SMTP (Simple mail transfer protocol). В дальнейшем к ним добавилось множество других. Наиболее важные протоколы (приведенные на илл. 1.34) мы рассмотрим далее. В их числе система доменных имен, DNS (Domain Name System), предназначенная для установления соответствий между именами хостов и их сетевыми адресами; HTTP (Hypertext transfer protocol), протокол для получения страниц из Всемирной паутины, и RTP (Real-time transport protocol), протокол доставки мультимедиа (например, голоса или фильмов) в режиме реального времени.
1.6.3. Критика модели и протоколов OSI
Ни модель OSI, ни модель TCP/IP с их протоколами не являются идеальными. Обе они нередко подвергались критике. В этом и следующем разделах рассмотрены некоторые из этих критических замечаний. Мы начнем с OSI, а затем поговорим о TCP/IP.
На момент выхода в печать второго издания данной книги (1989 год) многим экспертам в сфере сетевых технологий представлялось, что будущее — за моделью OSI и ее протоколами, а все остальное обречено на забвение. Но все обернулось иначе. Почему? Имеет смысл проанализировать причины, по которым OSI не стала успешной. Их можно резюмировать так: неподходящий момент времени, плохая архитектура, неудачная реализация и неудачная политика.
Неподходящий момент времени
Рассмотрим первую причину: неподходящий момент времени. Для успеха стандарта время его принятия играет критическую роль. Дэвид Кларк (David Clark) из MIT разработал теорию стандартов, которую он назвал «апокалипсис двух слонов» (илл. 1.35).
Илл. 1.35. «Апокалипсис двух слонов»
На этом графике отражена активность, сопутствующая любой новой разработке. Возникновение новой темы приводит к колоссальному взрыву исследовательской деятельности в виде научных работ, обсуждений, статей и конференций. Через какое-то время ажиотаж понемногу угасает, однако разработку замечают крупные корпорации, и в нее вливаются миллиардные
