Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) Страница 17

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

4.26 Совместное использование сетевого интерфейса

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

Чтобы понять, как это происходит, рассмотрим конкретный интерфейс — локальную сеть Ethernet. Если персональный компьютер или сервер станут использовать интерфейс Ethernet для TCP/IP, IPX или DECnet, то как будут сосуществовать эти протоколы?

Мы уже знаем ответ на этот вопрос. Заголовок уровня связи данных содержит поле, идентифицирующее протокол сетевого уровня для конкретного сообщения.

На рис. 4.23 показан интерфейс Ethernet, совместно используемый стеками протоколов TCP/IP, IPX и DECnet. Посредничающий при выполнении операций программный уровень драйверов устройств скрывает действия по вводу/выводу от стеков протоколов более высокого уровня.

Рис. 4.23. Протоколы совместно используют сетевой интерфейс.

4.27 Замечания об уровне связи данных

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

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

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

Далее мы увидим, что процедура автоматического определения наибольшего размера датаграммы может выполняться для любого заданного пути пересылки данных (глава 7). Оптимизируя размер датаграмм, можно исключить фрагментацию и пересылать большие массивы данных более эффективно.

4.28 Завершающая часть кадра

Некоторые проблемы возникают при использовании нестандартных форматов протоколов из устаревших версий TCP/IP. Реализация BSD 4.2 предоставляет нестандартный формат для MAC-кадров Ethernet, в котором исключено поле типа кадра, а информация заголовков уровней 3 и 4 перемещена в завершающую часть кадра (trailer). Цель этой перестановки — ускорение обработки поступающих кадров за счет снижения количества копирования данных. Такая возможность реализуется в некоторых коммерческих продуктах.

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

4.29 Рекомендуемая литература

RFC 1661 описывает протокол PPP. Аутентификация в PPP рассматривается в RFC 1334, а автоматический мониторинг качества линии — в RFC 1333.

Существует несколько RFC, обсуждающих пересылку датаграмм IP поверх средств более низкого уровня: RFC 1356 для X.25, RFC 1490 для Frame Relay, RFC 1209 для SMDS, RFC 1390 для FDDI, RFC 1577, 1932, 1626 и 1755 для ATM, RFC 1088 для NetBIOS, RFC 1055 для SLIP, RFC 1042 для сетей IEEE 802, RFC 894 для Ethernet и RFC 1201 для ARCNET.

Сведения о HDLC можно найти в ISO 3309, 4335 и 7809. Серия IEEE 802 и ISO 8802 описывает физические носители, доступ к носителю, а также протоколы логических связей для локальных и городских сетей.

Рекомендации CCITT по X.25 можно обнаружить в "Красной книге" CCITT 1984 г. Существует несколько документов по стандартам для Frame Relay. Лучше всего начать с ANSI T1.606 и рекомендации CCITT 1.122.

RFC 893 обсуждает инкапсуляцию в завершающей части кадра.

Глава 5

Именование и адресация

5.1 Введение

Каждый сетевой узел должен иметь имя и адрес. Каким образом производится их присваивание? Для небольшой независимой локальной сети это не проблема, но если количество компьютеров составляет сотни или тысячи, выбор хорошей схемы для присваивания имен и адресов имеет большое значение, поскольку он позволит избежать неприятностей при удалении, добавлении или перемещении хостов и маршрутизаторов.

Администраторы Интернета сталкиваются с обслуживанием имен и адресов в огромной сети, размер которой ежегодно удваивается. Однако в Интернете выбрана удачная стратегия — делегирование полномочий.

Схема имен и адресов Интернета TCP/IP позволяет:

■ Делегировать присваивание имен и адресов тем, кто несет ответственность за работу всей или части отдельной сети

■ Позволить именам отражать логическую структуру организации

■ Присваивать адреса, отражающие топологию физической сети в организации

Далее мы увидим, что в Интернете применяется метод иерархического именования, позволяющий администратору создавать для систем описательные и простые в запоминании имена.

5.2 Примеры имен Интернета

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

blintz.med.yale.edu

couscous.med.yale.edu

gazpacho.med.yale.edu

lazagne.med.yale.edu

paella.med.yale.edu

sukiyaki.med.yale.edu

strudel.med.yale.edu

Серверам часто дают такие имена, чтобы пользователи могли легко их найти. Например:

www.whitehouse.gov (Белый дом — резиденция президента США. — Прим. пер.)

ftp.microsoft.com (ftp-сайт компании Microsoft. — Прим. пер.)

gopher.jvnc.net (служба Gopher. — Прим. пер.)

Имена сайтов (узлов) Интернета не зависят от регистра символов. Например, www.whitehouse.gov можно записать как WWW.WHITEHOUSE.GOV или WWW.Whitehouse.Gov. В книге мы будем использовать имена из строчных, прописных или из комбинации строчных и прописных символов.

5.3 Иерархическая структура имен

Иерархическая структура имен достаточно проста. Каждая организация имеет содержательное имя верхнего уровня, подобное yale.edu, whitehouse.gov или microsoft.com. Схему именования внутри этих имен организация выбирает самостоятельно. Например, в Йельском и во многих других университетах именование делегировано факультетам и подразделениям. Следовательно, появляются имена, заканчивающиеся на:

cs.yale.edu

math.yale.edu

geology.yale.edu

Некоторые подразделения университета создают дополнительные под-имена (имена более низкого уровня). Например, компьютеры вычислительного центра, расположенные в здании с неформальным прозвищем The Zoo (зоопарк), именуются по названиям различных животных:

lion.zoo.cs.yale.edu

leopard.zoo.cs.yale.edu

tiger.zoo.cs.yale.edu

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

hickory.theory.cs.yale.edu

pecan.theory.cs.yale.edu

olive.theory.cs.yale.edu

walnut.theory.cs.yale.edu

5.4 Администрирование имен

Использование иерархической структуры имен упрощает проверку уникальности имени компьютера, поскольку она возлагается на соответствующий персонал. Отметим следующее:

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