RFC 4413 — Поведение полей TCP/IP

Статус документа

В этом документе содержится информация для сообщества Internet. Документ не задает каких-либо стандартов Internet. Допускается свободное распространение документа.

Тезисы

В этом документе описано поведение полей TCP/IP в контексте сжатия заголовков. Такое сжатие возможно благодаря тому, что большинство полей заголовка незначительно отличается от пакета к пакету. Многие из полей являются статическими или меняются более или менее предсказуемо. При разработке схем компрессии заголовков весьма важно понимать поведение полей. Примером такого анализа может служить RFC 3095. Данный документ играет аналогичную роль для сжатия заголовков TCP/IP.

Оглавление

• 1. Введение
• 2. Общая классификация
• 2.1. Поля заголовка IP
• 2.1.1. Поля заголовка IPv6
• 2.1.2. Поля заголовка IPv4
• 2.2. Поля заголовка TCP
• 2.3. Общие размеры для IP/TCP
• 3. Классификация повторяющихся полей заголовков
• 3.1. Заголовок IPv4 (внутренний и/или внешний)
• 3.2. Заголовок IPv6 (внутренний и/или внешний)
• 3.3. Заголовок TCP
• 3.4. Опции TCP
• 3.5. Сводные данные по репликации
• 4. Анализ картины изменения полей заголовков
• 4.1. Заголовок IP
• 4.1.1. IP Traffic-Class / Type-Of-Service (TOS)
• 4.1.2. Флаги ECN
• 4.1.3. Идентификация IP
• 4.1.4. Флаг запрета фрагментации (DF)
• 4.1.5. IP Hop-Limit / Time-To-Live (TTL)
• 4.2. Заголовок TCP
• 4.2.1. Порядковый номер
• 4.2.2. Номер подтверждения
• 4.2.3. Резерв
• 4.2.4. Флаги
• 4.2.5. Контрольная сумма
• 4.2.6. Окно (Window)
• 4.2.7. Указатель срочности (Urgent)
• 4.3. Опции
• 4.3.1. Обзор опций
• 4.3.2. Поведение поля опций
• 5. Другие наблюдения
• 5.1. Неявные подтверждения
• 5.2. Совместно используемые данные
• 5.3. Доля заголовков TCP
• 5.4. Независимость полей и поведение пакетов
• 5.5. Короткоживущие потоки
• 5.6. Master Sequence Number
• 5.7. Ограничение размера опций TCP
• 6. Вопросы безопасности
• 7. Благодарности
• 8. Литература
• 8.1. Нормативные документы
• 8.2. Дополнительная литература

1. Введение

В этом документе описывается формат заголовков TCP/IP и поведение полей заголовка (т. е., изменение этих полей в потоке TCP). Описание приводится в контексте сжатия заголовков.

Поскольку поведение заголовков IP несколько отличается от описанного ранее в RFC 3095 [31] для протоколов UDP и RTP, эти заголовки также рассматриваются здесь.

Этот документ заимствует множество классификационных фрагментов из RFC 3095 вместо включения ссылок на этот документ.

Согласно формату, представленному в RFC 3095 [31], поля заголовков TCP/IP классифицируются и анализируются в два этапа. Сначала мы проводим общую классификацию (глава 2), в которой поля подразделяются на основе установившихся сведений и допущений. Эта общая классификация не принимает во внимание изменение характеристик полей, в той или иной степени зависящее от реализации или используемого приложения. В главе 3 рассматривается вопрос использования значений полей для оптимизации короткоживущих потоков. Более детальный анализ изменения характеристик приводится в главе 4. В заключение глава 5 описывает обработку полей заголовков с учетом их оптимального сжатия.

Основным вопросом является определение базы для рассмотрения имеющихся реализаций TCP/IP. Этот обзор основан на анализе развернутых в настоящее время реализаций TCP, которые поддерживают стандартизованные IETF механизмы.

Представляют интерес также общеие требования в части прозрачности. Множество предложенных недавно расширений TCP используют ранее зарезервированные биты полей в заголовках TCP. Следовательно, не следует полагаться на то, что зарезервированные биты имеют нулевые значения — они могут изменяться. В идеальном варианте схема компрессии должна принимать это во внимание.

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