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

Второй протокол этого уровня, 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 не появилось.

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