TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
6.13.2 Поля назначения, поле источника и поле протокола
Наиболее важными полями заголовка являются: Destination IP Address (IP-адрес назначения), Source IP Address (IP-адрес источника) и Protocol (протокол).
IP-адрес назначения позволяет маршрутизировать датаграмму. Как только она достигает точки назначения, поле протокола позволяет доставить ее в требуемую службу, подобную TCP или UDP, Кроме TCP и UDP, существует еще несколько протоколов, способных посылать и получать датаграммы. Организация IANA отвечает за координацию присваивания значений параметрам TCP/IP, включая значения в поле протокола. Некоторые значения из этого поля имеют лицензионный, специфичный для конкретного производителя смысл.
В таблице 6.1 показаны наиболее распространенные значения из поля
Таблица 6.1 Общепринятые номера из поля протокола заголовка IP
| Номер | Название | Протокол | Описание |
|---|---|---|---|
| 1 | ICMP | Internet Control Message Protocol | Переносит сообщения об ошибках и поддерживает отдельные сетевые утилиты |
| 2 | IGMP | Internet Group Management Protocol | Обеспечивает группы для многоадресных рассылок |
| 6 | TCP | Transmission Control Protocol | Обслуживает сеансы |
| 8 | EGP | Exterior Gateway Protocol | Устаревший протокол для маршрутизации во внешней сети |
| 17 | UDP | User Datagram Protocol | Обслуживает доставку независимых блоков данных |
| 88 | IGRP | Interior Gateway Routing Protocol | Обеспечивает взаимный обмен информацией о маршрутизации между маршрутизаторами компании Cisco |
6.13.3 Версия, длина заголовка и длина датаграммы
В настоящее время используется четвертая версия IP (версия "Следующее поколение" имеет номер 6).
Длина заголовка измеряется в 32-разрядных словах. Если не нужны дополнительные варианты, можно ограничиться длиной заголовка в 5 слов (т.е. 20 октетов). Если задействованы один или больше дополнительных вариантов, может потребоваться заполнить конец заголовка незначащими нулями до границы 32-разрядного слова.
Поле длины датаграммы определяет размер датаграммы в октетах. В это значение включается как заголовок, так и часть данных датаграммы. В таком 16-разрядном поле можно указывать значения до 216– 1 октет = 65 535 октетов.
Сетевые технологии — не единственная причина ограничений на размер датаграмм. Различные типы компьютеров, поддерживающих IP, имеют разные ограничения, связанные с размером буферов памяти, используемых для сетевого трафика (стандарт IP требует, чтобы все хосты были способны принимать датаграммы не менее чем из 576 октетов).
6.13.4 Приоритет и тип обслуживания
Первоначальным спонсором набора протоколов TCP/IP было Министерство обороны США, для которого было важно задание приоритетов датаграмм. Приоритеты мало используются вне военных и правительственных организаций. Для приоритета предназначены 3 бита, обеспечивающие 8 различных уровней.
Стандарт IP не регламентирует действия с битами приоритета. Первоначально они предназначались для установки параметров подсетей, которые будет пересекать датаграмма при следующем попадании. Например, на основе битов приоритета управляется протокол Token-Ring. В этом случае IP должен отображать биты приоритета в соответствующие уровни Token-Ring.
Тип обслуживания (Type of Service — TOS) содержит биты, определяющие качество обслуживания информации, которое может повлиять на обработку датаграмм. Например, когда маршрутизатору не хватает памяти, он вынужден отклонять некоторые датаграммы. Он мог бы рассматривать только датаграммы, у которых бит надежности установлен в единицу, и отбрасывать датаграммы с нулевым битом надежности.
Положение приоритета и типа обслуживания:
| Биты | Тип | Описание |
|---|---|---|
| 0-2 | Приоритет | Уровни 0-7 |
| Уровень 0 — обычный приоритет | ||
| Уровень 7 — самый высокий приоритет | ||
| 3-6 | TOS | Задержка, надежность, пропускная способность, стоимость или безопасность |
| 7 | Зарезервировано для будущего использования |
Тип обслуживания определяет (как описано в текущем документе Assigned Numbers) значения, приведенные в таблице 6.2. Это взаимоисключающие значения — для любой IP-датаграммы требуется только одно значение TOS. Стандарт Assigned Numbers рекомендует использовать специальные значения для каждого из приложений. Например для telnet — минимизировать задержку, для копирования файлов — максимизировать производительность и надежность при доставке управляющих сетевых сообщений.
Таблица 6.2 Значения поля типа обслуживания (TOS)
| Значение TOS | Описание |
|---|---|
| 0000 | По умолчанию |
| 0001 | Минимизировать денежную стоимость |
| 0010 | Максимизировать надежность |
| 0100 | Максимизировать производительность |
| 1000 | Минимизировать задержку |
| 1111 | Максимизировать безопасность |
Некоторые маршрутизаторы полностью игнорируют поле типа обслуживания, в то время как другие могут использовать его при выборе трафика, который следует предохранить на случай недостатка оперативной памяти. Можно надеяться, что в будущем поле типа обслуживания будет играть гораздо большую роль. Рекомендуемые в документе Assigned Numbers значения представлены в таблице 6.3.
Таблица 6.3 Рекомендуемые значения поля типа обслуживания
| Протокол | Значение TOS | Описание |
|---|---|---|
| Telnet и другие протоколы для регистрации | 1000 | Минимизировать задержку |
| Управляющий сеанс FTP | 1000 | Минимизировать задержку |
| Сеанс FTP по пересылке данных | 0100 | Максимизировать производительность |
| TFTP | 1000 | Минимизировать задержку |
| Фаза команд SMTP | 1000 | Минимизировать задержку |
| Фаза данных SMTP | 0100 | Максимизировать производительность |
| Запрос DNS к UDP | 1000 | Минимизировать задержку |
| Запрос DNS к TCP | 0000 | Без специального управления |
| Преобразование зон в DNS | 0100 | Максимизировать производительность |
| NNTP | 0001 | Минимизировать денежную стоимость |
| Ошибки ICMP | 0000 | Без специального управления |
| Запросы ICMP | 0000 | Обычно 0000, но иногда посылаются с другим значением |
| Ответы ICMP | То же, что и у запроса, для которого формируется ответ | |
| Любые IGP | 0010 | Максимизировать надежность |
| EGP | 0000 | Без специального управления |
| SNMP | 0010 | Максимизировать надежность |
| BOOTP | 0000 | Без специального управления |
6.13.5 Поле времени жизни
Когда в интернет-системе IP происходит изменение топологии, например обрыв связи или инициализация нового маршрутизатора, некоторые датаграммы могут сбиться со своего маршрута за тот короткий период времени, пока не будет выбран новый маршрутизатор.
Более серьезные проблемы возникают из-за ошибок при ручном вводе информации о маршрутизации. Такие ошибки могут привести к потере датаграммы или зацикливанию ее по круговому маршруту на длительное время.
Поле времени жизни (Time-To-Live — TTL) ограничивает время присутствия датаграммы в интернете. TTL устанавливается хостом-отправителем и уменьшается каждым маршрутизатором, через который проходит датаграмма. Если датаграмма не достигает пункта назначения, а ее поле TTL становиться нулевым, она отбрасывается.