Компьютерные сети. 6-е изд.

Непосредственно над межсетевым уровнем в модели 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. «Апокалипсис двух слонов»

На этом графике отражена активность, сопутствующая любой новой разработке. Возникновение новой темы приводит к колоссальному взрыву исследовательской деятельности в виде научных работ, обсуждений, статей и конференций. Через какое-то время ажиотаж понемногу угасает, однако разработку замечают крупные корпорации, и в нее вливаются миллиардные инвестиции.

Стандарты должны быть написаны в «углублении» между двумя «слонами». Если они создаются слишком рано (до появления общепризнанных результатов исследований), то вопрос, скорее всего, еще недостаточно изучен; в результате получается плохой стандарт. Если же слишком поздно, то к тому моменту множество компаний уже инвестируют огромные средства в свои варианты, так что стандарты будут просто проигнорированы. Если промежуток между слонами слишком мал (поскольку все торопятся начать эксплуатацию), то они могут «раздавить» создателей стандартов.

Похоже, что стандартные протоколы OSI действительно оказались «раздавлены». К моменту появления протоколов OSI конкурирующие с ними протоколы TCP/IP уже широко использовались университетами. И хотя миллиардная волна инвестиций еще не пришла, академический рынок оказался достаточно обширным для того, чтобы многие компании начали осторожно предлагать продукты на TCP/IP. Когда же появилась модель OSI, никто не хотел поддерживать второй стек протоколов (разве что принудительно), так что на рынке не возникло никаких первоначальных предложений. Все компании ждали, пока кто-нибудь сделает первый шаг в этом направлении, но этого так и не произошло, и поддержки OSI не появилось.

Плохая архитектура

Вторая причина того, что OSI так и не завоевала популярность: и модель, и ее протоколы несовершенны по своей сути. Выбор семи уровней носил скорее политический, а не технический характер. Два уровня (сеансовый и уровень представления) были практически пусты, в то время как два других (сетевой и уровень передачи данных) были переполнены.

Модель OSI, вместе с соответствующими определениями служб и протоколами, чрезвычайно сложна. В распечатанном виде стандарты представляют собой стопку бумаги высотой почти в метр. Плюс еще сложность реализации и неэффективность эксплуатации. В этой связи вспоминается загадка, придуманная Полом Мокапетрисом (Paul Mockapetris), цитируемая в работе Роуза (Rose, 1993):

Вопрос: Что получится, если скрестить гангстера с международным стандартом?

Ответ: Человек, делающий вам предложение, которое вы не способны понять.

Еще одна проблема OSI, помимо сложности, состоит в том, что некоторые функции (например, адресация, управление потоком и обработка ошибок) встречаются на всех уровнях модели. Зальцер и др. (Saltzer et al., 1984) отмечают, что эффективная обработка ошибок должна производиться на самом верхнем уровне, так что повторять ее на каждом из нижних уровней не нужно, к тому же это бесполезно.

Неудачная реализация

Учитывая запредельную сложность модели и ее протоколов, ничего удивительного, что первые реализации были громоздкими и медленными. Все, кто пробовал с ними работать, потерпели неудачу. Очень скоро понятие «OSI» стало ассоциироваться у всех с плохим качеством. И хотя реализация со временем улучшилась, образ закрепился. Стоит людям решить, что продукт неудачный, его песенка спета.

И напротив, одна из первых реализаций TCP/IP в составе Berkeley UNIX была довольно неплохой (и к тому же бесплатной). Она быстро вошла в употребление, и в результате образовалось большое пользовательское сообщество. Это влекло за собой совершенствование продукта, что, в свою очередь, приводило к дальнейшему расширению сообщества. В случае с OSI все было иначе.

Неудачная политика

Благодаря первой реализации многие люди, особенно в академической среде, считали TCP/IP частью Unix, а к Unix в 1980-х в университетах испытывали нечто среднее между родительскими чувствами и любовью к яблочному пирогу.

OSI, напротив, многими считался детищем европейских министерств телекоммуникаций, Европейского сообщества и позднее правительства США. Эти убеждения имели под собой основания лишь частично. Однако сама идея навязывания правительственными бюрократами второсортного стандарта несчастным исследователям и программистам, в поте лица разрабатывающим сети, не слишком помогала продвижению OSI. Некоторые даже провели аналогию с ситуацией вокруг языка программирования ПЛ/1. В 1960-х IBM назвала ПЛ/1 языком будущего, однако позднее Пентагон объявил, что им станет Ada.

1.6.4. Критика модели и протоколов TCP/IP

У модели и протоколов TCP/IP тоже есть свои проблемы. Во-первых, в этой модели нет достаточно явного разграничения понятий служб, интерфейсов и протоколов. Рекомендуемые практики разработки ПО требуют четко различать спецификацию и реализацию, что модель OSI делает очень тщательно, а TCP/IP — нет. Вследствие этого модель TCP/IP не может применяться в качестве основы для проектирования сетей с применением новых технологий.

Во-вторых, модель TCP/IP не слишком универсальна и не подходит для описания любых других стеков протоколов, кроме TCP/IP. Например, описать Bluetooth с помощью модели TCP/IP невозможно.

В-третьих, канальный уровень вообще не является уровнем в обычном понимании этого термина в контексте многоуровневых протоколов. Это интерфейс (между сетевым и уровнем передачи данных). Различие между интерфейсом и уровнем критически важно, небрежности тут недопустимы.

В-четвертых, в TCP/IP не различаются физический уровень и уровень передачи данных. Между тем они представляют собой совершенно разные вещи. Физический уровень связан с характеристиками передачи информации по медному кабелю, оптоволокну или беспроводными средствами. Задача уровня передачи данных состоит в определении начала и конца фреймов (или кадров) и отправка их с одной стороны на другую с надлежащей степенью надежности. Корректная модель должна содержать оба упомянутых уровня по отдельности. В случае с TCP/IP это не так.

И последнее. IP и TCP были тщательно продуманы и хорошо реализованы. При этом многие ранние протоколы зачастую были сделаны на скорую руку парой аспирантов, работавших до изнеможения. Реализации протоколов тогда распространялись бесплатно — это привело к их повсеместному использованию и глубокому внедрению в повседневную практику. В результате они плохо поддаются замене. Сегодня некоторые из них выглядят как сущее недоразумение. Например, протокол виртуального терминала, TELNET, был разработан для механического терминала Teletype, рассчитанного на 10 символов в секунду. Ему неведомы графические интерфейсы и мышь. Тем не менее 53 года спустя его все еще используют.

1.6.5. Модель, используемая в этой книге

Как уже упоминалось ранее, сильная сторона эталонной модели OSI — сама модель (за вычетом сеансового уровня и уровня представления), оказавшаяся исключительно удобной для описания сетей. И напротив, сильная сторона эталонной модели TCP/IP — протоколы, повсеместно используемые на протяжении многих лет. В данной книге мы будем применять гибридную модель, чтобы совместить эти преимущества (илл. 1.36).

5

Прикладной

4

Транспортный

3

Сетевой

2

Канальный

1

Физический

Илл. 1.36. Эталонная модель, используемая в этой книге

Эта модель состоит из пяти уровней: физического, канального, сетевого, транспортного и, наконец, прикладного. Физический уровень определяет способ передачи битов по различным средам в виде электрических (или прочих аналоговых) сигналов. Канальный уровень имеет дело с пересылкой сообщений конечной длины между непосредственно соединенными устройствами с заданной степенью надежности. Примеры протоколов канального уровня — Ethernet и 802.11.