Во-вторых, модель 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.

Сетевой уровень занимается объединением каналов связи в сети и интерсети для пересылки пакетов между удаленными компьютерами. Сюда входит поиск пути пересылки пакетов. Основной пример протокола этого уровня, который мы изучим далее, — IP. Транспортный уровень повышает предоставляемые сетевым уровнем гарантии доставки. Чаще всего это выражается в увеличении надежности и предоставлении абстракций доставки (например, надежного байтового потока), подходящих для нужд различных приложений. Важный пример протокола транспортного уровня — TCP.

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

Последовательность глав нашей книги основана на этой модели. Таким образом, мы не упускаем из виду значение модели OSI для понимания архитектур сетей, но в основном сосредоточиваемся на протоколах, играющих важную практическую роль, начиная с TCP/IP и заканчивая более новыми — 802.11, SONET и Bluetooth.

11 Или уровня представления. — Примеч. ред.

1.7. Стандартизация

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

1.7.1. Стандартизация и открытый исходный код

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

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

Стандарты описывают, что требуется для совместимости с другими продуктами — ни больше ни меньше. Это способствует расширению рынка и росту конкуренции между компаниями на основе качества программных продуктов. Например, стандарт 802.11 описывает несколько скоростей передачи данных. При этом он не указывает, при каких обстоятельствах отправитель должен использовать конкретную скорость, что является ключевым фактором для высокой производительности. Это решение отдается на откуп создателю продукта. Зачастую обеспечить совместимость при таком подходе непросто, ведь существуют разные стандарты, в которых описано множество способов реализации. Например, в случае 802.11 существует столько проблем, что отраслевая группа Wi-Fi Alliance приступила к работе над совместимостью внутри стандарта 802.11. Что касается программно-определяемых сетей, ONF (Open Networking Foundation) пытается разработать как стандарты, так и их реализации с открытым исходным кодом, чтобы гарантировать совместимость протоколов управления с программируемыми сетевыми коммутаторами.