TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
Когда несколько маршрутизируемых протоколов совместно используют одну виртуальную цепь (см. рис. 4.22), кадр AAL5 начинается с уже известных нам заголовков LLC и SNAP. Тип IP Ethernet заключается в подзаголовке SNAP (см. рис. 4.22).
Рис. 4.22. Для идентификации IP в ATM AAL используются LLC и SNAP.
Отметим, что кадр AAL5 не имеет в заголовке полей с адресами источника и назначения. Дело в том, что после вызова устанавливается виртуальная цепь от источника до точки назначения, а необходимая для коммутации в точке назначения информация находится в 5-октетном заголовке ячейки.
Заключительная
4.24 Максимальное число пересылаемых элементов
Каждая из рассмотренных нами технологий имеет различные максимальные размеры для своих кадров. После исключения заголовка кадра, заключительной части, а также заголовков LLC и SNAP (если они присутствуют), полученный результат будет определять максимально возможный размер датаграммы, которую можно переслать по носителю. Эта величина называется максимальным пересылаемым элементом (Maximum Transmission Unit — MTU).
Например, максимальный размер кадра для сети 802.3 10BASE5 равен 1518 октетам. Вычитая длину MAC-заголовка и завершающей части (18 октетов), поле управления связи Type 1 и заголовок SNAP (8 октетов), мы получим MTU, равный 1492 октетам.
В таблице 4.1 приведены MTU для различных технологий.
Таблица 4.1 Максимальный пересылаемый элемент
| Протокол | Максимальное количество октетов в датаграмме (MTU) |
|---|---|
| По умолчанию для PPP | 1500 |
| PPP (с небольшой задержкой) | 296 |
| SLIP | 1006 (исходное ограничение) |
| X.25 | 1600 (отличается для некоторых сетей) |
| Frame Relay | Обычно не менее 1600 |
| SMDS | 9235 |
| Ethernet версии 2 | 1500 |
| IEEE 802.3/802.2 | 1492 |
| IEEE 802.4/802.2 | 8166 |
| 16 Mb IBM Token-Ring | Максимально 17914 |
| IEEE 802.5/802.2 4-Mb Token-Ring | Максимально 4464 |
| FDDI | 4352 |
| Hyperchannel | 65535 |
| ATM | По умолчанию 9180 Максимально возможно 16K-1 |
Специальным случаем является линия "точка-точка". Она реально не наследует ограничений на размер датаграммы. Оптимальный размер зависит от уровня ошибок в данной линии связи. Если он высок, то лучшая производительность достигается при более коротких элементах данных. Максимальное значение по умолчанию в 1500 байт используется наиболее часто.
Первоначально протокол SLIP был специфицирован с максимальной длиной датаграммы в 1006 байт. Некоторые реализации могут поддерживать до 1500 байт, преобразуя SLIP в другие форматы пересылки данных по последовательной линии "точка-точка".
Для Token-Ring показано предельное значение MTU. Реально MTU для Token-Ring зависит от множества факторов, включая время удержания маркера в кольце.
4.25 Создание туннелей
Всегда придерживаться структуры деления на уровни —
Создание туннеля не представляет особых сложностей — просто вокруг элемента данных создается один или несколько дополнительных заголовков, маршрутизация выполняется средствами другого протокола, а извлечение полезной информации происходит в точке назначения.
Мы уже рассматривали применение туннеля. Когда датаграмма IP перемещается по сети X.25, она обрамляется заголовком сетевого уровня X.25. В этом случае трафик IP пересылается через туннель в среде X.25.
На практике применяется множество других вариантов использования туннелей. Иногда трафик IPX операционной системы Novell NetWare пересылается по туннелю в сети IP. Сообщения из NetWare обрамляются заголовками IP или UDP, маршрутизация производится в сети IP, а доставка выполняется на удаленный сервер NetWare. Многие разработчики предлагают продукты для пересылки по туннелю трафика SNA в сети IP.
Туннели всегда приводят к дополнительной нагрузке. Поскольку часть сетевого пути скрыта внутри внешнего протокола, использование туннеля сокращает возможности по управлению и обслуживанию в сети и часто создает дополнительный трафик, не имеющий отношения к пересылке полезной информации.
4.26 Совместное использование сетевого интерфейса
Как уже отмечалось, несложно найти локальные и региональные сети, использующие одновременно несколько протоколов. На практике один сетевой узел иногда посылает и принимает данные по нескольким протоколам через единый сетевой интерфейс.
Чтобы понять, как это происходит, рассмотрим конкретный интерфейс — локальную сеть Ethernet. Если персональный компьютер или сервер станут использовать интерфейс Ethernet для TCP/IP, IPX или DECnet, то как будут сосуществовать эти протоколы?
Мы уже знаем ответ на этот вопрос. Заголовок уровня связи данных содержит поле, идентифицирующее протокол сетевого уровня для конкретного сообщения.
На рис. 4.23 показан интерфейс Ethernet, совместно используемый стеками протоколов TCP/IP, IPX и DECnet. Посредничающий при выполнении операций программный уровень драйверов устройств скрывает действия по вводу/выводу от стеков протоколов более высокого уровня.
Рис. 4.23. Протоколы совместно используют сетевой интерфейс.
4.27 Замечания об уровне связи данных
Доля датаграмм, управляющих информацией, оказывает влияние на общую производительность. Разумеется, когда нужно переслать в сети большой объем данных, лучше заполнять датаграммы как можно плотнее.
Для разных типов сетей максимальные размеры датаграмм различны. В главе 6 мы познакомимся с предоставляемым в IP механизмом фрагментации — разделением больших датаграмм с последующей пересылкой в кадрах с датаграммами меньшего размера. Такая возможность обеспечивает доставку данных, даже если превышается используемый размер MTU. Однако можно предположить, что фрагментация и последующее воссоздание снижают время ответа сети.
Если пара взаимодействующих хостов подключена к одной и той же локальной сети, то желательно оптимизировать пересылку данных за счет использования максимально возможного размера датаграммы. Однако при работе с удаленным хостом через сеть неизвестного типа некоторые реализации принудительно используют меньшее значение для максимального размера датаграммы (иногда 576 октетов), чтобы избежать фрагментации.
Далее мы увидим, что процедура автоматического определения наибольшего размера датаграммы может выполняться для любого заданного пути пересылки данных (глава 7). Оптимизируя размер датаграмм, можно исключить фрагментацию и пересылать большие массивы данных более эффективно.