В конце 60-х гг. Агентство перспективных исследовательских проектов (Advanced Research Project Agency — ARPA) Министерства обороны США (позднее переименованное в DARPA) начало сотрудничать с университетами и другими исследовательскими организациями в области новых технологий обмена данными.

Все эти организации совместно разработали Сеть агентства перспективных исследовательских проектов (Advanced Research Project Agency Network — ARPANET), первую сеть с коммутацией пакетов. Экспериментальный вариант этой сети из четырех узлов был запущен в эксплуатацию в 1969 г. Реализация прошла успешно, а ее возможности были протестированы на сети, протянувшейся через всю территорию США. В 1975 г. Агентство оборонных коммуникаций взяло на себя ответственность за эксплуатацию созданной сети, которая все еще рассматривалась как экспериментальный вариант.

 

1.1.1 Зарождение TCP/IP

Первые протоколы ARPANET работали медленно и часто приводили к краху сетевых коммуникаций. В статье Винтона Г. Серфа и Роберта Е. Кана A Protocol for Packet Network Interconnections (журнал IEEE Transactions of Communications, май 1974 г.) был предложен новый набор основных протоколов. В этой работе были заложены основы для последующей разработки протокола Интернета (IP) и протокола управления передачей (TCP). Начиная с 1980 г., потребовалось около трех лет для преобразования хостов ARPANET на новые протоколы (число хостов к тому времени приближалось к 100).

Возможности новых протоколов были продемонстрированы в 1978 г., когда терминал, расположенный на движущемся по Калифорнии автофургоне, переслал данные, сформированные в пакеты, на узел SRI International через всю территорию США и далее по спутниковой связи на хост в Лондоне (см. рис. 1.1).

Рис. 1.1. Демонстрация роботы TCP/IP с использованием нескольких различных сетевых технологий

В начале 80-х гг. ARPANET была полностью переделана на новые протоколы. К 1983 г. эта сеть содержала уже более 300 узлов и предоставляла своим пользователям обширные ресурсы. В 1984 г. исходная сеть ARPANET была разделена на две отдельные сети: первая, сохранившая исходное название, предназначалась для исследований и новых разработок, вторая — названная MILNET — стала неклассифицированной сетью для военных целей.

В начале 80-х гг. ARPANET была полностью переделана на новые протоколы. К 1983 г. эта сеть содержала уже более 300 узлов и предоставляла своим пользователям обширные ресурсы. В 1984 г. исходная сеть ARPANET была разделена на две отдельные сети: первая, сохранившая исходное название, предназначалась для исследований и новых разработок, вторая — названная MILNET — стала неклассифицированной сетью для военных целей.

 

TCP/IP обладает уникальными характеристиками, которые обеспечивают долговечность этих протоколов. Архитектура TCP/IP позволяет объединять сетевые кластеры, формируя то, что называется "интернетом". Для пользователя интернет выглядит как одна большая сеть, сформированная из всех хостов, подключенных к отдельным сетевым кластерам.

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

 

1.3.1 Доступность TCP/IP

Когда наличие TCP/IP стало обязательным требованием для всех компьютеров, закупаемых Министерством обороны США, разработчикам пришлось заняться реализацией TCP/IP для обеспечения условий правительственных поставок. На рис. 1.2 показано, как с помощью TCP/IP могут взаимодействовать различные системы, локальные и региональные сети.

Рис. 1.2. TCP/IP — окружение для оборудования от различных производителей и различных сетей

Министерство обороны США обеспечило доступность TCP/IP, реализовав эти протоколы в Unix (по именам разработчиков — BBN — Bolt, Beranek, Newman). Далее Калифорнийский университет в Беркли использовал код BBN в операционной системе Berkeley Software Distribution (BSD) версии 4.2 (одна из разновидностей UNIX). Эта операционная система и ее более поздние версии были реализованы на многих аппаратных базах. Позднее TCP/IP был добавлен и в System V Unix компании AT&T.

В 90-х гг. TCP/IP начали использоваться в коммерческих программных продуктах и стали наиболее универсальными протоколами из доступных на рынке. Процесс интеграции протоколов TCP/IP в серверы и настольные системы был поистине стремительным.

Кроме того, поддержка TCP/IP реализована практически во всех сетевых технологиях (см. главу 4).

 

Разработка новых протоколов TCP/IP и обслуживание старых координируется Советом по архитектуре Интернета (Internet Architecture Board — IAB, который ранее назывался Internet Activities Board). IAB идентифицировал техническую специализацию новых средств. Например, в прошлом IAB направлял исследовательские работы по созданию новых протоколов сетевого управления, более функциональных протоколов маршрутизации и следующих версий IP.

В 1992 г. была сформирована Ассоциация Интернета (Internet Society), в которую и вошла IAB. Целью Internet Society является помощь в расширении и обеспечении успешной работы Интернета.

IAB контролировала несколько важных групп: рабочую группу технологии Интернета (Internet Engineering Task Force — IETF), которая разрабатывает и реализует новые протоколы, управляющую группу технологии Интернета (Internet Engineering Steering Group — IESG), которая осуществляет руководство и контроль за деятельностью IETF.

 

1.6.1 Рабочие группы и разработка протоколов

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

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

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

 

1.6.2 Другие источники протоколов Интернета

Хотя большинство протоколов TCP/IP разрабатывается и реализуется рабочими группами IETF, существенное участие в этом процессе принимают исследовательские группы из университетов и коммерческих организаций. Чтобы независимые проекты получили одобрение, они должны быть и пригодны, и полезны.

Исходные коды новых протоколов часто помещаются в общедоступные базы данных Интернета. Разработчики могут использовать эти коды как отправную точку в своих собственных реализациях. Такой метод имеет множество преимуществ. Прежде всего, снижается стоимость разработки и время ее проведения. Одинаковые исходные коды позволяют также достичь согласования в работе продуктов от различных разработчиков.

Пользователи могут копировать и устанавливать исходные коды протоколов на свои системы. Разумеется, применение бесплатных программных продуктов не предусматривает технической поддержки и обслуживания, предоставляемых разработчиками для коммерческих реализаций.

 

Спецификации новых протоколов распространяются в документах, называемых запросами комментариев (Requests For Comments — RFC). Все документы RFC имеют последовательные номера. На сегодняшний день существует уже более тысячи таких документов.

Пользователи могут получить RFC в службе каталогов и баз данных InterNIC. Кроме того, эти документы существуют на множестве общедоступных сайтов по всему миру, поскольку разрешено их свободное копирование между любыми сайтами Интернета посредством пересылки файлов.

Иногда спецификации протоколов подвергаются изменениям, например вследствие исправления обнаруженных ошибок, а также для повышения производительности или добавления новых возможностей. Измененные протоколы публикуются в RFC с новыми номерами.

InterNIC обслуживает индексы для RFC, а для устаревших документов предоставляется номер заменяющего RFC. Например, индекс для RFC 1098 (стандарт SNMP) содержит ссылки на устаревший документ RFC (1067) и пополняющий RFC 1098 документ с номером 1157:

1098 Case, J.D.; Fedor, М.; Schoffstall, M.L.; Davin, С.

Simple Network Management Protocol (SNMP). 1989 April; 34p.

(Format: TXT=71563 bytes) (Obsoletes RFC 1067; Updated by RFC 1157)

He все RFC описывают протоколы. Некоторые из них служат для систематизации и описания сведений, используемых в Интернете. Существует RFC с рекомендациями по выбору имен для компьютеров. Другой RFC содержит руководство по администрированию сетей TCP/IP и реализации в них средств безопасности. Имеются RFC, описывающие стратегии повышения производительности, экспериментальные алгоритмы или обсуждающие этические вопросы Интернета. После пересмотра некоторые RFC получают статус документов Best Current Practices — BCP (описание лучшего текущего способа применения).

 

1.7.1 Состояние и статус стандартов

IAB периодически публикует информацию о работе над протоколами. Стадии разработки определяют текущее состояние протокола:

■ Experimental (экспериментальный)

■ Proposed (предлагаемый)

■ Draft (черновик)

■ Standard (стандарт)

Некоторые протоколы маркируются как информационные (informational), другие, не использующиеся в настоящее время,— как исторические (historical).

Протоколы классифицируются также по уровню требований. Некоторые протоколы являются стандартами, другие применяются только в специальных целях. Отдельные протоколы утратили свою полезность, и их применение отменено. Формальные требования отражают статус протокола:

■ Required (требуется использовать)

■ Recommended (рекомендован к применению)

■ Elective (необязателен)

■ Limited Use (ограниченное использование)

■ Not recommended (не рекомендован к применению)

Текущий статус и состояние протоколов Интернета описываются в RFC, называемом IAB Official Protocol Standards (официальные стандарты протоколов IAB). Этот документ периодически изменяется, отражая изменение номеров RFC.

 

1.7.2 Присвоенные номера

Сетевые параметры, специальные сетевые адреса, имена служб и стандартные идентификаторы терминалов либо компьютерных систем перечислены в RFC с именем Assigned Numbers (присвоенные номера).

Присвоенные номера Интернета администрируются организацией авторизации присвоенных номеров (Internet Assigned Numbers Authority — IANA), расположенной в настоящее время в Институте информационных служб университета Южной Калифорнии.

Документ Assigned Numbers содержит почтовые адреса, номера телефонов и адреса электронной почты, которые разработчики протоколов могут использовать для регистрации информации об авторизации.

 

1.7.3 RFC и стимулирование сетевого взаимодействия продуктов различных производителей

То, что пользователи не должны придерживаться только одной компьютерной архитектуры, стало главной причиной одобрения TCP/IP в качестве коммуникационных стандартов правительственными учреждениями США. Эти организации желали покупать оборудование на рынке с реальной конкуренцией, когда предъявляемым требованиям удовлетворяет продукция различных разработчиков. Принятие и обслуживание стандартов должно было привести к снижению цен и лучшему качеству услуг.

Однако при использовании оборудования различных производителей возникает несколько проблем:

■ Стандарты часто содержат необязательные возможности. При реализации различными производителями это может усложнить взаимодействие.

■ Разработчики иногда не до конца понимают требования стандартов, вследствие чего их продукты работают не вполне корректно.

■ Возможны ошибки в спецификациях стандартов.

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

■ Отдельная система с неудовлетворительными характеристиками пересылки или приема/передачи данных (за счет использования неэффективных алгоритмов) может снизить производительность всех систем сети.

Два документа RFC (октябрь 1989 г.) были посвящены как указанным проблемам, так и коррекции ошибок, разъяснению определений, спецификации необязательных возможностей, перечислению конфигурационных параметров и идентификации наиболее производительных алгоритмов. Наиболее важно то, что в этих документах специфицируются единые требования к реализации хостов. В прошлом сказывалось отсутствие этих документов. Корректность операций, взаимодействие и производительность существенно улучшились при строгом соблюдении требований следующих RFC:

RFC 1122, Requirements for Internet Hosts — Communication Layers (Требования к хостам Интернета — уровни взаимодействия). В этом документе описывается уровень связи данных, IP и TCP.

RFC 1123, Requirements for Internet Hosts — Application and Support (Требования к хостам Интернета — приложения и их поддержка). Этот документ определяет удаленную регистрацию, пересылку файлов, электронную почту и различные прикладные службы.

В 1995 г. был опубликован документ, относящийся к операциям маршрутизаторов:

RFC 1812 Requirements for IP Version 4 Routers (Требования к маршрутизаторам для протокола IP версии 4).

 

1.7.4 Связанные документы

Серия RFC не содержит спецификаций протоколов и была опубликована как отдельный набор документов For Your Information (FYI — К вашему сведению). Например: RFC 1325 Answers to commonly asked "new Internet user" questions (Ответы на наиболее распространенные вопросы новых пользователей Интернета).

Еще одна серия, Internet Engineering Notes (IEN — Заметки по технологии Интернета), содержит набор дискуссионных материалов, написанных еще в первые годы разработки протоколов Интернета.